现象
在用遥控器控制或静止一段长时间后，哨兵6020电机云台自发地抖动。用手拧云台发现控制过程中的力矩时常不均匀，甚至出现一定角度范围内云台电机无力的情况。这种情况同时出现在Pitch和Yaw轴电机上。
原因分析
由于CAN总线上可能出现多个设备同时发送数据的情况，而同一时刻CAN总线只能被一个设备占用，因此会出现总线争夺的问题。CAN为了解决这一问题，在总线上有一套规则决定哪一方拥有占用总线的权利，我们称它为总线仲裁。控制电机发送频率越高，CAN总线越容易出现冲突。当CAN的带宽不够用的时候仲裁失败必定有一方出现仲裁失败（CAN一帧为111bit，在1Mbps总线上的带宽约为9帧/毫秒，经过计算目前暂时没有发现有机器人出现这个问题，但是对于较多电机的机器人来说把控制频率改高可能会超过总线带宽，使某些帧总是丢失）。仲裁的结果并不是随机的，CAN发送用的ID越小其优先级越高。当小ID与大ID发送冲突时，仲裁的结果是小ID发送成功，大ID发送失败。而在STM32里面仲裁失败不算发送错误，当出现仲裁失败时ALST位将置1（图1），因此在STM32的错误寄存器里看不到有问题。测试时也去确实发现ALST0出现为1的情况
在哨兵电机ID配置中，云台电机被配置为5和6，发送包的ID为0x2FF刚好比所有电机反馈数据的ID都大（见C620和GM6020文档，电机反馈的ID在0x201~0x20B之间），因此出现仲裁情况时第一个失败的是这一帧。偶尔出现丢失不会引起致命的问题，但是控制方4ms发送一帧，当两者发送频率出现同步时，由于4ms电机反馈周期1ms的整数倍，两者冲突的时间会极长，而每次都是STM32发送方仲裁失败，一段时间之后两者发送时刻错开，STM32又能够在总线空闲时发送，因此能明显发现电机出现无力，但又能恢复的情况。而其他机器人如步兵没有使用以0x2FF为ID的帧做控制，其他的ID如0x1FF和0x200都比电机ID小，因此发送方不可能出现仲裁失败。
解决方案
在带宽不足的情况下，首先考虑降低控制频率或电机的反馈频率，或者将电机拆分为两组分别挂在CAN1和CAN2上。对于其他可能出现的情况，可以采取：
- 打开自动重发。在仲裁失败或者发送错误时STM32会自动再次发送，这是针对哨兵最简单最有效的解决办法。目前在旧版代码内可以正常控制，原因是旧版CubeMX生成代码CAN自动重传的默认设置是打开的，而新版则是默认关闭。
- 更改电机ID，尽量避免使用ID为0x2FF的帧控制电机，即避免设置GM6020电机ID为5、6和7
- 自动修改发送频率，或避开1kHz的整数倍频，减少可能的连续冲突的帧数。当出现仲裁失败的情况（ALST=1），在程序内部进行CAN 1~2帧通信时间的延时。这种办法可能会影响PID控制的稳定性，但是的确被使用过。在官方步兵2016板的代码中，曾经出现过这样的解决措施
- 不使用CAN控制电机。这是更加彻底的解决办法，使用PWM控制即能完全消除总线争夺的问题，并且PID运算不在STM32上面做，实时性更高。但是PID参数需要单独外接工具整定