☰
基于Livox MID360的20m/s高速避障无人机:传感器选型与系统设计
2026/9/28 1:48:14 网站建设 项目流程

1. 为什么偏偏是Livox MID360:高速避障的传感器选型逻辑

做高速避障无人机,第一个绕不开的问题就是:用什么传感器去“看”世界。超声波响应慢、作用距离短,视觉方案在强光或暗光下容易翻车,传统机械式激光雷达虽然成熟,但体积大、重量高、动辄上万元,装到一台追求20m/s飞行速度的穿越机上,基本等于给短跑运动员绑了沙袋。我前后试过三种方案,最后锁定Livox MID360,原因很实在。

MID360是一款非重复扫描的固态激光雷达,重量约265克,测距范围在80米左右(对10%反射率目标约40米),水平视场角360度,垂直视场角-7度到52度,点频最高约20万点每秒。这几个参数放在一起,意味着它用一颗雷达就能覆盖机身周围几乎全部方向,不需要像机械式雷达那样靠旋转去拼凑视野,也不像某些固态雷达只有前向一个窄锥角。对于高速飞行来说,前向和侧向的感知盲区越小,留给飞控的反应时间就越充裕。

这里要解释一个关键点:为什么高速避障对“视场角”这么敏感。假设无人机以20m/s飞行,前方30米出现障碍物,从探测到需要完成减速或转向,总时间只有1.5秒。如果雷达只有前向60度视场,那么当无人机做急转弯时,侧方障碍物可能在转弯过程中才进入视野,此时距离已经很近。MID360的360度水平视场让机身四周始终处于感知范围内,飞控在做横向机动时不需要“扭头”去看,这是高速场景下非常实际的收益。

另一个选它的理由是点云密度和帧率。MID360单帧点云在非重复扫描模式下,随着积分时间增加,覆盖会越来越密。对于避障来说,我们不需要每帧都做完整建图,而是要在几十毫秒内判断出“哪个方向有障碍、距离多少”。它的数据输出频率和ROS驱动成熟度,让整个感知链路可以跑在机载计算机上,不需要额外下传处理。

当然,选它也有代价。MID360的点云是非重复扫描的,单帧看起来比较稀疏,直接拿单帧做障碍物聚类容易漏检。我的做法是累积3到5帧再做处理,用时间换密度。这个取舍在后面讲数据处理时会详细展开。

注意:MID360对强光直射比较敏感,正对太阳飞行时点云噪声会明显增加。实际飞行尽量避开正午逆光航线,或者给雷达加装遮光罩。

2. 整机架构设计:从雷达数据到电机响应的完整链路

2.1 硬件拓扑与算力分配

一台能跑20m/s避障的无人机,硬件上不能只是“把雷达装上去”那么简单。我的配置是:机架用5寸穿越机改装的碳纤维框架,轴距约250mm,动力系统选6S电池配2806.5电机和5.1寸三叶桨,悬停油门在35%左右,最大推力推重比约4:1。这个动力冗余是为了在高速下还能有足够的加速度去做紧急避让。

飞控用Pixhawk 6C,刷PX4固件。机载计算机用Jetson Orin Nano,负责跑雷达驱动、点云处理和局部路径规划。雷达通过以太网连接到Orin Nano,飞控和Orin Nano之间用串口做MAVLink通信。整个链路是:MID360出点云 → Orin Nano做障碍检测和避障决策 → 通过MAVLink发送速度或位置设定点给PX4 → PX4控制电机执行。

这里有一个容易踩坑的地方:很多人把雷达直接接到飞控上,指望飞控自己处理点云。PX4虽然支持避障,但它的算力有限,处理20万点每秒的点云根本不现实。正确的分工是机载计算机做重活,飞控只负责稳定控制和执行设定点。Orin Nano的算力足够跑一个轻量级的点云处理管线,同时留出余量给视觉或其他任务。

2.2 坐标系与安装标定

雷达装到机架上,必须做外参标定。MID360的坐标系定义是:X向前,Y向左,Z向上。安装时尽量让雷达的X轴和机头方向一致,Z轴和机体垂直。如果安装有偏差,点云里的障碍物位置就会和实际位置对不上,避障逻辑会误判。

我的做法是:先把雷达用减震球固定在机架顶部,尽量靠近重心位置,减少飞行振动对点云的影响。然后在平地上放一个已知位置的障碍物,手动记录点云中障碍物的坐标,和实际坐标对比,算出旋转和平移偏差。如果偏差在5厘米和2度以内,基本可以接受。超过这个范围,需要在ROS里加一个静态变换节点做补偿。

提示:MID360的IP地址默认是192.168.1.1XX网段,如果机载计算机的网段冲突,需要先改雷达IP。改IP用Livox Viewer或者SDK里的配置工具,改完记得重启雷达。

2.3 供电与振动处理

MID360的功耗约6瓦,供电电压9到27伏,可以直接从6S电池经BEC降压到12伏供电。但要注意,雷达对电源噪声比较敏感,最好单独用一个低噪声BEC,不要和电调共用一路电源。我试过和电调共用,点云里会出现规律性的噪声条纹,换了独立BEC之后就干净了。

振动是另一个隐形杀手。高速飞行时电机振动会通过机架传到雷达,导致点云在垂直方向上出现“拖尾”。我的处理是在雷达和机架之间加四颗硅胶减震球,同时在PX4里把雷达的安装位置设置为远离振动源。如果振动仍然明显,可以在点云处理前加一个统计滤波,把明显偏离主体的点去掉。

3. 点云数据处理:从原始数据到障碍物地图

3.1 驱动安装与数据接收

在Orin Nano上跑MID360,官方提供了ROS和ROS2的驱动包。我用的是ROS2 Humble,安装livox_ros_driver2,配置好雷达IP和主机IP后,启动驱动节点,就能在/livox/lidar话题上收到点云数据。数据格式是自定义的CustomMsg,需要转换成标准的PointCloud2才能用PCL或Open3D处理。

转换的时候要注意时间戳同步。MID360的点云每个点都带时间戳,如果直接当成同一时刻的点处理,高速飞行时会有运动畸变。我的做法是用驱动里的时间同步功能,把点云按帧对齐到同一时刻,或者用IMU数据做去畸变。这一步在低速时影响不大,但20m/s飞行时,一帧点云的时间跨度内无人机可能移动了几十厘米,不去畸变的话障碍物位置会明显偏移。

3.2 点云滤波与地面分割

原始点云里包含地面、机身自身振动产生的噪声、以及远处的稀疏点。直接拿来做避障,计算量大且容易误判。我的处理流程是三步:

第一步,用直通滤波把雷达后方和上方不需要的点去掉。虽然MID360是360度,但无人机主要关心前向和侧向,后方可以适当裁剪,减少计算量。

第二步,用统计滤波去掉离群点。设置邻域点数为20,标准差倍数为1.5,把明显孤立的噪声点滤掉。

第三步,地面分割。用RANSAC拟合地面平面,把地面点去掉,剩下的就是障碍物候选点。这一步很关键,因为地面点如果不去掉,避障算法会以为下方一直有障碍,导致无人机不敢下降。

地面分割的参数需要根据飞行高度调整。RANSAC的距离阈值设0.2米左右比较合适,太小会把地面上的小起伏当成障碍,太大又会漏掉低矮障碍物。

3.3 障碍物聚类与膨胀

去掉地面后,剩下的点用欧式聚类分成不同的障碍物簇。聚类容差设0.5米,最小簇点数设10,最大簇点数不设上限。每个簇计算一个包围盒,得到障碍物的位置和尺寸。

然后做膨胀处理。因为点云是稀疏的,障碍物边缘可能不完整,如果直接按包围盒避障,无人机可能从边缘擦过去。我的做法是把每个障碍物的包围盒向外膨胀0.5米,相当于给无人机加了一个安全半径。这个膨胀距离根据飞行速度调整:速度越快,膨胀越大。20m/s时我用到0.8米。

膨胀后的障碍物信息会写入一个局部代价地图,用栅格表示,每个栅格记录是否有障碍。栅格分辨率设0.2米,范围覆盖机身周围20米。这个代价地图就是后续路径规划的依据。

实操心得:点云聚类的参数不要照搬教程。不同场景下障碍物的大小和密度差别很大,最好在实际飞行场地先录一段点云,离线调好参数再上机。

4. 避障算法实现:20m/s下的反应速度从哪来

4.1 局部路径规划选型

高速避障不能用全局规划,因为障碍物是动态出现的,全局规划来不及重算。我用的是基于采样的局部规划方法,在速度空间里采样多组速度和角速度组合,预测每组组合在未来0.5秒内的轨迹,检查轨迹是否与代价地图冲突,选一条无冲突且最接近目标方向的轨迹执行。

这个方法的优点是计算量可控,在Orin Nano上跑1000组采样大约需要5到8毫秒,满足20Hz的控制频率。缺点是采样分辨率有限,可能错过最优解,但在高速避障场景下,安全通过比最优路径更重要。

采样范围要根据速度调整。最大速度设20m/s,最大角速度设90度每秒,加速度限制设5m/s²。这些参数决定了无人机的机动能力边界,设得太激进会导致轨迹不可执行,设得太保守又避不开障碍。

4.2 紧急制动与优先级

局部规划之外,我还加了一层紧急制动逻辑。当障碍物距离小于安全距离(我设的是3米)且局部规划找不到无冲突轨迹时,直接触发紧急制动,以最大减速度停下来。这个逻辑是最后一道防线,宁可停住也不要撞上去。

紧急制动的减速度设8m/s²,从20m/s到停住需要2.5秒,滑行距离约25米。所以安全距离不能设得太小,否则制动距离不够。实际飞行时,我把前向安全距离设为15米,侧向设为8米,后方设为5米。这些距离是根据制动距离和反应时间反推出来的。

4.3 速度自适应策略

固定参数在低速时太保守,高速时又不够安全。我的做法是让安全距离和膨胀半径随速度线性变化。速度低于5m/s时,膨胀半径0.3米,前向安全距离5米;速度到20m/s时,膨胀半径0.8米,前向安全距离15米。这样低速时无人机可以灵活穿梭,高速时自动拉开安全余量。

这个自适应策略用一个简单的线性插值实现,输入是当前速度,输出是膨胀半径和安全距离。实测下来,这个策略让无人机在低速穿越窄缝和高速直线飞行之间切换得很自然,不需要手动调参。

5. 飞控配置与MAVLink通信

5.1 PX4避障参数设置

PX4里和避障相关的参数主要有几个:CP_DIST是碰撞预防的距离阈值,设成和机载计算机一致的安全距离;CP_GO_NO_DATA设0,表示没有障碍物数据时允许飞行;CP_MAX_DIST设20米,表示避障考虑的最大距离。

还要开COM_OBS_AVOID,让PX4接收来自机载计算机的避障设定点。这个参数打开后,PX4会把外部发来的速度设定点经过碰撞预防模块检查后再执行,相当于飞控层面还有一层保护。

注意:PX4的碰撞预防模块默认只处理前向障碍,如果要用全向避障,需要在机载计算机里把障碍物信息转换成PX4能理解的格式,或者直接用机载计算机的速度设定点覆盖飞控的避障逻辑。

5.2 MAVLink消息设计

机载计算机和飞控之间的通信,我用的是MAVLink的SET_POSITION_TARGET_LOCAL_NED消息,发送速度设定点。消息里包含速度的XYZ分量和偏航角速度。发送频率设20Hz,和局部规划的频率一致。

这里有一个细节:PX4对速度设定点有加速度限制,如果机载计算机发的速度变化太剧烈,PX4会做平滑处理,导致实际响应比预期慢。我的做法是在机载计算机里也加一个加速度限制,让发出的速度设定点本身就在飞控能执行的范围内。这样飞控不需要做额外平滑,响应更直接。

5.3 失控保护与降级策略

高速避障最怕的是机载计算机死机或通信中断。我的保护策略是:如果飞控超过0.5秒没收到新的速度设定点,自动切换到位置保持模式,悬停等待;如果超过3秒没恢复,自动返航。这个逻辑在PX4里用失控保护参数配置,COM_OBL_RC_ACT设成返航,COM_OF_LOSS_T设成0.5秒。

另外,雷达数据如果中断,机载计算机应该立即停止发送速度设定点,让飞控进入悬停。我在机载计算机里加了一个看门狗,监控雷达话题的更新频率,低于10Hz就触发保护。

6. 实测调参与常见问题排查

6.1 首次试飞的分步验证

不要一上来就开20m/s。我的试飞流程是:先悬停测试雷达数据是否正常,点云里能不能看到地面和周围障碍物;然后以3m/s低速飞行,测试避障逻辑是否能识别障碍并绕开;再逐步提速到5m/s、10m/s、15m/s,每个速度段飞几个起落,确认避障行为符合预期;最后才上20m/s。

每个速度段重点看两个指标:一是障碍物检测的延迟,从障碍物进入视野到无人机开始机动的时间;二是避障后的轨迹是否平滑,有没有出现震荡或急停。如果延迟超过100毫秒,或者轨迹震荡明显,就要回去调参数。

6.2 常见问题速查表

现象可能原因排查方法解决措施
点云稀疏,障碍物漏检单帧点云密度不足查看单帧点云点数累积3到5帧再处理
障碍物位置偏移雷达外参不准或运动畸变对比静止时点云和实际位置重新标定外参,加去畸变
无人机震荡避障参数过于激进观察速度设定点变化降低加速度限制,增大膨胀半径
紧急制动频繁触发安全距离设得太大查看制动触发时的障碍距离适当减小安全距离或提高规划成功率
雷达数据中断网线接触不良或供电不稳检查网口指示灯和电压更换网线,独立BEC供电
高速时避障反应慢点云处理延迟大测量从收到点云到发出设定点的时间降低点云分辨率,优化聚类参数

6.3 几个用血泪换来的经验

第一个经验:雷达的安装角度比想象中重要。我一开始把雷达水平安装,结果垂直视场角只有-7到52度,下方盲区很大,低空飞行时看不到近处地面。后来把雷达向前倾斜了10度,下方盲区减小,低空避障明显改善。

第二个经验:点云处理不要追求完美。一开始我试图把每个障碍物都精确聚类,结果计算量太大,延迟超过50毫秒。后来改成先用栅格做粗略的占据检测,只在必要时才做精细聚类,延迟降到15毫秒以内。

第三个经验:电池电压对雷达影响很大。6S电池满电25.2伏,放到3.5伏每片时只有21伏,如果BEC质量不好,雷达供电可能跌到10伏以下,导致点云异常。我的做法是BEC选宽压输入,输出稳定在12伏,并且在电池低压时降低飞行速度,减少雷达功耗压力。

第四个经验:飞行场地要提前扫描。第一次在陌生场地飞,雷达把场地边缘的围栏当成了障碍物,导致无人机一直往中间躲。后来我养成了习惯,每次换场地先用低速飞一圈,让雷达建一个粗略的场地地图,确认没有误检再提速。

7. 从能飞到好用:几个可以继续深挖的方向

这套配置跑通之后,20m/s直线避障已经比较稳定了。但如果要应对更复杂的场景,还有几个方向可以继续做。一个是多雷达融合,MID360虽然360度,但垂直视场有限,加一个下视雷达可以补盲,对起降和低空飞行帮助很大。另一个是把视觉和雷达做前融合,视觉提供语义信息,雷达提供精确距离,两者互补可以区分“需要避开的障碍”和“可以穿过的草丛”。

还有一个方向是预测性避障。现在的逻辑是看到障碍才反应,如果能把障碍物的运动趋势也考虑进去,比如对向飞来的无人机,就可以提前规划绕行路线,而不是等到很近才急转。这个需要引入目标跟踪,计算量会上去,但Orin Nano的算力还有余量。

最后说一个实际体会:高速避障的瓶颈往往不在算法,而在传感器安装、供电、振动这些“脏活”上。我见过太多人算法调得很好,一飞就炸,最后发现是雷达没固定牢或者网线松了。把硬件做扎实,比调参更重要。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询