企业官网建设流程全解析

• 嵌入式
• 物联网
• 机器人
• 自动驾驶
• 智能硬件

PX4 飞控的启动过程完全由 shell 脚本驱动，本文以docs/en/concept/system_startup.md为主线，结合当前仓库中 ROMFS/px4fmu_common/init.d 与 ROMFS/px4fmu_common/init.d-posix 的源码，系统讲解 NuttX 与 POSIX（Linux/macOS）两套启动机制、机架配置的加载原理，以及如何通过/etc/config.txt、/etc/extras.txt、板级 init 脚本等途径定制启动流程。读完本文，你将掌握 PX4 从加电到 MAVLink 通知"boot complete"的完整链路，并具备在真实飞控与 SITL 仿真环境中自主定制启动行为的能力。

启动脚本体系概览

PX4 的启动逻辑不依赖复杂框架，而是由一组精心组织的 POSIX shell 脚本构成，它们按运行平台分为两套：

• NuttX（真实飞控）：脚本位于 ROMFS/px4fmu_common/init.d，编译时通过 ROMFS/px4fmu_common/init.d/CMakeLists.txt 中的px4_add_romfs_files打包进固件的 ROMFS，并在运行时挂载到/etc/init.d。
• POSIX（SITL 仿真）：仅用于 Linux/macOS 的脚本位于 ROMFS/px4fmu_common/init.d-posix。从 ROMFS/px4fmu_common/CMakeLists.txt 可以看到，只有当板型匹配sitl时才会把init.d-posix加入构建。

在 ROMFS/px4fmu_common/init.d 目录中，两类文件有着清晰的分工：

1. 机架配置文件（airframe configurations）：所有以"数字 + 下划线"命名的文件（如 4001_quad_x、2100_standard_plane、50000_generic_rover_differential），存放在init.d/airframes子目录。它们定义了特定机型的参数、混控器与默认配置，构建时会被导出为airframes.xml，供地面站 QGroundControl 的机架选择界面解析展示。新增一种机架配置的完整流程参见 添加新机架文档。
2. 通用启动逻辑脚本：其余以rc.开头的文件（如rcS、rc.sensors、rc.vehicle_setup、rc.logging）构成启动框架。其中第一个被执行的文件是 init.d/rcS（POSIX 平台对应 init.d-posix/rcS），它负责按顺序调用其余所有脚本。

整个rcS是一段线性执行序列，关键节点包括：挂载 microSD 卡（必要时格式化）→ 加载参数 → 重置参数（SYS_AUTOCONFIG）→ 加载板级默认值（rc.board_arch_defaults/rc.board_defaults/rc.additional_init）→ 依据SYS_AUTOSTART加载机架脚本（rc.autostart）→ 启动传感器、估计器、PX4IO、Commander、MAVLink 等模块 → 执行用户自定义脚本（config.txt/extras.txt）→ 最后通过mavlink boot_complete通知上位系统启动完成。

POSIX 平台（Linux/macOS）的启动机制

在 POSIX 平台上，系统 shell（如 Ubuntu 上指向 dash 的/bin/sh）被用作脚本解释器。为了让 shell 脚本能以"执行单个程序"的方式调用 PX4 模块，启动框架做了如下几项工程化设计：

模块的符号链接伪装

PX4 的所有模块在 POSIX 上并非独立的可执行文件，而是编译进同一个px4二进制。为了让系统看起来每个模块都是独立程序，构建系统会在构建目录的bin文件夹中为每个模块创建符号链接px4-<module> -> px4。当执行该链接时，PX4 检查argv[0]：如果以px4-开头，就把命令转发给主 PX4 实例处理。

使用px4-前缀有两个实际好处：避免与系统命令（如shutdown）冲突；支持在终端中直接键入px4-<TAB>进行补全，方便发现可用模块。

PATH 与别名机制

• 包含符号链接的bin目录会在执行启动脚本前被加入PATH变量，使 shell 能解析到这些链接。
• 启动脚本内部直接以commander start这种无前缀方式调用模块，依靠的是别名文件：构建时会为每个模块在bin/px4-alias.sh中生成形如alias <module>=px4-<module>的别名。init.d-posix/rcS 的第一条有效语句就是. px4-alias.sh（该文件需在 PATH 中）。

客户端/服务器模式与 UNIX Socket

shell 为每个模块启动一个新的（客户端）进程，而真正运行模块线程的是主 PX4 实例（服务器）。二者通过UNIX socket通信：服务器监听 socket，客户端连接并发送命令，服务器把模块输出与返回码回传给客户端，从而在终端中呈现出"直接运行了该命令"的效果。

rcS 的间接执行

主 PX4 实例执行rcS的方式很特别：它自己并不启动任何模块，而是先更新PATH，然后以rcS文件为参数运行一个 shell。也就是说，启动脚本的"解释器"是系统 shell，PX4 主进程只负责把脚本内容喂给 shell。

多实例（多机仿真）

为了支持多机 SITL 仿真，可以启动多个服务器实例，客户端通过--instance选择实例。实例编号在脚本中以$px4_instance变量可见——例如 init.d-posix/rcS 中会据此设置MAV_SYS_ID与UXRCE_DDS_KEY为px4_instance+1，并为 UXRCE-DDS 客户端加上-n px4_$px4_instance命名空间前缀，从而隔离多架仿真的 MAVLink 系统 ID 与 ROS 2 命名空间。

运行时手动调用模块

当 PX4 已在系统上运行时，可从任意终端直接执行模块（示例来自原文档）：

cd <PX4-Autopilot>/build/px4_sitl_default/bin ./px4-commander takeoff ./px4-listener sensor_accel

第一条命令向正在运行的 PX4 实例发送起飞指令，第二条订阅并打印sensor_accel话题数据——这正是客户端/服务器模型在日常调试中的典型用法。

动态模块（Dynamic Modules）

正常情况下所有模块都编译进单个 PX4 可执行文件；但在 POSIX 上，可以将某个模块单独编译为独立文件，再通过dyn命令在运行时加载：

dyn ./test.px4mod

该命令的实现在 src/systemcmds/dyn/dyn.cpp：它借助<dlfcn.h>动态装载一个未编译进 PX4 二进制的模块，用法为dyn ./hello.px4mod start，非常适合插件化开发与快速迭代测试。

NuttX 平台的启动机制

NuttX 内建了 shell 解释器NuttShell（NSH），因此rcS脚本可以直接在 NSH 中执行，无需符号链接、别名等 POSIX 侧的适配机制。脚本通过 ROMFS 挂载为只读的/etc/init.d，机架脚本则由rc.autostart依据SYS_AUTOSTART参数找到对应文件并 source 执行。

调试系统启动

• 错误容忍：某个驱动或软件组件失败不会中止整个启动过程，这是由启动脚本开头的set +e控制的（见 init.d/rcS 第 3 行注释，取消注释并改用set -e可恢复"出错即退出"）。
• 查看启动日志：连接系统控制台并对板子断电重启，得到的启动日志包含启动序列的详细信息，通常会给出启动中止的线索。如需更细的调试，可在rcS中取消注释set -x打印每条脚本命令的追踪信息。

常见的启动失败原因

• 自定义应用导致内存耗尽：系统 RAM 不足。在 NSH 中执行free查看剩余 RAM。
• 软件故障或断言：产生堆栈跟踪（stack trace），可从控制台日志定位。

替换整个系统启动

可以在 microSD 卡上创建文件/etc/rc.txt（实际路径为/fs/microsd/etc/rc.txt，microSD 根目录对应/fs/microsd），写入全新的启动配置，从而完全替换默认启动：旧配置中的任何内容都不会再被自动启动；如果该文件为空，则什么都不启动。这一点与 init.d/rcS 中的分支逻辑吻合——脚本检测到/fs/microsd/etc/rc.txt存在时直接 source 它并跳过整个默认启动块。

不过，定制默认启动（见下文）几乎总是比整体替换更好的方案。

自定义系统启动的三种途径

自定义启动的首选方式是为你的机型引入一套新的机架配置。机架配置文件既可以编译进固件，也可以放在 SD 卡上。如果只是小幅调整，则采用下述"动态自定义"方式。

动态自定义：config.txt 与 extras.txt

如果只需要"微调"现有配置（比如多启动一个应用、设置几个参数），可以在 SD 卡的/etc/目录下创建两个文件：

• /etc/config.txt：修改参数值
• /etc/extras.txt：启动附加应用

警告：系统启动文件是 UNIX 文件，必须使用UNIX 行尾（LF）。如果在 Windows 上编辑，请使用合适的编辑器。

说明：这两个文件在 PX4 代码中对应/fs/microsd/etc/config.txt与/fs/microsd/etc/extras.txt，microSD 根目录由路径/fs/microsd标识。在 init.d/rcS 中它们被定义为变量FCONFIG与FEXTRAS。

修改配置参数（config.txt）

config.txt在主系统配置完成之后、系统正式启动之前被加载，用于覆盖参数默认值。例如在 SD 卡上创建etc/config.txt，内容如下：

param set-default PWM_MAIN_DIS3 1000 param set-default PWM_MAIN_MIN3 1120

这里把第 3 路主输出（PWM_MAIN_DIS3）的禁用值设为 1000µs、最小油门（PWM_MAIN_MIN3）设为 1120µs，set-default保证仅在参数尚无用户修改时生效。注意 init.d/rcS 中该文件是在传感器、估计器启动之前被 source 的，因此这里设置的参数会影响到后续所有模块的初始化。

启动附加应用（extras.txt）

extras.txt用于在主系统启动完成后启动附加应用，典型场景是载荷控制器（payload controllers）等可选的自定义组件。

警告：在系统启动文件中调用未知命令可能导致启动失败。此时系统通常不会继续发送 MAVLink 消息，请检查系统控制台打印的错误信息。

示例：在 SD 卡上创建etc/extras.txt，内容为：

custom_app start

其中custom_app是你的自定义模块，需已编译进固件或可通过其他方式执行。

让命令变为可选：用set +e与set -e包裹，即可控制失败是否致命：

set +e optional_app start # optional_app 未知或失败都不会导致启动失败 set -e mandatory_app start # mandatory_app 未知或失败将中止启动

这与rcS开头set +e的设计一脉相承：错误容忍开关在整个启动流程中可随时切换。在 init.d/rcS 的末尾，FEXTRAS脚本在板级 extras（rc.board_extras）之后被 source，之后才启动日志记录器。

附加 Init 文件自定义（编译进固件）

在极少数无法通过机架配置或动态自定义达成目标的情况下，可以添加一个脚本并针对某个make目标构建变体将其编译进固件。

警告：绝大多数情况下应优先使用机架配置。此方法仅适用于边缘场景，例如定制基于cannode的板子。

具体步骤（以boards/<vendor>/<board>为例）：

1. 新增 init 脚本：在boards/<vendor>/<board>/init目录下添加启动时运行的脚本，例如rc.additional：

   # File: boards/<vendor>/<board>/init/rc.additional param set-default <param> <value>

   该文件会被 init.d/rcS 中rc.additional_init段在加载机架配置之前 source 执行。

2. 新增板级变体：在boards/<vendor>/<board>/下创建<variant>.px4board，并声明额外脚本：

   # File: boards/<vendor>/<board>/var.px4board CONFIG_BOARD_ADDITIONAL_INIT="rc.additional"

3. 编译该变体：在编译目标后追加变体名：

   make <target>_var

深入：rcS 的完整启动时序（以 NuttX 为例）

结合 init.d/rcS 源码，可以把真实飞控的启动链路归纳为以下阶段：

1. 环境准备：设置R /根路径，source rc.filepaths（由Tools/filepaths/generate_config.py生成），定义FCONFIG、FEXTRAS、FRC等关键文件变量，打印ver all版本信息。
2. 板级早期初始化：执行可选的rc.board_early（可在此设置影响 rcS 的环境变量）。
3. 存储挂载：检测/dev/mmcsd0，尝试挂载 microSD；若存在.format标记或挂载失败则执行mkfatfs -F 32格式化并重挂，并通过STARTUP_TUNE播放对应的启动音提示（如 SD_ERROR / SD_INIT）；无 SD 卡的板子则查询 MTD 参数分区作为后备存储。
4. 参数加载与重置：param select+param load-or-init从 BSON 参数库加载参数，失败时回退到备份导入并转储bsondump调试信息；若SYS_AUTOCONFIG被置位，则param reset_all（保留机架、校准、飞行时间、MAV_SYS_ID 等）触发一次参数重置。
5. 板级与机架配置：依次 sourcerc.board_arch_defaults、rc.board_defaults、rc.additional_init，然后执行rc.autostart（自动生成的机架脚本选择逻辑）按SYS_AUTOSTART加载对应 airframe 文件；找不到机架则尝试 SD 卡上的外部机架（rc.autostart_ext，对应 ROMFS/px4fmu_common/init.d/rc.autostart_ext，它 source${SDCARD_EXT_PATH}/rc.autostart），仍失败则报错并将SYS_AUTOSTART归零。
6. 核心驱动与模块：tone_alarm、dataman、load_mon、rgbled等基础组件启动；按SYS_HITL分流：HITL 模式用模拟传感器（sensors start -h），否则加载rc.board_sensors与rc.sensors并启动真实传感器；随后按参数选择估计器（ekf2/local_position_estimator/attitude_estimator_q），更新 PX4IO 固件并启动，接着是rc_update、manual_control、commander、pwm_out/dshot输出。
7. 机载与通信服务：rc.vehicle_setup按机型设置参数；启动可选串口驱动（rc.serial由Tools/serial/generate_config.py自动生成）、rc_input、MAVLink（USB/CDCACM 自动检测）、navigator、gimbal、logger（rc.logging）等。
8. 用户自定义与收尾：source 用户config.txt与extras.txt；执行rc.autostart.post、param lock锁定只读参数、rc.board_bootloader_upgrade；最后unset所有脚本变量以释放 RAM，并通过mavlink boot_complete宣告系统完全就绪。

POSIX 侧的 init.d-posix/rcS 遵循相似骨架，但增加了仿真专属逻辑：按PX4_SIM_MODEL环境变量在init.d-posix/airframes中反查自动启动 ID（SYS_AUTOSTART），设置模拟传感器校准 ID（CAL_ACC0_ID等DRV_IMU_DEVTYPE_SIM设备）、禁用 CPU/RAM 上限检查（COM_CPU_MAX -1）、放宽 RC 要求（COM_RC_IN_MODE 1），并根据PX4_SIM_SPEED_FACTOR等比缩放超时参数；支持通过PX4_PARAM_<name>环境变量覆盖参数，最后启动px4-rc.simulator与uxrce_dds_client（默认 UDP 端口 8888）。

实践要点小结

• 只想快速改参数：在 SD 卡创建etc/config.txt，用param set-default <参数> <值>逐行覆盖。
• 只想附加启动应用：在 SD 卡创建etc/extras.txt，用set +e/set -e控制失败是否致命。
• 整机替换启动：在 SD 卡创建etc/rc.txt，将完全取代默认启动序列。
• 需要编译进固件的定制：在boards/<vendor>/<board>/init/添加脚本 + 新建<variant>.px4board声明CONFIG_BOARD_ADDITIONAL_INIT，再用make <target>_var编译。
• SITL 调试模块：进入build/px4_sitl_default/bin，直接执行./px4-<module>；动态模块用dyn ./xxx.px4mod加载。
• 排查启动问题：连接系统控制台查看启动日志，关注set +e下的错误容忍行为，用free检查 RAM，用set -x开启脚本追踪。

• 嵌入式
• 物联网
• 机器人
• 自动驾驶
• 智能硬件