ABOT-M1-ATK ROS小车建图导航与赛前验收实战

简介面向参加中国机器人及人工智能大赛、全球校园精英人工智能算法大赛巡航赛项的选手与机器人初学者这份 PDF 文档聚焦 ABOT-M1-ATK 智能车的开箱配置与快速上手帮助读者在缺乏现场指导时独立完成整机调试。内容涵盖激光雷达环境感知与建图、导航目标点路径规划、视觉识别与语音交互、远程桌面控制以及射击模块验证并对取机搬运、充电维护、相机与雷达保护等安全事项逐条说明建图部分还区分 gmapping、hector、cartographer 等不同方案与功能包组织方式便于按模块对照实操。压缩包共 1 个 PDF 文件约 2.3MB篇幅紧凑、步骤连贯已有 585 人学习下载适合备赛团队与课程实验使用可据此逐项验证各项功能快速搭建 ROS 智能车调试环境减少摸索与误操作导致的器件损伤。1. 一台能直接下场跑巡航的 ROS 小车省掉的不是钱是时间箱子刚拆开的时候多数人第一反应是找电源键。我见过更稳妥的做法是先想清楚一件事这台 ABOT-M1-ATK 到底是一台能动的成品还是一条从激光雷达到机器人导航、从视觉识别到无人驾驶巡航赛项的完整链路。它给的是后者——一套已经跑通的 ROS 工作空间、几个能直接roslaunch起来的建图和导航节点、外加相机、语音、射击三个外设的验证入口。对备赛队伍和做课程设计的人来说最贵的从来不是硬件是把雷达、底盘、TF、代价地图这几样东西对齐所花的那几周。这篇就按我实际拆箱到跑通导航的顺序写哪一步该看什么、参数改哪儿、哪里容易翻车都摊开讲。2. 上电、远程桌面与工作空间把散件状态的车点亮2.1 上电顺序与供电边界随车的是一块 10 寸 HDMI 显示器第一次上电必须接上它因为后面要连 WiFi、要看主控有没有正常进桌面。顺序是死的先接 HDMI 线再给显示器供电然后按车身电源开关等 5 秒最后按主控制器开关。这个 5 秒不是客气底盘供电和主控供电是两路主控先起来而底盘还没稳住串口设备枚举会漏表现出来就是雷达话题起不来。取机器的手法也得说清楚。双手放在前后轮胎之间的位置抬不要托拽激光雷达雷达上方不要压任何东西。这不是矫情激光雷达是靠内部皮带或轴承带动旋转的托一下可能不马上坏但会留下长期的角度偏差建图时表现为墙面周期性扭曲这种问题你很难第一时间怀疑到雷达本体上。电量管理上有个明确的红线电量显示一格就充电用 DC12.6V/2.0A 的充电器充电器背部红灯是充电中、绿灯是充满。长时间半个月不用也要补一次电。锂电池过放之后保护板会锁死车就变成一块砖这种后悔药没有地方买。上车后先用两条命令确认设备枚举情况# 列出底盘和雷达的串口设备正常应能看到 ttyUSB0/ttyUSB1 或 ttyACM0 ls -l /dev/ttyUSB* /dev/ttyACM* 2/dev/null # 查看 USB 设备的厂商信息用来区分哪个是雷达、哪个是底盘 lsusb第一条命令决定后面 launch 能不能起来。常见的对应关系是雷达占一个 ttyUSB底盘控制板占另一个如果只剩一个设备先查 USB 线有没有插紧、是不是插在了供电不足的 HUB 上再查底盘电源有没有打开。第二条命令用来交叉验证雷达厂商的 VID/PID 和底盘单片机是不同的认错了串口launch 会报打开设备失败而不是报话题没数据这两种错误指向完全不同的方向。2.2 远程桌面接入把显示器和键鼠从车上摘掉车跑起来之后还拖着显示器和键鼠是不现实的尤其是建图阶段要跟着车走。标准做法是让车连上网络用远程桌面工具接管桌面。工具选哪款不重要认准两个特征支持识别码 验证码连接、支持画面和输入同时回传。车里的系统一般预装了其中一款点左下角图标能呼出。网络这一步是整条链路的咽喉。可以用场地路由器也可以直接用手机热点两种都行但要保证电脑和车在同一个网段。热点有个细节2.4G 和 5G 如果是同名双频设备可能连到 2.4G 上带宽不够远程桌面画面会糊成马赛克但控制指令还是通的容易误判成软件卡顿。我的习惯是热点名字直接标 5G或者干脆关掉 2.4G 那一路。配对完成后先在车上看一眼自己拿到的地址再从电脑侧 ping 一次# 在车的终端里看本机 IP确认拿到的网段 hostname -I # 在电脑端验证链路替换成车上显示的地址 ping -c 4 192.168.43.xxx # 再反向从车 ping 一次电脑确认双向可达 ping -c 4 192.168.43.yyy单向可达是最坑的一种状态远程桌面能看画面但 ROS 多机通信、rosbag 回传全都不通。原因是电脑侧防火墙拦了入站或者两台设备虽然都在线但分属不同网段一个走了热点一个走了路由器的有线口。双向都通再往下走这一步省不掉。提示远程桌面的识别码每台机器不同以车上实际显示的为准不要去抄别人的。2.3 四个工作空间的目录地图改哪个文件心里要有数打开文件管理器源码目录集中在四个 catkin 工作空间里。新手最容易犯的错是把 launch 文件改错工作空间改了半天空欢喜。工作空间负责的内容典型改动位置robot_ws底盘、IMU、各模块驱动、综合 demo自主巡航底盘串口、里程计标定、bringup launchlidar_ws激光雷达驱动与导航相关雷达 IP/串口、robot_slam下的建图与导航 launchabot_vision视觉相关功能相机设备号、分辨率、识别节点参数abot_voice语音合成与识别音频设备、TTS 节点参数每个工作空间的src下才是功能包。启动前必须 source 对应工作空间否则roslaunch找不到包报的是 package not found而实际文件明明在那儿——八成是环境变量没加载对。# 每次新开终端都要执行按实际安装路径调整 source /opt/ros/你的发行版/setup.bash source ~/robot_ws/devel/setup.bash source ~/lidar_ws/devel/setup.bash # 确认功能包能被找到 rospack find abot_bringup rospack find robot_slamrospack find返回空就是没 source 对。另外注意几个工作空间有覆盖关系后 source 的会覆盖前面同名的包如果两个工作空间里存在同名功能包行为会变得很玄学。我一般在.bashrc里按固定顺序 source不临时手打。2.4 相机、语音、射击三个外设的最小验证主控起来之后先别急着建图把三个外设各点一次火十分钟能省掉后面几小时的排查。视觉链路用 USB 相机节点加图像查看器# 启动相机节点 roslaunch usb_cam usb_cam_test.launch # 另开终端查看图像话题的实际输出频率 rostopic hz /usb_cam/image_raw # 图形化查看画面 rosrun rqt_image_view rqt_image_viewusb_cam_test.launch里要关注的是video_device通常是/dev/video0、image_width/image_height和pixel_format。分辨率设太高USB 带宽吃满帧率会掉到个位数视觉识别节点处理不过来设太低识别距离不够。640×480 是个稳妥起点。rostopic hz如果在 15~30 之间说明链路正常如果显示 0 或者一帧都没有先查/dev/video*是否被别的进程占用再查相机排线有没有松动。相机模块不能用手指或尖锐物体碰镜头前的红外滤光片刮花之后画面对比度会明显下降这种损伤不可逆。语音链路要分两步先起 roscore再起 TTS 节点最后手动发一条消息# 终端一 roscore # 终端二启动语音合成节点 rosrun robot_voice tts_subscribe # 终端三往话题里塞一句话 rostopic pub /voiceWords std_msgs/String data: 一二三四 -1-1表示只发一次。耳机要先在系统设置里通过蓝牙配对成功否则声音会走 HDMI 输出你在车上听得见、远程桌面那头听不见容易误判成节点没工作。TTS 有延迟是正常的从发消息到出声通常有半秒到一秒别连发十条去测。射击模块的上电和触发是分开的两件事# 打开射击模块的电源开关后再启动驱动 roslaunch abot_bringup shoot.launch # 发一条空字符串触发一次 rostopic pub /shoot std_msgs/String data: -1能听到击发声就说明驱动和硬件通了。水弹必须用矿泉水泡够 8 小时以上再装弹仓泡不够会卡弹卡弹硬打会把波箱齿轮打崩。测试时枪口绝对不能对着人和贵重物品这条没有例外。3. 激光雷达建图三选一gmapping、hector、cartographer 的适用边界3.1 选型的核心问题有没有可用的轮式里程计三种建图算法在这台车上都能跑差别不在谁更先进而在你手上有什么。gmapping 是粒子滤波依赖里程计做运动预测雷达做观测更新对里程计精度敏感但对算力要求低hector 只用雷达靠扫描匹配估计运动不需要里程计代价是快速转向或经过长走廊时容易丢cartographer 用子图和回环检测建出来的图最规整但参数最多、调起来最费时间。算法依赖里程计回环检测算力占用适合的场景gmapping是无中场地不大、里程计已标定的常规室内hector否无低里程计不准、只能靠雷达的中小场地cartographer可选有高场地大、有回环、追求地图一致性备赛场景我一般先跑 gmapping十分钟能出一张能用的图如果发现图里的墙是双层重影说明里程计和雷达的外参或者轮距标定有问题这时候换 hector 反而能验证一下是不是里程计拖后腿。cartographer 留在场地大、需要闭合回环的时候用。3.2 gmapping 跑通两条 launch 加键盘遥控启动顺序是底盘带 IMU 的 bringup 先起再起建图最后起可视化# 终端一底盘、IMU、雷达驱动 roslaunch abot_bringup robot_with_imu.launch # 终端二gmapping 建图 roslaunch robot_slam gmapping.launch # 终端三地图可视化 roslaunch robot_slam view_mapping.launch # 终端四键盘遥控 rosrun teleop_twist_keyboard teleop_twist_keyboard.py键盘控制有一组容易记混的键位U/I/O控制前进方向上的左前、正前、右前J/L是原地左右转M//是后方三向。开了大写锁定之后U/O变成左前右前平移J/L变成左右平移/变成左后右后平移。这个设计对全向底盘很友好但键位记错会导致你以为车在往前走实际上在原地平移建出来的图自然是一团。gmapping 的参数在 launch 里值得改的就几个!-- gmapping.launch 中 slam_gmapping 节点的关键参数 -- launch node pkggmapping typeslam_gmapping nameslam_gmapping outputscreen param namebase_frame valuebase_footprint/ param nameodom_frame valueodom/ param namemap_frame valuemap/ param namedelta value0.05/ !-- 栅格分辨率(m)室内 5cm 足够 -- param namemaxUrange value5.5/ !-- 小于雷达量程留 0.5m 余量 -- param nameparticles value50/ !-- 粒子数场地大再往上加 -- param namelinearUpdate value0.2/ !-- 走 20cm 更新一次 -- param nameangularUpdate value0.2/ !-- 转 0.2rad 更新一次 -- param nameminimumScore value200/ !-- 匹配分数门槛玻璃幕墙要调低 -- /node /launchdelta决定了地图文件的体积和路径规划的精细度0.05 意味着 20 米见方的场地是 400×400 的栅格再细下去导航的代价地图计算量会明显上升。maxUrange一定要比雷达标称量程小一点因为量程边缘的点噪声最大把这些点喂进去会让匹配分数虚高。particles加到 80 以上建图会变慢除非场地特别大否则没必要。minimumScore是匹配失败的判定门槛场地里有大面积玻璃或者反光地面时雷达点会穿透或者散射这时候把门槛降到 100~150让系统别那么快判定丢位。3.3 cartographer 与 hector什么时候换、换之前改什么hector 的启动最省事因为它不需要里程计# 终端一只起雷达和底盘不用带 IMU 的 bringup 也行 roslaunch abot_bringup robot_with_imu.launch # 终端二hector 建图 roslaunch abot_slam hector_mapping.launch # 终端三可视化 roslaunch abot_slam view_mapping.launchhector 的软肋是快速旋转。雷达扫描频率如果是 10Hz转一圈需要 0.1 秒这期间车转了 90 度前后两帧的点云匹配就找不到对应关系了。所以用 hector 时遥控要慢转向尤其要慢这是操作层面的约束不是参数能救的。cartographer 的启动分两段# 终端一 roslaunch abot_bringup robot_with_imu.launch # 终端二 roslaunch abot_slam cartographer.launch它的参数在 lua 配置文件里最常动的是三个TRAJECTORY_BUILDER_2D.num_accumulated_range_data控制多少帧累积一次场地空旷可以调大提高点云密度场地狭窄调小避免运动畸变submaps.num_range_data决定一个子图包含多少帧值越大子图越稳但回环越难触发use_imu_data在有 IMU 的情况下设 true能让快速转向时的位姿估计不至于崩。cartographer 建图时 CPU 占用明显更高远程桌面的画面可能会卡这属于正常现象不要误以为死机了去强制重启。3.4 地图保存与复用三个前提缺一不可三种算法建完图保存命令是同一个# 建图终端不要关闭的情况下另开一个终端执行 roslaunch abot_slam save_map.launch # 保存后确认文件确实生成了 ls -lh ~/.ros/ # 或 map_server 配置里指定的输出路径前提有三个。第一建图的节点必须还在跑map_server是从运行中的map话题上取数据的节点关了就没数据可取。第二保存路径要有写权限默认写到~/.ros/下换到别的目录要改 launch 里的路径参数。第三生成的是.pgm加.yaml一对文件.yaml里记录了分辨率和原点坐标两个文件必须一起移动只拷.pgm导航时会读不到元信息。注意地图原点对应建图开始时车的初始位置。下次导航如果车的摆放位置和建图起点差得远AMCL 的初始定位就会偏宁可多花三十秒把车摆回原位。4. 导航链路从 robot_with_imu 到 2D Nav Goal 的完整依赖4.1 导航栈吃的是什么TF 树、代价地图、AMCL导航能不能跑八成取决于 TF 树对不对。完整的链条是map → odom → base_footprint → base_link → laser。robot_with_imu.launch负责发布odom → base_footprint底盘里程计和 IMU 融合出来的AMCL 负责发布map → odom的修正量雷达驱动负责base_link → laser。任何一环断了rviz 里就会报 No transform from [xxx] to [map]导航直接不动。代价地图这块robot_radius和inflation_radius是两个必须匹配实车尺寸的参数。robot_radius填小了规划出来的路径会贴着墙角走实车过不去填大了窄门口直接判定为不可通行。inflation_radius是膨胀半径一般设成车体半径的 0.5~1 倍太小容易擦碰太大在狭窄区域会把通路堵死。# costmap_common_params.yaml 中的关键项 robot_radius: 0.22 # 按实车最大外接圆半径填写单位 m inflation_radius: 0.30 # 膨胀半径狭窄场地适当减小 observation_sources: scan scan: topic: /scan data_type: LaserScan clearing: true # 允许清除障碍 marking: true # 允许标记障碍 max_obstacle_height: 2.0clearing: true意味着雷达看不到的地方会被当成自由空间擦掉这在动态场地里是必要的否则有人走过一次那个位置就永久变成障碍物。4.2 启动顺序与三个终端的职责导航的启动是三条命令顺序不能乱# 终端一底盘 IMU 雷达 roslaunch abot_bringup robot_with_imu.launch # 终端二地图服务 AMCL move_base roslaunch robot_slam navigation.launch # 终端三rviz 可视化 roslaunch robot_slam view_nav.launch第一条必须先起因为navigation.launch里的 AMCL 需要/scan和/odom已经存在否则会一直等到超时。第二条起来之后rviz 里应该能看到地图、雷达点云和机器人的位姿箭头。第三条只是可视化理论上可以最后起但建议一起起方便观察 AMCL 的粒子云有没有收敛。4.3 AMCL 定位与目标点下发AMCL 的核心参数是粒子数和更新阈值!-- navigation.launch 中 amcl 节点的关键参数 -- node pkgamcl typeamcl nameamcl outputscreen param namemin_particles value500/ param namemax_particles value3000/ param nameupdate_min_d value0.1/ !-- 走 10cm 更新一次 -- param nameupdate_min_a value0.2/ !-- 转 0.2rad 更新一次 -- param namelaser_model_type valuelikelihood_field/ param nameodom_model_type valuediff/ !-- 全向底盘改 omni -- /nodeodom_model_type是最容易错的一项。这台车是全向底盘如果还按diff差分模型算横向平移时 AMCL 的预测会持续偏离表现是车走直线没事、一平移定位就飘。粒子数上到 3000 是为了在初始位置不确定时能快速收敛代价是 CPU 占用稳定之后可以降到 1000 左右。下发目标点就是在 rviz 里点2D Nav Goal在地图空白处按住鼠标拖出方向。也可以用命令行发方便脚本化# 向目标点 (x2.0, y1.0)朝向正前方(四元数 w1) 发一次导航目标 rostopic pub -1 /move_base_simple/goal geometry_msgs/PoseStamped \ {header: {frame_id: map}, pose: {position: {x: 2.0, y: 1.0, z: 0.0}, orientation: {x: 0.0, y: 0.0, z: 0.0, w: 1.0}}}frame_id必须是map写成odom的话目标点会随定位漂移而偏移。目标点尽量不要贴着膨胀区的边界留 20cm 余量。4.4 导航跑不动的排查顺序按这个顺序看能覆盖九成问题。先看/move_base/status状态一直是 ACTIVE 但车不动说明规划出了路径但控制没执行查底盘 cmd_vel 有没有收到。再看/scan有没有数据没数据说明雷达驱动挂了代价地图是空的规划器会认为到处都是自由空间。然后看 TFrosrun tf tf_echo map base_link如果报错或者数值跳变说明定位在丢。最后看全局代价地图rviz 里把global_costmap打开如果整张图都是膨胀区说明robot_radius或者inflation_radius设大了。5. 避坑与排查五条实际踩过的记录5.1 建图重影墙变成两条现象是 rviz 里同一面墙出现两条平行线间隔几十厘米走得越远越明显。原因是里程计标定不准轮距或者轮径参数和实车不符直行一段距离后里程计报告的位置和实际位置对不上雷达匹配只能强行拉回来拉不回来就出现重影。车上如果是全向轮还要额外确认三个轮的辊子角度没有装反。解决方式是先做里程计标定让车直行 2 米对比/odom累计的距离和卷尺量出来的实际距离比值接近 1 才算过关再原地转 360 度对比/odom的偏航角累计值和实际角度。两项都校准后再建图。临时应急可以换 hector因为它不依赖里程计图会干净很多但代价是快速转向时容易丢。5.2 地图保存了导航却加载失败现象是save_map.launch执行完提示成功navigation.launch起来后 rviz 里没有地图终端报Failed to load map。原因基本是两个一是只拷了.pgm没拷.yaml或者两个文件不同名二是.yaml里的image字段写的是相对路径而启动导航时的工作目录变了相对路径解析不到。解决方式是把两个文件放在同一目录、保持同名把image改成绝对路径或者确认 launch 里的map_server用了正确的yaml_filename参数。改完用rosrun map_server map_server xxx.yaml单独起一次验证能出图再往导航里接。5.3 远程桌面连上了ROS 节点却起不来现象是画面能看能点但在远程终端里执行roslaunch报各种环境变量或者权限错误。原因是远程桌面会话和本地登录会话的环境变量不共享.bashrc里的source在远程会话里可能没执行尤其是非交互式 shell。另一个常见原因是ROS_MASTER_URI指向了别的主机。解决方式是每次开终端先手动 source 一遍或者把 source 写进.bashrc的最前面注意要在非交互判断之前。用echo $ROS_MASTER_URI确认指向本机http://localhost:11311多机配置时才改成车的主机名或 IP。5.4 目标点发下去车原地打转或直接拒绝现象是点了2D Nav Goal车原地左右摆动几下就停或者 rviz 里目标点一闪就没了。原地打转通常是 AMCL 定位没收敛粒子云散在整张地图上规划器每次算出来的路径方向都不一样。原因可能是初始位置和建图起点差太远或者雷达数据和地图对不上比如场地里家具挪了位置。目标点被拒绝则是规划失败看/move_base/status里的状态码返回 4 是路径规划失败。九成是目标点落在膨胀区里或者当前定位下的车已经在障碍物内部。解决办法是先用 rviz 的2D Pose Estimate手动给一个粗略初始位姿等粒子云收拢成一小团再发目标点。5.5 外设哑火相机没图、语音没声、射击不触发相机没图先查/dev/video0是不是被占用了。多个节点同时打开同一个相机设备第二个会失败但不一定报错表现就是话题存在但没有数据。用fuser /dev/video0看谁占着。语音没声先确认蓝牙耳机在系统里是默认输出设备再看tts_subscribe节点有没有订阅上/voiceWords。用rostopic info /voiceWords看订阅者数量是 0 就说明节点没起来或者话题名拼错。射击不触发先确认射击模块的独立电源开关打开了——它和主控不是一路电主控开着不代表射击模块上电了。再确认shoot.launch里的驱动节点正常运行rostopic list里能看到/shoot话题。水弹卡住时不要连续发送触发指令先断电清理弹仓。6. 一次跑通赛前整机验收的十分钟流程真正比赛前我不会只测单项功能而是按一条完整链路走一遍把每次都要重复的命令固化成脚本。这样出问题时能立刻判断是环境问题还是硬件问题。#!/bin/bash # 赛前自检逐项确认关键话题和 TF 是否就绪 source ~/robot_ws/devel/setup.bash source ~/lidar_ws/devel/setup.bash echo 1. 检查设备枚举 ls /dev/ttyUSB* /dev/ttyACM* 2/dev/null || echo 串口设备缺失 echo 2. 检查关键话题 for topic in /scan /odom /usb_cam/image_raw; do timeout 3 rostopic hz $topic /dev/null 21 \ echo $topic OK || echo $topic 无数据 done echo 3. 检查 TF 链 timeout 3 rosrun tf tf_echo map base_link /dev/null 21 \ echo TF OK || echo TF 断裂检查 amcl 与底盘 bringup echo 4. 检查电量 echo 电量低于两格请先充电不要带电调试导航脚本本身不复杂价值在于把凭感觉判断变成看输出判断。第 2 步的rostopic hz是最灵敏的探针话题存在但没数据的情况太常见了光看rostopic list会被骗。第 3 步的 TF 检查要在导航 launch 起来之后执行否则map帧还不存在一定报错。验收的实操顺序我固定成先上电看串口再起 bringup 看/scan频率然后起建图在场地里走一圈确认地图没有重影保存地图、起导航、手动给初始位姿、发一个三米外的目标点看车能不能平稳到达。整套下来十分钟左右任何一步卡住就停下来查不要带着问题往下走。有个习惯我保持了很久每次改完 launch 文件先用roslaunch --ros-args或者直接rospack find确认改的是当前 source 的那个包而不是另一个工作空间里的同名备份。被这个坑过一次之后我改任何参数前都会先rospack find打印一遍路径多花两秒钟省掉半小时的自我怀疑。希望帮到你赛场上少走点弯路。本文还有配套的精品资源点击获取