1. 平衡小车速度环的“隐形杀手”：正反馈到底怎么来的
平衡小车这个项目，十个做的人里有八个都卡在同一个坑上：直立环调得好好的，小车能站住了，一加速度环，车就开始往一个方向缓慢加速，越跑越快，最后直接冲出去撞墙。你以为是速度环参数没调好，于是拼命调PID，结果怎么调都不对——因为问题根本不在参数上，而是你的速度环极性搞反了，把负反馈接成了正反馈。
这个现象在圈子里太常见了，常见到几乎每个做过平衡小车的人都能讲出一段被它折磨的经历。我当初第一次做平衡小车的时候，也在这个问题上耗了整整两天，一度怀疑是陀螺仪漂移、电机死区、编码器精度的问题，最后才发现是速度环的输出符号搞反了。所以这篇文章，我想把正反馈这件事从头到尾讲清楚，包括它的原理、怎么判断、怎么修、以及怎么在代码层面避免再犯。
速度环在平衡小车里扮演的角色，是让小车在保持直立的同时，不会因为重心偏移而一直往一个方向跑。它的核心逻辑是：如果小车往前跑了，速度环就输出一个让小车往后倾的修正量，让小车减速回来。反过来，如果小车往后跑了，速度环就输出一个让小车往前倾的修正量。这个逻辑听起来很简单，但一旦符号搞反，速度环就变成了“加速器”——小车往前跑，速度环反而让它更往前倾，结果就是越跑越快，形成正反馈。
正反馈这个词在控制理论里是个贬义词，因为它意味着系统会自我放大偏差，最终失控。但在某些场景下，正反馈是有意为之的，比如振荡器、比较器里的迟滞环节。不过在平衡小车的速度环里，正反馈绝对是个bug，不是feature。它的本质是：你的修正方向和小车实际运动方向一致了，而不是相反。
PID控制器在这里的作用，是把速度偏差转换成倾角修正量。直立环负责让小车保持平衡，速度环负责让小车不跑偏。两者是串级关系：速度环的输出作为直立环的输入，直立环再输出给电机。这个串级结构决定了速度环的极性必须和直立环的极性匹配，否则就会出问题。
直立环的极性判断相对直观：小车往前倾，电机就得往前转，把轮子“追”到重心下面去。这个逻辑是符合直觉的。但速度环的极性就绕了一层：小车往前跑，速度环要输出一个“往后倾”的修正量，这个修正量再经过直立环，变成电机往后转的指令。如果你在代码里直接把速度环的输出加到直立环的输入上，而没有考虑符号，那就很容易搞反。
我见过很多教程在讲速度环的时候，只讲PID参数怎么调，不讲极性怎么判断，结果就是新手照着抄代码，参数调了半天，车还是往一边倒。其实判断速度环极性有个很简单的办法：用手把小车往前推，看轮子是往前转还是往后转。如果轮子往前转，说明速度环极性反了；如果轮子往后转，说明极性对了。这个测试不需要上车跑，静态就能判断。
还有一个更隐蔽的情况：速度环的极性在代码里是对的，但因为编码器的计数方向搞反了，导致实际效果还是正反馈。编码器计数方向反了，速度的符号就反了，速度环的输出符号也跟着反，结果就是极性又错了。所以判断速度环极性的时候，一定要先确认编码器计数方向是对的。怎么确认？用手往前推小车，看编码器读数是正还是负。如果往前推读数是负，那编码器方向就反了，得在代码里取反。
这个问题的根源在于，平衡小车的控制链路里有很多个符号环节：编码器计数方向、速度环输出符号、直立环输入符号、电机驱动方向。这些符号只要有一个搞反，整个系统就可能变成正反馈。而且这些符号之间是相互耦合的，你改了一个，可能另一个也得跟着改。所以最稳妥的办法是：先把直立环调好，确保小车能站住；然后单独测试速度环的极性，用手推的方法判断；最后再把速度环加进去，观察小车的反应。
我在实际调试中发现，速度环极性对了之后，小车的表现会有一个很明显的特征：你用手往前推小车，它会有一个“抵抗”的力，轮子会往后转，试图把你推的力抵消掉。如果你推得越快，它抵抗得越强，这就是负反馈在起作用。反过来，如果极性反了，你往前推，轮子也往前转，你会感觉小车在“配合”你推它，越推越顺，最后直接冲出去。
这个“抵抗感”是判断速度环极性最直观的体感。你不需要看波形，不需要算参数，用手推一下就能判断。我后来带新人的时候，第一件事就是让他用手推小车，感受这个抵抗感。感受对了，再上车调参数；感受不对，先修极性，别碰PID。
2. 从代码层面拆解速度环极性的判断与修正
2.1 速度环在串级PID里的位置和符号逻辑
平衡小车的控制结构通常是这样的：最外层是速度环，输入是编码器测到的实际速度，输出是期望的倾角修正量；中间层是直立环，输入是陀螺仪和加速度计融合得到的实际倾角，加上速度环输出的修正量，输出是电机的PWM值；最内层是电流环或者直接是电机驱动。这个串级结构里，速度环的输出是“叠加”在直立环的期望倾角上的。
具体来说，直立环的期望倾角通常是0度，也就是小车保持竖直。速度环的输出会改变这个期望倾角：如果小车往前跑，速度环输出一个正的修正量，期望倾角就变成正的角度，小车就会往后倾，从而减速。如果速度环输出负的修正量，期望倾角就变成负的角度，小车往前倾，加速。
所以速度环的输出符号，决定了小车是“抵抗”还是“配合”当前的运动方向。如果符号对了，速度环输出正修正量，期望倾角为正，小车往后倾，减速，这是负反馈。如果符号反了，速度环输出负修正量，期望倾角为负，小车往前倾，加速，这是正反馈。
在代码里，这个符号通常体现在速度环PID的输出上。比如位置式PID的输出是：
speed_pid.output = Kp * error + Ki * integral + Kd * derivative;如果这个output直接加到直立环的期望倾角上，那么符号就取决于error的定义。如果error = target_speed - actual_speed，那么当actual_speed > target_speed时，error为负，output为负，期望倾角为负，小车往前倾，加速——这就是正反馈。正确的做法应该是error = actual_speed - target_speed，或者把output取反后再加到期望倾角上。
这个符号问题在增量式PID里更隐蔽，因为增量式PID的输出是增量，不是绝对值。增量式PID的公式是：
speed_pid.output += Kp * (error - error_last) + Ki * error + Kd * (error - 2*error_last + error_prev);这里的output是累加的，符号问题会累积，一旦方向反了，output会越来越大，小车会越来越快地冲出去。所以增量式PID的速度环，极性判断更重要，因为它的正反馈效应比位置式更猛烈。
我个人的习惯是，在速度环的输出上加一个符号变量，比如：
#define SPEED_LOOP_SIGN (-1) speed_pid.output = SPEED_LOOP_SIGN * (Kp * error + Ki * integral + Kd * derivative);这样如果发现极性反了，只需要改这个宏定义，不用去动PID内部的公式。这个习惯让我在调试的时候省了很多事，因为极性问题和参数问题是两个独立的问题，分开处理更清晰。
2.2 编码器计数方向对速度环极性的影响
编码器计数方向是速度环极性问题的“隐藏关卡”。很多人在代码里把速度环的符号改对了，但编码器计数方向是反的，结果实际效果还是正反馈。因为速度环的输入是编码器测到的速度，如果编码器方向反了，速度的符号就反了，速度环的输出符号也跟着反，极性又错了。
判断编码器计数方向的方法很简单：用手把小车往前推，看编码器的读数是正还是负。如果往前推读数是正，说明编码器方向是对的；如果往前推读数是负，说明编码器方向反了，需要在代码里取反。这个测试要在电机不转的情况下做，否则电机的运动会影响编码器读数。
我在实际项目里，通常会在编码器读取函数里加一个方向宏：
#define ENCODER_DIR (-1) int16_t encoder_read(void) { int16_t raw = read_encoder_hardware(); return ENCODER_DIR * raw; }这样编码器方向和速度环符号就是两个独立的宏，调试的时候可以分别调整，不会互相干扰。我见过有人把这两个方向混在一起调，改了一个另一个又不对，最后把自己绕晕了。
还有一个细节：有些编码器的计数方向在硬件上就是反的，比如A相和B相接反了，或者编码器装在了电机的另一侧。这种情况下，你可以在硬件上改接线，也可以在软件里取反。我个人的建议是软件取反，因为硬件改接线容易出错，而且软件取反更灵活，调试的时候改一个宏就行。
2.3 电机驱动方向与速度环极性的耦合
电机驱动方向是另一个容易和速度环极性耦合的环节。如果电机驱动方向反了，直立环的极性就反了，小车会直接倒下去，根本站不住。所以电机驱动方向必须在调直立环之前就确认好。
确认电机驱动方向的方法：给电机一个正的小PWM值，看轮子是往前转还是往后转。如果往前转，说明驱动方向是对的；如果往后转，说明驱动方向反了，需要在代码里取反。这个测试要在小车悬空的情况下做，否则小车会跑出去。
电机驱动方向、编码器计数方向、速度环输出符号，这三个方向是相互独立的，但它们的组合决定了速度环的最终极性。我通常会在代码里把这三个方向都定义成宏，调试的时候一个一个确认：
#define MOTOR_DIR (1) #define ENCODER_DIR (1) #define SPEED_LOOP_SIGN (-1)确认的顺序是：先确认电机驱动方向，确保直立环能站住；再确认编码器计数方向，确保速度读数正确；最后确认速度环输出符号，确保速度环是负反馈。这个顺序不能乱，因为每一步都依赖前一步的正确性。
我踩过的一个坑是：电机驱动方向和编码器方向同时反了，结果直立环能站住，速度环极性看起来也是对的，但实际效果还是正反馈。因为两个方向同时反，速度环的输入和输出都反了，负负得正，又变成正反馈了。这个坑很隐蔽，因为单独看每个方向都是“对”的，但组合起来就是错的。所以确认方向的时候，一定要一个一个来，不要同时改两个。
3. 实操：从零搭建一个极性正确的速度环
3.1 硬件准备与接线检查
在开始调速度环之前，先把硬件接线检查一遍。需要的硬件包括：主控板（STM32或者Arduino都行）、电机驱动模块、编码器电机、陀螺仪模块、电池。接线的时候注意几点：电机驱动的电源线和信号线不要接反，编码器的A相和B相不要接反，陀螺仪的I2C线不要接反。
我个人的习惯是，接线完成后先用万用表测一遍通断，确保没有虚焊和短路。然后给主控板烧一个最简单的测试程序，让电机正转一秒、反转一秒，看轮子的转向对不对。这个测试不需要陀螺仪和编码器，只需要电机驱动能正常工作。
编码器的测试稍微麻烦一点，需要读编码器计数。我通常会用串口打印编码器读数，用手转动轮子，看读数是不是随着转动变化。如果读数不变，说明编码器没接好；如果读数变化但方向不对，说明A相和B相接反了。这个测试要在电机不转的情况下做，否则电机的运动会影响编码器读数。
陀螺仪的测试更简单，用串口打印陀螺仪的角速度读数，用手转动小车，看读数是不是随着转动变化。如果读数不变，说明陀螺仪没接好；如果读数变化但方向不对，说明陀螺仪的安装方向反了，需要在代码里取反。
3.2 直立环的调试与极性确认
直立环是速度环的基础，直立环没调好，速度环根本没法调。直立环的调试步骤是：先调P，让小车能站住但会抖动；再调D，让抖动减小；最后调I，让小车能抵抗缓慢的偏移。这个过程中，极性必须是对的，否则小车会直接倒下去。
判断直立环极性的方法：用手把小车往前倾，看轮子是往前转还是往后转。如果轮子往前转，说明极性是对的；如果轮子往后转，说明极性反了，需要在代码里取反。这个测试要在小车悬空的情况下做，否则小车会跑出去。
我个人的经验是，直立环的P值从10开始调，每次增加5，直到小车能站住但会抖动。然后加D，从0.5开始调，每次增加0.1，直到抖动减小到可以接受。最后加I，从0.01开始调，每次增加0.01，直到小车能抵抗缓慢的偏移。这个过程中，如果小车往一边倒，说明极性反了，先修极性，别调参数。
直立环调好之后，小车应该能站住，但会缓慢地往一个方向跑。这个“缓慢跑”就是速度环要解决的问题。如果小车跑得很快，说明直立环的P值太大了，需要减小。如果小车跑得很慢但一直跑，说明直立环的P值差不多了，可以开始调速度环。
3.3 速度环的接入与极性测试
速度环的接入要一步一步来。先把速度环的P值设得很小，比如0.1，I和D设为0。然后把小车放在地上，用手往前推，看轮子的反应。如果轮子往后转，说明极性是对的；如果轮子往前转，说明极性反了，需要改速度环的输出符号。
这个测试的关键是“用手推”，而不是让小车自己跑。因为小车自己跑的时候，速度环的输出会累积，一旦极性反了，小车会很快冲出去，来不及观察。用手推的时候，速度环的输出是瞬时的，你可以清楚地看到轮子的反应。
我个人的习惯是，用手推小车的时候，推的力度要小，速度要慢，这样才能看清楚轮子的反应。如果推得太快，轮子的反应会被直立环的修正掩盖，看不清楚。推的时候注意感受轮子的“抵抗感”，如果轮子往后转，你会感觉到一个阻力；如果轮子往前转，你会感觉到一个“顺滑感”，好像小车在配合你推。
极性确认之后，再慢慢增加速度环的P值，直到小车能抵抗缓慢的偏移。然后加I，让小车能消除稳态误差。最后加D，让速度环的响应更快。这个过程中，如果小车开始往一边倒，说明速度环的极性又反了，或者P值太大了，需要检查。
3.4 参数整定与正反馈的排查
速度环的参数整定和直立环类似，也是先P后I再D。但速度环的参数整定有一个特殊的地方：速度环的输出是倾角修正量，所以它的P值不能太大，否则会让小车抖动。我个人的经验是，速度环的P值从0.1开始调，每次增加0.05，直到小车能抵抗缓慢的偏移。然后加I，从0.01开始调，每次增加0.01，直到小车能消除稳态误差。最后加D，从0.01开始调，每次增加0.01，直到速度环的响应更快。
如果速度环的参数调了半天，小车还是往一边倒，那就要排查正反馈了。排查的方法是：用手推小车，看轮子的反应。如果轮子往前转，说明极性反了；如果轮子往后转，说明极性是对的，问题可能在参数上。如果极性是对的但小车还是往一边倒，那可能是编码器方向反了，或者电机驱动方向反了，需要逐个排查。
我踩过的一个坑是：速度环的极性是对的，但编码器的计数方向反了，结果速度环的输入符号反了，输出符号也跟着反了，实际效果还是正反馈。这个坑很隐蔽，因为速度环的极性看起来是对的，但实际效果是错的。所以排查正反馈的时候，一定要把编码器方向、电机驱动方向、速度环输出符号都检查一遍。
4. 常见问题与排查技巧实录
4.1 速度环正反馈的典型症状与快速判断
速度环正反馈的典型症状是：小车在直立环调好的情况下，一加速度环就往一个方向缓慢加速，越跑越快，最后冲出去。这个症状和速度环参数没调好的症状很像，但有一个关键区别：参数没调好的时候，小车是“抖动”或者“振荡”；正反馈的时候，小车是“单向加速”。如果你看到小车往一个方向越跑越快，那基本就是正反馈了。
快速判断的方法是：用手往前推小车，看轮子的反应。如果轮子往前转，说明是正反馈；如果轮子往后转，说明是负反馈。这个测试不需要上车跑，静态就能判断。我通常会在速度环接入之前先做这个测试，确保极性是对的，再上车调参数。
还有一个更隐蔽的症状：小车在低速的时候看起来正常，但一加速就往一边倒。这个症状可能是速度环的P值太大了，也可能是正反馈在高速的时候才显现出来。判断的方法是：把速度环的P值减小一半，如果症状消失，说明是P值太大了；如果症状还在，说明是正反馈。
4.2 编码器方向反了的排查与修正
编码器方向反了的排查方法是：用手往前推小车，看编码器的读数是正还是负。如果往前推读数是负，说明编码器方向反了，需要在代码里取反。这个测试要在电机不转的情况下做，否则电机的运动会影响编码器读数。
修正的方法是：在编码器读取函数里加一个方向宏，比如：
#define ENCODER_DIR (-1) int16_t encoder_read(void) { int16_t raw = read_encoder_hardware(); return ENCODER_DIR * raw; }这样编码器方向就是一个独立的宏，调试的时候改一个宏就行，不用去动速度环的代码。我个人的习惯是，编码器方向和速度环符号分开定义，这样调试的时候可以分别调整，不会互相干扰。
4.3 电机驱动方向反了的排查与修正
电机驱动方向反了的排查方法是：给电机一个正的小PWM值，看轮子是往前转还是往后转。如果往后转，说明驱动方向反了，需要在代码里取反。这个测试要在小车悬空的情况下做，否则小车会跑出去。
修正的方法是：在电机驱动函数里加一个方向宏，比如：
#define MOTOR_DIR (-1) void motor_set(int16_t pwm) { int16_t dir = (pwm >= 0) ? 1 : -1; int16_t abs_pwm = (pwm >= 0) ? pwm : -pwm; set_motor_hardware(MOTOR_DIR * dir * abs_pwm); }这样电机驱动方向就是一个独立的宏，调试的时候改一个宏就行。我个人的习惯是，电机驱动方向、编码器方向、速度环符号都分开定义，这样调试的时候可以一个一个确认，不会互相干扰。
4.4 速度环参数整定的常见误区
速度环参数整定的常见误区是：把速度环的P值调得太大，导致小车抖动。速度环的P值不能太大，因为它的输出是倾角修正量，P值太大会让倾角修正量太大，小车会抖动。我个人的经验是，速度环的P值从0.1开始调，每次增加0.05，直到小车能抵抗缓慢的偏移。如果小车开始抖动，说明P值太大了，需要减小。
另一个误区是：把速度环的I值调得太大，导致小车振荡。速度环的I值不能太大，因为它的输出是累积的，I值太大会让累积量太大，小车会振荡。我个人的经验是，速度环的I值从0.01开始调，每次增加0.01，直到小车能消除稳态误差。如果小车开始振荡，说明I值太大了，需要减小。
还有一个误区是：把速度环的D值调得太大，导致小车对噪声敏感。速度环的D值不能太大，因为它的输出是微分量，D值太大会让微分量对噪声敏感，小车会抖动。我个人的经验是，速度环的D值从0.01开始调，每次增加0.01，直到速度环的响应更快。如果小车开始抖动，说明D值太大了，需要减小。
4.5 常见问题速查表
| 症状 | 可能原因 | 排查方法 | 修正方法 |
|---|---|---|---|
| 小车往一边缓慢加速 | 速度环正反馈 | 用手推小车，看轮子转向 | 改速度环输出符号 |
| 小车往一边倒 | 直立环极性反了 | 用手倾小车，看轮子转向 | 改直立环输出符号 |
| 小车抖动 | 速度环P值太大 | 减小P值，看症状是否消失 | 减小速度环P值 |
| 小车振荡 | 速度环I值太大 | 减小I值，看症状是否消失 | 减小速度环I值 |
| 小车对噪声敏感 | 速度环D值太大 | 减小D值，看症状是否消失 | 减小速度环D值 |
| 速度读数方向反了 | 编码器方向反了 | 用手推小车，看编码器读数 | 改编码器方向宏 |
| 电机转向反了 | 电机驱动方向反了 | 给电机正PWM，看轮子转向 | 改电机驱动方向宏 |
这个速查表是我在实际调试中总结出来的，基本上覆盖了速度环调试中常见的问题。我个人的习惯是，遇到问题先查表，找到可能的原因，然后按排查方法确认，最后按修正方法处理。这个流程让我在调试的时候少走了很多弯路。
5. 从正反馈问题延伸出去的几个思考
5.1 为什么新手容易在速度环极性上翻车
新手容易在速度环极性上翻车，根本原因是速度环的极性判断比直立环绕了一层。直立环的极性是“小车往前倾，轮子往前转”，这个逻辑符合直觉，容易判断。但速度环的极性是“小车往前跑，轮子往后转”，这个逻辑反了一层，需要绕个弯才能理解。
而且速度环的极性还和编码器方向、电机驱动方向耦合，这三个方向只要有一个搞反，整个系统就可能变成正反馈。新手往往只关注PID参数，忽略了极性这个更基础的问题。我见过很多新手，PID参数调了好几天，最后发现是极性反了，改一个符号就解决了。
还有一个原因是，很多教程在讲速度环的时候，只讲PID参数怎么调，不讲极性怎么判断。新手照着教程抄代码，参数调了半天，车还是往一边倒，最后只能放弃。其实如果教程里加一句“用手推小车，看轮子转向”，就能省下很多时间。
5.2 正反馈在其他控制系统里的表现
正反馈在其他控制系统里也有类似的表现。比如温度控制系统，如果加热器的控制信号反了，温度越高加热越猛，温度就会失控。比如电机调速系统，如果速度环的极性反了，电机转速越高，速度环输出越大，转速就会失控。比如无人机的高度控制，如果高度环的极性反了，无人机越高，高度环输出越大，无人机就会飞走。
这些场景的共同点是：控制系统的输出和期望方向一致了，而不是相反。判断的方法都是一样的：给系统一个扰动，看系统的反应是“抵抗”还是“配合”。如果抵抗，说明是负反馈；如果配合，说明是正反馈。
我个人的经验是，任何闭环控制系统，在调试之前都要先确认极性。极性问题是最基础的问题，也是最容易犯的问题。确认极性的方法很简单：给系统一个扰动，看系统的反应。这个测试不需要精确的参数，只需要观察方向。
5.3 如何从代码架构上避免极性错误
从代码架构上避免极性错误，最有效的方法是：把所有的方向都定义成独立的宏，调试的时候一个一个确认。比如：
#define MOTOR_DIR (1) #define ENCODER_DIR (1) #define SPEED_LOOP_SIGN (-1) #define ANGLE_LOOP_SIGN (1)这样每个方向都是独立的，调试的时候可以分别调整，不会互相干扰。我个人的习惯是，在代码里加一个“方向确认”函数，上电的时候自动测试每个方向，如果发现异常就通过串口报警。这个函数不需要很复杂，只需要给电机一个小的PWM，读编码器，看方向对不对。
还有一个方法是：在代码里加一个“极性测试”模式，上电的时候进入这个模式，用手推小车，串口打印速度环的输出符号，看是不是负反馈。这个模式不需要上车跑，静态就能判断极性。我个人的习惯是，每次改完方向宏，都先跑一遍极性测试，确认无误后再上车调参数。
5.4 速度环增量式PID的极性特点
增量式PID的速度环，极性特点比位置式更明显。因为增量式PID的输出是累加的，一旦极性反了，输出会越来越大，小车会越来越快地冲出去。位置式PID的输出是瞬时的，极性反了的时候，小车会加速，但加速的幅度受限于PID的输出限幅。增量式PID没有这个限制，输出会一直累加，直到饱和。
所以增量式PID的速度环，极性判断更重要。我个人的经验是，增量式PID的速度环，P值要设得比位置式小，因为它的输出是累加的，P值太大会让累加量太大，小车会抖动。而且增量式PID的速度环，极性测试要更小心，因为一旦反了，小车会很快冲出去，来不及观察。
判断增量式PID速度环极性的方法：用手推小车，看轮子的反应。如果轮子往后转，说明极性是对的；如果轮子往前转，说明极性反了。这个测试要在速度环的P值设得很小的情况下做，否则小车会很快冲出去。我个人的习惯是，增量式PID的速度环，P值从0.05开始调，每次增加0.02，直到小车能抵抗缓慢的偏移。
5.5 速度环与直立环的耦合调试技巧
速度环和直立环是串级关系，调试的时候要分开调，不能一起调。我个人的习惯是：先把直立环调好，确保小车能站住；然后把速度环的P值设得很小，接入速度环，用手推小车，确认极性；最后慢慢增加速度环的P值，直到小车能抵抗缓慢的偏移。
这个过程中，如果小车开始抖动，说明速度环的P值太大了，需要减小。如果小车开始振荡，说明速度环的I值太大了，需要减小。如果小车对噪声敏感，说明速度环的D值太大了，需要减小。这个调试流程我用了很多次，基本上每次都能调出稳定的速度环。
还有一个技巧是：速度环的输出限幅要设得合理。速度环的输出是倾角修正量，限幅太大会让小车抖动，限幅太小会让小车抵抗不了偏移。我个人的经验是，速度环的输出限幅设在5度到10度之间，具体值取决于小车的重心高度和轮距。重心越高，限幅越小；轮距越宽，限幅越大。
6. 写在最后的一些实操体会
速度环正反馈这个问题，说到底是一个“方向”问题，不是“参数”问题。方向对了，参数随便调调就能跑；方向反了，参数调出花来也没用。我当初在这个问题上耗了两天，最后发现是速度环的输出符号反了，改一个负号就解决了。从那以后，我每次调速度环之前，都会先用手推小车，确认极性，再上车调参数。
这个习惯让我在后面的项目里少走了很多弯路。我后来做过的几个平衡小车项目，速度环都是一次调通，没有再出现过正反馈的问题。我个人的体会是，平衡小车的调试，最怕的不是参数难调，而是方向搞反。方向搞反了，你越努力调参数，小车跑得越快，最后只能撞墙。
所以如果你现在正在被速度环正反馈折磨，我的建议是：先别碰PID参数，先用手推小车，看轮子的反应。如果轮子往前转，先把速度环的输出符号改反，再上车调参数。这个简单的测试，能帮你省下很多时间。我见过太多人在这上面耗了好几天，最后发现是极性反了，改一个符号就解决了。希望这篇文章能帮你避开这个坑。
