1. 树莓派4B跑激光雷达这件事，为什么值得动手做一遍
把一台巴掌大的树莓派4B、一套Ubuntu 22.04系统、一颗思岚RPLIDAR C1激光雷达凑在一起，能做出什么？这是我这段时间反复被问到的问题。答案比很多人想的要实在：一套能跑通的二维环境扫描与建图平台。这个东西不花哨，但它是移动机器人、自动导航小车、室内测绘这些方向的入门底座——你能用它看到真实的距离数据流，能让机器人在房间里转一圈就吐出一张地图，还能把这套东西接到ROS2上继续往上叠算法。
我之所以选树莓派4B作为主控，理由很朴素。第一，它便宜且好买，几百块的板子烧了不心疼，适合反复折腾。第二，它自带40针GPIO、四个USB口、千兆网口和无线网卡，思岚C1这类USB接口的雷达插上就能用，不需要额外的转接板。第三，ARM64生态这两年成熟得差不多了，Ubuntu 22.04 LTS对树莓派4B有官方支持镜像，apt源里的ROS2 Humble也是现成的，省去了大量交叉编译的痛苦。相比之下，如果你拿一台x86小主机，功耗和体积都上去了；拿一块单片机，又跑不动完整的ROS2和建图算法。树莓派4B正好卡在那个"够用且不贵"的位置上。
选Ubuntu 22.04而不是20.04，主要是为了ROS2。ROS2 Humble的官方支持平台就是Ubuntu 22.04，这是长期支持版本，维护到2027年，apt直接装，不用自己编译源码。我在网上看到很多人还在纠结装20.04还是22.04，其实如果你的目标就是激光雷达加ROS2建图，22.04是更省事的那条路。20.04对应的ROS2 Foxy已经停止官方维护了，新项目没必要再往上靠。当然，如果你的项目里有一堆只支持Foxy的历史代码，那就另说——这也是我在实际选型时踩过的判断点，后面会专门聊。
思岚RPLIDAR C1是我这次用的雷达。它是思岚产品线里偏入门的一款二维激光雷达，360度扫描，USB直连，价格友好，配套的SDK和ROS驱动都有开源仓库。很多人第一次买雷达容易犯迷糊：看到参数表上写"12米测距""10Hz扫描频率"就以为随便哪款都行，实际上不同型号在室内强光下的表现、在深色物体上的回波质量、数据接口的稳定性差别很大。C1这个定位的雷达，最适合的就是室内、中小场景、对成本敏感的建图需求，比如房间级的地图构建、走廊导航、教学演示。
这套组合能解决的问题，说白了就是三件事：让树莓派认得出雷达、让雷达的数据稳定地流出来、让数据变成一张能用的地图。听起来简单，但每一步都有坑。系统镜像烧录、串口权限、udev规则、ROS2的驱动编译、TF坐标变换、建图参数调优，任何一环出问题，结果就是雷达转着但屏幕上什么都没有，或者地图飘得没法看。
这篇文章适合谁？如果你是刚拿到树莓派和雷达、想从零跑通一套建图demo的爱好者，这篇文章可以当成一份带坑位标注的操作记录；如果你已经装好了系统，卡在"雷达能转但ROS2收不到数据"这一步，可以直接跳到权限和驱动那几节；如果你在纠结硬件选型和系统版本，前几章的对比分析能帮你少走弯路。我会把每一步为什么这么做讲清楚，而不只是丢一串命令——因为真正让你卡住的，往往不是命令本身，而是命令背后的机制没搞明白。
2. 硬件选型与系统镜像：别在第一步就把自己坑了
2.1 树莓派4B的版本差异与散热这个绕不开的话题
树莓派4B有几个容易忽略的版本差异。内存有2GB、4GB、8GB之分。跑ROS2加建图，我建议至少4GB起步。原因在于ROS2 Humble加Cartographer这类建图包，运行时内存占用不低，再加上Ubuntu桌面环境本身要吃掉一部分，2GB版本会频繁触发交换分区，建图过程中卡顿甚至进程被杀。4GB是舒服的入门线，8GB适合你后面想在同一块板子上再叠视觉、导航这些模块。
另一个坑是供电。树莓派4B对电源很挑，官方要求5V/3A。很多人用手机充电头凑合，结果就是雷达一转、CPU一满载，电压跌下去，系统直接重启或者USB设备掉线。我实测中最典型的症状就是：雷达刚开始转得好好的，建图跑到一半突然断连，dmesg里刷一堆USB设备重新枚举的日志。换一个稳定的5V/3A电源，问题立刻消失。这类"看起来是软件问题、实际是供电问题"的情况，在树莓派项目里非常常见，一定要先把电源排除掉。
散热也是必须处理的。树莓派4B的SoC在持续负载下温度会冲到80度以上，触发降频，建图这种CPU密集型任务受影响明显。我用的是带风扇的金属外壳，风扇接在GPIO的5V和GND针脚上常转。这里提醒一句：树莓派4B的风扇针脚，5V对应的是物理引脚2或4，GND是6、9、14、20、25、30、34、39这些。如果你买的是三线风扇，第三根线是测速线，可以不接。接线时务必断电操作，接错到3.3V针脚上风扇转速会变慢，接反了风扇不转——这些都是新手常见的低级错误，但确实会让人排查半天。
存储方面，我强烈建议用质量好的A2级别microSD卡，容量32GB以上。别用那种便宜的大容量卡，树莓派上随机读写性能差，系统会明显拖慢。如果预算允许，用USB3.0接口接一个SSD启动，速度快一个档次，建图时写日志、存地图的体验完全不一样。SSD启动需要在树莓派上先改一次启动顺序，这个步骤官方文档写得很清楚，照着做就行。
2.2 Ubuntu 22.04 for Raspberry Pi的镜像选择与烧录要点
Ubuntu官方为树莓派提供了专门的镜像，路径是ubuntu.com/download/raspberry-pi。这里有个关键区分：桌面版和服务器版。桌面版带图形界面，方便你插显示器直接操作；服务器版没有界面，资源占用小，适合远程SSH。我的建议是，如果你手边有显示器和键盘，先用桌面版把系统装起来、网络配好、确认硬件都正常，再决定要不要换成服务器版。桌面版在树莓派的HDMI输出上第一次启动可能会遇到分辨率和黑屏问题，这时候别慌，多半是显示器的EDID识别问题，换个显示器或者等系统完全启动后再插HDMI线，通常能解决。
烧录工具用Raspberry Pi Imager最省事，它内置了Ubuntu镜像的下载选项，还能在烧录前预配置WiFi和SSH。这一步非常重要：在Imager的设置里提前填好WiFi名称密码、主机名、用户名密码，烧录完插卡开机，系统自动连上网络，你直接SSH进去，省去了接显示器配置的麻烦。我试过用Rufus这类通用工具烧录Ubuntu镜像，也能用，但Rufus不能预配置WiFi，你得自己处理cloud-init或者手动配网，反而更麻烦。所以树莓派场景下，Raspberry Pi Imager是更顺手的选择。
首次启动会比较慢，系统在做初始化，可能要三五分钟。耐心等，别急着断电。启动完成后，第一件事是更新系统：sudo apt update && sudo apt upgrade。树莓派的/boot/firmware分区里如果空间紧张，apt upgrade可能会报空间不足，这时候需要先清理一些不需要的包。这个坑挺隐蔽的，我第一次遇到时以为是镜像坏了，其实是boot分区满了。
网络配置方面，Ubuntu 22.04默认用netplan管理网络。如果你在Imager里配过WiFi，开机就自动连上。如果没连上，检查/etc/netplan/下的yaml文件。有个常见问题是树莓派4B的板载无线网卡在某些镜像版本里驱动加载不稳定，表现为wlan0时有时无。遇到这种情况，先rfkill list看是不是被软屏蔽了，rfkill unblock all解开；如果是驱动问题，可以插一个USB无线网卡临时顶上。有线网口是最稳的，做激光雷达项目我建议一开始就用网线，排除无线变量。
2.3 装完系统后的几项必做设置
系统跑起来后，有三件事建议立刻做完。第一，换apt源。默认源在国外，更新慢得让人崩溃。换成国内镜像源能提速十几倍，具体源地址网上都有现成的，改/etc/apt/sources.list即可。第二，设置静态IP或者固定DHCP。树莓派做机器人平台，IP变来变去很讨厌，在netplan配置里给它绑一个固定地址，后面SSH和ROS2多机通信都省心。第三，关闭自动休眠和屏幕黑屏。Ubuntu桌面版默认几分钟无操作就黑屏，在设置里改成"永不"，或者用gsettings命令直接关掉。别小看这个，建图过程中屏幕黑掉会让你误以为系统挂了。
再补充一个关于时间同步的细节。ROS2节点之间通信对时间戳敏感，如果树莓派时间不对，TF变换会报时间外插值的错误。确保系统开了NTP自动对时，timedatectl命令可以看到同步状态。这个坑我在调试Cartographer时踩过，地图一直建不好，最后发现是系统时间差了十几秒。
3. RPLIDAR C1的硬件接入与底层通信确认
3.1 C1的接口特性与USB转串口的本质
思岚RPLIDAR C1通过USB接口和主机通信，但它的底层其实是串口协议。雷达内部有一个USB转串口芯片，所以你在系统里看到的不是"USB设备"，而是一个/dev/ttyUSB0这样的串口设备。理解这一点非常关键，因为后面所有的权限问题、波特率问题，本质上都是在和这个串口打交道。
C1的默认通信波特率是115200（具体以你手上的型号文档为准，思岚不同型号有差异）。雷达通过这个串口持续输出扫描数据，每一圈扫描给出角度和距离的点云。SDK负责把这些原始数据解析成结构化的扫描帧。你在代码里拿到的是"这个角度上有多远"的信息，而不是裸字节。
插上雷达后，用lsusb能看到思岚的设备，用ls /dev/ttyUSB*能看到串口设备节点。如果/dev/ttyUSB*里什么都没有，那说明系统没识别到串口芯片，可能是线的问题、口的问题，或者雷达没供电。C1是通过USB线从主机取电的，所以USB口的供电能力要够。树莓派4B的USB口供电普遍够用，但如果同时接了多个USB设备，可能出现供电不足导致雷达识别失败。遇到这种情况，接一个有独立供电的USB扩展坞，问题通常能解决。
3.2 串口权限这个最常见的第一个坑
Ubuntu默认情况下，普通用户没有访问/dev/ttyUSB0的权限，只有dialout组的成员才有。如果你直接用普通用户跑雷达程序，会报"Permission denied"。解决办法是把自己加到dialout组：sudo usermod -aG dialout $USER。注意，加完组之后要重新登录（或者重启）才生效，这一点很多人会忽略，加完组发现还是没权限，其实是没重新登录。
单纯加到dialout组其实还不够稳，因为设备节点是热插拔时动态创建的，每次插拔后权限归属可能会有变化。更靠谱的做法是写一条udev规则，把这个特定的雷达设备固定映射成一个别名，比如/dev/rplidar，并设置好权限。udev规则文件放在/etc/udev/rules.d/下，文件名以.rules结尾。规则内容要根据你雷达的厂商ID和产品ID来写，用lsusb命令能看到这两个ID。写好规则后，sudo udevadm control --reload-rules && sudo udevadm trigger让规则生效。
这条udev规则的好处是双重的：一是权限稳定，二是设备名固定。因为如果你同时接了多个串口设备，ttyUSB0和ttyUSB1的顺序可能变来变去，程序里写死ttyUSB0就会出问题。用一个固定的别名，不管插拔多少次、接了几个设备，程序里永远指向那一个，可靠性高得多。这是我强烈建议做的一步，虽然看起来只是"配置"，但它解决的是后面反复折腾的根源。
3.3 用官方工具先验证雷达本身是好的
在装任何SDK、任何ROS驱动之前，先用思岚官方的测试工具确认雷达硬件本身没问题。思岚提供了跨平台的SDK和可视化工具，你可以拉取源码编译，也可以找现成的可执行文件。这个工具能直接显示出雷达的扫描点，如果它能看到一圈圈散点，说明雷达、线、供电、串口权限全都正常，问题一定在后面对应的软件层。
这一步的意义在于"分层排查"。如果我跳过这一步，直接在ROS2里跑，然后发现没数据，我就要同时怀疑雷达坏没坏、权限对不对、驱动装没装对、话题名对不对、TF配置对不对——变量太多了。先用官方工具确认硬件层OK，就把问题范围缩小到软件层，排查效率天差地别。这是我在做所有传感器项目时都坚持的原则：先把最底层的链路打通，再往上叠。
官方工具编译时可能会遇到依赖缺失。通常会需要CMake、编译器等基础工具，如果树莓派上还没装，sudo apt install build-essential cmake补上。编译过程中如果报找不到某个头文件，多半是缺了对应的开发包，看报错信息apt装一下就行。这一步一般不会太难，如果卡住，大概率是网络或者依赖的问题，和雷达本身无关。
4. Ubuntu 22.04上装ROS2 Humble与激光雷达驱动
4.1 ROS2 Humble在ARM64上的安装路径选择
ROS2 Humble在Ubuntu 22.04上的安装，官方提供deb包安装方式。这套方式在x86上很成熟，在ARM64上同样有对应的仓库，树莓派可以直接用。流程大致是配置apt源、导入密钥、安装ros-humble-desktop或更精简的ros-humble-ros-base。这里我建议装ros-humble-ros-base，不带图形化工具，体积小、依赖少，树莓派上更轻快。你需要的工具可以后面按需单独装。
安装过程中最容易出的问题是源配置。如果apt源里加了ROS2的仓库但密钥没导入对，apt update会报签名验证失败。这个错误信息的提示其实很明确，照着手动导入密钥即可。另一个坑是网络问题导致的下载中断，ROS2的包不小，网络不稳时可能装到一半失败，这时候重新apt install，apt会从断点继续。
装完之后，ros2 run demo_nodes_cpp talker跑一下，看能不能正常输出消息。这一步是验证ROS2环境本身OK的基准，别跳过。如果demo都跑不起来，后面装驱动也是白搭。
环境变量方面，每次打开新终端都要source一下ROS2的setup脚本，否则找不到ros2命令。嫌麻烦的话把source写进.bashrc。这里有个细节：如果你是多个工作空间叠加，source的顺序会影响环境变量，先source底层的ROS2，再source你自己编译的工作空间，顺序反了会有包路径问题。
4.2 RPLIDAR的ROS2驱动获取与编译
思岚官方维护了ROS2版本的RPLIDAR驱动包，放在开源代码托管平台上。拿到源码后，你需要在你的工作空间里编译它。ROS2用colcon作为构建工具，命令是colcon build。这里有个ARM64特有的注意点：RPLIDAR驱动依赖SDK，SDK里有C++代码，编译时会用到系统的编译器和基础库。树莓派上编译前确认build-essential和cmake都装了，不然会在编译阶段报错。
编译时如果遇到和Python相关的构建错误，通常是setuptools或者empy版本的问题。ROS2 Humble对Python包的版本有要求，装一下python3-empy这类常见依赖能解决大部分问题。另一个常见错误是colcon build时某个包编译失败导致整个工作空间构建中断，这时候看那个包的单独报错，逐个解决，别急着重跑整个构建。
编译成功后，source install/setup.bash，然后启动雷达节点。启动命令会加载一个参数文件，里面配置了串口名、波特率、帧率这些。这里就是你前面udev规则发挥作用的地方：参数里把串口设成你固定的别名，不管设备顺序怎么变，雷达节点都能正确找到设备。如果启动后报"cannot open serial port"，先检查串口名对不对、权限够不够、雷达插没插紧。这三个检查项按顺序过一遍，基本都能定位到原因。
4.3 让数据真正流出来：话题、frame_id与可视化验证
雷达节点启动后，它会发布扫描数据话题。用ros2 topic list能看到这个话题，用ros2 topic echo能看到具体的数据内容。如果话题在列表里但echo没有数据，可能是雷达没有真正开始扫描，或者数据发布被卡住。一个实用的检查手段是ros2 topic hz看一下话题的发布频率，正常应该是接近雷达的扫描频率（C1大概是10Hz左右，以实际型号参数为准）。如果hz很低或者时有时无，多半是串口通信不稳定或者供电问题。
frame_id是另一个容易被忽略但非常关键的配置。激光雷达发布的数据里带有一个坐标系名字，就是frame_id，通常默认是laser或laser_frame之类。后面做TF变换和建图时，你要保证建图模块里配置的坐标系名字和雷达发布的frame_id完全一致，错一个字母，建图就会报"no transform from xxx to xxx"。我第一次配这个时，就在frame_id上卡了很久，因为报错信息不够直白，容易被带偏到别的地方去排查。
可视化验证用RViz2。在RViz2里添加一个LaserScan显示，选对话题，设置好固定坐标系，就能看到雷达扫出的点云。如果RViz2里看不到点，先确认话题选对了、坐标系设对了、然后看一眼是不是雷达的数据本身就在动。RViz2在树莓派上跑比较吃力，如果卡顿明显，可以用一台电脑通过ROS2的多机通信，把数据从树莓派传出来在电脑上看，这样可视化流畅很多。多机通信需要配置好两边的ROS_DOMAIN_ID一致，以及网络能互通。
5. 从数据流到一张能用的地图：建图配置与调参
5.1 建图方案的选择与Cartographer的适配性
拿到稳定的激光扫描数据后，下一步是把它变成地图。ROS2生态里做二维建图，常见的选择有Cartographer、SLAM Toolbox这几种。Cartographer在激光建图上非常成熟，回环检测做得好，适合室内场景；SLAM Toolbox启动更快、配置更简单，适合快速上手。我这次主要用Cartographer这条线，因为它在二维激光建图上的效果稳定，社区资料也多。
Cartographer的ROS2版本是cartographer_ros，需要单独安装或从源码编译。在树莓派上，我建议用apt安装预编译的版本，省去编译的时间和踩坑。Cartographer的配置分几个部分：Lua配置文件定义建图参数，Launch文件定义节点启动的拓扑，URDF或者静态TF定义传感器的坐标系关系。这几块要逐一对上，任何一个坐标系名字对不上都会导致建图失败。
坐标系这块要理清楚。典型的配置是三个坐标系：map是最上层的全局地图坐标系，odom是里程计坐标系，base_link是机器人本体坐标系，再加上雷达的laser坐标系。雷达的扫描数据从laser坐标系发出，Cartographer通过TF把它们串起来。静态TF用来定义laser相对base_link的安装位置和姿态——哪怕你只是把雷达放在桌上没动，也要配这个静态变换，告诉系统雷达在哪儿。很多人以为雷达不动就不需要TF，结果启动后一直报找不到变换，就是这里的问题。
5.2 建图过程中的参数调整与"地图飘"的成因
地图飘，是激光建图新手最常抱怨的问题。表现形式是：走一圈回到原点，地图上却对不上，墙体扭曲、重影，越走越乱。造成这个问题的原因有好几层，要逐层排查。
第一层是里程计。如果你有轮式底盘，里程计来自编码器；如果你像我一样只是手动拿着雷达走，那里程计就没有。没有里程计的情况下，Cartographer可以只靠激光做扫描匹配来建图，但这就对激光数据的质量和扫描频率要求更高。C1这种入门级雷达，在快速移动或者转向时，数据稀疏会导致匹配误差累积，地图就容易飘。解决办法是移动要慢、要稳，转圈的时候尤其慢一点，给算法足够的时间做匹配。
第二层是时间戳和TF的时间同步。前面提过系统时间的问题，如果时间戳不对，TF变换在时间轴上对不上，扫描匹配就会乱。用ros2 topic hz看TF话题的发布频率，正常应该很稳定。如果TF发布抖动很大，检查是不是某个节点的CPU占用过高导致发布时间不稳。
第三层是环境特征。激光建图依赖环境里有足够的几何特征——墙、门、家具。如果你在一个空旷的、四壁都是纯白墙、几乎没有特征的房间里建图，算法很难找到匹配点，地图就会飘。这时候可以人为放一些纸箱、椅子增加特征。这是很实用的经验：建图环境要有"料"，纯白空旷房间是激光SLAM的噩梦。
参数上，Cartographer里有一组和扫描匹配相关的参数，比如匹配的搜索窗口大小、点云采样密度。默认参数在一般室内场景够用，但如果你的移动速度快，可以把搜索窗口调大一些，给匹配更多容错空间。调参的原则是"先跑通、再优化"，不要一上来就改一堆参数，那样出问题都不知道是哪个参数导致的。
5.3 保存地图与验证结果的正确姿势
建图完成后要保存地图。Cartographer提供保存地图的服务调用，会生成两个文件：一个.pgm图像文件，就是地图的可视化图像；一个.yaml文件，描述地图的分辨率、原点位置、图像路径这些元信息。保存时要注意，地图的坐标系原点和你建图时的原点是对齐的，这个在后续导航里很重要。
保存完成后，验证地图质量。打开.pgm看，墙体应该是清晰的直线，点云填充均匀。如果看到墙体是锯齿状的、有明显的重影、或者直线是弯的，说明建图过程中有漂移，这张图拿去做导航会有问题，建议重新建。重影最常见的原因是回环检测没做好——也就是你走一圈回到起点时，算法没有把当前扫描和之前的扫描正确关联起来。Cartographer的回环检测参数可以调，但更重要的是移动轨迹要合理，别走得太快、别在同一个地方反复绕。
还有一个实用建议：地图保存后，用RViz2加载地图话题看一下，确认地图和当时的环境对得上。同时，把建图时的bag包录下来是个好习惯，ros2 bag record录下扫描话题和TF话题，这样后面调参、重跑建图都不用重新推着雷达走一遍。Bag包在调试阶段的价值极高，我强烈建议第一次建图就录下来。
6. 实战中那些让我停下来想半天的坑
6.1 雷达转但没数据：一次完整的排查链路
有一次我遇到雷达能转（风扇在转、电机在响），但ROS2里话题就是没数据的情况。这种情况最容易被误判，因为它"看起来在工作"。我当时的排查链路是这样的：第一步，ls /dev/ttyUSB*确认设备节点存在，存在。第二步，ros2 topic hz看话题频率，是0，没有数据。第三步，ros2 topic echo看内容，空的。第四步，回到底层，用官方测试工具跑，发现官方工具能出点——说明硬件和串口都正常，问题在ROS驱动的配置层。
继续往下，检查驱动节点启动时的日志，发现报的是串口打开失败，但错误信息里提到的串口名和实际设备名不一致。原来是参数文件里写的串口名没更新成我udev规则里的别名，它还在找旧的默认名字。改成正确的别名，重启节点，数据立刻出来了。这个坑的教训是：每次改了udev规则或者换了USB口，都要回头检查驱动参数文件里的串口名。这个细节特别容易被遗忘，因为改规则的时候你不会想到驱动参数。
还有一次是另一种"转但没数据"：雷达转了半天，官方工具也出点，但一到ROS2里就没数据。最后发现是波特率配置不对。参数文件里的波特率和雷达实际的不一致，导致驱动收到的是乱码，解析不出有效的扫描帧。不同型号的雷达波特率可能不同，一定要以你手上那颗雷达的规格为准去设置。这个坑很难从表象上判断，因为设备节点存在、权限也对、官方工具也正常，唯独ROS里不行，很容易让人怀疑到驱动本身有bug。
6.2 供电不足引发的间歇性断连
前面提过供电，但这里要展开说，因为这个坑的表现极具迷惑性。症状是：系统运行一段时间后，雷达突然掉线，/dev/ttyUSB0消失，过几秒又重新出现。或者建图跑到一半，整个程序崩了。这类间歇性问题非常难debug，因为复现不稳定。
我后来的判断方法是：一边跑建图，一边用dmesg -w盯着内核日志。掉线的那一刻，内核会打印USB设备断开的日志，说明是物理层的连接断了，而不是软件逻辑的问题。顺着这个线索，我把雷达单独接一个有源USB hub，问题不再复现。结论就是树莓派USB口在负载下的供电波动导致雷达芯片复位。这个经验很值钱：凡是间歇性、无规律、重启就好、跑一会儿又坏的问题，先怀疑供电，尤其是树莓派这种USB供电能力有限的平台。
解决供电问题有几个手段。一是换更稳定的电源适配器，确保5V/3A以上且电压稳定。二是用带独立供电的USB hub接雷达。三是尽量避免雷达和其他大功率USB设备共享同一个USB控制器——树莓派4B的两个USB口其实分属不同的控制器，区分开接能减少相互干扰。这些做法我都试过，组合起来用最稳。
6.3 树莓派性能瓶颈下的可视化方案
树莓派4B跑RViz2是真的吃力。RViz2是重的图形程序，占CPU和内存都大，和Cartographer抢资源，结果就是建图卡顿、掉帧、地图质量下降。我一开始在树莓派本机上跑RViz2看图，边建图边看，效果很差，整个系统都在卡。
后来我改成"分离方案"：树莓派只负责跑雷达驱动和Cartographer，轻装上阵；可视化放在一台x86电脑上，通过同一个网络、同一个ROS_DOMAIN_ID，把话题数据订阅过去看。这样树莓派专心建图，可视化流畅，两边互不干扰。配置多机通信的关键是两边IP能互通、ROS_DOMAIN_ID要一致、ROS_LOCALHOST_ONLY不能开（开了就只监听本机，外面看不到）。这几个变量对上了，跨机器订阅话题就很顺。
这个方案对性能的提升是立竿见影的。树莓派上的CPU占用降下来之后，Cartographer能更从容地做扫描匹配，地图质量肉眼可见地变好。所以我给所有在树莓派上跑SLAM的人的建议都是：别在本机跑可视化，把计算和显示分开。这是树莓派平台的资源现实决定的，不是软件优化能绕过去的。
6.4 系统层面那些拖慢建图的隐形设置
Ubuntu 22.04桌面版默认开着一些后台服务，比如自动更新检查、无人值守升级、桌面搜索索引。这些小东西平时无所谓，但在树莓派这种资源紧张的设备上，它们会在你建图的时候突然占一波CPU或者IO，导致建图卡顿甚至丢帧。我建议在建图前把这些关掉：sudo systemctl stop unattended-upgrades、禁用snap相关的自动刷新等。
换掉桌面环境也是一个选择。如果你确认不需要图形界面，用Ubuntu Server版或者把桌面换成轻量的，能省下几百MB内存。我自己长期用的是Server版加SSH，只在需要的时候通过远程可视化看数据。这个选择让树莓派的资源几乎全部留给建图任务。
交换分区也值得设置一下。树莓派的默认交换空间比较小，内存紧张时容易OOM。适当地增大swap能缓解，但swap在SD卡上会拖慢速度、增加卡损耗。所以治本之道还是保证内存够用（选4GB以上版本）加上减少不必要的后台进程。
7. 把整套流程固化下来的一些个人习惯
做这套东西做久了，我慢慢形成了一些自己的习惯，分享出来供参考。第一个习惯是"分层验证"。雷达项目涉及的层级很多——硬件、串口、SDK、ROS驱动、TF、建图。每引入一个新层级，前一个层级必须是验证过的、稳定的。绝不跳级调试。这个习惯让我在遇到问题时能快速定位到是哪一层出的问题，而不是一通乱试。
第二个习惯是"留底配置"。udev规则、netplan网络配置、Cartographer的Lua参数、Laune文件、ROS2的环境变量，这些东西我都在一个备份目录里存一份，注释清楚每个参数为什么这么设。树莓派项目最爱折腾系统，重装一次系统这些配置全没了，有备份能省掉大量重复劳动。特别是udev规则里雷达的厂商ID产品ID，重装后重新查一遍很烦，存着直接用。
第三个习惯是"先录包再调参"。第一次用某个雷达、某个环境建图时，我会先把数据录成bag包，再慢慢调参数。因为调参可能要试很多组，如果每次都推着雷达重新走一遍，时间和体力都受不了。有了bag包，调参变成离线回放，效率高得多，还能反复对比不同参数的效果。
第四个习惯是"记录异常"。我有个简单的文本记录，专门记每次遇到的奇怪现象、当时的判断、最后的原因。比如"雷达间歇掉线—怀疑软件—实为供电"，这条记录让我以后再遇到类似症状能秒想到供电方向。传感器和机器人项目里的坑有很强的重复性，记录一次，受益很久。
这套树莓派加Ubuntu加RPLIDAR C1的组合，从硬件到建图走完一遍，最花时间的其实不是哪一步命令，而是把每一层的原理搞明白之后的"啊原来是这样"。我最初也以为装了驱动就能出图，实际做下来才发现，从设备节点到话题到TF到地图，每一环都有它自己的逻辑，理解这些逻辑，比记住一堆命令有价值得多。C1这颗雷达在这个价位上表现够用，树莓派4B也扛得住这套负载，只要你把供电、权限、时间同步、可视化分离这几件事处理好，它稳定的样子会让你觉得前面折腾的每一步都值。最后分享一个小技巧：如果你的地图总是局部漂移，先别急着调Cartographer的复杂参数，去看看是不是移动过程中雷达有轻微的俯仰晃动——雷达安装的稳固程度，对建图质量的影响比很多软件参数都大。
