从零打造送药小车：基于ROS的移动机器人全栈开发实践

1. 项目概述与核心价值最近刚带着团队完成了一个送药小车的集训项目从零到一从方案设计到最终调试整个过程下来感触颇深。这个项目乍一听可能觉得就是个“带轮子的箱子”但真正上手后才发现它融合了机械结构、嵌入式控制、传感器融合、路径规划乃至简单的物联网通信等多个技术领域是一个绝佳的综合性实践平台。无论是对于在校学生参加智能车竞赛还是对于工程师想快速验证移动机器人AGV/AMR的某些关键技术送药小车都是一个非常理想的载体。这次集训的核心目标是打造一个能够在模拟医院病房或养老院走廊环境中自主完成“从药房到指定床位”的药品配送任务的小车。它需要能识别路标如房间号、规避静态障碍和动态行人模拟、精准停靠在目标点并具备一个简单的取放药机构。整个过程我们摒弃了昂贵的成品套件坚持从开源硬件和常见传感器入手旨在吃透每一个技术环节。如果你也对移动机器人、嵌入式开发或者自动化项目感兴趣这篇总结或许能帮你避开我们踩过的那些坑更高效地实现自己的“送药小车”。2. 整体方案设计与核心思路拆解2.1 需求分析与技术选型考量送药小车的核心需求可以分解为移动底盘、环境感知、决策控制、任务执行和人机交互。我们的方案设计也紧紧围绕这五点展开。首先移动底盘是基础。我们对比了差速驱动、麦克纳姆轮全向移动和舵轮转向等多种方案。差速驱动结构最简单、控制成熟、成本最低虽然不能横向移动但对于在笔直或缓弯走廊中行驶的场景完全够用。麦克纳姆轮虽然灵活但结构复杂、成本高、对地面平整度要求也高在铺有地毯或稍有起伏的医院环境中可能打滑。因此我们最终选择了经典的两轮差速驱动两个万向轮的方案电机选用带编码器的直流减速电机为后续的里程计计算和精准控制打下基础。其次环境感知是眼睛。我们需要让小车“看得见”路在哪、障碍在哪、目标在哪。这里我们采用了多传感器融合的策略定位与建图核心是激光雷达LiDAR。我们选用了一款性价比不错的单线激光雷达用于构建走廊环境的二维地图SLAM和实时定位。这是实现自主导航的基石。路标识别为了识别房间号或特定标志我们增加了摄像头。考虑到处理能力我们选择了轻量级的USB摄像头配合OpenCV进行图像处理识别预设的AprilTag或ArUco码一种类似于二维码的视觉基准标记这种方式比直接进行复杂的数字OCR要稳定和快速得多。近距离避障激光雷达有盲区且对于低矮、透明障碍物比如临时放置的输液架可能失效。因此我们在小车前后左右加装了多组超声波传感器和红外避障传感器作为最后一道安全防线。里程计电机的编码器提供轮子转动的原始数据通过计算可以得到小车的相对位移和转角航向即里程计信息。它高频、短期相对准确但与激光雷达定位信息融合后能极大提升定位的稳定性和精度。决策控制是大脑。我们选用树莓派4B作为主控制器。它的优势在于性能足够运行ROSRobot Operating System和简单的视觉算法GPIO丰富便于连接各种传感器社区支持强大。我们将ROS部署在树莓派上所有传感器数据、控制指令都在ROS的节点Node和话题Topic框架下进行通信这使得软件架构非常清晰调试方便。任务执行即取放药机构。我们设计了一个简单的舵机控制的推杆或夹爪模块安装在车身特定位置。当小车到达目标床位时由树莓派通过GPIO发送PWM信号控制舵机动作将药盒推出或夹取放下。这部分关键在于机械结构的可靠性和重复定位精度。人机交互我们做了简化通过一个手机APP或网页基于ROS的rosbridge和web_video_server包开发可以发送目标点如“送药至302房”并实时查看小车摄像头画面和状态。注意技术选型没有绝对的好坏只有是否适合。我们的选择基于“在满足功能需求的前提下追求最高的性价比和可维护性”。例如如果预算极其有限可以尝试用RGB-D摄像头如Intel Realsense D435i同时替代激光雷达和单目摄像头做SLAM与避障但算法复杂度和计算资源消耗会成倍增加。2.2 系统架构与ROS框架搭建确定了硬件软件架构就成了项目成败的关键。我们采用ROS1 Noetic版本因其在树莓派上的生态最成熟作为软件框架。下图展示了我们搭建的核心系统架构[用户指令] -- (ROS Master - 树莓派) | |-- (导航节点 Nav Stack: move_base) | |-- 全局规划器 (global_planner) | |-- 局部规划器 (dwa_local_planner) | -- 恢复行为 (recovery_behaviors) | |-- (感知节点) | |-- 激光雷达驱动 (rplidar_ros) | |-- 摄像头驱动 (usb_cam) | |-- 里程计计算 (odometry_publisher) | -- 传感器融合 (robot_pose_ekf) | |-- (控制节点) | -- 电机驱动 (motor_driver_node) | |-- (任务节点) |-- 视觉识别 (aruco_detect) -- 舵机控制 (servo_control_node)搭建过程的关键步骤与避坑点操作系统与ROS安装树莓派刷入Ubuntu 20.04 Server镜像然后按照ROS官网教程安装ROS Noetic。这里第一个坑就是电源。树莓派4B在高负载下功耗不小务必使用足额5V/3A的电源否则会在运行SLAM或导航时突然重启。我们为此烧坏了一张TF卡。创建工作空间与功能包mkdir -p ~/medicar_ws/src cd ~/medicar_ws/src catkin_init_workspace cd .. catkin_make source devel/setup.bash将电机驱动、传感器驱动等必要功能包通过git clone放入src目录。我们自定义的功能包主要包含medicar_bringup启动所有硬件驱动、medicar_navigation导航配置、medicar_vision视觉识别、medicar_control底层控制。硬件驱动与通信激光雷达通常通过USB转串口连接。安装对应的ROS驱动包如rplidar_ros确保在launch文件中配置正确的串口端口如/dev/ttyUSB0和波特率。电机与编码器树莓派GPIO直接驱动电机能力有限且危险。我们使用了L298N或TB6612FNG电机驱动模块。编写一个motor_driver_node节点订阅/cmd_vel话题速度指令转换为PWM信号和方向信号输出给驱动板同时读取编码器脉冲发布到/odom话题。编码器计数与里程计计算这是精度保障的关键。需要在节点中实现一个高频至少50Hz的中断服务或轮询准确计数编码器脉冲。里程计公式虽简单位移 脉冲数 / 每圈脉冲数 * 轮子周长但必须考虑车轮打滑和机械误差。我们通过实验标定了轮子直径和轮间距这两个关键参数。URDF模型创建在ROS中需要用URDF文件描述小车的物理属性尺寸、形状、关节、传感器安装位置。虽然我们的车简单但一个准确的URDF对于在RViz中可视化、以及导航栈中的代价地图计算至关重要。务必根据实际测量尺寸编写。3. 核心模块实现与调试细节3.1 地图构建与定位自主导航的第一步是让小车知道自己在哪里。我们采用gmapping包进行SLAM建图。实操流程启动所有硬件驱动roslaunch medicar_bringup bringup.launch启动gmapping节点roslaunch medicar_navigation gmapping.launch启动键盘遥控节点rosrun teleop_twist_keyboard teleop_twist_keyboard.py打开RViz可视化rosrun rviz rviz -drospack find medicar_navigation/rviz/slam.rviz然后通过键盘遥控小车在需要导航的区域如整个走廊缓慢、匀速地走一遍尽量覆盖所有角落特别是直角转弯处。gmapping会实时融合激光数据与里程计数据生成地图。调试心得与避坑指南地图质量不佳出现重影、扭曲这几乎总是里程计不准导致的。首先检查编码器接线是否牢固计数程序是否有丢脉冲或跳变。其次在平坦地面上让小车走一个标准的2米直线和一个360度原地旋转在RViz中观察/odom坐标系下的轨迹是否准确。误差过大就需要重新标定轮子直径和轮间距。标定方法让小车走固定距离如5米记录编码器脉冲总数反算实际轮子周长。建图时小车“飘移”严重降低遥控移动速度建图时建议线速度不超过0.2 m/s角速度不超过0.5 rad/s。同时确保激光雷达安装稳固没有抖动。如何保存地图建图完成后使用命令rosrun map_server map_saver -f ~/map会生成map.pgm地图图像和map.yaml地图参数文件。3.2 自主导航配置与调参有了地图就可以配置ROS的导航栈move_base了。这是整个项目中最需要耐心调试的部分。核心配置文件与参数解析在medicar_navigation/param目录下主要需要配置以下几个YAML文件costmap_common_params.yaml: 定义全局和局部代价地图共通的参数如障碍物膨胀半径、传感器话题。obstacle_range: 2.5 # 传感器最大有效障碍物检测距离 raytrace_range: 3.0 # 用于清理动态障碍物遗留痕迹的距离 inflation_radius: 0.3 # 障碍物膨胀半径要大于小车半径global_costmap_params.yaml/local_costmap_params.yaml: 分别定义全局和局部代价地图的更新频率、坐标系、话题等。global_planner_params.yaml: 全局规划器如navfn参数主要调default_tolerance目标点容差。local_planner_params.yaml: 局部规划器我们用的dwa_local_planner参数这是调参的重中之重。DWAPlannerROS: max_vel_x: 0.4 # 最大前进速度根据电机能力设置 min_vel_x: -0.1 # 最大后退速度 max_vel_theta: 1.0 # 最大旋转速度 acc_lim_x: 0.5 # 前进加速度限制 acc_lim_theta: 1.0 # 旋转加速度限制 vx_samples: 20 # 速度采样数量影响平滑度和计算量 vtheta_samples: 40 path_distance_bias: 32.0 # 路径跟随权重越大越贴路径 goal_distance_bias: 20.0 # 目标趋近权重 occdist_scale: 0.1 # 障碍物代价权重越大越避障 sim_time: 1.5 # 模拟前瞻时间单位秒调试过程实录问题小车在目标点附近来回震荡无法稳定到达。排查检查goal_tolerance位置和角度容差是否设置过大。检查controller_frequency控制频率是否太低建议至少15Hz。检查里程计数据是否延迟严重。解决适当减小xy_goal_tolerance和yaw_goal_tolerance如0.05米0.1弧度。确保/odom话题发布频率足够高30Hz。问题小车在狭窄通道或门口卡住反复调整姿态甚至触发恢复行为。排查inflation_radius膨胀半径设置是否过大导致可行区域过窄。max_vel_x是否过快在狭窄空间来不及调整。解决根据小车实际轮廓包括外扩的安全余量精确设置inflation_radius。在local_costmap_params.yaml中可以针对局部代价地图单独设置更小的inflation_radius和更大的update_frequency使其在狭窄区域反应更灵敏。同时可以编写一个简单的节点当检测到前方通道宽度小于阈值时动态发布一个更小的max_vel_x到/cmd_vel话题上注意与规划器的速度限制协调。问题遇到动态障碍模拟行人后规划路径不合理原地打转。排查局部代价地图中obstacle_layer的combination_method是否设置为1覆盖这能确保动态障碍物被及时标记和清除。sim_time模拟时间是否太短导致规划器“眼光”不够长远。解决确保动态障碍物能被传感器激光雷达、超声波稳定检测并发布到/scan或自定义的/obstacle话题并被代价地图层订阅。适当增加sim_time如从1.0增至1.5或2.0让规划器有更多时间评估不同轨迹。3.3 视觉识别与任务触发导航到位后需要识别特定标志床位号并触发送药动作。AprilTag/ArUco码识别流程在目标位置如病房门框、床头粘贴打印好的ArUco码。使用aruco_ros包。启动节点后它会订阅摄像头图像发布识别到的标记的位姿信息。我们编写一个task_manager节点订阅/aruco_single/pose标记相对于摄像头的位姿和/amcl_pose小车在地图中的位姿。当小车到达目标点附近通过导航且task_manager节点检测到特定ID的ArUco码出现在摄像头视野中并且其位姿满足预设条件例如距离摄像头0.5米以内且正对则判定为“已到达精确送药点”。精准停靠控制仅仅识别到标记还不够我们需要控制小车调整姿态使其正对标记并保持精确距离。这里我们采用了一个简单的视觉伺服思路在task_manager节点中根据识别到的ArUco码的位姿pose消息中的x, y, z和方向计算横向偏差和角度偏差。发布一个精细的Twist速度指令到/cmd_vel话题进行微调。例如如果标记中心在图像中偏左则控制小车向右微转如果距离大于0.5米则缓慢前进。当偏差小于阈值如位置偏差0.02米角度偏差0.05弧度时停止移动并触发舵机动作完成“送药”。实操心得视觉识别的光照稳定性是关键。我们最初在室内日光灯下测试良好但移到有窗户的走廊下午阳光斜射导致识别率骤降。解决方案一是在摄像头外加一个遮光罩二是对图像进行自适应直方图均衡化CLAHE预处理增强对比度三是在条件判断中增加一个“连续识别到N帧才确认”的滤波逻辑避免误触发。4. 系统集成与实战问题排查4.1 多节点协同与消息同步当所有模块单独测试都正常后集成起来却可能出现各种诡异问题根源往往是节点间的协同和时序。典型问题1节点启动顺序导致崩溃。现象使用一个总的launch文件启动所有节点有时导航栈move_base会报错退出提示找不到/map话题或/tf变换缺失。分析与解决ROS节点是并行启动的。如果map_server发布/map启动稍慢于move_base订阅/map就会出错。同样如果robot_state_publisher发布机器人坐标系tf启动慢于需要tf的节点如amcl也会出错。方案在launch文件中使用node标签的requiredtrue属性、launch-prefixbash -c sleep 1.0; $0 $延迟启动或者更优雅地使用node的respawntrue让崩溃的节点自动重启。但最佳实践是确保每个节点在发布关键话题前有适当的等待或检查机制。典型问题2/cmd_vel话题冲突。现象手动遥控时小车正常但切换到自主导航模式后小车不动或者动作怪异。分析与解决遥控节点teleop_twist_keyboard和导航栈的move_base节点都会发布/cmd_vel话题。如果两者同时运行后发布者会覆盖前者但更常见的是消息交错导致电机驱动收到混乱的指令。方案使用ROS的topic_tools中的mux节点创建一个/cmd_vel话题的多路复用器。可以设置一个优先级例如导航指令优先级高于遥控指令或者通过一个自定义的“模式切换”服务来动态选择/cmd_vel的来源。典型问题3tf变换树错误或不完整。现象在RViz中看到小车模型、激光扫描点、地图完全对不上或者导航规划出的路径天马行空。分析与解决这是ROS机器人中最常见也最头疼的问题之一。所有传感器数据、机器人位姿都需要通过tf树统一到同一个坐标系通常是map或odom。使用rosrun tf view_frames可以生成当前tf树的PDF图直观检查。常见错误包括base_link小车基座到laser激光雷达的tf没有正确发布odom坐标系到base_link的tf由里程计节点发布但频率或数据有问题map到odom的tf由amcl发布但amcl定位失败。方案严格按照URDF文件中定义的关节关系发布tf。使用static_transform_publisher发布静态变换如摄像头到基座的距离和角度。确保每个变换的父帧和子帧名称正确无误。在launch文件中使用node的outputscreen查看各个节点的输出信息定位是哪个tf出了问题。4.2 电源管理与稳定性优化送药小车作为一个移动系统电源是生命线。我们经历了多次因电源问题导致的系统不稳定。问题清单与解决方案问题树莓派在电机启动或舵机动作时重启。原因电机和舵机是感性负载启动瞬间电流极大引起电源电压瞬间跌落俗称“拉低”导致树莓派欠压重启。解决电机/舵机电源与树莓派电源彻底分离使用两套独立的电池组如一套7.4V锂电池给电机驱动板一套5V大容量充电宝给树莓派和传感器。如果必须共用务必在电机驱动板的电源输入端并联一个大容量如1000uF以上的电解电容用于缓冲瞬间大电流。同时确保电池电量充足旧电池内阻增大压降更严重。问题运行一段时间后传感器数据出现漂移或丢失。原因USB总线供电不足。树莓派上连接了摄像头、激光雷达可能通过USB转串口等多个USB设备。解决使用带外部供电的USB HUB为高功耗USB设备如激光雷达单独供电。检查树莓派的/sys/class/thermal/thermal_zone0/temp如果温度过高80°C也会导致USB控制器不稳定需要加装散热片或风扇。问题编码器计数偶尔出现巨大跳变。原因电磁干扰。电机运行时产生的电磁场干扰了编码器信号线或树莓派的GPIO。解决使用屏蔽双绞线连接编码器。在编码器信号线与地线之间并联一个0.1uF的瓷片电容进行滤波。尽可能让编码器线远离电机电源线。4.3 场地适应性调整与性能提升实验室环境理想但实际场地如铺有地毯的走廊、不同光照条件会带来新挑战。地面摩擦系数变化地毯摩擦力远大于光滑地砖。这会导致同样的PWM占空比下小车实际速度变慢里程计计算不准进而影响定位和导航精度。调整针对不同地面需要重新标定电机转速-占空比曲线。让小车在目标地面上以多个不同占空比匀速行驶测量实际速度建立查找表或拟合公式在电机驱动节点中做补偿。动态环境处理真实环境中行人不是匀速直线运动的障碍物。策略在local_costmap_params.yaml中减小obstacle_layer的observation_sources的expected_update_rate并设置marking和clearing为true让代价地图能更快地更新和清除障碍物信息。可以考虑在局部规划器参数中适当增加occdist_scale障碍物代价权重让小车更倾向于远离预测的障碍物轨迹。计算资源优化树莓派性能有限同时运行SLAM、导航、视觉识别可能卡顿。优化视觉识别节点不需要高频运行可以降低其运行频率如从30Hz降到5-10Hz。使用robot_pose_ekf节点融合里程计和IMU如果有数据可以得到比单纯里程计更稳定、更准确的/odom话题减少amcl的计算负担提升定位鲁棒性。考虑将视觉识别等计算密集型任务放到性能更强的上位机如笔记本电脑上通过ROS网络与树莓派通信。但这会引入网络延迟和稳定性问题需权衡。5. 项目总结与扩展思考经过这次高强度的集训送药小车从一个概念变成了一个能够稳定执行多任务、适应一定环境变化的实体。回顾整个过程最大的收获不是做出了一个车而是打通了“感知-决策-控制-执行”的完整链路并对其中每一个环节的细节和陷阱有了切身的体会。如果想让这个小车更上一层楼还有很多可以扩展的方向多车调度与协同这是从单机智能到系统智能的跨越。可以引入ROS的multimaster_fkie或基于ROS2的DDS通信实现多台小车的位置共享和任务分配。需要设计一个中心调度服务器处理订单、分配任务、解决路径冲突死锁预防与恢复。更高阶的感知用RGB-D摄像头如Intel Realsense或固态激光雷达替代单线雷达获取三维点云。这样可以识别更复杂的障碍物如悬空的桌子腿、斜坡甚至通过点云分割识别出“门”、“床”、“人”等语义信息让导航和交互更智能。云端监控与数据回传通过4G/5G模块或Wi-Fi将小车的状态信息、摄像头画面实时上传到云端服务器。可以开发一个Web监控面板远程查看所有小车状态、下发指令、记录运行日志并为后续的大数据分析如路径优化、故障预测积累数据。机械结构优化当前的取放药机构是固定的。可以设计一个可升降、可旋转的机械臂末端适应不同高度的床头柜或病床。这涉及到更复杂的运动学控制和可能的多自由度舵机控制。这个项目像一把钥匙打开了一扇通往机器人系统的大门。每一个遇到的问题和解决的方案都是宝贵的经验。它告诉我们在机器人领域理论上的可行和工程上的稳定可靠之间隔着无数个需要耐心调试的细节。希望这篇总结里记录的那些“坑”和“解法”能让你在打造自己的送药小车或任何移动机器人项目时走得更顺畅一些。