ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

速腾聚创机器人业务过半,激光雷达导航选型与排坑实践

2026/8/31 12:56:26 拓冰建站 浏览量
速腾聚创机器人业务过半,激光雷达导航选型与排坑实践 速腾聚创机器人业务占半壁江山——这条信息如果放在新闻流里可能很快会被淹没。但对做机器人导航、感知或整机集成的人来说它值得停下来拆一拆一家以车载激光雷达起家的公司为什么会在某个时间点让机器人业务占据一半营收这个变化背后不只是公司的业务取舍更是机器人感知方案正在经历一次明显的成本下探和工具链迁移。过去几年很多机器人项目选传感器时第一反应是用视觉相机因为便宜、数据直观、算法生态也成熟。但真正做长期导航和可靠性要求较高的项目时激光雷达在建图、定位、避障中的稳定性优势依然明显。速腾聚创业务结构的变化从供应商角度印证了一件事机器人大规模落地时工程上对“直接测距”的需求比我们想象中更刚。这篇文章不打算做公司财报分析而是想聊聊这个信号对机器人开发者的实际影响。围绕激光雷达在机器人导航里的角色、选型思路、接入流程、参数调整、踩坑经验以及一套可复用的排查链路展开说说我的观察和实操建议。1. 先看清楚机器人业务占半壁江山到底意味着什么1.1 这不是简单增加一条产品线而是下游市场的重心变了速腾聚创早期以车载激光雷达为核心业务面向的是汽车前装和辅助驾驶。机器人业务从无到有再到占据一半营收说明下游需求结构已经发生了变化。汽车市场受车型周期、法规认证和量产节奏影响需求相对集中而机器人领域的需求虽然碎片化但增长曲线很陡——服务机器人、工业AMR、巡检机器人、复合机器人、人形机器人都在尝试用激光雷达做感知。当机器人业务占比达到一半供应商对产品定义的态度就会彻底改变。过去可能把车载产品的指标降一降、改个接口给机器人用现在会反过来专门为机器人场景设计产品追求中等测距、低功耗、小体积、抗环境光、成本适中。这种变化会直接传导到开发者手里能用更低的价格买到更合适的雷达同时获得更完整的 SDK 和示例代码。1.2 车载激光雷达和机器人激光雷达的产品逻辑完全不同很多人以为把车载激光雷达减配一下就能做成机器人雷达这是误解。车载场景要求远距离探测上百米、高速动态目标跟踪、车规级可靠性和复杂天气适应整个系统按“保障安全”的目标设计。机器人场景则更复杂工作距离通常 10 到 30 米就够特殊室外场地可能要求 40 米以上但很少需要 200 米。移动速度低但环境更杂玻璃门、金属货架、反光地面、低矮障碍物、动态行人和车辆。对体积、功耗、接口便捷性要求更高很多机器人是电池供电雷达不能成为功耗大户。成本敏感一个机器人要用一到三颗雷达如果单颗价格太高整机方案就没有市场竞争力。所以当一家车载激光雷达公司把机器人业务做到一半意味着它已经重新定义了一套产品逻辑而不是简单把车载雷达搬过来。1.3 机器人业务增长的底层驱动力从应用端看AMR/AGV、巡检机器人、配送机器人正在从“能跑通”走向“稳定跑几个月”。导航方案也从实验室demo变成生产级系统对传感器一致性、固件稳定性和长期数据可靠性的要求都提高了。从供应链看激光雷达在机器人领域的出货量一旦形成规模成本就能被打下来供应链成熟度也会提升。雷达模组价格降低后原本因为成本犹豫的小团队也敢在方案里加入激光雷达。这是一个正循环。速腾聚创的营收结构变化只是这个循环在头部公司身上的一次显性体现。2. 激光雷达在机器人导航里到底负责什么2.1 建图、定位、避障三个环节的角色不同在机器人导航系统里激光雷达不是一个单独的硬件而是和里程计、IMU、视觉、控制器一起组成一个感知系统。按职责可以拆成三块建图激光雷达提供无纹理依赖的几何距离信息能生成比较干净的环境栅格或点云地图。2D雷达常用 grid map3D雷达可以生成二维栅格投影或三维占据地图。建图质量直接决定后面定位的天花板。定位在已建好的地图里估计机器人当前位置。2D雷达可以用 AMCL3D雷达可以用 NDT 或 ICP 做点云配准。激光雷达的优势是测距误差稳定不像视觉那样容易受到光照变化影响。避障实时检测障碍物距离让局部代价地图可以及时避让。2D雷达能检测同一高度平面内的物体但对低矮障碍物、悬空物体有盲区3D雷达能提供三维轮廓信息但数据量更大需要经过地面分割和障碍物投影处理。在具体工程里这三部分不一定都用同一颗雷达。有的机器人会单独装一颗2D雷达做建图和定位再装一颗3D雷达做避障或者加一个视觉传感器做补盲。选型前先划清楚每颗雷达到底承担什么角色比直接看参数更重要。2.2 为什么单靠视觉方案在很多项目里不够视觉方案的优点是信息丰富能识别物体、读二维码、检测颜色而且摄像头很便宜。但把它作为唯一的测距来源时会遇到几个实际问题深度估算在弱纹理、反光、暗光环境下噪声很大。单目视觉的尺度不确定需要靠运动或IMU辅助。双目视觉的计算开销和对基线精度的要求都不低。视觉容易受曝光、眩光、运动模糊影响导致定位跳变。这不是说视觉不好而是说视觉单独做定位避障时冗余度不够。激光雷达直接输出距离不依赖环境纹理也不怕夜里没光。只要点云质量没问题建图和定位的稳定性就明显高一个档。这也就是为什么很多量产级移动机器人在成本允许的前提下依然会选择激光雷达作为主传感器。2.3 常见激光雷达方案的类型与适用边界不列具体型号只按类型和适用边界梳理。类型常见形态适用场景注意点2D单线雷达一个测距平面360度扫描室内平面导航、普通AMR、扫地机器人对低矮障碍物和悬空物体有盲区3D机械式雷达多线旋转扫描点云量大室外复杂地形、无人叉车、工程车辆体积大、价格高、震动时点云会畸变3D固态/半固态雷达MEMS、转镜或Flash式服务机器人、复合机器人、人形机器人垂直FOV和分辨率受型号限制需要仔细对比选型边界很清晰如果主要场景是室内平面地面没有太多高低落差2D雷达加视觉避障通常已经够用如果需要在室外跑或者会遇到坡道、楼梯、低矮货架3D雷达更合适如果要做全向感知但不想增加体积可以考虑多颗2D雷达组合或者选择水平FOV大的3D雷达。3. 机器人开发者如何迎接这个趋势从选型到落地3.1 选型判断框架很多第一次做机器人导航的人一上来就盯雷达最远测多少米这其实是优先级放错了。选型应该从系统需求倒推关注参数和场景的匹配关系。我一般会按下面这个顺序过一遍参数对机器人的影响参考建议测距范围决定建图覆盖宽度和避障反应时间室内10-20m足够室外至少20m水平FOV决定单颗雷达能否覆盖机器人前后左右2D雷达一般360°3D雷达要关注水平角度垂直FOV决定能否感知低矮或高位障碍物垂直角度越大盲区越少角度分辨率决定远距离小目标能否被识别分辨率越高点云越密但数据量越大测距误差影响地图精度和避障安全距离误差越小越好但不要忽略误差一致性帧率影响动态避障的实时性移动速度快就选20Hz以上功耗影响电池续航电池平台要优先看功耗接口与驱动决定接入成本优先选择有官方ROS/ROS2驱动的型号在实际项目中建议把“测距范围”和“角度分辨率”结合起来看。不要只看最远量程还要看量程末端的分辨率衰减。如果一颗雷达最远标称30米但在25米处角度分辨率已经很低那它只能感知“有一个大东西”但不知道“是什么形状”。3.2 最小可用流程把一颗雷达接进 ROS 2如果雷达已经选好先把最小链路跑通。顺序可以这样确认驱动来源。优先用厂商提供的ROS2驱动包其次考虑社区维护的第三方驱动。创建或进入ROS2工作空间编译驱动包cd ~/ros2_ws colcon build source install/setup.bash启动雷达节点。不同雷达驱动包名不同但启动方式类似ros2 launch driver_package driver_launch_file.py查看话题列表确认节点已经发布点云或激光扫描数据ros2 topic list查看话题发布频率确认数据流稳定ros2 topic hz /scan如果雷达发布的是/scan说明是LaserScan消息通常来自2D雷达如果是/cloud或类似话题说明是PointCloud2消息常见于3D雷达。这个差异会影响后面的滤波和配准方案。启动 RViz2添加对应显示项确认点云数据符合预期rviz2在RViz中把 Fixed Frame 设置为雷达对应的TF坐标系然后添加 PointCloud2 或 LaserScan 显示。这一步能看到雷达是否正常工作、安装角度是否明显偏移、点云里是否有大量噪声。3.3 参数调整的常见思路雷达接入后通常要做几件事才能让它真正服务导航设定雷达坐标系与机器人基座的TF关系。先手动测量安装位置写入TF发布器之后通过标定精修。对点云做直通滤波。把雷达靠得太近或超出有效范围的噪声点去掉# 示例结构使用通用滤波库 from sensor_msgs.msg import PointCloud2 # 具体滤波参数请根据雷达和场景调整对2D激光扫描做局部去噪。可以用半径离群点滤波把孤立的杂点去掉。但滤波半径不要设太大否则细小的桌腿、柱子会被当成噪声滤掉。建图时降低移动速度。激光雷达在快速旋转或机器人快速转弯时会产生运动畸变如果里程计不够准地图会出现重影。第一次建图最好让机器人以 0.2~0.3 m/s 的速度走等地图基线干净了再提速。定位时不要只依赖雷达。在轮式里程计、IMU和雷达之间做好融合用 robot_localization 这类工具做扩展卡尔曼滤波或无迹卡尔曼滤波。雷达数据只作为其中的一个观测源。3.4 从单台验证到多机部署的坑单台机器人跑通只是一个开始。多机部署时很多问题会从“某台机器坏了”变成“环境问题导致所有机器不稳定”。串口和网络冲突多台雷达接入同一台电脑或者多台机器人连同一个网络时要确保接口名称固定并且网络带宽充足。话题/节点名冲突如果多台机器人共享类似代码很容易出现同一话题被不同机器人覆盖。部署时给每台机器人加命名空间。雷达外参不一样每台机器人的雷达安装位置可能都会有一点差异不能直接复制 TF 文件。最好建立一套标定记录流程每台机器人的标定结果单独管理。固件版本一致同一型号雷达的不同固件版本在点云畸变处理、温度补偿行为上可能有差异。批量部署前要锁死固件版本。4. 最容易踩坑的五个环节4.1 点云坐标系和机器人基座的标定这是新手最容易出问题的地方。雷达的坐标系方向和机器人基座的坐标系方向如果没有精确对齐建出来的地图会整体偏转定位时也会出现系统性的漂移。常见的错误有把 TF 中的 x 和 y 写反把 z 轴朝上写成朝下角度单位在弧度和角度之间搞混。遇到过几次之后我的经验是先把 TF 树打印出来逐一检查雷达坐标系在 RViz 中是否和机器人模型视觉对齐再用一段地面直线行走记录点云轨迹看雷达推出来的轨迹和真实行走轨迹是否重合。4.2 动态环境下滤波器参数无法一刀切很多激光雷达在室内强阳光、反光地面、白色墙面、金属网格环境中会产生杂散点。过滤是必要的但参数不是全局固定的。例如使用半径离群点移除时邻域半径设得太大距离雷达较远的细小障碍物会被当成孤点滤掉导致避障漏检半径设得太小又可能保留一堆噪声点让局部代价地图出现闪烁。正确做法是在不同场景分别录制数据调节半径和最小邻居数找一个在“去噪”和“保留细节”之间的平衡点。这个平衡点往往要结合安全距离一起算不要只看点云好看。4.3 多雷达叠加时的外参标定为了全向感知有些机器人会装多颗激光雷达比如前后各一颗。多雷达的外参标定如果不准确点云叠加后在机器人前后方向就会出现明显错位。这个问题在室内小空间里尤其明显因为地图特征密集两条点云差几厘米避障就可能把过道判成堵死。标定多雷达外参时建议使用专门的标定工具或标定板先离线处理再放到运行场景里做验证。不要只凭米尺测量或者盯着 RViz 目测因为角度误差很难靠肉眼发现。多雷达时间同步同样重要如果两颗雷达的帧率不一致或时间戳有偏差高速移动时的点云拼接也会错位。4.4 长尾场景反光、玻璃、雨雾激光雷达对强反光材质和透明物体的处理并不完美。在玻璃门前部分光斑会穿过玻璃或被反射导致点云上出现一个虚假的“墙面”或“空洞”。在镜面、深色金属表面雷达可能丢点或产生拖尾。在雨雾天气点云中会出现大量微小噪点影响建图和定位。这类场景不能只靠调参数解决。更稳妥的方式是做多传感器冗余比如用超声雷达或视觉来辅助检测玻璃门用毫米波雷达处理雾天。激光雷达的可靠性再高也需要其他传感器补盲。真正到量产项目时这类长尾场景往往比理想环境中的性能更决定成败。4.5 性能评估不能只看 datasheetdatasheet上的测距精度、角度分辨率和帧率基本都是实验室理想条件下的结果。实际使用中这些参数会受到以下因素影响供电电压不稳定雷达可能出现短暂丢帧或点云跳变。振动会让机械式雷达的点云产生畸变机器人经过颠簸路面时尤其明显。环境温度过高或过低时测距误差可能会变大。长期运行后雷达窗口上积累的灰尘也会降低探测能力。所以在一颗雷达进入候选目录后一定要做场景化测试把雷达装到目标机器人上在真实场地跑几天白天、黑夜、强光、轻度粉尘、不同地面材质都要覆盖。性能要按“真实场景中的最小可用水平”来评估而不是按宣传指标。5. 排查链路当机器人定位漂移或避障失效时按什么顺序查这部分我想给一套可复用的排查链路。无论你用的是 2D 雷达还是 3D 雷达遇到定位漂移、建图重影、避障漏检或误检时都可以按这个顺序逐层排查避免像无头苍蝇一样乱改参数。5.1 先看现象确定故障域先把你看到的问题归一下类。典型现象有地图整体歪斜或出现重影。定位时机器人在原地小幅抖动。运行一段时间后位置缓慢漂移。障碍物明明在前方避障却没有任何反应。点云中频繁出现空洞、断层或噪点。雷达话题频率不稳定时断时续。不同的现象指向不同的问题层。例如地图重影通常指向 TF 标定、里程计或雷达运动畸变避障漏检可能指向点云滤波过强、局部代价地图参数或雷达安装角度。5.2 按链路逐层排查排查顺序建议固定为输入层 → 环境层 → 数据层 → 算法层 → 资源层 → 工具边界。输入层在 RViz 里查看点云是否正常。重点确认点云有没有明显断层。有没有一帧多出来的“假点”。雷达有没有因供电不足而周期性掉线。雷达的扫描频率是否和设置一致。环境层看雷达安装姿态是否因为碰撞或长期震动发生了变化。检查支架螺丝、雷达外壳、连接线缆。同时看雷达周围有没有被支架、挡板遮挡 FOV有没有阳光直射。数据层使用ros2 topic hz检查话题频率使用ros2 topic echo检查时间戳是否递增正常。再看 TF 是否连续ros2 tf2_echo可以用来确认雷达坐标系和机器人基座坐标系的转换是否稳定。算法层根据现象核对参数。定位漂移时检查里程计协方差、IMU方向是否反了、雷达匹配的初始猜测是否合理。避障漏检时检查局部代价地图的膨胀半径、滤波器的去噪强度、障碍物点云是否被分割到了未知区域。资源层查看CPU和内存占用。点云话题如果数据量巨大而工控机性能不足会出现处理延迟和丢帧。特别是 3D 雷达加多传感器融合时实时性更依赖硬件。工具边界如果以上都正常就要承认这个方案本身可能有局限。比如雷达装在一颗 100kg 的机器人上通过金属楼梯时点云中的楼梯边缘反射很复杂导致障碍物投影到 2D 代价地图时出现虚假边界。这时就不是参数问题而是传感器组合和场景不匹配需要换方案或加入其他传感器。5.3 记录数据与复现排查问题时不建议直接在实机上边改边看。更稳妥的做法是录制一份 rosbagros2 bag record -a -o problem_case录制内容至少包括雷达点云、TF、里程计、IMU、robot_state_publisher 发布的状态。然后可以离线回放ros2 bag play problem_case重新跑定位或建图算法复现问题再试不同参数。这样每次改动都有依据也方便团队协作时其他人一起看。这个习惯一开始会显得很重但等机器人项目跑到几十台之后没有数据记录排查问题几乎无从下手。6. 这件事对行业和个人开发者意味着什么6.1 传感器成本下降会带来什么速腾聚创机器人业务过半最直接的影响是更多人可以看到激光雷达在机器人领域是有规模需求的。当供应商愿意为机器人单独定义产品成本下探和工具链成熟就是必然结果。这会让原本因为价格放弃激光雷达的团队重新评估方案用视觉还是用激光雷达。成本一旦降到合适的区间很多室内导航项目会愿意把激光雷达作为标配。到时开发者能够以更低成本获得更稳定的定位避障能力机器人导航也会从“赛车级改装”变成“通用配件”。但要注意成本下降不代表门槛自然降低。传感器只是入口能否把数据用好才是真正的竞争力。6.2 机器人工程化的分工变化过去做机器人导航往往一个团队要负责从驱动到算法的所有事情。现在头部传感器厂商提供的 SDK 越来越完整从数据解析到 ROS 驱动、从标定工具到示例代码都越来越接近“开箱即用”。这不是说开发者没有技术活了而是工作重心会转移。未来竞争更多的会是场景定制、系统集成、可靠性测试和长尾问题处理。谁能在真实环境里把一套感知方案调到连续运行几个月不出大问题谁的能力就越稀缺。这是个好事把精力从重复造轮子转向解决真正影响落地的工程问题。6.3 开发者该补哪些能力面对这个趋势我觉得有三块能力值得持续投入点云处理基本功滤波、分割、配准、体素降采样。这些是理解雷达数据的基础也是排查问题的前提。多传感器标定和 TF 管理能够独立完成雷达和轮式里程计、IMU、相机之间的标定并且管理好每台机器人对应的外参文件。系统化数据意识录包、回放、复现、对比参数用数据而不是感觉来判断问题。这一条对多人协作项目尤其重要。另外建议花时间至少深入掌握一两个主流的导航方案比如 2D 的 Cartographer 与 AMCL3D 的 LIO-SAM、FAST-LIO 或 NDT 配准。不需要什么都会但至少要把一条链路从建图、定位到避障完整跑通过并且能解释清楚每个环节的输入输出。“半壁江山”这个信号放在两年前可能还只是公司战略层面的一个数字。但现在往回看它更像是机器人感知方案进入成熟期的一个注脚。激光雷达不会取代视觉视觉也不会一直单打独斗最后落地的系统一定是多种传感器各司其职。真正稀缺的是能把传感器组合成可靠系统、并且能在现场稳定运行的工程师。与其纠结哪家公司的财报更漂亮不如先把眼前这台机器人的点云、TF 和里程计调明白。这才是这个行业里永远不过时的硬功夫。