搞无人机自主导航的人最近应该都绕过不开一个名字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. 常见问题速查表症状可能原因排查方向点云有拖影、地图模糊mid360时间戳与IMU不同步换新版雷达驱动开启时间同步校准系统时间FAST-LIO无里程计输出IMU话题名不匹配或初始化失败rostopic list对比配置查看启动日志检查点云噪声Rviz里TF断链某个frame未发布外参缺失检查TF树确认map-body-livox_frame链路完整规划器不生成路径局部地图无数据或坐标系不对检查点云是否进入代价地图确认坐标系一致真机飞行振荡速度/加速度限制过松调小ego-planner速度加速度降PX4位置环增益Offboard模式切入失败PX4定位源未正确配置检查视觉/雷达里程计辅助定位开关的参数电机响应异常机架类型或混控器选错核对PX4机架参数验证电机转向与桨叶方向编译时报雷达驱动链接错误依赖包编译顺序不对先单独编译雷达驱动再编译整体代码这份速查表覆盖了我在跑通过程中遇到的大部分问题。遇到新问题时建议先把Rviz里的话题频率、TF树、日志三个信息源拉出来绝大多数故障都能快速定位到具体环节。7. 一点个人体会跑通REAL_DRONE_400最大的门槛不是编译环境而是理解整个数据闭环里面坐标系和数据流的走向。我见过有人把雷达驱动、FAST-LIO、ego-planner每个部分分开看都懂但合在一起就是找不到问题本质就是没有把握住话题之间的串联关系。先仿真、再真机先看数据、后调参数按这个思路做下来整个过程会顺利得多。最后分享一个实用的小技巧真机调试时先找一段L型走廊遥控器手动飞一趟把雷达点云、里程计、图像保存下来离线回放分析每一段的数据变化。这样比直接在线调参试错高效不少也能避免在飞行现场频繁重启节点。这套系统后续还可以接自主探索算法配合更大范围的中继通信在有挑战的室内环境中会展现出更完整的价值。
搞无人机自主导航的人最近应该都绕过不开一个名字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. 常见问题速查表症状可能原因排查方向点云有拖影、地图模糊mid360时间戳与IMU不同步换新版雷达驱动开启时间同步校准系统时间FAST-LIO无里程计输出IMU话题名不匹配或初始化失败rostopic list对比配置查看启动日志检查点云噪声Rviz里TF断链某个frame未发布外参缺失检查TF树确认map-body-livox_frame链路完整规划器不生成路径局部地图无数据或坐标系不对检查点云是否进入代价地图确认坐标系一致真机飞行振荡速度/加速度限制过松调小ego-planner速度加速度降PX4位置环增益Offboard模式切入失败PX4定位源未正确配置检查视觉/雷达里程计辅助定位开关的参数电机响应异常机架类型或混控器选错核对PX4机架参数验证电机转向与桨叶方向编译时报雷达驱动链接错误依赖包编译顺序不对先单独编译雷达驱动再编译整体代码这份速查表覆盖了我在跑通过程中遇到的大部分问题。遇到新问题时建议先把Rviz里的话题频率、TF树、日志三个信息源拉出来绝大多数故障都能快速定位到具体环节。7. 一点个人体会跑通REAL_DRONE_400最大的门槛不是编译环境而是理解整个数据闭环里面坐标系和数据流的走向。我见过有人把雷达驱动、FAST-LIO、ego-planner每个部分分开看都懂但合在一起就是找不到问题本质就是没有把握住话题之间的串联关系。先仿真、再真机先看数据、后调参数按这个思路做下来整个过程会顺利得多。最后分享一个实用的小技巧真机调试时先找一段L型走廊遥控器手动飞一趟把雷达点云、里程计、图像保存下来离线回放分析每一段的数据变化。这样比直接在线调参试错高效不少也能避免在飞行现场频繁重启节点。这套系统后续还可以接自主探索算法配合更大范围的中继通信在有挑战的室内环境中会展现出更完整的价值。
