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.1I和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参数先用手推小车看轮子的反应。如果轮子往前转先把速度环的输出符号改反再上车调参数。这个简单的测试能帮你省下很多时间。我见过太多人在这上面耗了好几天最后发现是极性反了改一个符号就解决了。希望这篇文章能帮你避开这个坑。