XTDrone+Mid-360+Faster-LIO仿真踩坑全记录：从Gazebo模型到连续建图

做仿真这几年最让我头疼的不是算法本身而是环境搭到一半雷达却出不了点云这类破事。最近折腾XTDrone Livox Mid-360的Gazebo仿真又在Faster-LIO适配这一层卡了好几天。网上关于XTDrone的资料其实不少但大部分都在讲怎么启动无人机、怎么跑通PX4真正把手把手把Mid-360雷达模型挂上去、点云接进Faster-LIO、最后能看到连续建图这件事讲透的文章我翻遍了很多平台都没找到特别完整的。所以这篇直接把我的踩坑过程、最终跑通的配置和几个关键的排错方法整理出来给后面要做Livox系列激光SLAM仿真的人省点时间。这篇内容适合这几类人看想在Gazebo里给无人机加Livox Mid-360做感知仿真、想把Faster-LIO这类激光惯性SLAM算法在仿真环境里先调通再上真机、或者单纯被XTDrone各种模型配置搞得晕头转向的同学。文章里我会把Gazebo雷达模型的插件选型、URDF写法、Faster-LIO的配置文件改动、时间戳同步这些核心问题都拆开讲所有参数和步骤都以我实际跑通的版本为准。1. 方案整体拆解XTDrone、Livox Mid-360与Faster-LIO怎么串起来1.1 先搞清楚XTDrone到底给了你什么XTDrone并不是一个独立的仿真器它更像一套配方——把PX4自动驾驶仪、Gazebo物理仿真、MAVROS通信、QGroundControl地面站这些组件绑定在一起预置好各种无人机模型和传感器模型让你不用从零拼凑。它的核心价值在于你可以在Gazebo里看到一架带旋翼动力学、带飞控、带传感器噪声的无人机然后通过MAVROS和真实PX4完全一致的接口去控制它。这意味着你在仿真里跑的代码切换到真机时只需要改话题名和参数不需要重写逻辑。XTDrone默认带了不少传感器模型包括普通的单线/多线激光雷达、摄像头、IMU、GPS这些。但Livox Mid-360这种非重复扫描的固态激光雷达仓库里虽然有视觉模型但点云仿真方式和你想象中不太一样很多时候需要自己改。1.2 为什么选Livox Mid-360做仿真雷达Livox Mid-360在实机上是一个非常特殊的传感器它采用非重复扫描方式扫描轨迹每帧都在变化短时间内点云会越来越密。水平和垂直方向的视场角分别达到360度和59度垂直方向从-7度到52度最远测距40米10%反射率点频20万点/秒。这个特性让它特别适合无人机——垂直视场角大能同时看到地面、前方和上方而且盲区只有0.1米近距感知能力很强。但在Gazebo里这个非重复扫描恰恰是最难仿真的点。Gazebo自带的射线传感器Ray Sensor是按固定角度步进扫描的出来的点云永远是规则网格状和真实Mid-360的花瓣形扫描轨迹完全不同。后面我会讲到仿真里做了妥协处理用规则扫描来模拟但算法侧感知区别不大。1.3 Faster-LIO是什么它和雷达仿真怎么对接Faster-LIO是LIOLiDAR-Inertial Odometry家族的一个代表性实现核心思路是用迭代扩展卡尔曼滤波器把IMU和激光雷达点云紧耦合在一起实时估算无人机的位姿。它比早期的LIO-SAM轻量不需要回环检测适合算力受限的平台。Faster-LIO对传感器有两个硬性要求一是点云频率不能太低二是IMU频率要足够高这样才能在两次激光扫描之间通过IMU递推位姿。放到Gazebo仿真里衍生出一个实际问题Gazebo仿真中的IMU和雷达都必须以仿真时钟作为时间基准如果驱动节点没有正确设置use_sim_timeFaster-LIO读到的IMU和点云时间戳就会打架轻则警告刷屏重则算法直接发散。这一点我在后面专门用一节来写。2. 核心环节一Livox Mid-360的Gazebo模型搭建细节2.1 雷达模型从哪里来官方模型还是自己写在XTDrone里挂Livox Mid-360有两个路线一是用Livox官方提供的Gazebo模型文件仓库里能找到sensor_mid360相关描述二是自己在URDF/Xacro里新建一个link和sensor然后用Gazebo插件生成点云。我建议优先用官方模型因为它的尺寸、外观、坐标系定义和真实雷达一致后续如果你要从仿真切换到实机坐标系不会出错。官方模型的plugin用的是libgazebo_ros_block_laser.so或者libgazebo_ros_gpu_laser.so本质上还是规则的射线扫描并不是真模拟非重复扫描但点云话题、坐标系、TF这些接口都是对的。如果你所在网络拉不下来官方模型完全可以在XTDrone已有的雷达模型基础上改——大多数情况下XTDrone仓库里已经有livox系列雷达的相关model文件你需要做的事是确认它是否已经挂到了无人机模型上。2.2 URDF/Xacro里怎么挂雷达一个最小可用配置以一个常见的XTDrone无人机模型为例你要在xacro文件里新增一个mid360_link并在gazebo标签里定义传感器插件。下面是我实际跑通过的最小配置传感器挂在机体正下方坐标系为x朝前、y朝左、z朝上。link namemid360_link inertial mass value0.265/ origin xyz0 0 0 rpy0 0 0/ inertia ixx0.001 ixy0.0 ixz0.0 iyy0.001 iyz0.0 izz0.001/ /inertial visual geometry mesh filenamepackage://xtdrone_sim/meshes/mid360/mid360.dae/ /geometry /visual collision geometry mesh filenamepackage://xtdrone_sim/meshes/mid360/mid360.dae/ /geometry /collision /link joint namebase_mid360_joint typefixed origin xyz0 0 -0.05 rpy0 0 0/ parent linkbase_link/ child linkmid360_link/ /joint这里有个细节origin决定了雷达在机体上的安装位置和姿态。Mid-360在实机手册里推荐垂直朝下安装此时坐标系是z轴朝下但在Gazebo模型里我建议保持z轴朝上、雷达朝前安装这样后续Faster-LIO的坐标系变换会简单很多。如果你在实机上用的是倒装尽量在仿真里也模拟倒装提前把外参标定的坑踩完。2.3 点云插件参数怎么配用GPU_Laser还是Block_LaserGazebo里生成激光雷达点云有两种主流插件libgazebo_ros_gpu_laser.so和libgazebo_ros_block_laser.so。前者用GPU渲染射线扫描速度快适合多线雷达后者是CPU射线追踪模型更准确但慢。对于Mid-360我最终选了GPU_Laser原因是Faster-LIO需要较高频率的点云Block_Laser在场景复杂时会把CPU吃满导致仿真帧率骤降进而影响PX4的控制稳定性。我的插件配置如下关键参数我都标注了含义gazebo referencemid360_link sensor typegpu_ray namemid360_sensor pose0 0 0 0 0 0/pose visualizefalse/visualize update_rate10/update_rate ray scan horizontal samples360/samples resolution1/resolution min_angle-3.14159/min_angle max_angle3.14159/max_angle /horizontal vertical samples60/samples resolution1/resolution min_angle-0.122173/min_angle max_angle0.907571/max_angle /vertical /scan range min0.1/min max40.0/max resolution0.01/resolution /range noise typegaussian/type mean0.0/mean stddev0.03/stddev /noise /ray plugin namemid360_controller filenamelibgazebo_ros_gpu_laser.so topicName/livox/lidar/topicName frameNamemid360_link/frameName hokuyo_min_angle-3.14159/hokuyo_min_angle hokuyo_max_angle3.14159/hokuyo_max_angle min_range0.1/min_range max_range40.0/max_range /plugin /sensor /gazebo几个参数解释一下update_rate10Mid-360实机扫描频率是10Hz这里设为10如果觉得Faster-LIO收敛慢也可以临时调到15但要注意和硬件特性保持一致。vertical.samples60用来近似Mid-360垂直方向59度的视场角从-7度到52度采样线数越多点云越密性能开销也越大。60是一个折中。vertical.min_angle-0.122173-7度转弧度。vertical.max_angle0.90757152度转弧度。range.min0.1, max40.0对应Mid-360的0.1米盲区和40米10%反射率量程。noise.stddev0.03对应Mid-360实机约3厘米的测距精度1σ。有一点必须提醒这个插件生成的是PointCloud2还是LaserScan取决于你装的Gazebo ROS插件版本。老版本里GPU_Laser通常输出LaserScan新版本通过output_type参数可以配成PointCloud2。Faster-LIO需要的是点云所以务必要在插件的plugin标签里加上output_typepointcloud2/output_type如果你漏了这一步后面话题虽然叫/livox/lidar但里面是LaserScan消息Faster-LIO解析不了十有八九会卡在等待点云消息这一步。2.4 TF坐标系的坑为什么点云在Rviz里是斜的很多人在Gazebo里挂好雷达后打开Rviz发现点云是倾斜的或者无人机稍微一动点云和模型就错位。这个问题90%出在TF上。XTDrone的无人机模型有base_link、base_footprint这些经典坐标系如果你的雷达link没有正确发布到base_link的TF或者frameName写错了Rviz里点云就只能显示在雷达自身的坐标系里看起来就是飘在空中的。排查方法很直接先跑rqt_tf_tree看TF树确认map - base_link - mid360_link这条链路完整。如果缺了mid360_link到base_link的变换多半是URDF里joint没写对或者robot_state_publisher没正常工作。另一个坑是Gazebo插件的frameName写的是mid360_link但实际模型里雷达link叫base_link/mid360_link这两个名字不一致也会导致点云在错误坐标系里。3. 核心环节二Faster-LIO与仿真雷达的完整适配过程3.1 Faster-LIO原生配置的局限Faster-LIO官方仓库默认支持Livox Avia、Livox Horizon、Velodyne几种雷达配置文件在config/目录下常见的有avia.yaml。它的代码里针对Livox系列雷达做了一些特殊处理比如点云去畸变、非重复扫描的特征提取。Mid-360作为较新的传感器官方仓库不一定直接提供现成的mid360.yaml你需要从avia.yaml复制一份来改。我这边最后跑通的配置关键参数是这么改的。先看common部分common: lid_topic: /livox/lidar imu_topic: /livox/imu time_sync_en: falselid_topic要和Gazebo插件里设置的/livox/lidar一致imu_topic要看你的IMU从哪来。这里有一个重要的设计决策如果用Gazebo里base_link上的IMU仿真插件那么IMU话题通常是/xtdrone/imu或者/mavros/imu/data如果想让雷达自带IMU的效果更真实可以在雷达模型里也加一个IMU插件话题设为/livox/imu。Mid-360实机确实内带一个IMU所以推荐后者。然后是预处理部分preprocess: lidar_type: 1 scan_line: 5 blind: 0.1 point_filter_num: 3lidar_type: 1表示Livox系列这个是Faster-LIO识别Livox点云格式的关键。scan_line原本在Avia里是6Mid-360的非重复扫描轨迹一般按5条等效扫描线处理这是我试了几次之后效果最稳的值。blind是近距离盲区过滤设为0.1米对应Mid-360的盲区。point_filter_num是降采样间隔数值越大参与匹配的点越少算法越快但精度会下降。仿真环境里点云相对干净我试过1到5最终用3速度和精度比较均衡。IMU噪声参数在mapping部分mapping: acc_cov: 0.1 gyr_cov: 0.1 b_acc_cov: 0.0001 b_gyr_cov: 0.0001Gazebo仿真的IMU噪声默认很小如果你把实机的IMU噪声参数搬进去Faster-LIO会很激进地信任激光雷达反而容易发散。仿真里把acc_cov和gyr_cov稍微调大一点让滤波器更平滑效果会好很多。3.2 Livox驱动节点还需要吗livox_ros_driver2与直接读PointCloud2这是一个容易绕晕的点。在实机上Livox雷达需要通过livox_ros_driver2这个驱动把雷达的私有协议转换成ROS标准消息。但在Gazebo仿真里雷达插件本身已经输出了PointCloud2理论上不需要再跑一个驱动节点。那为什么很多教程还是让你装livox_ros_driver2因为Faster-LIO的代码在处理Livox点云时会检查点云消息里是否有Curvature这个字段——这是Livox点云特有的一个通道用来表示点的曲率。普通的Gazebo GPU_Laser生成的PointCloud2没有这个字段Faster-LIO在读取时会报错或者直接跳过所有点。解决的办法有两个方向方法A在Faster-LIO代码里关掉对Curvature的依赖修改lidarFactor.cpp或preprocess.h中相关判断。这个改动对小白不友好容易引入编译问题。方法B让livox点云话题名一致但在Faster-LIO里使用PointCloud2的通用读取方式。我的做法是不改Faster-LIO的源码而是在Gazebo点云输出和Faster-LIO之间加一个中继节点把Gazebo的PointCloud2包装成带Curvature字段的Livox定制点云格式。这个中继节点大概50行Python就能搞定用rospy订阅/livox/lidar_raw重映射后发布到/livox/lidar。代码大致是这样的#!/usr/bin/env python3 import rospy from sensor_msgs.msg import PointCloud2 def callback(msg): # 这里可以做通道重映射把需要字段补齐 pub.publish(msg) rospy.init_node(livox_relay) sub rospy.Subscriber(/livox/lidar_raw, PointCloud2, callback) pub rospy.Publisher(/livox/lidar, PointCloud2, queue_size10) rospy.spin()当然如果你的Gazebo插件本身就能输出带Curvature字段的点云那这一步就省略。实测下来用官方Livox模型配合官方插件时点云格式最接近真机能直接从livox_ros_driver2的/livox/lidar主题拿到带曲率字段的点云用通用GPU_Laser时则需要中继转换。3.3 launch文件怎么改仿真时间、话题重映射、初始位姿Faster-LIO的launch文件里一般会定义两个node一个启动laserMapping主程序一个启动livox_ros_driver2节点。在Gazebo仿真里你要把livox_ros_driver2那个节点去掉改成直接订阅Gazebo的话题同时确保所有传感器节点都使用仿真时钟。我最终的launch文件核心片段如下launch param nameuse_sim_time valuetrue/ node pkgfaster_lio typefaster_lio namefaster_lio outputscreen rosparam file$(find faster_lio)/config/mid360.yaml/ remap from/livox/lidar to/livox/lidar/ remap from/livox/imu to/livox/imu/ /node node pkgtf typestatic_transform_publisher namebase_link_to_camera_init args0 0 0 0 0 0 base_link mid360_link 100/ /launch这里有一个经常被忽略的细节use_sim_timetrue必须放在launch文件顶层或者每个节点的param里因为Gazebo默认时间线是从0开始的仿真时间和系统时钟不同步。如果这个参数在节点启动后才生效节点会认为所有消息时间戳都是过去的直接丢弃表现就是Faster-LIO订阅不到任何点云或IMU数据。另一个点是静态TF。由于我们用了mid360_link但Faster-LIO内部期望点云帧和IMU帧之间有关系最常见的方式是发布一个base_link到mid360_link的静态变换。如果你不想让Faster-LIO输出完全在map坐标系下也可以把初始位姿参数在launch里设0让它从原点开始。3.4 时间戳同步仿真环境里最容易踩的坑如果你在Gazebo里跑Faster-LIO遇到过程序能启动、但建图一片空白或者运行几秒后位置疯狂乱跳的情况大概率就是时间戳问题。仿真环境里时间戳的坑主要有三个来源点云节点设置了use_sim_time但IMU节点没有设置导致IMU时间戳是系统时钟雷达时间戳是仿真时钟两者对不上。Gazebo插件的update_rate和Faster-LIO期望的雷达频率不一致。比如插件是10Hz但mid360.yaml里通过extrinsic_T或blind等参数推算出来的期望频率是20Hz算法内部时间差会累积。电脑性能不足Gazebo的仿真时钟变慢real time factor降到了0.5以下但Faster-LIO以为时间是匀速流动的导致卡尔曼滤波增益计算错误。我推荐的粗暴解法是所有与仿真相关的节点统一在launch里指定param nameuse_sim_time valuetrue/不要只在一个节点上设置。同时用rostopic hz /livox/lidar和rostopic hz /livox/imu确认两者的实际频率若IMU频率低于100Hz说明仿真负载太高需要降低点云采样密度或者关闭Gazebo的渲染。4. 完整实操流程从零把XTDrone Mid-360 Faster-LIO跑通4.1 环境准备ROS版本和XTDrone版本怎么选我建议直接按XTDrone官方文档推荐的组合来Ubuntu 20.04 ROS Noetic PX4 1.13或1.14 Gazebo 11。如果你非要在Ubuntu 22.04 ROS2 Humble下跑Faster-LIO有ROS2分支XTDrone也有对应的ROS2版本但插件配置和话题类型差异很大不建议第一次就挑战。在开始之前确认以下内容已经安装XTDrone并且能正常启动xtdrone_gazebo一个基础世界无人机能起飞。已经安装Faster-LIO并编译通过。编译时建议用catkin_make或catkin build前先source /opt/ros/noetic/setup.bash。已经安装rviz和rqt_tf_tree调试离不开。在正式操作前我还习惯先跑一个最小验证启动Gazebo空世界手动用spawn_model命令把一个单独的Mid-360模型加载进去看Rviz里有没有点云。这样把雷达问题从大型无人机系统中隔离出来排查起来轻松很多。4.2 把Mid-360挂到XTDrone的无人机上XTDrone加载无人机的入口在xtdrone/sitl_config和xtdrone/worlds目录具体是哪架无人机取决于你launch时指定的模型名称。在XTDrone里无人机的sdf/xacro模型定义通常在PX4-Autopilot/Tools/sitl_gazebo/models下XTDrone也会复制一份到自己的models目录。我们需要把上文写好的mid360_link和joint加到无人机模型的xacro文件里同时把对应的Gazebo插件也塞进去。实际操作时要注意xacro的include顺序。XTDrone的无人机模型文件本身可能已经include了一些common传感器比如GPS、磁力计如果你把雷达插件的定义直接追加在文件末尾Gazebo加载时可能会因为sensor name重复而报错。一个稳妥的办法是单独写一个mid360.xacro然后在无人机主文件里用xacro:include filename.../引进来避免和原文件里已有的雷达插件冲突。改完模型文件后启动XTDrone的无人机仿真cd ~/xtdrone roslaunch xtdrone_sim xtdrone_quadrotor.launch这个launch会启动Gazebo世界、PX4 SITL、MAVROS等。如果修改没有生效先检查终端里有没有模型加载失败的报错再用gz model --list看看当前世界里的模型列表确认无人机里是否真的有mid360_link。4.3 启动Faster-LIO并观察建图模型加载完成、点云话题连续输出后就可以启动Faster-LIO了。先打开两个终端终端1source ~/catkin_ws/devel/setup.bash roslaunch faster_lio mapping_mid360.launch终端2source ~/catkin_ws/devel/setup.bash rviz -d ~/catkin_ws/src/FAST_LIO/rviz_cfg/mid360.rviz打开Rviz后添加PointCloud2显示话题选择/cloud_registeredFaster-LIO输出的注册点云固定坐标系选择map。这时你应该能在地面看到一个由点云构成的平面这就是初始帧。在无人机不动的情况下Faster-LIO输出的轨迹应该稳定在原点附近点云不会出现重影或虚影。如果此时点云是糊的先不要急着起飞检查雷达的noise.stddev参数是不是设得太大或者IMU噪声参数是否合理。稳定后你可以通过QGroundControl手动解锁并起飞给一个缓慢的上下运动指令观察点云地图是否跟着一起扩展。我实测在XTDrone默认的树林场景里Mid-360 Faster-LIO能比较稳定地建出周围环境的地图但前提是飞行速度不要超过1m/s转弯时姿态角速度不要太大毕竟仿真雷达只有10Hz点云密度比实机低不少。4.4 仿真里怎么验证建图精度很多人在仿真里把Faster-LIO跑起来了但不知道怎么判断建得准不准。最简单的方法是看/path这个话题把Faster-LIO输出的轨迹和XTDrone提供的真值轨迹可以通过MAVROS的/mavros/local_position/odom获取放在同一个Rviz里对比。如果轨迹重影严重说明累积漂移大要么是IMU参数不对要么是点云配准失败。另一个方法是做闭合检测让无人机绕着一个建筑物飞一圈回到起点。用Rviz的测量工具看看起点和终点的轨迹位置是否重合。Gazebo仿真里没有完美的真值但闭合误差通常应该在0.3米以内超过1米就要检查配置。5. 常见问题与排查技巧实录5.1 Gazebo界面一直闪、仿真卡顿怎么办这个问题在NVIDIA显卡和Intel核显的机器上都可能出现表现是Gazebo窗口疯狂闪烁或者画面撕裂。排查顺序如下先确认显卡驱动。运行glxinfo -B如果没有输出或者报错说明OpenGL环境有问题需要安装mesa-utils。对于NVIDIA机器在启动launch前设置环境变量export LIBGL_ALWAYS_SOFTWARE1强制软件渲染。这个一开画面虽然会稍微变慢但不会再闪烁。如果软件渲染导致Gazebo太卡可以改回来然后在Gazebo的~/.gazebo/gui.ini里把渲染引擎改成OGRE 2.1兼容模式。如果闪烁只在点云显示时出现问题在Rviz的GPU渲染上可以把Rviz的Advanced选项里的Use GPU关掉或者把点云显示的Decay Time调小。5.2 点云没有输出或话题不存在在Rviz里看不到任何点云先用rostopic list | grep livox确认话题是否存在。如果话题不存在问题在Gazebo插件没加载检查终端里有没有类似[WARN] [GazeboRosGpuLaser]: Plugin not attached的警告。通常原因是gazebo referencemid360_link里的reference名字和URDF里的link名字不一致或者插件XML放在了sensor外面。如果话题存在但没有任何消息先用rostopic hz /livox/lidar看频率。频率为0说明插件没有在发布。一个隐蔽的坑是 Gazebo的仿真时钟暂停了。有时候你启动了launch但Gazebo的pause按钮被误触整个世界是静止的所有传感器都不会输出。在Gazebo窗口下方的工具栏点击Play按钮即可。这个原因看起来蠢但真的会把人卡住半天。5.3 点云全是NaN或空点点云消息有、但值全是NaN大概率是射线打到了min_range以内的物体或者射线根本没有命中任何物体比如雷达朝下安装时如果无人机模型没有地面射线会打到无穷远然后被转成NaN。解决办法是把min0.1/min调小或者确保无人机初始位置距离地面在0.5米以上不要贴着地面启动。另一个原因是GPU_Laser的更新频率和GPU渲染不同步。把插件的update_rate从10降到5试试如果NaN消失说明是渲染竞争导致的。5.4 Faster-LIO启动后立即崩溃崩溃有几种典型表现段错误或者Segmentation fault一般是点云消息里的字段不完整比如没有Curvature字段。按我在3.2节讲的方法加中继节点或者把点云转成sensor_msgs::PointCloud2后手动补充字段。程序卡在Waiting for LiDAR dataIMU数据到了但LiDAR没到。检查Gazebo插件是否真的在发布rostopic echo /livox/lidar -n1看看有没有header。启动后几秒内位置飞到十万八千里IMU和雷达时间戳不同步或者IMU数据方向反了。检查IMU话题的z轴是否朝上、加速度是否约等于重力加速度9.8。Gazebo仿真里没有真实的加速度计偏置如果你把acc_cov设得太小滤波器会过于信任IMU导致微小的噪声被放大。时间戳问题的排除我建议使用下面这个命令看消息延迟rostopic echo /livox/lidar/header/stamp -n1 rostopic echo /livox/imu/header/stamp -n1对比两条消息的秒和纳秒部分如果一个是仿真时钟比如123.456一个是系统时钟比如1688000000.123那就不用怀疑了就是use_sim_time没设全。我把这些常见问题整理成一个速查表格方便你对照排查问题现象直接原因解决方法Gazebo窗口闪烁OpenGL渲染冲突设置LIBGL_ALWAYS_SOFTWARE1或更新显卡驱动话题不存在插件未加载 / link名不匹配检查gazebo reference与URDF link名话题存在但无数据Gazebo暂停 / 插件未发布点击Gazebo Play按钮检查update_rate点云全是NaN射线未命中 / 近距离盲区降低min_range确保无人机离地足够高Faster-LIO不订阅点云话题名不一致 / use_sim_time未设核对launch中的remap统一时间源建图轨迹发散IMU时间戳不同步 / 噪声参数过小统一use_sim_time调大acc_cov6. 一些我趟过之后觉得值得说的经验真要说起来这套环境里最耗时间的不是算法参数而是仿真物理传感器模型和算法预期之间的缝隙。第一个经验是仿真里不要追求和实机一模一样的点云形态。非重复扫描是Mid-360的灵魂但在Gazebo里很难完美复现。如果只跑Faster-LIO规则扫描的GPU_Laser已经足够了因为LIO算法本质上是对点云做特征提取和配准对扫描轨迹的细节不敏感。只有当你要做感知、避障或者目标检测时才需要花心思去模拟非重复扫描的分布密度。第二个经验是模块化验证比一次性整体启动高效得多。我强烈建议先单独把雷达模型加载到一个空世界里确认点云能出、TF树完整再放进XTDrone。如果一上来就启动整个XTDrone出了问题你会很难判断是雷达模型的问题、PX4的问题还是MAVROS的问题。我甚至会在启动Faster-LIO之前先用pcl_viewer或者Rviz静态观察几秒钟点云确认点云的坐标系和无人机机体坐标系大致对齐再让算法上跑。第三个经验是关于Livox雷达的坐标系外参。Mid-360的官方坐标系定义中z轴沿着雷达的旋转轴x轴指向雷达的正前方。在URDF里挂载雷达时很多人习惯用rpy0 0 0但如果你的XTDrone模型中base_link的x轴指向机头方向而雷达安装时为了美观做了90度旋转那你必须在joint里显式写出这个旋转否则点云会整体偏转90度。这类问题在仿真里不会报警但会导致建图结果扭曲非常难排查。最稳妥的办法是写完URDF后先在Rviz里把雷达的点云和无人机的3D模型同时显示出来直观检查点云是否在正确方位。最后再分享一个小技巧如果你想在仿真里测Faster-LIO的抗噪能力不要只调Gazebo插件里的stddev。更真实的做法是给IMU加一个缓慢漂移的bias模拟温度变化引起的陀螺仪零偏变化。Gazebo的IMU插件自带bias参数你可以设置一个非常小的值比如bias0.001/bias然后观察Faster-LIO在长时间飞行中是否能通过激光雷达的观测来估计并补偿这个bias。如果能说明你的算法配置是健康的如果直接发散那大概率是IMU和雷达的时间同步还有问题。这一步做完你对这套系统的理解会比单纯跑通demo深很多。