MissionPlanner中CAN_FORWARD请求异常导致资源占用的技术分析

问题背景

在飞行控制系统开发中，MissionPlanner作为地面站软件与飞行控制器之间的通信至关重要。近期发现一个严重的技术问题：MissionPlanner在不恰当的场景下持续发送CAN_FORWARD请求，导致飞行控制器资源被异常占用。

问题现象

当用户未打开CAN总线用户界面时，MissionPlanner仍然持续向飞行控制器发送CAN_FORWARD请求。这一行为在ArduPilot 4.5.6稳定版本中尤为严重，会导致以下后果：

1. DroneCAN线程资源被100%占用
2. 其他遥测链路消息无法正常传输
3. 低带宽无线电链路可能被完全淹没
4. 用户可能失去对飞行系统的态势感知能力

技术原理分析

CAN_FORWARD机制原本设计用于在CAN总线用户界面活动时，将特定CAN消息转发到遥测链路。这一功能在调试和监控CAN设备时非常有用，但不应在非活动状态下持续请求。

在ArduPilot架构中，DroneCAN线程负责处理所有CAN总线通信。当收到大量CAN_FORWARD请求时，线程需要处理这些请求并准备相应的转发数据，这会消耗大量CPU资源。特别是在资源受限的飞行控制器上，这种异常行为会严重影响系统整体性能。

问题根源

经过代码审查发现，该问题源于一个针对MissionPlanner的修改。原本CAN_FORWARD请求应仅在用户主动打开CAN总线界面时触发，但修改后的代码逻辑导致这些请求被无条件持续发送。

解决方案

针对此问题，开发团队采取了以下措施：

1. 修正MissionPlanner的请求逻辑，确保CAN_FORWARD仅在相关界面活动时发送
2. 在ArduPilot端增加防护机制，防止类似异常请求导致系统资源耗尽
3. 优化DroneCAN线程的资源管理策略

经验总结

这一事件为飞行控制系统开发提供了重要经验：

1. 通信协议实现必须考虑异常情况下的系统行为
2. 地面站软件应严格遵循"按需请求"原则
3. 资源受限系统需要完善的过载保护机制
4. 功能测试应包含非预期使用场景的验证

通过这次问题的发现和解决，MissionPlanner与ArduPilot的协同工作可靠性得到了进一步提升，为开发者提供了处理类似通信问题的参考方案。