无人机自主导航实战：REAL_DRONE_400从仿真到真机部署

搞无人机自主导航的人，最近应该都绕过不开一个名字：REAL_DRONE_400。这是某高校开源的一套无人机自主导航方案，配合mid360激光雷达，能在没有GPS的室内、桥下、隧道这类场景里完成定位、建图、避障和自主飞行。我花了大概两周时间，从仿真环境到真机部署完整跑通了这套系统，中间把代码、参数、硬件接线、坐标系、PX4配置全都过了一遍。这套东西对做机器人导航、SLAM、无人机决策的研究生和工程师来说，是一个很合适的参考实现。今天把这轮折腾的记录整理出来，从系统架构、仿真快速跑通，到真机部署、常见坑排查，按实操顺序一次讲清楚。

1. 先看懂这套系统到底在跑什么

很多人拿到开源代码就急着编译，结果跑出来一堆乱糟糟的报错，源头问题就是没搞明白代码里的数据流。动手之前先把架构看懂，后面所有问题排查都会顺很多。

1.1 整体架构：感知、规划、控制三层闭环

REAL_DRONE_400本质上是“感知-规划-控制”三层闭环。感知层使用mid360激光雷达，通过FAST-LIO做激光惯性里程计，实时输出机体在全局坐标系下的位置和姿态；规划层拿到里程计信息后，基于局部感知的点云数据生成占据栅格，再由ego-planner在栅格地图中搜索一条无碰撞的轨迹；控制层通过MAVROS把轨迹目标点发送给PX4飞控，飞控内部做姿态和位置控制，驱动电机响应。

这三层各自独立，但通过ROS话题完成数据衔接。感知层输出/Odometry，规划层订阅它并输出/planning/path，控制层订阅路径后把期望位置发给/mavros/setpoint_position/local。理解这条主线之后，任何一个环节跑不动，都能快速定位问题出在哪个话题没有数据。

选择mid360做感知核心，是因为它几乎是为小型无人机设计的。水平视场角360度，垂直视场角约70度，接近一个半球覆盖，重量只有几百克，放在400mm轴距的机架上完全不成问题。而且它的非重复扫描模式能让点云在短时间内覆盖更全面，不像传统旋转雷达那样存在扫描盲区，即使机载CPU算力普通，也能实时处理它的点云。

1.2 源码结构里藏着启动顺序

REAL_DRONE_400的仓库模块划分得很清楚，大致包括雷达驱动、感知算法、规划算法、仿真环境、飞控桥接这几类。启动整套系统时，launch文件的加载顺序也是有讲究的：先启动mid360驱动发布点云，再启动FAST-LIO让它同时订阅点云和IMU数据，之后启动规划器，最后连接MAVROS。

我之前犯过一个低级错误：先把所有节点都启动了，结果FAST-LIO一直等待点云话题超时，规划器又等待里程计话题超时，日志里全是timeout。其实正规的启动顺序就是数据流的反向：先有传感器数据，再做状态估计，最后做规划和指令下发。

1.3 仿真是跑通全流程的第一步

官方仓库提供了Gazebo仿真环境，仿真里也有一套mid360的雷达模型。这意味着不需要接真机、不需要飞控硬件，就能在电脑里验证感知、规划、控制这个链路是否正常。强烈建议所有人在硬件到手前先把仿真跑通，这一步能帮你省掉至少一半的硬件调试时间。

2. 环境准备：先把编译环境收拾干净

这套系统依赖不少，编译顺序搞错了容易浪费时间。我建议按“基础依赖-仿真依赖-雷达驱动-感知规划包”的顺序来。

2.1 系统版本与ROS选型

官方推荐在Ubuntu 18.04或20.04环境下使用ROS Melodic或Noetic。我用的是Ubuntu 20.04加ROS Noetic，整体编译比较顺利。如果还在用Ubuntu 16.04的老环境，建议直接换系统，别在这种过时环境上浪费时间。

PX4仿真需要Gazebo和MAVROS。依赖项可以通过apt安装，ROS Noetic对应的是Gazebo 11，兼容性没有问题。装MAVROS时建议直接用官方二进制包，比源码编译稳定得多。

2.2 编译顺序与常见依赖坑

我的编译顺序是：先编译雷达驱动相关的工具包，再编译FAST-LIO、ego-planner，最后编译REAL_DRONE_400主包。

需要注意一点：FAST-LIO有几个分支，原版对mid360的适配存在一些旧接口问题。我们要选适配mid360的版本，关键看两点，一是支持livox_ros_driver2新版驱动消息类型，二是IMU话题和点云话题的参数能分别独立配置。

编译时最容易出现的错误是缺少livox_ros_driver的动态链接库，因为雷达驱动没有先编译进来。建议在catkin_make之前先单独编译雷达驱动包，然后source一下环境，再继续编译全栈。

2.3 三个必须关注的配置文件

• FAST-LIO的yaml：里面写明了雷达外参、IMU内参、点云话题名、IMU话题名、雷达类型。mid360在旧版FAST-LIO里经常需要手动设置雷达类型为livox，新版本会自动识别。
• ego-planner的yaml：重点关注机身体积、最大速度、最大加速度、地面高度这些参数，仿真可以先用默认值，真机必须调小速度限制。
• 全局地图参数：这里有地图分辨率、局部地图范围、障碍物膨胀半径。默认的0.05米分辨率在仿真里够用，但真机跑起来计算量偏大，可以适当调大到0.1。

配置文件的名称可能在不同版本里略有不同，但核心参数八九不离十。遇到改参数不生效的情况，先检查是否同时存在多个launch加载了同一份yaml，经常会有某个launch文件里写死了参数覆盖了你修改的配置。

3. 仿真环境跑通：五分钟看到点云和轨迹

仿真环境跑通是一个重要里程碑，它验证了编译结果没问题，数据链路也通畅。很多人卡在仿真这一步，而且报错信息五花八门，我来按实际执行顺序写清楚。

3.1 启动mid360雷达仿真

在REAL_DRONE_400提供的Gazebo仿真环境里，雷达插件会生成mid360的点云数据并发布到/livox/lidar这类话题上。启动命令很简洁，拉起来之后Gazebo会加载一架带雷达的四旋翼模型，同时Rviz会把点云显示出来。

这一步如果无法启动，大概率是Gazebo模型库下载超时，要确保网络环境能正常访问Gazebo的模型库资源，或者提前把模型文件放到本地~/.gazebo/models目录。

3.2 启动FAST-LIO和ego-planner

雷达仿真起来后，另开终端运行FAST-LIO的launch文件。FAST-LIO内部会同时订阅点云和IMU数据，IMU数据在仿真里是由Gazebo模型发布，通常话题是/mavros/imu/data或者/imu/data。启动成功后，Rviz里应该能看到里程计轨迹和当前姿态，点云会从杂乱逐渐收敛成清晰的环境轮廓。

再开一个终端启动ego-planner，它能订阅FAST-LIO的里程计输出和点云信息，在局部地图中进行路径搜索。此时在Rviz里手动设置一个目标点，就能看到规划器生成一条从当前位置到目标点的路径，同时机体模型会沿着路径移动。

3.3 怎么判断“跑通”了

我判断仿真是否跑通的标准有三个，缺一不可：Rviz里能看到实时点云且点云贴合环境、FAST-LIO输出的轨迹平滑且没有明显的漂移、规划器在给定目标点后能生成可执行的路径并控制仿真机体完成飞行。

如果点云有但轨迹不动，优先检查点云和IMU有没有进入FAST-LIO。用rostopic echo查看话题频率是一种最直观的方式，点云话题频率至少有10Hz才算正常，IMU频率通常在100Hz以上。IMU没进来、点云容差不够这些异常都会有日志输出，建议开三个终端分别监控三个话题的频率变化。

3.4 仿真里的常见参数问题

仿真器的雷达噪声很小，几乎不会出现真机常见的点云拖影，所以如果仿真里FAST-LIO也跑飘了，通常是坐标系的问题。常见表现是轨迹快速飞出去，点云发散，Rviz里的TF报错。这时去检查TF树，看map到body是否正常连续，livox_frame是否在雷达驱动里正确发布。坐标系不闭合的坑，十个里面有八个是少了一截TF。

4. 真机部署：从仿真切到实机的关键改动

仿真跑通只是拿到了入场券，真机才是真正的考验。从仿真到真机涉及硬件选型、外参标定、PX4配置、安全测试，每一步都有关键改动，缺少任何一个环节都会在飞行时付出代价。

4.1 硬件清单与安装要点

我这里用的是一台400mm轴距的四旋翼，搭载mid360雷达、一块拥有6GB以上显存的机载电脑、Pixhawk系列飞控，运行PX4固件。雷达安装时尽量让雷达坐标系与机架坐标系对齐，减少外参换算误差。安装位置选择机架底部或者顶部中心，保证视场角不被机臂、螺旋桨遮挡。

机载电脑和飞控之间用串口连接，一般要额外配一条电平转换线。建议在通电之前先用万用表确认电压转换模块的输出电压，避免烧坏飞控。别问我为什么强调这个，我确实见过因为转接模块标称错误导致飞控供电异常的案例。

4.2 外参标定：这是精度好坏的分水岭

仿真里雷达和机体坐标系天然对齐，真机则不然，哪怕安装时再仔细，总会有几度的偏角。外参标定不准确，FAST-LIO的里程计输出会有明显漂移，轻则地图失真，重则飞行途中直接偏出航线。

外参标定的方式有很多种：结构简单的安装可以先测量雷达的安装角度，比如俯仰角、横滚角、偏航角，直接写入FAST-LIO的yaml；条件允许的话，用官方标定工具做一次手眼标定更加准确。标定完成后，启动FAST-LIO，观察静止状态下Rviz里的地图是否保持稳定，缓慢旋转无人机时地图是否跟着机体正确转动。如果地图有明显扭曲，说明外参不准，不要开始飞行测试，先回头把标定做扎实。

4.3 PX4固件与机架参数配置

PX4端需要做的配置主要集中在这几块：多旋翼机架选型、位置估计器参数调整、偏移模式设置。

由于整套系统在没有GPS的环境下工作，PX4的位置估计不能依赖GPS，需要根据外部输入的里程计和气压计做数据融合。具体到参数上，需要把对应GPS辅助导航的使能位关闭，允许外部视觉或雷达里程计数据作为位置来源输入。如果配置不正确，飞控会一直报定位质量差，无法切入任务模式。

另一个容易忘的是机架参数。如果选错机架类型，混控器输出可能完全错误，电机转速异常。强烈建议在真机测试前先做一次螺旋桨旋转方向检查，确保每个电机转向和桨叶方向匹配，这在室内飞行时能避免很多意外。

此外，使用MAVROS的offboard模式时，飞控输出的位置设定点频率必须稳定在10Hz以上。如果机载电脑性能不足，建议单独做一个线程保证设定点频率，很多震荡问题其实就是设定点发布掉帧引起的。

4.4 从仿真切换到真机的参数调整

仿真环境里雷达没有真实噪声，地图分辨率取0.05米也跑得动，但真机上这样设置会在感知距离和高频更新之间挣扎。我建议把局部地图分辨率调成0.08到0.1米，最大飞行速度先限制在1米每秒以内，最大加速度限制在1.5米每秒平方以内，确认稳定之后再逐步放宽。

另一个关键差异是雷达驱动的消息类型。仿真里可以兼容新旧消息格式，真机最好统一使用新版雷达驱动，保证时间戳对齐和运动补偿正确。旧版驱动在真机上唯一的“优势”是大家更熟悉，但付出的代价是频繁的时间戳错乱，调试积极性会被严重打击。

4.5 安全测试的正确姿势

真机首飞绝对不能一上来就全自主探索，我当时的测试梯度是：先手动模式下起飞悬停，确认飞控响应正常；再切入offboard模式悬停，让飞控跟随外部位置设定点保持不动；然后设置一个1米外的目标点，观察机体能否缓慢平移到目标点；最后才打开自主规划的完整流程。

每一次测试前都要检查遥控器的模式和急停开关，一旦发现跟踪偏差变大，迅速切回手动模式。无人机的安全事故大多不是系统设计复杂，而是测试梯度跨得太快，把不一致的问题一次性暴露在了高速飞行当中。

5. 真机调试踩坑实录

踩坑是最有学习价值的部分，这里把我实际遇到的几个问题及排查过程写出来，很多代码仓库的issue里也挂着同样的求助帖。

5.1 点云拖影与时间戳错位

第一次在走廊里跑真机，Rviz里看到的点云有很明显的动态拖影，地面都像糊了一层纱。排查后发现是雷达驱动的时间戳与IMU时间戳没有同步，FAST-LIO做状态估计的时候，用了有偏差的时间戳，导致点云配准出现残差。

解决办法是使用新版雷达驱动并开启时间同步功能，同时校准系统时间，保证机载电脑的时钟足够准确。时间不同步在仿真里几乎不存在，但真机上不解决这个，建图和定位质量都上不去。

5.2 FAST-LIO不输出里程计数据

另一个高频问题是FAST-LIO启动后不输出/Odometry话题，或者偶尔输出但很快中断。我遇到的情况是IMU话题没有匹配上，启动日志里一直等待IMU数据。用rostopic list对照FAST-LIO配置里的IMU话题名，改掉不一致的地方问题就消失了。

还有一种可能是点云噪声太大导致FAST-LIO在初始化阶段反复失败，日志里会出现初始化相关错误。这时可以暂时把点云过滤噪声阈值调大，或者把雷达安装得更稳固一些，减少振动带来的点云畸变。

5.3 规划器不发布路径

规划器正常订阅了里程计和点云，但给定目标点后不输出任何路径。这个问题起初以为是规划算法参数没配好，后来发现是local map没有点云进入，规划器在空地图里没法找到任何合法轨迹。检查后发现点云话题的坐标系没对齐，规划器判断点云都在地图范围之外，把坐标系对齐后路径生成就正常了。

5.4 真机飞行时的振荡

把仿真里默认的加速度限制直接搬到真机上，飞行过程中出现明显的前后振荡。振源其实是规划路径的曲率比较突变，而飞控的位置环响应太快，两者不匹配。在ego-planner里把最大加速度降低，并在PX4端适当降低位置控制的比例增益，振荡就缓解了。这个问题提醒我：仿真里的参数和真机的物理特性是两回事，切换时要留出安全余量。

5.5 仿真和真机的点云质量差异

Gazebo的雷达模型几乎不带噪声，点云密度也稳定，而真机在光照、材质、振动等影响下，点云会稀疏、带飞点，远距离区域还会出现断层。这直接影响FAST-LIO的初始化速度和稳定性。建议真机调试时先用遥控器慢速飞行一圈，让算法完成地图初始化，同时观察里程计是否稳定输出，再进入自主规划。真机上多点耐心，比反复重启节点更有效。

6. 常见问题速查表

这份速查表覆盖了我在跑通过程中遇到的大部分问题。遇到新问题时，建议先把Rviz里的话题频率、TF树、日志三个信息源拉出来，绝大多数故障都能快速定位到具体环节。

7. 一点个人体会

跑通REAL_DRONE_400最大的门槛不是编译环境，而是理解整个数据闭环里面坐标系和数据流的走向。我见过有人把雷达驱动、FAST-LIO、ego-planner每个部分分开看都懂，但合在一起就是找不到问题，本质就是没有把握住话题之间的串联关系。先仿真、再真机，先看数据、后调参数，按这个思路做下来，整个过程会顺利得多。

最后分享一个实用的小技巧：真机调试时先找一段L型走廊，遥控器手动飞一趟，把雷达点云、里程计、图像保存下来，离线回放分析每一段的数据变化。这样比直接在线调参试错高效不少，也能避免在飞行现场频繁重启节点。这套系统后续还可以接自主探索算法，配合更大范围的中继通信，在有挑战的室内环境中会展现出更完整的价值。