我先说我自己的结论这套环境你能搭起来不代表你会用能跑起来才算是真正入门了无人机轨迹跟踪。我去年第一次在 Ubuntu 上玩 PX4、Gazebo、ROS2 三件套的时候前三天全耗在 Gazebo 窗口乱闪和微消息桥接上。等我把整条链路彻底跑通回过头看发现真正值钱的经验不是某个安装命令而是搞清楚每个模块为什么这么设计、出了错该往哪个方向查。这篇就把我踩过的坑和最终验证过的完整流程按顺序写清楚。这套环境适合两类人一类是刚接触无人机仿真想在完全不碰硬件的条件下验证飞行逻辑的初学者另一类是自己写 ROS2 轨迹规划或控制算法想用真实的 PX4 飞控做闭环验证但还没打通接口的开发者。我会把版本怎么选、固件怎么编、仿真怎么联调、ROS2 怎么桥接、轨迹跟踪节点怎么写以及高频故障怎么排查一次讲透。1. 这套全栈到底在做什么版本选型决定成败1.1 三个组件怎么分工轨迹跟踪的逻辑链路是什么很多人把 PX4、Gazebo、ROS2 当成三个独立的软件来装却忽略了它们是一整条数据链路。搞清楚分工后面调试会轻松很多。PX4 是飞行控制系统负责姿态估计、位置控制、状态机切换以及各种安全逻辑。在仿真环境里它并不直接运行在飞机硬件上而是以 SITLSoftware In The Loop的方式作为一个进程运行把真实的传感器输入换成 Gazebo 给出来的仿真数据。Gazebo 则是物理仿真平台负责模拟重力、空气阻力、电机推力、地面接触以及 IMU、GPS、气压计等传感器数据。你可以把它理解成一个虚拟现实物理引擎的组合体PX4 命令输出给 GazeboGazebo 把计算结果反馈给 PX4形成一个动态闭环。ROS2 在这里面充当的是外部算法接入层。你在机器人领域写的路径规划、目标检测、状态估计等算法都是通过 ROS2 的话题与 PX4 交互。轨迹跟踪仿真要做的事情就是由 ROS2 节点发布期望位置或者期望速度PX4 接收后通过自己的控制器生成油门和姿态指令最终驱动 Gazebo 里的无人机完成飞行动作。这个逻辑链路是ROS2轨迹生成节点 → /fmu/in/trajectory_setpoint → PX4位置控制器 → 姿态控制器 → 电机指令 → Gazebo物理引擎 → 传感器数据 → PX4状态估计 → /fmu/out/vehicle_local_position → ROS2反馈很多人一开始只关心怎么能飞忽略了闭环反馈这一层。轨迹跟踪的核心是跟踪误差你必须能拿到实时的位置反馈把期望轨迹和实际轨迹放在一起对比否则谈不上跟踪。1.2 版本组合对照Ubuntu/ROS2/PX4/Gazebo 该配对用版本选择会直接决定你后面三天是顺利还是爆炸。这里不是越新越好而是匹配才能跑。下表是几组我实际见过且验证过的组合组合UbuntuROS2PX4 版本Gazebo适合场景经典稳定20.04Foxyv1.13Gazebo 11老教程多但 ROS2 桥接方案较旧推荐组合22.04Humblev1.14.3Gazebo 11社区大量示例基于此uXRCE-DDS 成熟较新组合24.04Jazzyv1.15Gazebo Harmonic新特性多但启动命令和话题命名有变化我推荐第一次搭建选择 Ubuntu 22.04 ROS2 Humble PX4 v1.14.3 Gazebo 11。原因很简单当前绝大部分可复现的教程、示例代码、问答帖子都是基于这套组合写出来的。你遇到问题到社区搜索的时候最容易匹配到答案。PX4 v1.13 之前使用 FastRTPS 桥接 ROS2配置复杂。PX4 v1.14 开始默认使用 uXRCE-DDS消息配置和通信稳定性都大幅改善。v1.15 之后的版本将默认仿真器切换为新的 Gz Harmonic启动命令从make px4_sitl gazebo变成了make px4_sitl gz_x500这对新手来说又是一层额外的学习成本。所以先用 v1.14 把链路跑通以后再升级也不迟。1.3 我的选型建议先稳定跑通再追新特性还有一个原则就是不要在同一时间引入太多变量。如果你用的是 24.04 的新系统、Jazzy 的新 ROS2、Harmonic 的新 Gazebo还有 PX4 最新 main 分支那么任何一个环节出问题你都不知道是哪个版本引起的。我自己的做法是系统固定 22.04ROS2 固定 HumblePX4 checkout 到具体的 release tag而不是直接使用 main 分支。这样环境稳定遇到问题可以排除版本因素。另外要注意的是PX4 的 main 分支是持续集成版本别人今天发出来的教程可能是基于昨天的一个 commit 写的明天就可能失效。用 release 版本能最大程度保证可复现。2. 基础环境准备装好 ROS2 和 PX4 依赖一次到位2.1 系统初始化与常用工具在开始之前请确保你用一个独立的 Ubuntu 22.04 系统。虚拟机也可以但要注意给足内存和 CPU否则编译固件会非常痛苦建议至少 8GB 内存、4 核以上。打开终端先把系统基础工具补齐sudo apt update sudo apt upgrade -y sudo apt install -y git curl cmake build-essential ninja-build pkg-config \ python3-pip python3-venv python3-jinja2PX4 的构建脚本会用到很多 Python 包包括empy、jinja2、pyros-genmsg等。这些会在下一步的官方脚本里自动安装但如果你提前用 pip 装过某些包注意版本冲突。比如empy的版本如果不对就会导致 ROS2 消息编译失败。2.2 ROS2 的安装与验证ROS2 Humble 的安装建议严格参照官方步骤。先把 apt 源添加好sudo apt install -y software-properties-common sudo add-apt-repository universe -y sudo apt update然后安装 ROS2 主包。我建议直接安装桌面版因为它包含了 rviz2、demo 节点和大量工具后面调试很有用sudo apt install -y ros-humble-desktop ros-dev-tools安装完成后把环境变量写进 bashrc避免每次手动 sourceecho source /opt/ros/humble/setup.bash ~/.bashrc source ~/.bashrc验证一下环境是否正常ros2 --help ros2 topic list如果ros2命令能找到说明 ROS2 核心安装成功。此时ros2 topic list应该只有一个空列表因为还没有运行的节点。2.3 PX4 源码与官方工具链脚本PX4 的官方仓库提供了自动话环境脚本可以省去大量手工安装依赖的时间。先克隆源码mkdir -p ~/workspace cd ~/workspace git clone --recursive https://github.com/PX4/PX4-Autopilot.git px4_firmware cd px4_firmware git checkout v1.14.3 git submodule update --init --recursive这里有两个小技巧。第一一定要加--recursive克隆PX4 用了大量子模块存放 Gazebo 模型、MAVLink 消息定义等第二checkout 到 release tag 后务必再执行一次git submodule update这能把子模块也切换到对应的版本状态。接着运行官方环境脚本bash ./Tools/setup/ubuntu.sh这个脚本会安装 Gazebo 11、gstreamer、Python 依赖、编译工具链等一堆东西。中途会要求输入 sudo 密码也可能弹窗询问 locale 设置按照提示完成即可。这一步是耗时大项网络正常的情况下通常需要 10 到 20 分钟如果中途断网或者被 CtrlC 中断直接重新运行脚本通常能继续不需要从零再来。2.4 一个小验证Gazebo 能不能独立启动在编译固件之前值得先验证一下 Gazebo 本身是否能正常运行避免后面排错时混在一起gazebo --version gazebo /usr/share/gazebo-11/worlds/empty.world正常情况下会弹出一个空的仿真世界画面里只有地面网格和天空。这一步如果出现窗口闪烁、黑屏、闪退先别急着往下走直接把图形驱动问题解决掉否则后面每一步都看不到飞行动画。这个问题我会在后面的故障排查章节展开讲。3. PX4 SITL 与 Gazebo 联调先让无人机在仿真里飞起来3.1 编译 SITL 固件进入 PX4 源码目录执行命令cd ~/workspace/px4_firmware make px4_sitl gazebo这句命令做了两件事编译无人机固件然后在 Gazebo 里启动一个默认的四旋翼模型。编译时间取决于机器配置一般需要 15 到 30 分钟。第一次编译时终端会输出大量 C 编译日志不要关掉终端。编译完成并启动后你会看到两个新窗口一个终端变成了 PX4 控制台pxh另一个是 Gazebo 窗口里面有架橙色的小四旋翼在跑道模型旁边。如果你没看到 Gazebo 窗口或者窗口一闪而过多半是环境变量没配对后面排查。3.2 启动 Gazebo 与 QGroundControl接下来下载并启动地面站软件 QGroundControl。去 PX4 官网下载对应 Linux 版本下载下来后先赋予执行权限chmod x ./QGroundControl.AppImage ./QGroundControl.AppImageQGroundControl 启动后会自动通过 UDP 14550 端口发现刚才启动的 SITL 仿真无人机。你会发现界面左侧的 HUD 显示已连接地图上出现飞机图标位置通常在世界原点附近GPS 状态为 3D Fix。这是因为 SITL 模式自动模拟了 GPS 信号。看到这个连接成功说明 PX4 固件、Gazebo 仿真、MAVLink 通信这一层完全打通了。如果你不需要做视觉传感器仿真只是验证飞行逻辑这套已经够用。3.3 不用地面站也能起飞SITL 控制台命令有些场景下你不会打开 QGroundControl比如批量跑测试。此时可以直接在 PX4 控制台里输入命令起飞pxh commander takeoff 10这条命令会让无人机自动起飞到 10 米高度。在真实飞行中起飞前需要解锁、检查 GPS、检查安全开关但在 SITL 里这些条件基本都会自动满足。起飞后在 PX4 控制台里可以查看状态pxh commander status pxh topic listener -n 1 vehicle_attitude pxh topic listener -n 1 vehicle_local_positiontopic listener是 PX4 内置的 uORB 话题监听命令能看到数据就说明状态估值正常。如果你之前没在 Gazebo 窗口里看到螺旋桨转动先执行commander takeoff手动控制的方式后面再折腾。3.4 确认仿真链路完整无人机能在仿真中飞起来还只是第一步。后面的轨迹跟踪需要的是外部节点跟飞控通信所以在继续之前最好确认一下 MAVLink 层是否真的稳定。你可以拉动 QGroundControl 的虚拟摇杆或者发送一个简单的 setpoint在 PX4 控制台里观察vehicle_local_position数值变化。如果这些都正常就可以放心进入 ROS2 桥接阶段了。此处最容易犯的错误是Gazebo 窗口看起来在动但 ROS2 里抓不到任何话题所以先把基础链路验证扎实才不至于后面摸黑排查。4. 打通 ROS2 与 PX4micro-ROS 代理、px4_msgs 和话题验证4.1 为什么 PX4 要通过 uXRCE-DDS 桥接 ROS2PX4 内部用的消息总线叫 uORB它是针对飞控嵌入式场景设计的极简发布订阅机制不直接兼容 DDS。ROS2 用的是 DDS 分布式通信协议。两者之间需要一个翻译官。这个翻译官在 PX4 新版本里就是 uXRCE-DDS 协议。PX4 固件内部运行一个 XRCE-DDS 客户端通过 UDP 把 uORB 消息序列化后发送给外部运行的 micro-ROS agent。micro-ROS agent 收到后再把消息以标准 DDS 形式转发到 ROS2 网络里。所以你需要同时具备三样东西PX4 固件里的客户端功能默认编译进去、外部 micro-ROS agent、以及 ROS2 端的消息定义px4_msgs。4.2 编译并启动 micro-ROS agent先安装依赖并克隆代码cd ~/workspace source /opt/ros/humble/setup.bash git clone --recurse-submodules -b humble https://github.com/micro-ROS/micro_ROS_Agent.git cd micro_ROS_Agent colcon build source install/setup.bash编译完成后启动 agentros2 run micro_ros_agent micro_ros_agent udp4 --port 8888 -r dds注意--port 8888是 PX4 默认的 uXRCE-DDS 端口不要写成别的。-r dds表示使用 ROS2 的 DDS 发现机制这样才能让 ROS2 节点看到来自 PX4 的话题。启动后终端会停留在监听状态此时 PX4 还没连接上来。如果终端报端口被占用可以先用netstat -tulnp | grep 8888查看占用情况多半是有残留的 agent 进程没有杀干净。接下来去 PX4 控制台在 pxh 提示符下输入pxh uxrce_dds_start udp -p 8888如果你看到 agent 终端里出现Client connected之类的日志说明握手成功。如果 PX4 提示已经启动过或者 agent 日志没有反应先检查两边的端口是否一致。4.3 创建 px4_msgs 工作区为了让 ROS2 节点能正确解析 PX4 发来的消息需要用到官方定义的消息包px4_msgs。创建 ROS2 工作区并克隆mkdir -p ~/ros2_ws/src cd ~/ros2_ws/src git clone https://github.com/PX4/px4_msgs.git cd ~/ros2_ws source /opt/ros/humble/setup.bash colcon build构建成功后把工作区环境加到 bashrcecho source ~/ros2_ws/install/setup.bash ~/.bashrc source ~/.bashrc注意px4_msgs一定要和你的 PX4 固件版本匹配。如果你用的是 v1.14.x 固件就用 v1.14.x 对应的 px4_msgs 版本否则可能出现字段名对不上的问题。4.4 发布和订阅验证让仿真数据在 ROS2 里流动桥接打通后在另一个终端里查看话题ros2 topic list | grep fmu我这边看到的是这样一类话题/fmu/in/offboard_control_mode /fmu/in/trajectory_setpoint /fmu/in/vehicle_command /fmu/out/vehicle_attitude /fmu/out/vehicle_local_position /fmu/out/vehicle_status然后尝试订阅位置话题ros2 topic echo /fmu/out/vehicle_local_position --once如果你能打印出一串坐标数据恭喜PX4 和 ROS2 已经真正打通了。后面就可以从 ROS2 节点里给飞控发指令实现轨迹跟踪。这里有一个很多新手踩过的坑用ros2 topic echo某些话题时迟迟不打印数据。原因通常是 QoS 策略不匹配。PX4 发布的传感器类和位置类话题默认是 BEST_EFFORT 可靠性策略而你用默认的 RELIABLE 去订阅就接收不到。后面写节点时订阅这些话题也要显式把 QoS 设置成 BEST_EFFORT。5. 轨迹跟踪仿真实战从起飞到画圆的完整流程5.1 离板控制协议与话题格式轨迹跟踪本质上是离板控制。所谓离板是指飞控不再自己按照预设任务飞行而是完全接受来自外部计算设备每秒发送的设定点。在 PX4 中离板控制涉及三个核心话题/fmu/in/offboard_control_mode告诉飞控你现在要用位置控制、速度控制还是姿态控制解除内部控制模式。/fmu/in/trajectory_setpoint具体的期望位置/速度/加速度设定点。/fmu/in/vehicle_command用于切换飞行模式、解锁电机等指令。三个话题里offboard_control_mode必须像心跳一样持续发布频率至少 20Hz否则飞控会认为通信中断退出离板模式并进入安全逻辑。这也是很多自己写节点的同学最容易忽略的细节只发轨迹点不发控制模式标志飞控根本不认。5.2 写一个 30Hz 的轨迹跟踪节点下面这个节点实现的功能是先让飞机在当前位置稳定悬停然后切换离板模式最后发布一个半径 5 米、高度 10 米的圆轨迹。节点每 30 毫秒发送一次数据也就是大约 30Hz。#!/usr/bin/env python3 import math import rclpy from rclpy.node import Node from rclpy.qos import QoSProfile, ReliabilityPolicy, HistoryPolicy from px4_msgs.msg import OffboardControlMode, TrajectorySetpoint, VehicleCommand, VehicleLocalPosition class OffboardTrajectory(Node): def __init__(self): super().__init__(offboard_trajectory) qos QoSProfile( reliabilityReliabilityPolicy.BEST_EFFORT, historyHistoryPolicy.KEEP_LAST, depth10, ) self.pub_offboard self.create_publisher( OffboardControlMode, /fmu/in/offboard_control_mode, qos) self.pub_traj self.create_publisher( TrajectorySetpoint, /fmu/in/trajectory_setpoint, qos) self.pub_vehicle_command self.create_publisher( VehicleCommand, /fmu/in/vehicle_command, qos) self.sub_pos self.create_subscription( VehicleLocalPosition, /fmu/out/vehicle_local_position, self.position_callback, qos) self.pos None self.counter 0 self.offboard_set False self.start_time None self.timer self.create_timer(0.033, self.loop) def position_callback(self, msg): self.pos msg def pub_offboard_control_mode(self): msg OffboardControlMode() msg.timestamp int(self.get_clock().now().nanoseconds // 1000) msg.position True msg.velocity False msg.acceleration False msg.attitude False msg.body_rate False self.pub_offboard.publish(msg) def pub_trajectory_setpoint(self, x, y, z, yaw0.0): msg TrajectorySetpoint() msg.timestamp int(self.get_clock().now().nanoseconds // 1000) msg.position [float(x), float(y), float(z)] msg.yaw float(yaw) self.pub_traj.publish(msg) def set_offboard_mode_and_arm(self): cmd VehicleCommand() cmd.timestamp int(self.get_clock().now().nanoseconds // 1000) cmd.target_system 1 cmd.target_component 1 cmd.command VehicleCommand.VEHICLE_CMD_DO_SET_MODE cmd.param1 1.0 cmd.param2 6.0 self.pub_vehicle_command.publish(cmd) arm VehicleCommand() arm.timestamp int(self.get_clock().now().nanoseconds // 1000) arm.target_system 1 arm.target_component 1 arm.command VehicleCommand.VEHICLE_CMD_COMPONENT_ARM_DISARM arm.param1 1.0 arm.param2 0.0 self.pub_vehicle_command.publish(arm) self.offboard_set True def loop(self): if self.pos is None: return self.counter 1 self.pub_offboard_control_mode() if not self.offboard_set and self.counter 5: self.set_offboard_mode_and_arm() if self.counter 20: x self.pos.x y self.pos.y z self.pos.z self.pub_trajectory_setpoint(x, y, z) else: if self.start_time is None: self.start_time self.get_clock().now().nanoseconds * 1e-9 t self.get_clock().now().nanoseconds * 1e-9 - self.start_time radius 5.0 omega 0.3 x radius * math.cos(omega * t) y radius * math.sin(omega * t) z -10.0 yaw math.atan2(y, x) self.pub_trajectory_setpoint(x, y, z, yaw) if self.counter % 30 0: dx (self.pos.x if self.pos else 0.0) - (x if x in locals() else 0.0) dy (self.pos.y if self.pos else 0.0) - (y if y in locals() else 0.0) dz (self.pos.z if self.pos else 0.0) - (z if z in locals() else 0.0) err math.sqrt(dx * dx dy * dy dz * dz) self.get_logger().info(ftrack error: {err:.2f} m) def main(argsNone): rclpy.init(argsargs) node OffboardTrajectory() try: rclpy.spin(node) except KeyboardInterrupt: pass finally: node.destroy_node() rclpy.shutdown() if __name__ __main__: main()这个代码里有两个地方值得仔细看。第一OffboardControlMode里我把position置为 True其余置 False这样飞控知道外部下发的是位置设定点。第二轨迹参数里z -10.0因为 PX4 使用 NED 坐标系Z 轴向下为正负值才代表高度。这是新手最容易搞反的坐标方向一旦写反飞机会一头栽向地面。5.3 启动验证跟踪圆轨迹并观察误差先确保之前的 PX4 SITL 和 micro-ROS agent 还在运行。然后另开一个终端先让无人机起飞pxh commander takeoff 10等无人机稳定在 10 米高度后在 ROS2 终端里启动轨迹节点cd ~/ros2_ws source install/setup.bash python3 offboard_trajectory.py正常现象是节点先输出若干次 track error 等于 0 或很小的值因为前 20 个周期在发当前位置设定点。之后无人机开始往圆形轨迹上飞误差先变大再收敛稳定后误差通常在 0.1 到 0.3 米之间。如果误差一直跳变很大或者无人机原地不动、越飞越偏再回头检查 QoS 设置和坐标系方向。在地面站里你还能看到航点轨迹QGroundControl 会把飞机的位置画出来。不过我更喜欢用ros2 topic echo配合自己的日志来评估跟踪效果ros2 topic echo /fmu/out/vehicle_local_position --field x --field y --field z --once如果后续想做更细致的分析可以把vehicle_local_position和期望轨迹都录成 rosbag离线回放并用 matplotlib 画图。5.4 扩展换成 8 字形或任意三维轨迹圆轨迹验证通过后把loop()函数里的参考轨迹换成 8 字形非常简单。做法是把 x、y 的生成公式改成利萨如曲线x radius * math.sin(omega * t) y radius * math.sin(2 * omega * t)如果想让轨迹点的生成和飞控命令解耦可以把轨迹生成部分拆成独立的 ROS2 包发布一个自定义的参考轨迹话题再由控制节点订阅并转发给 PX4。这样你就有了一个参考轨迹层 离板控制层的干净架构后面替换新算法时不用碰飞控通信代码。6. 高频问题排查闪烁、超时、话题丢失的根因链路6.1 Gazebo 窗口闪烁或闪退怎么办为什么 Gazebo 界面一直在闪是我见过的最常见问题。这通常不是 Gazebo 本身的 bug而是 GPU 渲染环境的问题。排查链路先走一遍第一步确认渲染方式glxinfo | grep renderer如果输出里有llvmpipe而不是你的显卡型号说明 Gazebo 在用 CPU 软件渲染。这种模式下 3D 画面很容易出现闪烁、卡顿或者黑屏。第二步安装显卡驱动。双显卡笔记本先确认当前使用的显卡prime-select query如果是nvidia没问题如果是intel或on-demand导致 GL 上下文不稳定。可以切换为 NVIDIA 独显模式或者反过来尝试intel模式因为有些老仿真的驱动和独显的 OpenGL 版本冲突。第三步针对软件渲染的情况可以临时让 Gazebo 走兼容管道export LIBGL_ALWAYS_SOFTWARE1 export GZ_IP127.0.0.1 gazebo如果是高 DPI 屏幕导致的渲染异常加上export QT_AUTO_SCREEN_SCALE_FACTOR0这里有个细节LIBGL_ALWAYS_SOFTWARE1会让画面更稳定但性能会下降。如果只是验证轨迹不影响使用如果要做视觉仿真就必须把显卡驱动真正配好。6.2 micro-ROS agent 连不上 PX4 的排查顺序连接失败时按下面的顺序排查不要乱试第一步确认 agent 是否真的在监听对应端口。agent 终端应该显示当前端口和套接字状态。第二步在 PX4 控制台里看客户端状态。输入pxh uxrce_dds_start udp -p 8888如果提示Could not start或者反复重启查看系统日志确认端口没有被防火墙拦截。SITL 默认走本地回环一般不会受防火墙影响但如果你的环境里跑着多个 SITL 实例端口可能会有冲突。第三步确认 DDS 域 ID 一致。默认情况下都是 0一般不用改。但如果你为了控制不同仿真实例设置了export ROS_DOMAIN_ID1那么 PX4 侧的 DDS 域也要对应调整否则两边永远发现不了对方。6.3 ROS2 看不到 /fmu/out 话题的原因如果能用ros2 topic list看到/fmu/out/vehicle_local_position但 echo 时没数据大概率是 QoS 不匹配。PX4 的传感器数据默认以 BEST_EFFORT 发送ROS2 CLI 默认用 RELIABLE 订阅收不到很正常。解决办法是在自己写的节点里把订阅的 QoS 设置成qos QoSProfile( reliabilityReliabilityPolicy.BEST_EFFORT, historyHistoryPolicy.KEEP_LAST, depth10, )另外有些话题本身不是持续发布的比如/fmu/in/vehicle_command它是命令型消息只会下发一次。用ros2 topic echo监听它本来就什么都等不到这不代表通信断了。如果连ros2 topic list都看不到/fmu/out系列话题那基本是 agent 没有连接成功回到上一节检查。6.4 编译和运行的经典坑编译 PX4 时最容易遇到的是子模块缺失。如果启动 Gazebo 时报找不到sitl_gazebo相关路径多半是克隆时没有加--recursive或者子模块没有完整拉取。修复方法cd ~/workspace/px4_firmware git submodule update --init --recursive编译时内存不够导致进程被杀可以将并行编译数调低make px4_sitl gazebo -j2还有一种情况是旧的 build 缓存和新版本代码冲突。切换版本后如果编译出现莫名其妙的错误直接清理构建目录再重来rm -rf build/px4_sitl_default make px4_sitl gazebo这些坑都不难解决关键是别在一个问题上反复重试先清理环境、确认版本、再重建通常都能解决。7. 环境跑通之后怎么把它变成日常开发工具到这里你已经有了一个完整的全栈仿真环境PX4 负责飞控逻辑Gazebo 提供仿真场景ROS2 负责外部算法通信你自己写的轨迹节点可以随时下发期望轨迹并读取跟踪误差。我在实际使用中慢慢养成几个习惯这里一并分享。第一把整个启动流程固化成 launch 文件或者 tmux 会话PX4 终端、agent、QGroundControl、轨迹节点各占一个面板省去每次手动开终端找目录的麻烦。第二每次跑轨迹之前先开ros2 topic list确认桥接正常再起飞这能避免飞了才发现话题没连上的尴尬。第三把vehicle_local_position的轨迹记录下来用 Python 脚本画期望轨迹与实际轨迹的对比图比肉眼看仿真画面靠谱得多。这套环境本质上是一个闭环验证平台你可以在上面快速测试各种轨迹算法、调 PID 参数、甚至扩展成多机协同仿真。只要你把底层链路理解透了以后无论是换飞机模型、换传感器噪声配置还是把控制器替换成 MPC 或强化学习都只是在一个稳定基座上做小改动不会再陷入从零到一的漩涡里。