这几年无人机圈子聊室内定位十个里有八个都在问同一个问题没有GPS无人机到底靠什么知道自己飞到了哪。尤其是我最近在折腾的这个项目——融合Mid360激光雷达和光流传感器做室内无GPS自主定位从硬件选型到算法调通踩了不少坑也攒了一堆实实在在的经验。这篇就完整复盘一下这套方案的来龙去脉、核心细节和实操指南给正打算入坑无GPS导航的朋友一份能直接照着做的参考。这套东西能解决什么问题呢说白了就是让无人机在没有卫星信号的厂房、地下车库、仓库、隧道这些地方依然能知道自己“在哪、往哪飞、飞多快”并且在此基础上实现定点悬停、航点飞行、自主返航甚至避障。市面上很多工业级室内无人机用的方案要么贵得离谱要么封闭不透明。我这套走的是开源飞控开源SLAM消费级传感器的路子成本可控代码可见软硬件都有二次开发空间。适合有ROS基础、想深入研究自主定位原理的飞手、机器人工程师、算法方向的学生。整个系统的核心思路并不复杂激光雷达负责构建高精度空间地图并算出精确位姿光流传感器负责在激光退化、点云稀疏的瞬间兜住速度估计两者各管一段再用滤波算法融合最终输出一个即使单传感器失效也能撑几秒的稳健定位结果。1. 方案设计与整体思路1.1 为什么选择“激光雷达光流”这套组合先回答一个很多人问过我的问题室内定位有UWB、有视觉SLAM、有反光贴标定为什么非要折腾激光雷达和光流原因很简单UWB需要提前布设基站姿态和位置解算依赖基站几何分布无人机一旦飞出基站覆盖范围就成了废铁。视觉SLAM对纹理要求高昏暗厂房、白墙、重复纹理环境下特征点大量丢失定位精度断崖式下跌。反光贴方案更是只适合固定路线巡检机器本身没有环境感知能力。激光雷达不同。它主动发光不受光照影响建筑结构、货架轮廓、管道支架都能产生稳定回波在室内环境里天然有优势。但纯激光SLAM也有软肋——特征稀疏的长走廊、玻璃幕墙、空旷大厅里点云约束不足位姿估计会漂移而且快速旋转运动时雷达点云畸变严重容易把地图“扯花”。光流传感器恰恰补上了这个短板。光流测的是图像平面上的像素运动速度不依赖绝对环境特征对地面纹理的敏感度远低于视觉SLAM。它在短时间内的速度测量非常平滑能够为激光位姿提供连续的速度约束帮SLAM撑过退化场景也能在点云匹配跳变的瞬间拉住速度估计不飞掉。所以这套组合的本质是激光雷达管“绝对定位”光流管“相对速度”两者各取所长用滤波把优势捏合到一起。这就好比你开车时高精地图告诉你当前在哪条车道激光SLAM车速表告诉你当前跑多快光流哪怕GPS丢星车速表和地图加一起也能让你知道车大概在什么位置。1.2 系统架构与数据流设计这套系统的整体架构分三层清晰地把“感知、计算、控制”拆开了。第一层是传感器层Mid360激光雷达通过以太网口连接机载计算机光流模块通过I2C接口连接飞控飞控内置的IMU惯性测量单元同时为飞控和机载计算机提供高频加速度与角速度数据。第二层是计算层机载计算机运行Livox驱动、激光SLAM算法我用的是FAST-LIO和扩展卡尔曼滤波EKF融合节点。激光雷达点云进入SLAM输出6自由度位姿光流速度与加速度数据进入EKF与激光位姿融合输出一个高频、平滑、鲁棒的最终位姿估计。第三层是执行层飞控以MAVLink协议接收机载计算机发来的视觉位姿vision_pose在Pixhawk的EKF2扩展卡尔曼滤波里把这些信息与IMU、光流数据进一步融合生成控制指令给电机。为什么这样分层核心原因是算力分配。激光SLAM的点云配准和地图更新非常吃CPU必须放在性能强的机载计算机上而飞控的EKF2运行频率高达数百赫兹擅长处理高频低延迟的姿态估计。两层EKF各管一段互不干扰即使其中一环断开底层飞控依然能靠IMU维持短时间的姿态稳定不至于直接炸机。这套架构里有一个细节值得注意激光雷达和光流的时间戳必须对齐。激光SLAM输出的位姿、光流输出的速度、IMU输出的加速度三者的时间基准如果不一致融合时会产生严重的相位误差导致无人机飞行时出现“慢半拍”的抖动。我的做法是用ROS的use_sim_time统一管理时间戳同时在飞控侧通过EKF2_AID_MASK参数开启vision time delay补偿具体调参后面细说。2. 硬件选型与安装布署2.1 核心传感器选型对比整个项目里最关键的硬件就是Mid360和光流模块选型的时候我做了不少对比这里直接给出我的结论。Mid360是Livox推出的一款360度非重复扫描激光雷达最大测距40米90%反射率水平视场角360度垂直视场角从-7度到52度。相比传统机械式雷达它的优势是体积小直径64mm高65mm、重量轻约265g、功耗低约7W而且非重复扫描模式让它在静止时也能逐渐累积覆盖视场角内的所有区域点云密度随时间提升特别适合室内低速飞行。相比Livox的另外两款产品AVIA和HorizonMid360的垂直视场角更大近距离盲区更小更适合安装在无人机上朝斜下方安装兼顾前方避障和下方建图。光流传感器我试过三种PX4FLOW、基于PMW3901芯片的光流模块比如Bitcraze的Flow Deck v2、以及基于OpenMV的光流。PX4FLOW自带声呐但帧率低、体积大已经属于过时方案。OpenMV灵活性高但需要自己跑算法消耗机载CPU资源实时性不好保证。PMW3901是纯硬件光流芯片功耗极低输出4自由度运动信息x/y运动、z轴旋转配合一个激光测距仪就能算出真实平移速度是目前性价比最高的选择。我最后选了PMW3901模块加一个VL53L1X激光测距模块的组合挂在飞控的I2C总线上一体的成熟模块很多接线也简单。关于IMU飞控自带的ICM-20689已经够用不需要额外增加高精度IMU。但如果预算允许在机载计算机和雷达之间串一个独立的IMU比如BMI088做外参标定会更好因为雷达自带的IMU环境震动干扰较大独立IMU的数据更容易标定这里看个人需求。2.2 传感器安装位置与减震细节安装布局决定了系统能不能稳定工作以下几点的优先级很高是我踩过坑之后才悟出来的。Mid360的安装位置要保证下方和前方不被机身遮挡。我一开始把它装在机架正中央结果被电池支架挡住了一半的垂直视场点云里始终有一块扇形空洞SLAM算法在空边缘处频繁出现匹配跳变。后来把雷达前移到机架头部下方留出约120度的无遮挡扇形区域问题立刻消失。具体安装角度建议让雷达水平面朝下倾斜10到15度这样既能扫描到前下方地面又能兼顾前方障碍物。光流模块必须安装在机架底部正中镜头垂直朝下不能被起落架、脚架、挂载件遮挡。安装高度建议距离地面至少10cm以上避免近场纹理模糊。VL53L1X激光测距模块和光流镜头尽量靠近安装这样高度测量和光流速度测量对应的是同一块地面区域误差更小。震动是传感器安装的天敌有两处必须做好减震。第一处是飞控的减震棉原厂自带的有时候厚度不够我用了两层3M VHB胶垫叠加实测IMU加速度噪声下降明显。第二处是Mid360和机架之间建议加一块薄的泡棉双面胶不要用硬连接否则电机高频震动会直接传给雷达导致点云出现周期性畸变。但注意减震垫不能太软否则雷达自身旋转惯性会引发共振点云反而更散。还有一个容易被人忽略的细节机载计算机和雷达必须共地。我在调试时遇到过一次诡异问题雷达偶尔丢包重连后却一切正常排查了一周才发现是雷达和电脑的USB/以太网口没有共地地电位漂移导致信号不稳定。用一根短线把两边金属外壳接在一起后问题彻底消失。2.3 整机供电设计与电池选型供电是整个系统稳定性的隐形基础。Mid360需要12V供电光流模块需要5V机载计算机我用的是NVIDIA Jetson Orin NX需要5VDC但电流要求高飞控有独立的电源模块给伺服和接收机供电。一套电池要同时供这么多设备电源分配就必须精心设计。我的做法是动力电池经过电源模块Power Module给飞控供电同时通过一个5V/5A降压模块给机载电脑供电再通过一个12V升压/降压模块给Mid360供电。光流模块直接从飞控的I2C排针取5V电电流不到200mA飞控供电足够。关键原则是动力电机用电和传感器用电要分开走线大电流负载电机急加速时的电流尖峰不要和传感器共用同一条线否则瞬间压降会让传感器复位重启。电池容量方面我这套系统整机功耗大约30到35W雷达7W、机载电脑15到20W、飞控光流加外设5W、其他损耗用4S 4200mAh锂电池实测悬停能飞约18分钟慢速巡航约12分钟。如果你要飞长走廊巡检这类任务建议用到4S 6000mAh以上或者考虑外接充电宝给机载电脑单独供电延长续航。3. 核心算法与定位实现3.1 激光SLAM框架选型为什么是FAST-LIO室内定位领域开源激光SLAM框架不少最常用的三个是LOAM/LIO-SAM、FAST-LIO/FAST-LIO2、Cartographer。各有特点但在“机载计算机性能有限传感器是Livox雷达需要快速落地”这个前提下FAST-LIO是最优解。LIO-SAM的思路是先做帧间配准再用因子图优化效果很稳但它对IMU预积分和雷达外参的依赖度极高标定不到位会出现明显漂移而且LIO-SAM的定位线程和建图线程开销大在Jetson Orin NX上跑倒是没问题但在更小的设备上会吃力。Cartographer在2D场景很强3D场景在室内多楼层时地图闭环依赖回环检测对机载算力和实时性的要求也比较高。FAST-LIO2用迭代扩展卡尔曼滤波IESKF把雷达点云和IMU紧耦合在一起核心优势有两个一是计算量小因为它不维护完整的局部地图只维护一个增量式体素地图ikd-Tree每次扫描只匹配一个小邻域CPU占用远低于LIO-SAM二是它对Livox雷达的原生支持非常好官方代码里直接有Livox系列的驱动和标定参数接口兼容性不用折腾。我最终选择了FAST-LIO2版本是2022年的最新主分支。编译一次通过跑了一天就把室内走廊的点云地图建出来了精度在5cm以内这个技术栈在民用机器人领域已经非常成熟。如果你也需要做跑图、测绘这类有较高精度要求的任务这个框架是推荐考虑的首选。它的静态地图输出PCD文件还能直接用于后续的路径规划配合Rviz可视化检查建图质量效率很直观。3.2 光流传感器的数据读取与速度解算光流模块输出的原始数据不是速度而是像素位移或者说光流值格式通常是x方向像素位移、y方向像素位移、质量指标quality和旋转量Z轴角速度。要把它变成实际速度需要一个关键转换光流值乘以高度再除以一个比例系数才能得到米/秒。具体公式是( V_x \frac{f_{low} \times H}{f_{ocal}} )其中( f_{low} )是光流传感器输出的x方向像素速度H是光流镜头到地面的实时高度从VL53L1X激光测距读出来focal是镜头焦距像素单位一般在90到200之间。光流模块的datasheet里一般会给出焦距Bitcraze Flow Deck v2在2.8mm镜头上大约是95像素不同模块可能不一样必须查datasheet确认不能用默认值否则速度会偏差非常大。这个公式背后的物理意义很直观同一个地物飞得越高它在画面里移动的像素越少同样的像素速度高度越高实际平移速度越快。你可以想象坐飞机看地面和站在地上看汽车完全是两个尺度。所以光流的解算必须配合测距仪实时高度不能假定固定高度。在飞控侧PX4的EKF2原生支持光流输入只要把光流模块接到I2C总线在QGroundControl里把EKF2_AID_MASK中的光流选项打开PX4就会自动用光流数据辅助导航。这是最简单的方案。但如果光线变化剧烈比如飞过LED灯下方、或者地面是纯色光滑地砖光流质量会急剧下降所以我在飞控EKF之上又做了一层机载计算机的EKF融合只把光流当作激光位姿的“趣味补充约束”而非主信息源这样即使光流瞬间失效也不会带崩整个定位。3.3 机载端EKF融合把位姿和速度绑在一起为了让激光SLAM位姿和光流速度在机载计算机内部先融合一遍我在Ubtuntu的ROS环境里写了一个轻量EKF节点输入三个话题/livox/lidar点云经FAST-LIO输出位姿/optic_flow/velocity光流解算速度/mavros/imu/data飞控IMUEKF的状态向量是9维位置三轴、速度三轴、姿态四元数或欧拉角用四元数会更准。预测方程用IMU加速度积分更新方程用激光位姿和光流速度交替更新。这里有个最重要的调参心得激光位姿和光流速度的方差噪声协方差设置不能凭感觉。激光位姿在点云丰富、静止或缓速平移时方差可以设置得很小比如位置0.01m、姿态0.01rad因为它绝对准。但在快速旋转、点云畸变、特征稀疏时激光位姿会出现跳变方差要放大到0.1m甚至更大否则EKF会被跳变带飞。光流速度的方差在纹理良好、高度稳定的情况下设到0.05m/s一旦光流质量指示值quality低于阈值动态把方差调大10倍甚至100倍让EKF自动减少对光流的信任。动态调整方差这个技巧非常管用能显著提升系统鲁棒性。具体做法是在光流回调函数里读质量值如果低于150PMW3901的质量范围通常是0到255就把协方差矩阵中的对应项临时改为1.0下一条高质量数据来了再改回来。融合后的最终位姿通过/mavros/vision_pose/pose话题发给飞控PX4收到后在EKF2里和IMU、光流再次融合最终控制无人机飞行。这套“双EKF”架构也许有人觉得冗余但实际飞行中给我带来了更强的安全感即使飞控侧EKF因为异常丢掉了光流机载端EKF依然能继续输出平滑位姿不会立刻失控。4. 实操配置与调参4.1 软件环境与依赖安装我的开发环境是Ubuntu 20.04 ROS Noetic机载电脑是Jetson Orin NX 16GB版本刷的JetPack 5.1.2自带OpenCV和CUDA编译FAST-LIO不需要额外装太多东西。先装依赖sudo apt-get install ros-noetic-pcl-ros ros-noetic-velodyne-msgs ros-noetic-livox-ros-driver编译FAST-LIO2cd ~/catkin_ws/src git clone https://github.com/hku-mars/FAST_LIO.git cd .. catkin_make source devel/setup.bashLivox驱动的编译要单独处理因为Livox官方驱动有些依赖需要从源码构建cd ~/catkin_ws/src git clone https://github.com/Livox-SDK/livox_ros_driver2.git cd livox_ros_driver2 ./build.sh ROS1 cd ~/catkin_ws catkin_make我建议先把雷达跑起来看Rviz里的点云是否正常再进SLAM避免算法问题、传感器问题混在一起难排查。4.2 标定流程内参、外参一个都不能少FAST-LIO2自带的配置文件里config/avia.yaml对应AVIAconfig/mid360.yaml对应Mid360但里面的外参矩阵留着的是默认值必须改成自己的。内参标定针对Livox雷达用官方工具livox_camera_calib或者livox_laser_camera_calibration需要打印一张标定板对着雷达扫这个过程通常10分钟能跑完。Mid360出厂时内参已经经过工厂标定所以如果你不接相机可以跳过雷达-相机内参标定直接用出厂参数但雷达本体到IMU的外参必须自己量。我的Mid360安装在机架前方相对飞控坐标系大概是x方向前移0.08m我往前挪过雷达所以平移量有点大y方向居中z方向比飞控高0.03m翻滚角约-8度雷达下倾安装俯仰约3度偏航约0度。但用尺子量出的尺寸只能当作初值直接拿来跑SLAM会发现地图“飘”尤其是转弯时地图连线错开。最终精度靠的是在线标定FAST-LIO2自带外参在线估计功能在配置文件里把参数extrinsic_est_en设为true跑一段包含旋转和平移的飞行数据不需要飞起来手拿飞机绕各轴转几圈就行算法会在初始化阶段自动优化外参。优化完成后把输出写到配置里再把extrinsic_est_en改回false这样系统更稳定。如果你外参量错了激光SLAM的表现会很有趣平移偏差在直行时几乎看不出来但转弯和往返飞行时地图会出现“错位重影”姿态估计也会跟着抖动。所以如果发现地图重影先别怀疑算法大概率是外参问题。4.3 FAST-LIO2关键参数调优FAST-LIO2的mid360.yaml核心参数我按踩坑经验整理了一份推荐初始值实际调试时可以根据场景动态微调。参数名推荐值含义与调参建议point_filter_num2或3抽稀比例值越大点云越少。室内场景设2合适点数太多会让CPU达到极限太少会导致匹配退化max_iteration3迭代EKF的最大迭代次数设太大影响实时性太小精度不足cube_side_length20ikd-Tree局部地图边长单位米。室内20米够用大厂房建议25至30米filter_size_surf0.4体素滤波叶子大小太大容易丢细节太小计算量大0.4在Orin NX上能跑到实时extrinsic_est_entrue标定时标定完成后改为falselidar_type11为Livox系列0为Velodyne别选错time_scale1e-3时间戳单位换算Livox雷达的时间戳是纳秒填1e-3表示毫秒务必对照说明书确认错一个数量级整个系统都会乱还有一个参数容易忽略filter_size_cur它是当前扫描的体素滤波叶子大小值越大匹配越粗糙但速度越快。我常用0.25也就是飞行时逐帧抽稀比较多、但地图细节保留的折中方案。我这里特别想强调time_scale这个坑。Mid360的时间戳单位是纳秒但有些固件版本输出的是毫秒甚至秒错一个数量级FAST-LIO会认为点云时间跨度极长或极短出现“点云在当前帧里穿来穿去”的诡异现象。遇到这种情况直接看点云在Rviz里是否静态如果点云内容在抖动、闪烁、变形先查时间戳换算。4.4 飞控EKF2参数配置与定位切换机载计算机EKF融合后的位姿发给飞控后PX4的EKF2需要配置才能相信这个外部位置信息。在QGroundControl的参数面板里重点调这几个EKF2_AID_MASK必勾选“vision position fusion”和“vision yaw fusion”前者告诉EKF2把视觉位姿当位置源后者让偏航角也听从视觉信息。注意如果你的雷达外参偏航不精确可以只勾位置融合让磁力计负责偏航室内磁干扰大的话再启用vision yaw。EKF2_HGT_MODE高度源选“Vision”因为室内气压计受桨叶气流影响大会漂几米视觉高度激光雷达点云Z轴准确得多。EKF2_EV_DELAY视觉位姿的延迟补偿单位是毫秒。我实测机载电脑的管线大约耗时30到50ms设成35ms左右具体可以扫一个斜坡看QGC里估计位置是否“拖尾”有拖尾就减少延迟提前就增加延迟。EKF2_EV_POS_X、EKF2_EV_POS_Y、EKF2_EV_POS_Z视觉传感器这里就是Mid360相对于飞控中心的安装位置偏移量单位米。这个参数经常被漏设但漏设会导致定点飞行时的位置目标与实际位置存在固定偏差比如飞机明明没动机头坐标系计算的期望位置却偏了20cm。配置完成后把模式切换为Offboard并在飞行模式里选择“Position”此时无人机的定点、航线飞行都会基于融合后的视觉定位结果。首次试飞前建议先一只手扶着无人机、另一只手在遥控器上轻推油门确认位置模式下Pixhawk能对抗你的推力自动回中再放手飞。5. 常见问题与避坑实录5.1 激光退化场景的识别与处理室内激光SLAM有几种经典退化场景处理不好定位必飘。第一种是长直走廊。沿走廊方向没有特征约束激光点云只提供侧墙的约束导致沿走廊方向的位置漂移会逐渐累加。处理办法有几个一是把光流速度信息的信任权重调高让它担任走廊方向的定位主力二是在飞行策略上避免纯直线高速运动人为控制无人机左右微幅摆动制造横向特征约束三是前期预扫描全程建图飞行时关闭地图更新只做纯定位匹配地图的全局一致性大幅提升。第二种是玻璃幕墙和镜子。Mid360的905nm激光打在玻璃上大概率穿透打在镜子上直接偏折结果就是那一片区域完全没有点云SLAM里出现“黑洞”。这种情况无解只能通过避开该区域或依靠其他传感器冗余。座位紧急预案我在EKF融合节点里加了一条逻辑如果激光位姿的协方差连续100帧超过阈值就切换为纯光流IMU模式控制权保持飞机不会漂移太远等雷达重新看到特征后再自动切回SLAM模式。第三种是空旷大厅。墙面距离超过10米点云密度骤降匹配约束不够。小型场景还好但展馆大厅这种空旷大空间实测FAST-LIO的性能会明显下降。我的经验是提前降低飞行速度、增加激光雷达帧率、确保雷达垂直视场里至少有地面特征。5.2 光流数据的“虚假运动”与失效判断光流传感器在低纹理或强光下极易输出“虚假运动”。纯色木地板、磨砂亚克力板、黑暗中灯光直射的地面都会让光流模块输出一个虚假的平移速度。判断光流是否可信我在程序里设了三个条件光流质量值必须大于阈值PMW3901设180以上低于这个值大概率是纹理不够。x、y方向速度变化率不能突变超过0.5m/s否则视为无效跳变。距离传感器测距值必须在0.2m到8m范围内超出范围光流完全不可信。这三点全部满足光流速度才输入EKF只要有一个不满足EKF就暂时忽略光流观测项。实测这套逻辑大大减少了误触发用在飞控EKF2里也一样如果你发现飞控一直在朝某个方向缓慢飘移大概率就是光流“看到了”一个不存在的运动先检查地面纹理和质量值。5.3 MAVLink传输带宽与延迟的取舍机载电脑向飞控发送视觉位姿的频率不是越高越好。PX4的EKF2外部视觉融合频率实测20到30Hz就很够用太高反而挤占MAVLink带宽导致遥控器和数传数据卡顿。MAVROS发布vision_pose话题时我设置了30Hz的节流QGC里显示EKF2接收视觉数据的频率也在30Hz左右飞控大约使用其中一半的数据量。延迟是另一个隐患。我早期用WiFi数传调试机载电脑和地面站之间延迟高但视觉位姿走的是机载电脑和飞控之间的串口/UART线缆不经过数传所以延迟很低。这里有一个大家容易犯的错用USB线把飞控直接连到机载电脑时MAVROS用的串口波特率默认921600但如果飞控的SER_TEL2_BAUD设置成57600数据会被严重降速视觉位姿到达延迟甚至超过100ms。我遇到过一次飞机悬停时持续高频震荡查了一圈才发现是这个原因。建议使用115200以上波特率并严格检查飞控端串口速率。5.4 实机飞行前的安全检查清单室内飞行空间小一旦失控撞墙撞人后果比室外严重得多。我整理了一份每次试飞前的检查单建议打印出来贴在工位电池电量大于30%机载电脑电压稳定所有传感器接线牢固雷达和光流镜头无遮挡在QGC里确认飞控收到vision position并显示“EKF good”状态Rviz中点云无异常畸变、SLAM状态正常、EKF协方差收敛遥控器模式开关打到Position并验证一键切换在飞行区域中央预留2到3米安全距离确认周围无易碎物和人员第一次试飞全程手动代偿手不离遥控器随时准备切回手动模式第一次飞行我强烈建议不要上自动航线先做定点悬停测试。无人机起飞到1米高度放手观察它在无杆量输入下能否自己保持在20cm范围内的位置误差内。如果它开始缓慢画圈、来回飘基本可以断定EKF融合有问题这时候绝对不能上楼先把地检问题解决再飞。结尾个人经验与扩展思路这套系统全链路跑下来我最大的感触是室内无GPS定位的技术门槛并不在某一项传感器或某一个算法上而在于所有传感器、算法、控制环节之间的协同和容错设计。每个单独的模块单独拿出来都有成熟方案但把它们组合到一起让它们在错误的上下文里“知道该相信谁”才是真正花时间的地方。我的建议是如果你也要做类似项目不要一上来就追求复杂功能。先把FAST-LIO跑通拿手持设备录制几段bag数据在仿真环境里旁路回放调参确认SLAM本身稳定后再接入光流然后是EKF最后才上真机。每一步都单独验证出问题时定位范围小得多不会从头怀疑到尾。最后再分享一个小技巧在机载电脑里保存一份param_backup.yaml把每次飞行前所有关键参数外参、协方差、延迟补偿、EKF参数都打进去命名带上日期。因为调参是一个漫长的过程有时候你明天改了一个参数后天发现变差了想回滚却发现不记得昨天的值是多少。有了这套备份你随时能回到任何一个历史状态这在长时间调试项目里救了我好几次。这套方案的扩展空间也很大。后端接上全局路径规划就能实现室内多点巡检加一个语义分割模型可以识别货架和托盘换成更大机架还能挂载机械臂做简单抓取。希望这篇实践记录能帮你在室内自主定位这条路上少踩几个坑飞得又稳又远。