说实话，这块RPLIDAR C1激光雷达和树莓派4B的组合，折腾得我比预想中久不少。去年年底拿到C1的时候，我第一次操作还是在X86笔记本上，插上USB转串口，make完官方SDK，三分钟就看见了角度和距离数据刷屏。可等我把这套东西整体挪到树莓派4B + Ubuntu 22.04上的时候，问题一个接一个：串口设备识别不到、dialout权限没加导致open failed、GPIO UART被系统串口控制台占用、供电电流不够导致雷达转速忽快忽慢、数据断帧……每一个问题单拎出来都不算难，但串在一起，足以把初学者的热情消磨干净。这篇文章就是把我从烧录系统、硬件接线、SDK编译，到数据解析、再接ROS2建图的完整过程记录下来，顺带把每个坑的成因和排查方式讲清楚。

适合谁看？手上正好有树莓派4B（或者其他arm64板子）和RPLIDAR C1，想从零跑通官方SDK，或者想进一步接ROS2做SLAM建图的人。哪怕你之前完全没碰过树莓派，只要按顺序跟着做，大概率也能把整个流程复现出来。

1. 这套组合的选型逻辑：为什么是4B、22.04和C1

1.1 树莓派4B在这套方案里的定位

树莓派4B现在依然是做机器人教学和原型验证最稳妥的板子。它有四个Cortex-A72核心，最高8GB内存，带USB 3.0，跑aarch64架构的Ubuntu非常成熟。为什么不用树莓派5？树莓派5性能和接口确实更好，但价格贵、散热要求高，而且早期部分Ubuntu镜像对5的支持明显没有4B完善。为什么不用Zero 2W？内存只有1GB，编译SDK勉强够，但后面一旦碰ROS2、cartographer这种大工程，很容易OOM，要么加swap要么直接放弃。

所以4B是个“性价比刚好”的选择：算力允许你在板子上直接编译、跑一点轻量算法，功耗又控制在几瓦，适合长时间挂在机器人上。内存版本建议选4GB或8GB，后面编译cartographer时，内存越多越省心。

1.2 Ubuntu 22.04比20.04好在哪

标题里直接点名了Ubuntu 22.04，这不是随便选的。22.04是LTS版本，支持周期到2027年，更关键的是它是ROS2 Humble的官方基准系统。很多人在搜“树莓派4b安装ubuntu20.04”，20.04确实也能用，对应的是ROS2 Foxy，但Foxy已经接近生命周期末尾，新版本的很多ROS包、教程都逐渐不再维护它了。

我自己的体会是：新项目直接22.04，别给自己留迁移成本。如果你用Ubuntu Server版，镜像只有几百MB，装完系统本身内存占用非常低，剩下来的资源全部留给雷达驱动和SLAM算法。桌面版在4B上也不是不能用，但桌面环境会吃掉不少内存和CPU，机器人跑起来经常要图形界面，实际上SSH远程操作才是常态。

1.3 思岚RPLIDAR C1的定位

RPLIDAR C1是思岚入门级激光雷达里比较有代表性的新成员。它是三角测距方案，360度扫描，测距范围大概从0.12米到12米，典型扫描频率在10Hz左右，对于室内建图、避障、教学演示来说完全够用。相比A1系列，C1体积更小、价格更亲民；相比更高端的A2/A3，C1不用反光镜系统，精度和抗环境光能力会弱一些，但这个价位本来就不是对标工业级场景的。

官方开源了跨平台SDK，支持Linux、Windows、macOS，这一点非常关键。SDK把底层串口协议、电机控制、数据解析全封装好了，我们拿到手的任务就是从SDK里把数据读出来、利用起来。这篇指南要解决的，就是在树莓派4B + Ubuntu 22.04这套环境下，把“读出数据”这件事彻底跑通，给后面的SLAM打基础。

2. 系统部署与接线：从烧录到串口识别的完整链路

2.1 烧录Ubuntu Server 22.04的细节

烧录工具推荐直接用Raspberry Pi Imager，在“其他通用操作系统”里能找到Ubuntu Server镜像。也可以去Ubuntu官网下载树莓派专用的22.04 LTS 64位镜像，然后配合balenaEtcher写卡。

几个容易忽略的点：

• 选错镜像架构会非常难受。一定选64位（arm64），因为很多ROS2二进制包和第三方库已经逐步放弃32位armhf了。装完开机后可以用uname -m看，输出aarch64就对了。
• 写入速度直接影响体验。树莓派4B对SD卡速度比较敏感，建议A2级别、U3速度的卡，至少32GB。太慢的卡在apt安装、编译写盘时会明显拖慢进度。
• 首次开机前最好在Imager里提前配置好WiFi和SSH，或者准备好网线。Ubuntu Server默认启用DHCP，插上网线后去路由器后台找树莓派的IP，然后ssh ubuntu@ip，初始账号密码是ubuntu / ubuntu，首次登录会强制改密码。
• 系统会自动扩容根分区，不需要像早期系统那样手动resize。

2.2 两种接线方案：USB适配器与GPIO UART

RPLIDAR C1本体的数据接口是3.3V TTL串口，但供电需要5V，所以接线方式直接决定后续会不会踩坑。

方案A：使用官方USB适配板。这是我最推荐的初学方式。C1可以通过配套的USB小板直接插到树莓派的USB口上，驱动内部完成电平转换和供电。插好之后执行lsusb，大概率能看到Silicon Labs CP210x的芯片信息，然后在dmesg | tail里看到ttyUSB0的分配记录。

方案B：直接用GPIO UART。适合做一体化机器人，省一个USB口。需要对照树莓派4B的引脚功能图确认引脚位置：

• 树莓派GPIO14（TXD）接C1的RXD
• 树莓派GPIO15（RXD）接C1的TXD
• GND接GND
• 5V接5V

注意，这里最容易犯的错是接错TXD和RXD方向，串口通信必须交叉连接。另一个坑是Ubuntu默认把UART0分配给了串口控制台，雷达的数据会和系统日志混在一起，表现出来就是乱码、数据完全不可用。解决方法是编辑/boot/firmware/cmdline.txt，把console=serial0,115200这段参数删掉，然后在/boot/firmware/config.txt里加一行enable_uart=1，重启后UART就空出来给雷达用了。设备名一般会出现在/dev/serial0或/dev/ttyAMA0。

无论哪种方案，都建议给雷达单独稳定供电。C1的电机启动瞬间电流不低，树莓派USB口供电余量有限，后面我会专门讲这个坑。

2.3 串口权限：很多人卡在打不开设备这一步

当你运行官方SDK里的示例时，最经典的报错就是Cannot open serial port。这个报错九成以上和权限有关。

插上USB适配器后执行：

ls -l /dev/ttyUSB0

输出一般是crw-rw---- 1 root dialout ...。也就是说，只有root用户和dialout组里的用户能访问这个设备。当前登录用户默认不在dialout组，所以必须把自己加进去：

sudo usermod -a -G dialout $USER

然后注销重新登录，或者在终端执行newgrp dialout让组权限立即生效。临时应急也可以：

sudo chmod 666 /dev/ttyUSB0

但重启后权限会恢复，不建议作为长期方案。

还有一个树莓派Ubuntu环境下的经典问题：插上CH340或者CP210x串口线后，设备名根本不出来，dmesg里报错usbserial: usb_serial_generic_register failed或者brltty抢占设备。这是因为系统自带的brltty盲文终端服务和某些USB转串口芯片冲突，直接卸载即可：

sudo apt remove brltty

另外，如果以后要同时接多路串口设备，设备名漂移会非常烦人。你可以写一个udev规则来固定符号链接，比如针对CP210x芯片：

SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", MODE="0666", SYMLINK+="rplidar"

保存到/etc/udev/rules.d/99-rplidar.rules，重载规则后插上设备，以后直接用/dev/rplidar访问，再也不用担心设备名变成ttyUSB1。

3. SDK编译实操：从clone到make落地的全过程

3.1 获取SDK和基础依赖

SDK在GitHub上的官方仓库是Slamtec/rplidar-sdk。树莓派上编译这份代码几乎不需要额外依赖，有g++和make就够了。先把基础工具链装上：

sudo apt update sudo apt install -y git build-essential git clone https://github.com/Slamtec/rplidar-sdk.git cd rplidar-sdk

如果你在树莓派上直接用GitHub不稳定，可以把仓库先拉到本地电脑或者用镜像仓库，再打包传到板子上。SDK的目录结构大致是：

• sdk/src：核心驱动源码
• sdk/app：若干示例应用，比如ultra_simple、rfstandalone
• sdk/samples：更复杂的示例工程
• output：编译输出的默认目录

树莓派4B是aarch64架构，不需要交叉编译，直接在板上make即可，编译时间非常短。如果之前在笔记本上make过，注意代码要重新在树莓派上编译，不能直接把x86的二进制拷过来用。

3.2 编译命令与产物

在SDK根目录执行：

make both

both表示同时编译常规工具和带帧模式的工具。也可以只编某个示例：

cd sdk/app/ultra_simple make

编译完成后，产物默认在output/Linux/Release/目录下，你会看到ultra_simple、rfstandalone、rfuzz这些可执行文件。如果你更喜欢CMake，同样支持：

mkdir -p build cd build cmake .. -DCMAKE_BUILD_TYPE=Release make

CMake方式的好处是方便IDE集成，但说实话，官方SDK用根目录的make both最省事，没那么多配置项。

3.3 编译问题排查

这一套在4B上基本是零依赖，唯一可能出问题的是你用了精简系统，没装build-essential。遇到make: command not found，直接：

sudo apt install build-essential

如果你的树莓派是1GB内存版本，同时在跑其他服务的话，make时可能卡住。解决办法是降低并行度：

make -j2

还有个小建议：不要用sudo make来编译。sudo会把编译产物变成root属主，之后你非root用户运行示例时还得处理文件权限，属于给自己找麻烦。

3.4 首次运行示例程序

进入产物目录，运行ultra_simple：

cd output/Linux/Release ./ultra_simple /dev/ttyUSB0

不指定波特率时，SDK会自动和雷达协商通信速率，所以一个参数就够了。如果一切正常，你立刻能看到类似这样的输出持续滚动：

RPLIDAR S/N: 0000000000000000 Firmware Ver: 1.25 Hardware Ver: 4 theta: 0, dist: 800 theta: 16, dist: 790 theta: 32, dist: 802 ...

这里theta是角度，dist是毫米单位的距离。第一次跑通这个输出的仪式感很强，意味着你的雷达、接线、系统环境整个链路是通的。

如果运行时报错，对照一下：

• Cannot open serial port：回到权限那一步，检查设备名和dialout组。
• 输出完全没有但程序不退出：雷达没在转或供电不足，检查5V供电。
• 输出乱码/持续timeout：接线不稳，或者GPIO模式下串口控制台没有关干净。

4. 理解激光雷达的数据格式：从串口帧到自定义读取

4.1 三角测距原理与C1的数据特性

RPLIDAR C1之所以便宜，核心原因是它用了三角测距方案。简单说，激光二极管发射一束红外光，打到物体后反射回来，被雷达内部的图像传感器捕捉。物体距离不同，光点在传感器上的像素位置就不同，通过几何三角关系就能算出距离。这种方法在近距离范围内精度不错，但距离越远，光点位置变化越不明显，精度会下降；遇到强光、镜面、玻璃这类反射异常的表面，数据就会变差。这和现在更高端的TOF雷达相比是两种技术路线，但价格差好几倍，教育项目完全够用。

数据层面，C1每完成一次360度扫描，大约会产生数百个测量点。每个点包含三部分核心信息：

• 质量/同步标志：用来区分新一圈扫描开始，以及反射信号质量
• 角度：以1/64度为单位的Q6格式，实际角度需要除以64
• 距离：单位是毫米

角度不是严格的整数度，比如可能是 0.015625°、0.78125°，这是正常的。雷达转速不是绝对均匀，数据处理时按原始角度来就行，不要假设固定角度间隔。

4.2 在SDK回调里拿到数据才是最快路线

很多人拿到SDK第一反应是想自己去写串口解析。SDK本身已经帮你把数据帧、校验、同步都处理好了，最快的方式是直接改官方示例，把自己的逻辑加进去。

在ultra_simple示例的源码里，核心循环大致是这样：

rplidar_response_measurement_node_t nodes[360*2]; size_t count = sizeof(nodes) / sizeof(nodes[0]); result = drv->grabScanData(nodes, count); drv->ascendScanData(nodes, count); for (size_t i = 0; i < count; ++i) { float angle = (nodes[i].angle_q6_checkbit >> RPLIDAR_RESP_MEASUREMENT_ANGLE_SHIFT) / 64.0f; uint16_t distance = nodes[i].distance_q2; // 这里就是每个测量点的角度和距离 }

grabScanData获取一帧数据，ascendScanData会把这些点按角度从小到大排序。排序这一步很重要，因为雷达旋转时数据点是顺着角度顺序回来的，但不做处理可能会漏掉同步点。

你可以在这个循环里把数据直接写入CSV文件：

std::ofstream out("scan.csv"); out << angle << "," << distance << std::endl;

在树莓派上跑几十秒，生成的CSV拷到电脑上用matplotlib画成极坐标图，就能看到房间轮廓。不需要先上ROS，这个验证过程足够直观。

4.3 想从串口裸读协议？可以，但先确认需求

有一种情况确实需要自己解析原始串口数据：硬件资源受限，不想引入整个SDK；或者你想在MCU上直接接C1。RPLIDAR的串口协议以0xA5作为请求起始字节，后面跟着命令码、负载长度和校验信息。比如后台需要不停发送扫描指令，雷达才会持续回传测量节点。

但我的建议很明确：如果树莓派是你的目标平台，直接用官方SDK就够了，自定义解析只有在换到其他平台时才值得做。因为协议里有同步、波特率协商、校验码这些细节，自己解析很容易在边界情况上翻车。真到了需要裸解析的时候，对照SDK源码里的rplidar_protocol.h和示例代码来写，比照着协议文档猜要稳得多。

5. 进阶：接入ROS2 Humble，让C1参与SLAM建图

5.1 树莓派上装ROS2的取舍

Ubuntu 22.04对应的ROS2发行版是Humble，这也是为什么这套组合适合做机器人。安装命令不复杂：

sudo apt install software-properties-common sudo add-apt-repository universe sudo apt update sudo apt install ros-humble-ros-base

这里我用的是ros-base而不是ros-humble-desktop。树莓派4B的资源有限，desktop会装一堆可视化工具，占地方又吃内存。真正需要RViz2的时候，完全可以在另一台电脑上装ROS2并配置为同一ROS2_DOMAIN_ID，把可视化拉到自己电脑上跑。这样树莓派只管数据处理和算法，画面渲染放在PC上，体验好很多。

5.2 编译运行rplidar_ros包

思岚官方维护了rplidar_ros的ROS2版本，clone下来直接编译：

mkdir -p ~/ros2_ws/src cd ~/ros2_ws/src git clone https://github.com/Slamtec/rplidar_ros.git cd ~/ros2_ws colcon build --symlink-install source install/setup.bash

启动驱动：

ros2 launch rplidar_ros rplidar_c1_launch.py

如果你的rplidar_ros版本没有专门针对C1的launch文件，就用通用launch，并手动指定串口：

ros2 launch rplidar_ros rplidar.launch.py serial_port:=/dev/ttyUSB0

启动后验证话题：

ros2 topic hz /scan ros2 topic echo /scan --once

hz显示的话题频率应该在8到10Hz左右。如果频率很低，先别急着怀疑雷达，回到SDK的ultra_simple看原始数据流是否正常。

5.3 cartographer源码编译的两个现实建议

热搜词里有个很典型的组合：“ros2 + cartographer + 激光雷达建图并保存”。理想很丰满，现实是cartographer_ros在ROS2 Humble下没有预编译二进制包，得源码编译。这是个痛苦的过程，依赖多，编译时间长，abseil版本还容易冲突。

如果你最终目的是先跑通建图，我有一个更现实的路径：先用ros-humble-slam-toolbox跑通整个流程。

sudo apt install ros-humble-slam-toolbox ros2 launch slam_toolbox online_async_launch.py

slam_toolbox和cartographer都是2D激光SLAM方案，对于单个房间、简单环境的效果都足够，而且安装省事，很适合树莓派。如果你确实需要cartographer，要么准备好足够的内存和swap（建议4GB swap），要么考虑用Docker镜像。纯激光模式在lua配置里要显式关掉IMU和里程计：

use_odometry = false, use_imu_data = false, num_accumulated_range_data = 1,

最后提醒一句：纯激光SLAM在运动过程中会逐渐累积漂移，尤其在走廊、玻璃墙这些场景特别明显。想建一张好看而稳定的图，要么控制机器人慢速移动，要么早点给自己接IMU和轮式里程计打基础。

5.4 保存地图：slam_toolbox和cartographer各来一套

地图保存是建图的收尾动作，很多人跑完SLAM却在最后一步卡住。

slam_toolbox场景下，只要SLAM节点在运行并且发布了/map，就可以用nav2的map_saver直接保存：

sudo apt install ros-humble-nav2-map-server ros2 run nav2_map_server map_saver_cli -f ~/slam_map

上面命令会生成slam_map.pgm和slam_map.yaml，PGM就是栅格化地图图像。

cartographer场景下，保存流程分两步。先把轨迹结束掉并把状态写出pbstream：

ros2 service call /finish_trajectory cartographer_ros_msgs/srv/FinishTrajectory "{trajectory_id: 0}" ros2 service call /write_state cartographer_ros_msgs/srv/WriteState "{filename: '/home/ubuntu/map.pbstream'}"

再把pbstream转换为pgm和yaml：

ros2 run cartographer_ros cartographer_pbstream_to_ros_map -pbstream_filename /home/ubuntu/map.pbstream -map_filestem /home/ubuntu/map

保存完成后务必检查map.pgm是否正常。如果全黑或全白，说明SLAM节点并没有把有效的栅格数据写到地图里，这时候要回头看雷达话题有没有连续数据、SLAM有没有在正常输出/map。

6. 实测中那些容易卡住人的坑与排查

6.1 现象与原因对照

下面这些坑是我实际测试中遇到过的，按照现象、排查链路、解决办法整理成了表格，方便你对照排查：

6.2 供电问题值得单独再强调

雷达数据异常的排查优先级里，供电永远排在最前面。C1的扫描电机在工作时需要瞬间电流，而树莓派4B的USB口在设计上更偏向数据设备，供电余量并不充裕。如果你用USB Hub，也要确认Hub本身是带电源的，而不是简单的一分多插口。

我自己的做法是：雷达供电和树莓派供电分开。雷达通过一个带电源开关的5V接线板供电，树莓派单独用官方电源。上电顺序我习惯先给雷达供电，等它转稳后再跑驱动程序。这样能减少启动瞬间电压跌落带来的数据污染。

6.3 热插拔和设备稳定性的建议

RPLIDAR C1属于光电精密器件，虽然USB支持热插拔，但我不建议在雷达运转时频繁插拔串口线。原因有两个：一是瞬间电流可能导致接口打火，二是串口线在带电状态下拔插容易让数据线进入不确定状态，有时候需要重插好几次才能恢复。

一个实用习惯是：接好线，用udev规则固定设备名，然后只通过树莓派的重启或驱动重启来控制雷达，不物理拔线。如果确实要拔，先把SDK/ROS节点停掉，再拔USB线。

另一个容易忽视的点是雷达窗口清洁。C1的发射和接收窗口如果沾了灰尘或指纹，近距离数据可能看不出问题，但中远距离的数据会明显变差。测试一段时间后如果发现测距整体变短，先擦一下雷达窗口，再谈算法优化。

最后分享一点个人操作习惯

这套组合玩下来，我最大的感觉是：它把“传感器从物理世界到数字世界”这个链路展示得非常完整，教育价值很高，但雷达的“脾气”也实实在在存在。它不是插上就能用的传感器，而是会把你的接线马虎、供电不足、系统配置不干净全部如实反映到数据里。所以，先把电源和串口权限这些基础工作做好，后面所有流程都会顺畅很多。

如果你打算从零开始复现这套环境，我的建议顺序是：先在树莓派上用USB适配器方式跑通ultra_simple，确认每一次转动都能稳定出数；再考虑GPIO UART省空间；最后再上ROS2和SLAM。别一上来就折腾cartographer，否则你根本分不清数据问题是雷达的、系统的，还是SLAM配置的。SDK跑通之后，后面的路其实就很开阔了。