企业官网建设流程全解析

如果你手头有一台装了 Ubuntu 20.04 的电脑，又刚好买了个思岚 RPLIDAR 二维激光雷达，估计你现在最想做的事就是让它赶紧转起来、把 /scan 数据发出来。这事情说难不难，但我在帮朋友和自己搭环境时确确实实踩过不少坑：串口没权限、雷达转了一半停住、launch 直接闪退、RViz 里看不到点云……每一件都能让人卡上半天。

这篇内容我打算按照我自己的搭建顺序来讲：先说思岚 RPLIDAR 各型号之间的区别和通信原理，再带你过一遍 Ubuntu 20.04 下的环境准备，然后是官方 SDK 编译和 ROS 驱动安装，最后把实际使用中常见的坑整理成速查表。全程基于 Ubuntu 20.04 + ROS Noetic，如果你是在虚拟机里跑，我也会提一句 USB 直通的注意点。适合刚接触激光雷达的小白，也适合被驱动折腾过但想看明白原理的老手。

1. 先把思岚 RPLIDAR 这个家族看明白

1.1 A系列、S系列到底差在哪

思岚的二维激光雷达名气很大，最常见的是 A1、A2、A3，再往上就是 S1、S2 这类 TOF 方案。很多人买回来只会用，不看硬件差异，其实这跟你后续选驱动、调参数有直接关系。

A 系列用的基本都是三角测距原理：激光发射器射出一束光，经过物体反射后，用内部的线阵 sensor 接收，根据光斑在 sensor 上的位置偏移算出距离。这种方案优点是近距离精度不错、成本低、适合室内导航；缺点是测量距离普遍不算远，室外强光下容易受影响。S 系列则用了 TOF（飞行时间）原理，测距更远、抗光性更好，价格自然也更贵。

从驱动角度看，好消息是思岚的 SDK 基本把所有型号统一了。也就是说，你下载一个 rplidar_sdk，A1、A2、A3 都能编出来跑，ROS 驱动也是同一套 rplidar_ros 包。差别主要集中在波特率和扫描频率上，到时候根据自己雷达背面的标签纸填参数就行。

1.2 数据是怎么从雷达传到电脑里的

你要想排错，就得先理解数据链路。RPLIDAR 在雷达内部把扫描到的距离和角度打包好，通过串口（UART）发送。我们拿到手的雷达模块一般已经集成了 USB 转串口芯片，常见的是 CP2102，插上电脑后系统会识别成类似/dev/ttyUSB0的设备，这就是串口设备文件。

所以驱动安装这件事，本质上分两半：一半是让系统能认出这个 USB 转串口设备并拿到读写权限，另一半是跑一个能解析雷达协议的软件。前者弄不好，后续各种报错都会冒出来；后者弄不好，只会看到乱码或者直接没反应。

这里我多说一句为什么很多人一上来就在/dev/ttyUSB0上卡住。Linux 系统对串口设备的访问权限限制很严格，默认情况下普通用户没有读写权限。Ubuntu 桌面版插上雷达后，你能在lsusb里看到设备，但打开串口时会提示Permission denied，这就是权限粒度为用户组的原因。解决办法就是你把自己的账户加入dialout组，或者写一条 udev 规则，让系统给这个设备开放权限。步骤我放在下一节，照着做就行。

2. 环境准备：Ubuntu 20.04、ROS Noetic、USB权限三板斧

2.1 ROS 装到能跑 launch 就算及格

如果你已经有能用的 Ubuntu 20.04，并且已经装好 ROS Noetic，这一小节可以直接跳过。没装的话，我给出最经典的一条龙：

sudo apt update sudo apt install ros-noetic-desktop-full echo "source /opt/ros/noetic/setup.bash" >> ~/.bashrc source ~/.bashrc

桌面完整版会包含 RViz、tf、常用 sensor_msgs 这些，后面可视化雷达数据时不用再补装依赖。如果你刚入门，我建议装desktop-full，别省那个空间去装ros-noetic-ros-base，不然后面看到满屏缺包错误会怀疑人生。

还有一个容易漏的地方：装完 ROS 后别忘了初始化rosdep，虽然 rplidar_ros 本身不需要太多额外依赖，但你自己后续建图、编译其他包时一定会用到：

sudo rosdep init rosdep update

如果rosdep update因为网络问题卡住，说明你的网络环境对 GitHub 等源不够友好，这种问题我不在博客里展开，但你可以通过配置本地镜像源或者代理源的方式来解决，这不是雷达本身的问题。

2.2 USB 权限：两行命令解决大半问题

雷达插上电脑后，先敲：

lsusb

正常情况下你能看到一行类似：

Bus 001 Device 003: ID 10c4:ea60 Silicon Labs CP210x UART Bridge

如果看不到，先检查 USB 线是不是纯充电线，很多线只能供电不能传数据。换一根线往往就解决了。接下来确认系统认出的串口设备：

ls -l /dev/ttyUSB*

可以看到/dev/ttyUSB0这样的设备文件。这个时候你直接用 SDK 打开串口大概率是Permission denied。解法是把当前用户加进dialout组：

sudo usermod -aG dialout $USER

改完需要注销重新登录一次，或者重启机器。不想重启的话，也可以临时用sudo chmod 666 /dev/ttyUSB0降低门槛，但这只是临时的，下次拔插又变回去了。

我更推荐直接写 udev 规则，让系统每次插上雷达就自动放开权限。创建文件/etc/udev/rules.d/99-rplidar.rules，内容写：

KERNEL=="ttyUSB*", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", MODE="0666", GROUP="dialout"

然后重载规则：

sudo udevadm control --reload-rules sudo udevadm trigger

这样以后再插雷达，设备权限就是对的。有人可能会问：为什么非要拘泥于dialout组？因为 Ubuntu 系统默认把串口设备放进dialout组，你把用户塞进去，等于给了所有常见串口设备的读写权限。写 udev 规则时指定GROUP="dialout"也是为了和系统管理方式保持一致，免得后面其他串口设备出现权限混乱。

另外，用虚拟机跑 Ubuntu 的同学注意：VMware 和 VirtualBox 默认不会把 USB 设备直接透传给你，你必须在虚拟机菜单里设置 USB 直通，把 RPLIDAR 从宿主机连接到虚拟机。怎么操作我放后面“常见问题”里具体说，这里先提示一句，免得你折腾半天系统设置结果根本没找到设备。

3. 官方SDK编译与快速验证

3.1 从 GitHub 拉 rplidar_sdk 并编译

ROS 驱动接触到的数据其实来自底层 SDK，所以我习惯先把官方 SDK 跑起来，验证雷达硬件、串口链路都没问题，再上 ROS。这样可以避免“以为是驱动坏了，其实是雷达供电不足”这种乌龙。

先安装编译工具：

sudo apt install git cmake build-essential

然后拉取 SDK：

git clone https://github.com/Slamtec/rplidar_sdk.git cd rplidar_sdk

新版 SDK 是 CMake 工程，编译很简单：

cmake -B build cmake --build build

编译产物一般在output/linux/release/目录下，你可以看看有没有ultra_simple这个可执行文件。如果是在旧版 SDK 里，也有直接的make命令，原理都一样。

这里顺便解释一下为什么要先编译 SDK：它不依赖 ROS，不依赖 sensor_msgs 那一套东西，只要串口权限对，它就能把雷达的原始数据打出来。如果这一步都跑不通，问题基本锁定在硬件、USB 线、串口权限这三块，排查范围很小，效率最高。

3.2 用 ultra_simple 验证雷达有没有输出

运行 SDK 自带的ultra_simple工具：

cd output/linux/release ./ultra_simple /dev/ttyUSB0 115200

如果你的 RPLIDAR 型号波特率不是 115200，换成官方文档给出的值，比如部分 A2/A3 系列是 256000。

如果一切正常，你会看到雷达电机转起来，终端里不断刷出类似下面的数据：

angle: 0.000000 distance: 0.120000 quality: 12 angle: 1.000000 distance: 0.150000 quality: 11 angle: 2.000000 distance: 6.540000 quality: 88 ...

每行是一个扫描点的角度、距离和信号质量。能看到这个输出，说明雷达硬件、USB 转串口、协议解析链路全通了。Ctrl+C 停掉程序后，雷达电机会跟着停转。

我遇到过一次很奇怪的情况：ultra_simple能输出数据，但角度跳着走，比如从 10 度直接跳到 60 度，看起来断断续续。最后发现是雷达放在桌面上太矮，周围一圈全是近距离障碍物，加上 USB 供电不稳导致电机转速波动，扫描频率和预期不一致。换了个带外部供电的 USB HUB 之后，数据马上稳定了。这个经验在后面建图时也很关键。

4. 基于ROS的驱动安装与可视化

4.1 创建工作空间并拉取 rplidar_ros

SDK 层面验证完，接下来就可以让 ROS 来接管了。rplidar_ros 是思岚官方维护的 ROS 驱动包，支持 ROS1 和 ROS2 的分支。我们先说 ROS1 Noetic 下的用法。

创建标准工作空间：

mkdir -p ~/catkin_ws/src cd ~/catkin_ws/src git clone https://github.com/Slamtec/rplidar_ros.git cd ~/catkin_ws catkin_make

catkin_make编译的时候会顺带编译 rplidar_ros 包，成功后需要让当前终端知道新工作空间：

source ~/catkin_ws/devel/setup.bash

别忘了echo "source ~/catkin_ws/devel/setup.bash" >> ~/.bashrc，不然每次开终端都要手动 source。这一步容易被新手忽略，后果就是敲roslaunch rplidar_ros的时候提示包找不到。

如果你对 CMake 构建方式更熟，也可以用catkin build，前提是装一下python3-catkin-tools。两种方式随便选，但别混用同一个工作空间，否则目录结构会乱。

4.2 launch 文件参数逐个拆解

rplidar_ros 包里提供了现成的 launch 文件，不过它默认参数不一定适合你的型号。我建议打开看一下：

roscd rplidar_ros cat launch/rplidar.launch

里面关键参数大概有这些：

frame_id这个参数很多人会忽略，但我建议一开始就把它设成laser，不要随便命名。后续做导航、建图时，tf 树里所有坐标关系都要围绕这个 frame_id 展开，如果你一会儿叫laser，一会儿叫rplidar，cartographer_ros 或者 move_base 配置里对不上，报错会非常抽象。

angle_compensate建议设为 true。原理是 RPLIDAR 运行时，角度每隔一个固定间隔输出一个点，但在电机转速波动时，点与点之间的角度间隔会不均匀。开启角度补偿后，内部会统一处理扫描角度的均匀性，后端算法拿到数据更规整。

4.3 用 RViz 看到 /scan 点云

启动雷达前，确保先启动roscore。如果你用的是 ROS 1，最简单的是：

roslaunch rplidar_ros rplidar.launch

正常的话终端会滚动日志，雷达电机同步转起来。然后再开一个终端：

rviz

在 RViz 左侧的 Display 面板里点击 Add -> By topic，选择/scan对应的 LaserScan 添加。把 Global Frame 改成laser（和 launch 里设置的 frame_id 一致），你就能看到一圈红色点云了。

如果看到的是一堆坐标乱飞、雷达点不在水平面转圈，多半是 Global Frame 没有设置成雷达坐标系。RViz 默认的 Global Frame 可能是map，激光数据来了但位置对不上，看起来就像杂散点。

还有个小经验：直接把雷达放平在桌面上扫，桌面会形成一条直线点云，墙和桌腿就是直线上的断口。你可以拿个纸箱在雷达前晃动，点云应该有明显遮挡变化，这比看角度数值直观得多。

5. 实际使用中避坑：从串口权限到虚拟机直通

5.1 问题速查表

我把自己遇到过和帮别人排查过的问题整理成了表格，建议截图存一份。

5.2 供电和电机：经常被忽略的“硬件坑”

软件层面都对了，雷达还是不转，这就要怀疑供电。

A1 这类入门型号，USB 口供电一般够用，但笔记本的 USB 口在负载较大时电压会掉，雷达电机可能转到一半被卡住，表现就是启动一瞬间转了一下，然后停了。这时候不要死磕驱动，先找个带外部供电的 USB HUB 试试。我记得一次在 Ubuntu 20.04 上调试，雷达扫描出现周期性缺口，大概每转一圈就掉一截数据，后来用万用表测了一下 USB 电压只有 4.2V，换供电后立刻正常。

A2、A3 或者部分高配型号，电机功耗更大，最好按照官方要求接外部电源或配套扩展板。这些型号的 USB 口更多是传数据用，光靠电脑口供电容易出事。

还有一个小细节：RPLIDAR 的电机控制引脚一般会由 SDK 在初始化时拉高，默认启动后才开始转。如果你自己改了 udev 规则，误操作把电机允许脉冲停掉，雷达就会看起来“有串口、没转动”。这种情况建议恢复原始 udev 规则，然后重新插拔。

5.3 数据异常别急着怪驱动

点云数据跳变这个问题，经常有人来问我，其实大概率不是驱动 bug，而是环境反光。RPLIDAR 对黑色吸光物体、高透明玻璃、镜面反射物体都容易产生异常值。黑色物体激光打上去回波信号弱，可能直接丢失；玻璃和镜子则会产生虚假的远距离反射点。

如果你发现某一块区域点云特别稀或者有“飞点”，先检查那里有没有透明水瓶、玻璃门、黑色亚光面板。调试环境尽量选在桌椅、纸箱、白墙这种正常漫反射物体旁边。

另外，扫描频率越高，单圈点云密度越低。A1 默认 10Hz 扫描时，一圈大概几百个点，你放大看肯定不是连续的线，这是正常现象。如果追求更密的数据，可以把扫描频率调低，或者换个更高采样率的型号。

5.4 ROS2 和建图扩展：驱动之外的上层玩法

现在不少同学用的是 Ubuntu 20.04 配 ROS2 Foxy，思岚也提供了 rplidar_ros2 包。用法类似：创建一个ros2_ws/src，clone 对应分支，用colcon build编译，最后ros2 launch rplidar_ros2 rplidar.launch.py。话题同样会发sensor_msgs/LaserScan。

驱动跑通之后，最自然的下一步就是建图。像 cartographer 这类 SLAM 方案吃的就是/scan+ 里程计 + IMU 这个黄金组合。激光雷达驱动就是你整个机器人感知系统的最底层，它只负责把一帧一帧的扫描数据发出来，之后的建图定位都建立在稳定、低延迟的激光话题之上。所以我一直强调驱动阶段多花点时间排查问题，建图时你会省很多力气。

6. 最后分享几个我自己的习惯

踩过几次坑之后，我每次拿到一台新的 RPLIDAR 雷达，都会按固定流程走一遍：先lsusb确认设备存在，再dmesg | tail看内核日志，然后用官方 SDK 的ultra_simple验证数据，最后才上 ROS 驱动。很多人一上来就 roslaunch，出了问题日志又乱七八糟，根本分不清是系统没识别 USB、还是串口权限不够、还是协议解析有问题。

还有一个习惯是固定/dev/ttyUSB0的设备名。插了多个串口设备时，内核分配的设备节点会变，今天 ttyUSB0，明天 ttyUSB1，launch 文件里的路径错了就起不来。解决方法是写一条比较严格的 udev 规则，根据idVendor、idProduct和物理 USB 路径分配固定名称，比如/dev/rplidar。这样 launch 文件写一次就不用改了，后面接 GPS、底盘的串口设备时也不会大家抢名字。

驱动这个东西，说白了就是“协议解析 + 权限管理”，真的把每一步的原理搞清楚，换个品牌的雷达你也能很快上手。希望这篇能让你在 Ubuntu 20.04 上少走点弯路，别像我当年那样，光是权限问题就折腾了一整天。