PX4 模式需求位图（mode_requirements）

一、功能定位

ModeUtil/mode_requirements.hpp/cpp 负责生成每个 nav_state 对应的模式需求位图，写入 failsafe_flags_s 的 mode_req_* 字段。

核心接口：

void getModeRequirements(uint8_t vehicle_type, failsafe_flags_s &flags);

• 输出：flags.mode_req_angular_velocity、flags.mode_req_attitude、flags.mode_req_local_position 等一组 uint32_t 位图
• 位图的位索引与 vehicle_status_s::NAVIGATION_STATE_* 数值一致（0~30）
• vehicle_type 参数预留接口，当前实现中未使用，保留以支持未来机型差异化

相关知识：控制模式生成逻辑、Commander 模块框架

---

二、核心抽象：位图 + 有效性标志

graph LR
    A["getModeRequirements()"] -->|"计算"| B["mode_req_X<br/>（uint32_t 位图）<br/>第 n 位=1 表示 NAVIGATION_STATE==n 需要X"]
    C["HealthAndArmingChecks"] -->|"检查传感器状态"| D["X_invalid<br/>（布尔）<br/>当前系统对X的判定"]
    
    B --> E{"组合逻辑"}
    D --> E
    E -->|"X_invalid=true 且 当前nav_state 在 mode_req_X 中被置位"| F["该模式不可运行<br/>或触发 failsafe"]

两个字段配合使用：

• mode_req_X：一个集合，表示哪些 nav_state 需要能力 X
• X_invalid：当前系统对能力 X 的健康判定

---

三、setRequirement() 最小实现

// 将某个 nav_state 对某类需求的依赖写入对应的位图
// 位图: 第 n 位为 1 表示 NAVIGATION_STATE==n 属于该需求集合
void setRequirement(uint8_t nav_state, uint32_t &requirement_bitmask) {
    requirement_bitmask |= (1u << nav_state);
}

---

四、各模式的需求配置

graph TD
    subgraph 模式需求层级
        MANUAL["MANUAL<br/>仅需: manual_control"]
        ALTCTL["ALTCTL<br/>需要: angular_velocity + attitude + local_alt + manual_control"]
        POSCTL["POSCTL<br/>需要: ALTCTL的全部 + local_position_relaxed"]
        AUTO["AUTO_MISSION<br/>需要: local_pos + global_pos + home_position + mission + angular_velocity + attitude"]
        RTL["AUTO_RTL<br/>需要: global_pos + home_position + angular_velocity + attitude"]
    end

主要模式的需求汇总（以多旋翼为例）：

模式	需要的能力集合
MANUAL	manual_control
ALTCTL	angular_velocity、attitude、local_alt、manual_control
POSCTL	ALTCTL + local_position_relaxed
AUTO_LOITER	local_position、attitude、angular_velocity
AUTO_MISSION	local_position、global_position、home_position（可选）、mission、attitude、angular_velocity
AUTO_RTL	global_position、home_position、attitude、angular_velocity

关键点：每次调用 getModeRequirements() 都会生成一整套 mode_req_* 位图字段。每个模式只在它依赖的那几类位图里被置位，其余位图中该模式对应位为 0。

---

五、需求类别与传感器数据源的绑定

*_invalid 标志并非抽象概念，而是由 HealthAndArmingChecks 的具体检查项绑定到对应的 uORB 话题。

angular_velocity_invalid

由 vehicle_angular_velocity 话题驱动，时间戳超时或数值非有限即 invalid。

attitude_invalid

由 vehicle_attitude 话题驱动，超时或四元数归一化/数值检查失败即 invalid。

local_position_invalid / local_position_invalid_relaxed

local_position_invalid：严格检查，要求 EKF 位置估计高质量且置信度高。

local_position_invalid_relaxed：宽松检查，允许估计精度稍低，POSCTL 模式使用此项（POSCTL 加入 local_position_relaxed 而非 local_position）。

global_position_invalid

要求 vehicle_global_position 话题有效且 EKF GPS 融合处于健康状态。

home_position_invalid

要求 home_position.valid 为真，且 Home 点的精度满足 RTL 所需的精度门限。

其他标志

标志	说明
local_altitude_invalid	本地高度无效（无气压计且无其他高度源）
offboard_control_signal_lost	Offboard 模式下控制信号超时
auto_mission_missing	任务模式下没有任务可执行
manual_control_signal_lost	RC/摇杆信号丢失

---

六、位图的消费路径

mode_req_* 位图与 *_invalid 标志共同存储在 failsafe_flags_s 话题中，被下游两个系统消费：

graph LR
    FLAGS["failsafe_flags_s<br/>mode_req_* 位图<br/>*_invalid 标志"]
    
    FLAGS --> MCHECK["ModeCheck<br/>判断某 nav_state 是否可运行/可切换"]
    FLAGS --> FSAFE["Failsafe 状态机<br/>判断是否触发 failsafe 动作"]
    
    MCHECK --> ARM["影响解锁条件<br/>canArm()"]
    MCHECK --> RUN["影响模式可运行性<br/>canRun()"]
    FSAFE --> NAVSTATE["影响最终 nav_state 选择"]

---

上一篇：控制模式生成逻辑
下一篇：Commander 核心调度