企业官网建设流程全解析

速腾聚创机器人业务占半壁江山——这条信息如果放在新闻流里，可能很快会被淹没。但对做机器人导航、感知或整机集成的人来说，它值得停下来拆一拆：一家以车载激光雷达起家的公司，为什么会在某个时间点让机器人业务占据一半营收？这个变化背后不只是公司的业务取舍，更是机器人感知方案正在经历一次明显的成本下探和工具链迁移。

过去几年，很多机器人项目选传感器时，第一反应是用视觉相机，因为便宜、数据直观、算法生态也成熟。但真正做长期导航和可靠性要求较高的项目时，激光雷达在建图、定位、避障中的稳定性优势依然明显。速腾聚创业务结构的变化，从供应商角度印证了一件事：机器人大规模落地时，工程上对“直接测距”的需求，比我们想象中更刚。

这篇文章不打算做公司财报分析，而是想聊聊这个信号对机器人开发者的实际影响。围绕激光雷达在机器人导航里的角色、选型思路、接入流程、参数调整、踩坑经验，以及一套可复用的排查链路，展开说说我的观察和实操建议。

1. 先看清楚：机器人业务占半壁江山到底意味着什么

1.1 这不是简单增加一条产品线，而是下游市场的重心变了

速腾聚创早期以车载激光雷达为核心业务，面向的是汽车前装和辅助驾驶。机器人业务从无到有，再到占据一半营收，说明下游需求结构已经发生了变化。汽车市场受车型周期、法规认证和量产节奏影响，需求相对集中；而机器人领域的需求虽然碎片化，但增长曲线很陡——服务机器人、工业AMR、巡检机器人、复合机器人、人形机器人都在尝试用激光雷达做感知。

当机器人业务占比达到一半，供应商对产品定义的态度就会彻底改变。过去可能把车载产品的指标降一降、改个接口给机器人用；现在会反过来，专门为机器人场景设计产品，追求中等测距、低功耗、小体积、抗环境光、成本适中。这种变化会直接传导到开发者手里：能用更低的价格买到更合适的雷达，同时获得更完整的 SDK 和示例代码。

1.2 车载激光雷达和机器人激光雷达的产品逻辑完全不同

很多人以为把车载激光雷达减配一下就能做成机器人雷达，这是误解。车载场景要求远距离探测（上百米）、高速动态目标跟踪、车规级可靠性和复杂天气适应，整个系统按“保障安全”的目标设计。机器人场景则更复杂：

• 工作距离通常 10 到 30 米就够，特殊室外场地可能要求 40 米以上，但很少需要 200 米。
• 移动速度低，但环境更杂：玻璃门、金属货架、反光地面、低矮障碍物、动态行人和车辆。
• 对体积、功耗、接口便捷性要求更高，很多机器人是电池供电，雷达不能成为功耗大户。
• 成本敏感，一个机器人要用一到三颗雷达，如果单颗价格太高，整机方案就没有市场竞争力。

所以当一家车载激光雷达公司把机器人业务做到一半，意味着它已经重新定义了一套产品逻辑，而不是简单把车载雷达搬过来。

1.3 机器人业务增长的底层驱动力

从应用端看，AMR/AGV、巡检机器人、配送机器人正在从“能跑通”走向“稳定跑几个月”。导航方案也从实验室demo变成生产级系统，对传感器一致性、固件稳定性和长期数据可靠性的要求都提高了。

从供应链看，激光雷达在机器人领域的出货量一旦形成规模，成本就能被打下来，供应链成熟度也会提升。雷达模组价格降低后，原本因为成本犹豫的小团队也敢在方案里加入激光雷达。这是一个正循环。速腾聚创的营收结构变化，只是这个循环在头部公司身上的一次显性体现。

2. 激光雷达在机器人导航里到底负责什么

2.1 建图、定位、避障三个环节的角色不同

在机器人导航系统里，激光雷达不是一个单独的硬件，而是和里程计、IMU、视觉、控制器一起组成一个感知系统。按职责可以拆成三块：

• 建图：激光雷达提供无纹理依赖的几何距离信息，能生成比较干净的环境栅格或点云地图。2D雷达常用 grid map，3D雷达可以生成二维栅格投影或三维占据地图。建图质量直接决定后面定位的天花板。
• 定位：在已建好的地图里估计机器人当前位置。2D雷达可以用 AMCL，3D雷达可以用 NDT 或 ICP 做点云配准。激光雷达的优势是测距误差稳定，不像视觉那样容易受到光照变化影响。
• 避障：实时检测障碍物距离，让局部代价地图可以及时避让。2D雷达能检测同一高度平面内的物体，但对低矮障碍物、悬空物体有盲区；3D雷达能提供三维轮廓信息，但数据量更大，需要经过地面分割和障碍物投影处理。

在具体工程里，这三部分不一定都用同一颗雷达。有的机器人会单独装一颗2D雷达做建图和定位，再装一颗3D雷达做避障，或者加一个视觉传感器做补盲。选型前先划清楚每颗雷达到底承担什么角色，比直接看参数更重要。

2.2 为什么单靠视觉方案在很多项目里不够

视觉方案的优点是信息丰富，能识别物体、读二维码、检测颜色，而且摄像头很便宜。但把它作为唯一的测距来源时，会遇到几个实际问题：

• 深度估算在弱纹理、反光、暗光环境下噪声很大。
• 单目视觉的尺度不确定，需要靠运动或IMU辅助。
• 双目视觉的计算开销和对基线精度的要求都不低。
• 视觉容易受曝光、眩光、运动模糊影响，导致定位跳变。

这不是说视觉不好，而是说视觉单独做定位避障时，冗余度不够。激光雷达直接输出距离，不依赖环境纹理，也不怕夜里没光。只要点云质量没问题，建图和定位的稳定性就明显高一个档。这也就是为什么很多量产级移动机器人在成本允许的前提下，依然会选择激光雷达作为主传感器。

2.3 常见激光雷达方案的类型与适用边界

不列具体型号，只按类型和适用边界梳理。

选型边界很清晰：如果主要场景是室内平面地面，没有太多高低落差，2D雷达加视觉避障通常已经够用；如果需要在室外跑，或者会遇到坡道、楼梯、低矮货架，3D雷达更合适；如果要做全向感知但不想增加体积，可以考虑多颗2D雷达组合，或者选择水平FOV大的3D雷达。

3. 机器人开发者如何迎接这个趋势：从选型到落地

3.1 选型判断框架

很多第一次做机器人导航的人，一上来就盯雷达最远测多少米，这其实是优先级放错了。选型应该从系统需求倒推，关注参数和场景的匹配关系。我一般会按下面这个顺序过一遍：

在实际项目中，建议把“测距范围”和“角度分辨率”结合起来看。不要只看最远量程，还要看量程末端的分辨率衰减。如果一颗雷达最远标称30米，但在25米处角度分辨率已经很低，那它只能感知“有一个大东西”但不知道“是什么形状”。

3.2 最小可用流程：把一颗雷达接进 ROS 2

如果雷达已经选好，先把最小链路跑通。顺序可以这样：

1. 确认驱动来源。优先用厂商提供的ROS2驱动包，其次考虑社区维护的第三方驱动。
2. 创建或进入ROS2工作空间，编译驱动包：

cd ~/ros2_ws colcon build source install/setup.bash

3. 启动雷达节点。不同雷达驱动包名不同，但启动方式类似：

ros2 launch <driver_package> <driver_launch_file>.py

4. 查看话题列表，确认节点已经发布点云或激光扫描数据：

ros2 topic list

5. 查看话题发布频率，确认数据流稳定：

ros2 topic hz /scan

如果雷达发布的是/scan，说明是LaserScan消息，通常来自2D雷达；如果是/cloud或类似话题，说明是PointCloud2消息，常见于3D雷达。这个差异会影响后面的滤波和配准方案。

6. 启动 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 性能评估不能只看 datasheet

datasheet上的测距精度、角度分辨率和帧率，基本都是实验室理想条件下的结果。实际使用中，这些参数会受到以下因素影响：

• 供电电压不稳定，雷达可能出现短暂丢帧或点云跳变。
• 振动会让机械式雷达的点云产生畸变，机器人经过颠簸路面时尤其明显。
• 环境温度过高或过低时，测距误差可能会变大。
• 长期运行后，雷达窗口上积累的灰尘也会降低探测能力。

所以在一颗雷达进入候选目录后，一定要做场景化测试：把雷达装到目标机器人上，在真实场地跑几天，白天、黑夜、强光、轻度粉尘、不同地面材质都要覆盖。性能要按“真实场景中的最小可用水平”来评估，而不是按宣传指标。

5. 排查链路：当机器人定位漂移或避障失效时，按什么顺序查

这部分我想给一套可复用的排查链路。无论你用的是 2D 雷达还是 3D 雷达，遇到定位漂移、建图重影、避障漏检或误检时，都可以按这个顺序逐层排查，避免像无头苍蝇一样乱改参数。

5.1 先看现象，确定故障域

先把你看到的问题归一下类。典型现象有：

• 地图整体歪斜或出现重影。
• 定位时机器人在原地小幅抖动。
• 运行一段时间后，位置缓慢漂移。
• 障碍物明明在前方，避障却没有任何反应。
• 点云中频繁出现空洞、断层或噪点。
• 雷达话题频率不稳定，时断时续。

不同的现象指向不同的问题层。例如地图重影通常指向 TF 标定、里程计或雷达运动畸变；避障漏检可能指向点云滤波过强、局部代价地图参数或雷达安装角度。

5.2 按链路逐层排查

排查顺序建议固定为：输入层 → 环境层 → 数据层 → 算法层 → 资源层 → 工具边界。

1. 输入层：在 RViz 里查看点云是否正常。重点确认：

   • 点云有没有明显断层。
   • 有没有一帧多出来的“假点”。
   • 雷达有没有因供电不足而周期性掉线。
   • 雷达的扫描频率是否和设置一致。

2. 环境层：看雷达安装姿态是否因为碰撞或长期震动发生了变化。检查支架螺丝、雷达外壳、连接线缆。同时看雷达周围有没有被支架、挡板遮挡 FOV，有没有阳光直射。

3. 数据层：使用ros2 topic hz检查话题频率，使用ros2 topic echo检查时间戳是否递增正常。再看 TF 是否连续，ros2 tf2_echo可以用来确认雷达坐标系和机器人基座坐标系的转换是否稳定。

4. 算法层：根据现象核对参数。定位漂移时，检查里程计协方差、IMU方向是否反了、雷达匹配的初始猜测是否合理。避障漏检时，检查局部代价地图的膨胀半径、滤波器的去噪强度、障碍物点云是否被分割到了未知区域。

5. 资源层：查看CPU和内存占用。点云话题如果数据量巨大，而工控机性能不足，会出现处理延迟和丢帧。特别是 3D 雷达加多传感器融合时，实时性更依赖硬件。

6. 工具边界：如果以上都正常，就要承认这个方案本身可能有局限。比如雷达装在一颗 100kg 的机器人上，通过金属楼梯时，点云中的楼梯边缘反射很复杂，导致障碍物投影到 2D 代价地图时出现虚假边界。这时就不是参数问题，而是传感器组合和场景不匹配，需要换方案或加入其他传感器。

5.3 记录数据与复现

排查问题时不建议直接在实机上边改边看。更稳妥的做法是录制一份 rosbag：

ros2 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 与 AMCL，3D 的 LIO-SAM、FAST-LIO 或 NDT 配准。不需要什么都会，但至少要把一条链路从建图、定位到避障完整跑通过，并且能解释清楚每个环节的输入输出。

“半壁江山”这个信号，放在两年前可能还只是公司战略层面的一个数字。但现在往回看，它更像是机器人感知方案进入成熟期的一个注脚。激光雷达不会取代视觉，视觉也不会一直单打独斗，最后落地的系统一定是多种传感器各司其职。真正稀缺的，是能把传感器组合成可靠系统、并且能在现场稳定运行的工程师。与其纠结哪家公司的财报更漂亮，不如先把眼前这台机器人的点云、TF 和里程计调明白。这才是这个行业里永远不过时的硬功夫。