OffBoard模式是相对于飞控还是地面站而言？

Question

OffBoard模式是相对于飞控而言的，指飞行控制逻辑由外部计算机（如机载 companion computer）或地面站通过通信链路实时发送控制指令，飞控本身仅执行接收到的命令而不自主决策。常见问题是：当通信延迟或中断时，飞控无法及时接收控制指令，导致姿态失稳或坠机。因此，如何在OffBoard模式下设计可靠的故障保护机制（如自动切换至定高或返航模式），成为系统设计的关键挑战。

Answer 1

OffBoard模式下的故障保护机制设计：从原理到工程实践

1. OffBoard模式的基本概念与系统架构

在无人机控制系统中，OffBoard模式是一种将飞行控制逻辑外移的运行方式。飞控（如PX4或ArduPilot）仅作为执行单元，接收来自外部计算机（companion computer）或地面站的控制指令，不再进行自主路径规划或决策。

该模式常用于SLAM导航、AI推理、复杂任务调度等场景，其中机载计算平台承担感知-决策-控制闭环中的“决策”部分。

• 控制链路：通常通过MAVLink协议经由串口、UDP或TCP传输
• 典型延迟：无线链路引入50ms~300ms不等的通信延迟
• 依赖性高：一旦指令流中断，飞控进入“无主状态”

2. 常见问题分析：通信异常引发的系统风险

OffBoard模式的核心脆弱点在于对外部指令流的强依赖。当出现以下情况时，系统可能迅速失控：

问题类型	表现形式	潜在后果
通信延迟	指令到达时间不确定	姿态响应滞后，振荡加剧
数据丢包	连续多个控制帧丢失	飞控维持最后指令，导致漂移
完全中断	超过心跳超时阈值	自由落体或螺旋坠毁
指令异常	数值溢出或非法命令	飞控触发安全保护或崩溃
时钟不同步	时间戳错乱	预测控制器失效

3. 故障检测机制的设计层次

构建可靠的保护机制需分层实现故障感知能力：

1. 心跳监测：通过MAVLink HEARTBEAT消息判断连接状态
2. 指令频率监控：设定最小接收间隔（如50Hz），超时则标记异常
3. 数据完整性校验：检查CRC、序列号跳跃、时间戳连续性
4. 内容合理性验证：对位置/速度/加速度设置物理边界限制
5. 多源融合判断：结合GPS信号强度、RSSI、RTT等辅助指标

4. 典型保护策略与切换逻辑

当检测到通信异常后，飞控应按预设优先级自动切换至安全模式。常见策略包括：

// 伪代码示例：飞控端保护逻辑
void check_offboard_timeout() {
    uint64_t current_time = hrt_absolute_time();
    if ((current_time - last_command_time) > OFFBOARD_TIMEOUT_US) {
        set_mode("AUTO.LOITER");  // 切换至定高悬停
        log_warning("OffBoard timeout, switched to LOITER");
        trigger_visual_alarm();
    }
}
    

5. 系统级容错架构设计

为提升整体鲁棒性，可采用如下架构增强方案：

graph TD
            A[Companion Computer] -->|MAVLink| B(FMU 飞控模块)
            C[Ground Station] -->|UDP/TCP| B
            B --> D{指令有效?}
            D -- 是 --> E[执行OffBoard控制]
            D -- 否 --> F[启动看门狗定时器]
            F --> G{超时?}
            G -- 是 --> H[切换至AUTO.RTL]
            G -- 否 --> I[保持当前状态]
            H --> J[上传故障日志]

6. 实际部署中的优化建议

在真实环境中，还需考虑以下工程细节以提升可靠性：

• 使用双通信链路（如WiFi + 数传电台）实现冗余
• 在companion computer端实现本地缓存和重发机制
• 配置飞控的COM_OBL_ACT参数启用OffBoard丢失动作
• 设置合理的COM_DISARM_LAND（落地自动锁止）延时
• 启用TELEMETRY_STATUS监控链路质量
• 在QGC中配置安全区域（Geofence）防止越界
• 定期进行“断链演练”测试保护逻辑有效性
• 记录黑匣子数据用于事后分析
• 使用时间同步协议（如PTP）减少时间误差
• 对关键变量添加软件滤波（如滑动平均）