问题描述
最近在开发一套云台自动追踪算法，但在实际测试中发现了一个非对称性跟随问题：
向左转动时： 云台基本能跟上目标移动速度，目标偏离中心点约 10%。
向右转动时： 云台明显跟不上目标，目标偏离中心点达到了 30% 左右。
如下图所示，屏幕中心的播放按钮即为我们的理想对准点：
情况 A：向左追踪
目标与中心点的偏差较小，表现正常。
情况 B：向右追踪
目标严重偏离中心，云台响应滞后。
核心疑问： 为什么同一套算法，左右移动的偏移量会存在如此大的差异？
实现原理
算法的逻辑链条如下：
位置变化： 计算目标在屏幕上的归一化移动速度。
速度转换： 将移动速度转换为所需的角速度。
指令下发： 将角速度映射到云台对应的控制档位，通过蓝牙发送指令。
分析与猜想
针对这一现象，我最初提出了四个猜想：
系统延迟： 识别、计算到蓝牙传输存在滞后。但细想后排除，因为如果是延迟问题，左右转动应该都会滞后，不会只出现在单侧。
硬件阻尼/Bug： 怀疑云台硬件在向右转动时存在某种物理阻力，或者固件在处理负电压方向时有 Bug。
角速度算法： 怀疑计算逻辑有误。但也基本排除，因为左右跟随使用的是同一套逻辑。
拟合公式误差： 云台的档位与速度关系是通过数据测量后进行线性拟合得到的，怀疑拟合精度不足。
实验验证
我重点研究了第 1 点（验证链路稳定性）和第 4 点（验证拟合准确性）。
首先，我编写了一个测试页面，手动发送固定速度档位，观察云台的实际表现是否与预期的“档位—角速度”映射表一致。 测试结果显示：硬件响应基本稳定，映射关系与原始表一致，排除了硬件突然“抽风”的可能性。
接着，我回到 Excel 对拟合公式的理论计算值与实际测量值进行了二次比对。 真相大白： 图表显示，实验值与公式计算值之间存在明显偏差，部分区间偏差达到了 10% 甚至更高。正是这看似微小的拟合误差，在闭环追踪过程中被不断放大，导致了向右跟随时的严重滞后。
总结
其实在最初进行函数拟合时，我已经发现了部分测量点与函数曲线不完全重合。但当时觉得这点偏差“应该影响不大”，就直接忽略了。
没成想，这个被我“由于偷懒而忽略”的小细节，最后让我苦思冥想了好几天。这次教训告诉我也提醒大家：在精密控制算法中，任何细微的偏差都可能在特定条件下演变成巨大的 Bug。