企业官网建设流程全解析

速腾聚创近期披露的业务结构里，机器人业务已经占到“半壁江山”。这个信号对做机器人的开发者来说，比单看某一款传感器更重要：激光雷达正在从自动驾驶的专属配套，变成机器人感知系统的常规组件。过去几年，很多团队做机器人导航和避障，第一反应是上摄像头或者超声波，遇到光照变化、玻璃墙面、细小障碍物之后，才会回头重新评估激光雷达的价值。

下面从“机器人为什么需要激光雷达、怎么选型、怎么在 ROS 2 里接起来、点云数据怎么处理、出了故障怎么排查”这条主线展开。适合刚开始接触激光雷达的机器人爱好者、准备给 AGV 或服务机器人做感知选型的工程师，以及想在课程项目里加入真实里程计的开发者。读完以后，你可以独立完成一个激光雷达从驱动接入到点云可视化的最小闭环，也知道后续做建图、定位、避障时该往哪个方向深入。

1. 从自动驾驶到机器人：激光雷达的主战场正在转移

1.1 机器人场景为什么比汽车更依赖激光雷达

一辆自动驾驶汽车大部分时间行驶在结构化道路上，车道线、路沿、交通标志提供了大量先验信息，摄像头加毫米波雷达的组合也能完成不少任务。但机器人面对的通常是半结构化甚至完全无结构的环境：商场里的玻璃门、仓库里伸出来的货架横杆、园区的细树枝、正在走动的人。这些目标对摄像头来说并不友好，玻璃会反光，低矮障碍物容易超出图像标注范围，纹理重复的地面会让视觉里程计漂移。

激光雷达直接测量每个点的三维坐标，不依赖环境纹理和外部光照。它对“距离”这个物理量的测量是直接的，因此建图时得到的栅格地图更干净，避障时也能在几十毫秒内得到障碍物的轮廓和距离。这不是说摄像头方案不行，而是说在机器人这种近距离、低速、场景多变的环境里，激光雷达的可靠性上限更高，工程量更可控。

1.2 激光雷达公司把产品重心转向机器人的原因

激光雷达最早的大规模应用场景是自动驾驶，但自动驾驶量产节奏慢、车型认证周期长，传感器单价又高。机器人则不同：扫地机器人、配送机器人、工业 AGV、安防巡检机器人、人形机器人的出货量增长很快，而且对传感器的体积、功耗、成本更敏感。从公开信息来看，速腾聚创这类激光雷达厂商的机器人业务占比提升，是行业从“为自动驾驶准备”转向“为机器人量产准备”的缩影。

对开发者来说，最直观的变化是官方 SDK 对 ROS 和 ROS 2 的支持越来越完整，很多型号出厂就带驱动、标定文件和应用示例。技术选型时，不再需要自己写底层协议解析，也不再需要从激光雷达厂商的汽车客户那里绕一圈才能拿到资料。这种生态变化，才是机器人业务占比提升背后真正影响开发者日常工作的部分。

1.3 建图、避障、交互对激光雷达的要求并不相同

同样叫“机器人用激光雷达”，任务不同，关注点完全不同：

• 导航建图要求点云稳定、角分辨率高、回环检测能对齐，室内通常用单线雷达或低线束雷达。
• 动态避障要求帧率足够高、数据延迟低，点云里的孤立噪点会直接触发急停。
• 人形机器人或近场交互更关注近距离盲区、大垂直视场角、点云密度和安全性。

把需求拆清楚以后再选传感器，比先买一个看起来参数很高的雷达再迁就驱动要省事得多。很多项目做不下去，不是因为算法不够先进，而是传感器选型阶段没有把任务边界定义清楚。

2. 激光雷达的核心原理和选型参数

2.1 ToF 测距为什么成为主流

市面上激光雷达的测距原理主要有三角测距、ToF（飞行时间）和 FMCW（调频连续波）。三角测距靠激光器与接收器之间的几何关系计算距离，成本和功耗低，但室内近距离效果尚可，室外强阳光下容易失效，射程也有限。ToF 通过测量激光发射和接收之间的时间差计算距离，公式是距离等于光速乘以飞行时间再除以二，测距范围大、抗环境光能力强，是目前机器人和车载激光雷达的主流方案。

最近几年 FMCW 也在升温。它通过频率差同时获得距离和速度信息，抗干扰能力更强，但当前成本和成熟度还不适合大规模进入机器人产品。选型时优先考虑各家主打的 ToF 产品，工程资料、驱动更新和社区案例都会多很多。

2.2 决定性能的七个关键参数

• 测距范围：机器人的运行速度和制动距离决定最远需要看多远，室内导航通常 20 到 40 米够用，室外园区或车辆场景需要 100 米以上。
• 水平/垂直视场角：扫地机器人只需要一个平面，水平 360 度即可；仿人机器人需要大垂直视场角看清脚下和高处。
• 角分辨率：区分同一角度、不同距离目标的能力，角分辨率不足会把细杆、线缆直接漏掉。
• 帧率：常见 10Hz 到 20Hz，避障任务帧率越高，反应越及时，但点云吞吐量也会变大。
• 测距精度和噪声：建图和里程计对精度敏感，定位误差会随距离累积。
• 防护等级：室内产品 IP 等级低一些，户外配送和巡检需要 IP65 以上，还要考虑雨雾、扬尘。
• 功耗和体积：电池供电的移动机器人对功耗很敏感，人形机器人对头部载荷有严格要求。

2.3 机器人场景选型的优先级

如果只是室内 AMR 导航，单线 2D 雷达性价比最高，它只输出一个平面的距离数据，上游的建图、定位算法非常成熟。如果是户外配送或巡检，至少要选 16 线或 32 线 3D 雷达，否则起伏路面、坡道和悬空障碍物都处理不了。如果是人形机器人上身的近场感知，要优先看近距离盲区、垂直视场角和点云密度，而不是一味追求长测距。

2.4 参数速查表

注意：上表只是选型参考方向，具体数值要以目标型号的数据手册为准，不要只看营销页面的最大测距，还要看该距离下的反射率条件和点频。

3. 在 ROS 2 中接入激光雷达的完整流程

3.1 环境准备

建议使用 Ubuntu 22.04 和 ROS 2 Humble。先确认系统已经安装 ROS 2：

ros2 --version

如果没有安装，先安装桌面版：

sudo apt update sudo apt install -y ros-humble-desktop python3-colcon-common-extensions echo "source /opt/ros/humble/setup.bash" >> ~/.bashrc source ~/.bashrc

安装完成后，创建一个专门用于激光雷达的工作空间。学习环境这样搭建就够了，不需要额外安装整套仿真平台；如果要在真实机器人上使用，还要把网络接口、时间同步和权限一并考虑进去。

3.2 编译安装厂商 SDK

大多数厂商在官方 GitHub 仓库提供 ROS 和 ROS 2 驱动。下面以通用流程为例，实际仓库地址和分支以官方文档为准：

mkdir -p ~/lidar_ws/src cd ~/lidar_ws/src git clone <厂商SDK仓库地址> cd ~/lidar_ws colcon build source install/setup.bash

编译过程中最常见的错误是缺少依赖包，例如yaml-cpp、pcl、Eigen3，可以按提示安装后再编译。不要跳过colcon build这一步直接运行，否则找不到编译产物。另一个容易踩的坑是 ROS 版本不匹配，ROS 1 的驱动包不能直接在 ROS 2 里编译，要确认仓库的分支或 tag 对应的是 humble 还是 noetic。

3.3 配置设备网络和点云话题

激光雷达通常要求电脑和雷达处于同一个网段。先看雷达背面或说明书上的默认 IP，然后把电脑的有线网卡配置到相同网段，例如雷达是 192.168.1.200，电脑可以配成 192.168.1.100。

在 SDK 的配置文件里填写设备 IP、本机 IP、目标端口和 frame_id。配置片段类似于：

frame_id: rslidar device_ip: 192.168.1.200 host_ip: 192.168.1.100 msop_port: 6699 difop_port: 7788

不同型号的端口可能不同，MSOP 口用于点云数据，DIFOP 口用于设备信息和角度同步，不要只填一个。frame_id 建议使用统一的坐标系名称，后面做 SLAM 时不需要反复改参数。

启动驱动：

ros2 launch rslidar_sdk start.py

如果 SDK 没有提供 launch 文件，可以直接运行可执行文件。启动后确认话题是否出现。这一步最值得花时间的是网络排查：很多“雷达不转”的问题，本质是电脑和雷达不互通，或者防火墙丢掉了 UDP 数据包。

3.4 用 RViz2 验证点云

打开新终端，检查话题列表：

ros2 topic list

正常能看到类似/rslidar_points的 PointCloud2 话题。查看话题类型和发布频率：

ros2 topic info /rslidar_points ros2 topic hz /rslidar_points

然后打开 RViz2 可视化：

rviz2

在左侧显示器中点击 Add，选择 By topic，再选择 PointCloud2，把 Fixed Frame 设为与 frame_id 一致的名字。如果点云正常旋转、形状符合周围环境，说明驱动和坐标设置都正确。

注意：如果 RViz 里看不到点，先检查 Fixed Frame，再检查话题是否真有数据，不要直接怀疑雷达坏了。

4. 点云数据处理：从原始点到可以用的障碍信息

4.1 frame_id 和坐标关系

点云里的每个点都有一个坐标，坐标系由 frame_id 标识。机器人身上一般有 map、odom、base_link、laser 等坐标系。激光雷达给出的点云默认在 laser 坐标系，只有当 TF 树里发布 laser 到 base_link 的变换关系后，其他模块才能把点云转换到机器人本体坐标。这也是新手最容易漏的一步：雷达数据本身没有变，但因为缺失 TF，导航和避障模块完全没法用。

在 ROS 2 里可以通过static_transform_publisher发布激光雷达相对机器人中心的外参：

ros2 run tf2_ros static_transform_publisher \ 0 0 0.3 0 0 0 base_link laser

这条命令的意思是激光雷达装在机器人中心正上方 0.3 米处，没有旋转。实际项目里，外参要用 CAD 模型或标定工具计算，不能靠目测。外参错了，点云看起来正常，但导航地图和真实位置会对不上。

4.2 用直通滤波裁掉不需要的空间

原始点云包含大量无用信息，比如天花板、远处的墙面、地面反射点。处理的第一步通常是直通滤波，保留感兴趣区域。以 PCL 为例：

#include <pcl/point_cloud.h> #include <pcl/point_types.h> #include <pcl/filters/passthrough.h> pcl::PointCloud<pcl::PointXYZ>::Ptr cloud(new pcl::PointCloud<pcl::PointXYZ>()); pcl::PointCloud<pcl::PointXYZ>::Ptr filtered(new pcl::PointCloud<pcl::PointXYZ>()); pcl::PassThrough<pcl::PointXYZ> pass; pass.setInputCloud(cloud); pass.setFilterFieldName("z"); // 按高度过滤 pass.setFilterLimits(-0.5, 1.5); // 保留地面以上 1.5 米内的点 pass.filter(*filtered);

这段代码把高度范围之外的点全部丢到filtered之外，后续聚类和避障只需要处理更小的点集。实际项目中，过滤范围要根据机器人尺寸、雷达安装高度和任务场景标定，不能照抄数值。设置范围过大，会保留大量无效点，增加计算量；设置范围过小，会漏掉车身上方的悬空障碍物。

4.3 地面分割和聚类避障

地面分割是把属于地面的点去掉，这样障碍物检测就只看垂直方向有明显高度的对象。常见做法包括 RANSAC 拟合平面、高度阈值法和栅格高度差法。RANSAC 的做法是反复随机选取三个点拟合一个平面，统计落在平面附近的点，得分最高的平面被当作地面，然后把距离该平面太近的点剔除。这种办法在平坦路面效果好，但遇到坡道和台阶时需要额外处理。

去掉地面后，再用欧几里得聚类把空间上相邻的点分成一个个对象，每个聚类对应一个障碍物，然后计算它的最小距离、包围盒和速度。这套流程在 ROS 2 里可以用PCL、laser_filters或自研节点实现。对 2D 激光雷达来说，更常用的方式是直接把 scan 数据喂给 navigation2 的 costmap，在地图层里做膨胀和避障。3D 点云则需要先做压缩或投影，因为原始点云的数据量过大，直接丢进全局规划器会拖垮 CPU。

5. 常见问题排查

5.1 启动后看不到点云

这是接入激光雷达时最高频的问题，排查顺序不应是随便换接口，而是按从输入到输出的链路走。

5.2 距离跳变和飞点

现象是点云里偶尔出现一个点突然跑到几十米外，或者近处物体边缘有毛刺。可能原因包括高反射率目标、阳光直射、雷达表面有污渍、以及被测物体表面本身很暗或很亮。检查方式是把雷达静止放置，观察同一位置多帧点云的稳定性。处理方式通常是开启 SDK 的多回波模式、提高置信度阈值，或者在上游算法里加入基于距离差的离群点剔除。

5.3 多台雷达互相干扰

一个机器人装了两台以上雷达时，A 雷达发出的激光可能被 B 雷达接收，表现为点云出现周期性重影。检查方式是两台雷达分开启动看是否正常，一起启动看是否出现新增噪点。不同厂商的处理方式不同，有的支持编码或抗串扰功能，有的要求错开安装角度和同步信号。购买前确认型号是否支持抗干扰，比调试时再加软件补偿省事得多。

5.4 帧率上不去、CPU 占用高

点云处理和可视化都可能成为瓶颈。先确认驱动输出本身是否达到额定帧率，如果驱动输出正常，说明瓶颈在算法节点。常见优化包括降低点云分辨率、只保留感兴趣区域、用体素滤波器降采样，以及关掉 RViz 里不必要的渲染。生产环境还要考虑把点云处理和导航放到不同 CPU 核心，或者用 GPU 点云库加速。

6. 选型清单与工程实践建议

6.1 机器人激光雷达选型检查清单

采购或评估一款激光雷达之前，可以把下面这些问题逐项确认一遍：

• 雷达的测距能力在 10% 和 90% 反射率下分别是多少米，而不是只看最大测距。
• 垂直视场角是否覆盖机器人的坡道、楼梯或脚下盲区。
• 角分辨率在目标检测距离上能不能分辨出 2 到 3 厘米粗的线缆。
• 帧率、点频和输出接口是否满足视觉融合或导航节点的数据需求。
• 室内外是否都需要，防护等级、工作温度范围是否符合实际运行环境。
• 官方是否提供 ROS 2 驱动、配置示例和已知问题列表。
• 长时间运行是否会因为发热导致测距漂移，是否有老化测试报告。
• 备用雷达、连接线、标定文件的采购周期和成本。

这些问题最好形成一份对比表，拿两到三款型号放一起打分，比单独看某一款的宣传参数要直观。选型不是选最贵或参数最高的，而是选与运行环境、算法栈、供应链能力最匹配的。

6.2 学习环境与生产环境差异

学习阶段只需要跑通话题和点云可视化，开发环境可以随意改参数。生产环境则完全不同，至少要考虑配置外置化、异常处理、日志监控、权限和安全、回滚方案、版本兼容、数据备份和功耗管理。具体来说：

• 驱动配置放入配置中心或单独配置文件，不写死在代码里。
• 给点云话题增加 QoS 策略和超时告警，雷达断线要能自动重启或上报。
• 记录点云帧率、延迟、异常点占比等指标，用于发布后体检。
• 生产固件要和 SDK 版本匹配，升级前先在老化环境跑一周。
• 户外机器人要做阳光、雨雾、沙尘下的长测，不能只在室内验证。

6.3 半壁江山背后的技术信号

回到标题里的“机器人业务已占半壁江山”，本质上是在说激光雷达的量产逻辑已经从单台自动驾驶测试车，转向了大规模出货的机器人产品。对开发者是好事：传感器成本下降，驱动和算法生态更完整，SLAM、导航和避障的门槛也会随之降低。

如果你刚开始入门，建议先买一台便宜的单线激光雷达，在 ROS 2 里跑通建图和定位，再逐步加一台 3D 雷达做避障。把传感器原理、参数含义和工程排查方法掌握扎实后，再转向人形机器人或室外复杂环境，会顺手很多。这个领域的技术栈会继续往低成本、高集成度、多传感器融合的方向走，越早把基础链路摸熟，后面做产品时的主动权越大。