本科毕设那阵子我手里握着两块板子一块树莓派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 我的硬件选型清单与总花费这套系统的硬件选择直接影响后面所有软件工作。我把自己的实际配置列在下面后面所有踩坑经历都是基于这套硬件发生的。组件型号价格区间选择理由主控树莓派4B 4GB300-500元算力够跑cartographer和轻量视觉识别生态成熟激光雷达RPLIDAR A1300-400元入门级360度2D雷达文档全资料多视觉模块OV5647 CSI摄像头500万像素30-80元走CSI接口不占USB带宽价格便宜电机驱动TB6612FNG20-40元MOS驱动芯片比L298N效率高、发热小电机带编码器直流减速电机 ×4100-160元编码器能提供轮式里程计对建图很重要底盘四驱亚克力底盘 / 成品差速底盘60-200元四驱便宜但转弯磨损大差速底盘更贴近真实AGV电源3S锂电池2200mAh 5V降压模块80-120元需要给树莓派、雷达、电机分别供电整套下来大约在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_x1 camera_auto_detect1改完重启后用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.0tracking_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才知道激光雷达相对于机器人中心的位置。我没有准确测量安装位置只写了一个拍脑袋的静态TFrosrun 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管道把摄像头画面桥接给OpenCVcap cv2.VideoCapture( libcamerasrc ! video/x-raw,width640,height480,framerate30/1 ! videoconvert ! video/x-raw,formatBGR ! appsink drop1, 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米就停车”这种单一逻辑否则视觉模块就白装了。我最后用的是下面这张判定表雷达前方距离视觉结果动作 0.5米识别到人立即停车等待人离开 0.5米无识别或不确定刹车后向障碍较少侧转向0.5 - 1.5米高置信度障碍减速选择绕行路径0.5 - 1.5米未识别目标保持速度但启动视觉连续检查 1.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这样“没技术含量”的地方。这是很现实的事情。如果让我重来一次底盘我会直接买成品带编码器的差速底盘摄像头和雷达的安装位置提前设计好把省下来的时间用在融合策略上那样避障系统的上限会高得多。