企业官网建设流程全解析

本科毕设那阵子，我手里握着两块板子，一块树莓派4B，一块Slamtec RPLIDAR A1，心里想的是别人视频里AGV小车在仓库里风骚走位的样子。结果第一次通电试跑，我的车在走廊尽头直直撞上了墙。激光雷达的数据明明已经在RViz里转起来了，避障逻辑却完全没生效。后来我才明白，从“雷达在转”到“车会躲”，中间隔着供电、驱动、坐标系、消息频率、融合策略一长串坑。

这篇就把我从零搭建AGV避障系统时，激光雷达加树莓派视觉模块这套组合的完整思路和踩坑记录写出来。内容以实用为主，不会绕弯子。如果你正打算拿树莓派做毕设、机器人比赛，或者只是想给自己弄一台能自动躲障碍的小车，这篇应该能帮你少走不少夜路。

1. 方案选型：为什么激光雷达和视觉模块必须同时上

1.1 激光雷达的边界：能测距离，但认不出“这是什么东西”

很多人一开始把激光雷达想得太神通广大，觉得雷达转一圈，周围障碍物不就全知道了嘛。但实际上2D激光雷达只能给你一个水平切面上的距离信息，它回答的问题是“在某个角度、某个距离上有一个反射点”，至于那是一个纸箱、一个人还是墙上的一幅画，雷达完全不知道。

我用的RPLIDAR A1属于三角测距方案，原理其实是初中几何：激光发射器打出一束光，照到障碍物后反射回来，接收端的CMOS传感器上会出现一个光斑。因为发射器、接收器和目标三者构成一个三角形，通过光斑在CMOS上的像素位置，结合发射器与接收器的基线距离，就能算出目标距离。这套方案成本低、360度扫描，但在强阳光下容易受干扰，对深色物体、玻璃和细长物体也不够稳定。TOF雷达用的是飞行时间法，测距更准，但价格基本翻倍。

真正致命的问题是：2D雷达只能扫一个平面。AGV在地面上跑，雷达装在20厘米高度，那么低于这个高度的障碍物——比如门槛、电线、台阶、掉地上的饮料瓶——都不会出现在scan数据里。这也是我后来坚决要加视觉模块的直接原因。小车能不能安全跑，看的不是它“看得有多远”，而是它对低矮障碍和动态目标有没有感知。

1.2 视觉模块补的是什么短板

摄像头解决的问题刚好是雷达的盲区。它能提供颜色、纹理、形状、语义信息，可以判断前方那个东西是人、是箱子、还是空地。在AGV场景里，视觉模块核心做三件事：

• 低矮障碍物检测：雷达扫不到的东西，视觉能看到。
• 目标语义分类：让系统知道前方是静态障碍还是行人，决定是停车等待还是绕行。
• 粗略测距与跟踪：单目测距误差较大，但可以用来做“前方3米内是否有疑似障碍”的粗判断。

雷达和视觉的关系，简单说就是“雷达负责精确测距，视觉负责认出目标”。雷达看到前方1.2米有反射点，视觉再判断那个位置是不是一个人，如果是人，那就减速等待；如果只是一个可绕过的箱子，就规划避障路径。两者是互补关系，不是替代关系。

1.3 我的硬件选型清单与总花费

这套系统的硬件选择直接影响后面所有软件工作。我把自己的实际配置列在下面，后面所有踩坑经历都是基于这套硬件发生的。

整套下来大约在1000到1500元。如果预算紧张，树莓派3B也能跑Noetic，但建图时CPU会直接满载，体验很差。如果是新项目，现在可以上树莓派5，只是Ubuntu 22.04配合ROS2的文档还没有4B时代那么全，需要多折腾一段时间。我自己坚守4B，理由是所有教程都能直接照着抄。

2. 系统环境与硬件接线：被串口、供电和镜像反复折磨的一周

2.1 镜像选择：Ubuntu 20.04 还是 Raspberry Pi OS

我第一次装的是Raspberry Pi OS，因为它对树莓派硬件支持最好，摄像头驱动一条命令就搞定。但很快发现问题：树莓派OS的apt源里ROS包非常零散，树莓派OS基于Debian的版本分类和Ubuntu并不一致，ROS Noetic官方支持的平台是Ubuntu 20.04，在树莓派OS上装ROS Noetic需要大量手动编译，依赖冲突能让人崩溃。

后来我一口气重刷成Ubuntu 20.04 LTS 64位 Server版，不用桌面环境，减少内存和CPU开销。Ubuntu 20.04是ROS Noetic的主场，apt直接装ros-noetic-desktop，不用折腾依赖。如果你想走ROS2路线，那就选Ubuntu 22.04配上ROS2 Humble。现在回头看，如果重新来一次，我会直接选后者，因为ROS1的很多工具链已经进入维护末期，新项目没必要从旧生态起步。

2.2 激光雷达接线和供电：USB转串口不是插上就完事

RPLIDAR A1默认通过一个USB转串口模块和树莓派通信。这里第一个大坑就是供电。我最初图省事，把雷达的电源线直接接到了USB转串口板上，指望它给雷达电机供电。结果雷达转速忽快忽慢，scan数据每几秒就断一次。

原因不复杂：A1的电机启动瞬间需要接近1A的电流，而USB转串口模块板载的LDO稳压器根本带不动这么高的负载，电压被瞬间拉低，雷达核心板直接复位。正确做法是雷达电机单独使用5V/1A电源，数据线的TX/RX/GND接到树莓派GPIO串口或USB转串口模块，并且一定要把雷达的GND、树莓派的GND、以及电机驱动的GND连在一起，也就是所谓“共地”。信号电平参考地不一致，串口收发就是乱码。

具体接线我整理成了这样：

• 雷达VCC和电机正极接外部5V电源。
• 雷达GND接外部电源负极，同时接树莓派GND。
• 雷达TX接USB转串口的RX。
• 雷达RX接USB转串口的TX。
• 如果有官方配套的USB转串口板，直接插上然后用外接电源给雷达供电，省事很多。

2.3 CSI摄像头OV5647的接线与驱动

摄像头我选了OV5647，也就是树莓派官方老款Camera Module的传感器芯片。便宜是一方面，另一方面走CSI接口不占USB通道，树莓派4B的USB带宽本来就不宽裕。

接线倒是很简单，一根排线插到树莓派4B的Camera接口上，但排线的金属触点方向非常关键，插反了摄像头会发热严重、系统识别不到。我自己的习惯是：排线插头上有金属触点的一面朝向树莓派板子上能看到的“印丝线框”那一侧，具体还是以你手上那块板子的丝印为准。

在Ubuntu 20.04上，OV5647默认由libcamera框架接管，OpenCV直接用cv2.VideoCapture(0)往往打不开或者只拿到一帧黑图。我一开始以为摄像头坏了，查了一晚上，最后发现需要额外配置/boot/firmware/config.txt，把摄像头检测相关的参数打开：

start_x=1 camera_auto_detect=1

改完重启后用libcamera-hello测一下，能看到预览画面就说明摄像头基本正常。如果要用OpenCV，可以通过GStreamer管道读取视频流，后面视觉部分细讲。

2.4 无屏幕远程开发环境的搭建

我全程没有给树莓派接显示器，全部靠SSH远程操作。烧录时用树莓派Imager往SD卡写入Ubuntu镜像，最关键一步是在“设置”里提前配置好用户名、SSH密码或密钥、WiFi连接信息。不要等启动后再去接屏幕配置，那样你就得额外准备HDMI线和键盘。

如果是老镜像，需要在boot分区放一个ssh空文件来开启SSH，再写一个wpa_supplicant.conf来连WiFi。但现在树莓派Imager已经内置了无线设置选项，比手写配置可靠得多。启动后用路由器后台找到树莓派的IP，或者局域网扫描工具扫一下，直接ssh登录。

远程开发我建议装tmux，这样建图和跑导航程序时，就算SSH断开，会话还在后台继续跑。这个习惯后来救了我好几次，有次建图建到一半网络断了，重连回去发现cartographer还在正常建，这是非常实用的经验。

3. 让激光雷达转起来：驱动、数据可视化与建图

3.1 驱动安装与串口权限

让A1转起来，在ROS Noetic下基本就是装rplidar_ros驱动。可以直接克隆源码编译，也可以apt安装现成的包。我是从GitHub拉源码放进catkin工作空间，编译一次之后就一直这么用：

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

编译完成之后，先不要急着launch，第一步要处理串口权限。树莓派上默认用户不属于dialout组，直接访问/dev/ttyUSB0经常会报权限错误。我的做法是：

sudo usermod -a -G dialout $USER sudo chmod 666 /dev/ttyUSB0

然后把用户重新登录一次，或者重启树莓派。接着启动雷达节点：

roslaunch rplidar_ros rplidar.launch

正常情况下rostopic hz /scan能看到频率在5Hz到10Hz之间波动，这取决于雷达转速设定。如果看到“Cannot open serial port”或者“Attempt to set baudrate failed”，八成是权限问题，或者雷达电机供电没接，串口设备根本没有枚举出来。

3.2 ROS1还是ROS2：我先选了Noetic，后来才明白的事

我的项目主体是在ROS Noetic上完成的，原因是当时所有资料、教程、比赛模板都基于ROS1。但项目做到后期，我越来越意识到ROS2才是该走的方向：

• ROS2的节点分发和进程隔离比ROS1干净，一个节点崩溃不会整个系统一起挂。
• DDS通信，天然支持分布式，树莓派和上位机之间通信更自然。
• 很多新版本工具链，比如Nav2、新版本cartographer示例，都优先支持ROS2。

但ROS2也有它的坑。A1的驱动在ROS2下本身就能跑，但可视化、建图、导航的配置方式跟ROS1完全不同，launch文件语法、参数获取方式、命名空间规则都变了。我当时时间紧，只能一条路走到黑。如果你现在刚开始，我建议直接从Ubuntu 22.04加ROS2 Humble起步，虽然初期学习曲线陡一点，但不会像我一样后来还要做迁移的心理建设。

3.3 cartographer建图与地图保存

建图我用的是cartographer。对于室内AGV场景，它的回环检测能力比传统的gmapping强不少，至少我建出来的走廊地图明显更方正。

安装很简单，Ubuntu 20.04 + Noetic可以直接apt安装：

sudo apt install ros-noetic-cartographer ros-noetic-cartographer-ros

难点在launch文件和lua配置。我这里不贴完整launch，重点讲几个我调过很多次的关键参数。cartographer通过一个.lua文件定义传感器配置，其中几个参数对AGV建图影响很大：

map_frame = "map", tracking_frame = "base_link", published_frame = "odom", max_range = 11.5, min_range = 0.15, map_update_interval = 2.0

• tracking_frame必须改成你的机器人基座坐标系，不能默认成空。
• max_range要比雷达实际测距范围略小，A1标称12米，设置成11到11.5米之间，避免边缘杂点进入位姿优化。
• map_update_interval决定地图更新频率，设小了CPU负担大，设大了反应迟钝，2秒是个比较稳妥的值。

启动建图时，我用键盘遥控小车在室内低速走一圈，尽量避免急转弯。走到差不多覆盖完整个区域后，保存地图：

rosrun map_server map_saver -f ~/map/my_warehouse

这样会生成my_warehouse.pgm和my_warehouse.yaml，后面给导航用。但保存出来的地图只能代表cartographer当前的处理结果，地图是否可靠，要打开rviz跟实际环境比对几何关系。这一步我在第一次建图时没认真做，后面导航吃足了苦头。

3.4 第一次建图就踩的坐标系坑

我建图的第一个晚上，地图里的走廊是斜的，墙壁画出来像平行四边形，雷达点云在RViz里和实际车头方向差了大概90度。查了很久才发现，不是cartographer的问题，而是我压根没发布好TF变换。

A1装在车头中央，树莓派作为主控，底盘中心是base_link。雷达扫描到的点云必须通过TF变换到base_link坐标系下，cartographer才知道激光雷达相对于机器人中心的位置。我没有准确测量安装位置，只写了一个拍脑袋的静态TF：

rosrun tf2_ros static_transform_publisher 0.15 0 0.15 0 0 0 base_link laser

这个命令本身没问题，问题出在数值是估算的，而且我没有确认yaw方向。雷达的0度方向到底朝向车头还是车尾，不同安装方式差别很大。后来用卷尺精确量了雷达中心到base_link中心的x、y、z距离，再调整yaw角看扫描点和墙体是否重合，地图最终才正常。

这个坑值得所有第一次做AGV的人注意：TF数值不是代码逻辑问题，而是机械测量问题，差一厘米，建图结果都会在回环时体现成重影。

4. 视觉模块避障：从OpenCV识别到单目测距

4.1 图像流获取：OpenCV读不到CSI摄像头怎么办

Ubuntu 20.04下，OV5647摄像头被libcamera驱动接管后，OpenCV直接cv2.VideoCapture(0)很容易失败，或者读出来的图像是纯黑。我查了一圈，发现原因是用libcamera时/dev/video0对应的设备节点不一定会按传统v4l2方式吐数据。

我的解决办法是用GStreamer管道把摄像头画面桥接给OpenCV：

cap = cv2.VideoCapture( "libcamerasrc ! video/x-raw,width=640,height=480,framerate=30/1 ! videoconvert ! video/x-raw,format=BGR ! appsink drop=1", cv2.CAP_GSTREAMER )

实测稳定之后，我又把分辨率降到640x480、帧率设成15fps，因为树莓派4B的CPU在跑cartographer的同时还要做视觉推理，全分辨率30fps会直接把CPU拖到满负荷，雷达建图都开始卡顿。视觉避障根本不需要高清，640x480足够识别障碍物类别和粗略测距了。

4.2 识别算法选择：颜色阈值入门，轻量模型升级

一开始我先尝试了最“土”的颜色阈值识别。把图像转到HSV空间，设定红色障碍物的色相范围，腐蚀膨胀、找轮廓，再用最小外接矩形框出来。这个方法在固定光照的室内非常稳定，而且CPU开销几乎可以忽略。虽然看起来很初级，但作为验证融合逻辑已经足够了。

后来我升级成了MobileNetSSD。这是一个轻量级目标检测模型，树莓派4B上通过OpenCV的dnn模块推理，一帧640x480大概20到30毫秒，基本可以跑到15fps。模型文件可以从常见的caffe版本获取，用起来不复杂：

net = cv2.dnn.readNetFromCaffe("MobileNetSSD_deploy.prototxt", "MobileNetSSD_deploy.caffemodel")

识别到人、椅子、箱子这些目标后，我把它转成避障系统中的“障碍物语义标签”，跟雷达距离数据绑定。这里有一个经验：如果你做的是电池供电的低功耗端侧设备，不建议让树莓派持续跑大模型。可以只在雷达检测到近处障碍时才开启视觉识别，识别完立刻释放模型，用低功耗的“事件唤醒”模式来替换“全时视觉”。

4.3 单目测距近似公式与误差分析

单目摄像头测距没有深度相机那么直接，核心公式其实就是小孔成像的相似三角形：

distance = (real_height * focal_length) / pixel_height

其中focal_length可以通过标定得到。我拿一个已知高度为20厘米的纸箱，放在距离相机1米处测量其像素高度，算出focal_length，然后反过来估计其他距离下的目标远近。

这个方法在3米内有参考价值，超过3米误差迅速增大，10米外基本不能信。误差来源有很多：相机安装有一定的俯仰角、镜头畸变、目标不完整、被测物体没有正对摄像头。后来我只用单目测距做“前方0到3米内是否存在疑似障碍”的粗判断，精确距离还是交给激光雷达。视觉可以告诉你“那里有个东西要注意”，但“距离到底是0.8米还是1.2米”还是要以雷达为准。

4.4 端侧AI视觉模块的思路

热搜词里有“超低功耗端侧AI视觉模块”，我也在这个项目里体会到了为什么这一类方案会流行。树莓派4B在跑视觉模型时功耗大概在5瓦上下，如果整机用3S锂电池供电，还要跑雷达和电机驱动，续航能明显感觉到紧张。

低功耗端侧AI的典型思路是：主控平时休眠，用低功耗雷达或超声波模块做接近感应；一旦发现近处可能有障碍，再唤醒视觉模块，以低帧率识别目标。识别完成后再让系统进入低功耗状态。这样电池供电的AGV可以在同样的电池容量下多跑很多时间。我把视觉推理帧率从15fps降到了2到5fps，避障效果没有肉眼可见的下降，但CPU温度和功耗都降了一截。

5. 激光雷达与视觉融合的避障策略

5.1 数据同步：雷达10Hz、视觉15Hz，怎么对齐

真正做融合的时候，第一个问题是数据时间戳对不上。雷达A1默认扫描频率在5到10Hz，视觉模块跑在15fps附近，两个传感器输出频率不同，直接拿各自最新数据做融合会产生0.1到0.2秒的时间差。AGV在0.2秒里能前进十几厘米，对避障来说这个误差不可忽视。

我用了两类方案解决。第一类是ROS的message_filters中的ApproximateTimeSynchronizer，让雷达scan消息和视觉识别结果按时间戳近似对齐。第二类更简单也更稳：在避障节点里保存最近一帧视觉识别结果，每次收到雷达scan时，用视觉缓存数据做融合判定。对于低速AGV，缓存方案就已经够用，毕竟视觉几帧内目标位置不会发生剧变。

5.2 全局路径规划A*与局部避障的分工

“避障”这个词其实涵盖了三个层次的问题。第一层是从起点到终点的全局路径搜索，我用的是A*算法，在地图栅格上搜索一条无碰撞路径。第二层是局部避障，也就是小车沿着全局路径走时，如果前方突然出现一个动态障碍，需要临时调整速度方向。第三层是紧急停止，逻辑简单粗暴：距离太近直接停车。

一开始我犯的错误是把所有避障都压在全局路径上，结果动态障碍一出现，A重规划又慢又抖。后来我改成了三层结构：全局用A，局部用Dynamic Window Approach（动态窗口法），紧急层用距离阈值触发。实际跑下来，动态障碍出现时小车会先减速、尝试绕行，而不是每次都在原地震荡。

5.3 坐标系与TF变换：base_link、laser、camera不能乱

融合策略写在代码里之前，要先把坐标系理顺。我的习惯是统一用base_link作为机器人坐标系原点，laser和camera分别挂在base_link下面。启动时发布静态TF，让激光点云和视觉目标都能映射到同一个坐标系里。

rosrun tf2_ros static_transform_publisher 0.15 0 0.15 0 0 0 base_link laser rosrun tf2_ros static_transform_publisher 0.08 -0.05 0.18 0 0 0 base_link camera

发布完这两条TF之后，在RViz里显示laser和camera两个参考系，同时打开TF树检查，看有没有断掉的链路。很多新手觉得TF就是个“坐标换算工具”，但实际在cartographer和costmap里，TF一旦出错，雷达都会自动把障碍物放到错误的位置，地图再准也没用。

5.4 融合避障判据与现场调参

融合避障不能只用“雷达<0.5米就停车”这种单一逻辑，否则视觉模块就白装了。我最后用的是下面这张判定表：

这个表不是一次调好的，我在实验室里反复测了好几轮。关键经验是刹车距离一定要给足。AGV有惯性，特别是四驱底盘，设定0.5米刹车可能实际停下来已经接近0.3米，如果负载再重点，很容易撞上去。安全阈值宁可大一点，也不要追求极限贴边。

6. 那些让我通宵的Bug排查链路

6.1 现象一：雷达数据时断时续，最后翻车根源是供电

这个问题我在2.2里提过，但完整的排查链路值得再走一遍。某天晚上雷达数据突然每隔十几秒就卡一次，我第一反应是驱动坏了，重新编译了三遍驱动，没用；又怀疑串口接触不良，换了一根杜邦线，还是不行；最后打开dmesg，发现每隔一段时间就有USB设备断开重连的记录。

这时候我才意识到问题在供电。雷达电机堵转电流大，USB转串口模块的稳压电路扛不住，电压跌落导致雷达核心板反复复位。解决办法是给雷达电机单独5V供电，串口模块只负责通信。这次排查花了两个多小时，其实只要一开始用万用表量一下雷达供电电压，问题几秒钟就能发现。这个教训让我从此养成了先看电源、再查软件的习惯。

6.2 现象二：地图越建越歪，漂移分析

地图漂移是cartographer建图最常见的坑，也是最难定位的坑之一。我的现象是：小车沿着一个方形走廊走一圈，回来时地图的墙和起点处的墙错开了十几厘米，整体呈现一个越来越歪的“斜四边形”。

排查链路是先怀疑雷达数据本身，把scan数据在RViz里叠在真实空间位置上看，发现雷达扫描没毛病。再怀疑轮式里程计，用编码器读数计算小车走的路程，发现转弯时两轮打滑严重，里程计累计误差过大。我是差速底盘，转弯时内侧轮和外侧轮速度差一旦过大，摩擦力不够就在原地打滑，编码器读数还在增长，但车体根本没动那么多。

解决办法有两步：第一步在机械上把驱动轮换成摩擦力更大的橡胶轮；第二步在传感器上增加IMU，用角速度数据辅助里程计修正。如果你没有IMU，可以先降低转弯速度，减少打滑，这样地图漂移会明显好转，但根治还是要加IMU。这也是为什么很多成品AGV都标配IMU的原因。

6.3 现象三：电机一启动，雷达数据变雪花

这个现象非常诡异，小车静止时雷达数据一切正常，电机一转起来，RViz里的激光点就开始出现毛刺和乱点，有些点甚至会跑到墙体后面去。一开始我以为是电机产生的电磁干扰影响了雷达的USB通信，但加了一圈磁环之后问题依旧。

后来用万用表测雷达供电电压，发现在电机PWM启动的瞬间，5V电压会下跌到4.4V左右。这就是典型的电源共路问题：电机驱动、树莓派、雷达全挂在同一组5V降压模块上，电机电流尖峰一上来，其他设备电压就掉。我最后的接线方式是：电机驱动直接从电池取电，树莓派和雷达使用独立的5V降压模块，所有模块的GND连在一起。同时还在雷达电源两端并联了220uF电解电容和100nF陶瓷电容，用来吸收瞬态电压跌落，雷达数据从此稳定了。

还有一个容易忽略的小坑：树莓派的散热风扇也要单独供电，不要接在给雷达供电的那一路5V上。风扇启动瞬间同样会产生电流尖峰，我有一段时间雷达数据不稳，罪魁祸首就是风扇和雷达共用了一组电源。

6.4 排查Bug的方法论：一次只改一个变量

这个项目后期，我为了防止自己“乱修”，给自己定了一条规矩：每次只改一个变量。有一次地图突然变得乱七八糟，我同时改了max_range、底盘控制频率和A*的启发函数权重，结果小车跑起来比之前还离谱，我却根本不知道是哪一个改动导致的。后来我只能把所有修改全部回滚，再一项一项重放，每个改动跑一次建图，花了整整一个下午才定位到是max_range设置太小导致建图边缘被裁掉。

这条规矩听起来简单，但实际操作中非常难坚持。尤其是调试到半夜，大脑发昏，看到一个问题就想顺手把旁边觉得不对的参数也一起改了。其实大部分雷达和SLAM问题，都不是复合原因造成的。一次只改一个变量的排查效率，远高于一次改五六个变量后的“交叉排除”。

如果你准备复刻这套系统，我给三个最实在的建议。第一，别一上来就追求完美的融合算法，先把雷达转起来，在RViz里看到scan数据，再用最小代码实现“探测到障碍就停车”，这个闭环跑通了再谈其他。第二，所有传感器的GND必须共地，供电要分路，一个模块一路稳压，这是整台AGV稳定运行的地基。第三，建图可以慢，但参数不能乱调，每次改动留好日志。我最初以为这个项目最大的难点是SLAM和路径规划，最后发现80%的时间都花在了供电、接线、TF这样“没技术含量”的地方。这是很现实的事情。如果让我重来一次，底盘我会直接买成品带编码器的差速底盘，摄像头和雷达的安装位置提前设计好，把省下来的时间用在融合策略上，那样避障系统的上限会高得多。