企业官网建设流程全解析

简介：这份资源是 ABOT-M1-ATK 智能车的快速上手配置指南，面向准备参加中国机器人及人工智能大赛、全球校园精英人工智能算法大赛巡航赛项的参赛学生与指导教师，也适合刚接触 ROS 无人车、需要在真实硬件上验证激光雷达建图、导航与视觉识别的初学者。资源包共 1 个 PDF 文件，约 2.3MB，以图文步骤形式组织内容，包含开箱取放与充电等注意事项、主控制器上电流程、向日葵远程桌面接入、Gmapping 建图与地图保存、2D Nav Goal 目标点导航、射击模块发射、USB 相机视觉查看、语音播报测试，以及 abot_vision、lidar_ws 等功能包目录说明，另有 Gmapping、Hector、Cartographer 三种建图方式的启动指令对照。已有 591 人学习，读者可据此按顺序完成整机各器件自检，快速搭起可跑通的竞赛调试环境，并借助指令清单排查启动与建图中的常见问题。

1. 桌面上那几个 .sh 脚本，先跑通哪条链路

第一次把 ABOT-M1-ATK 摆到地上，最让人迷惑的往往不是算法，而是桌面上的 1-gmapping.sh、2-navigation.sh 这几个脚本——双击就跑，跑完却说不清后台到底起了哪些节点。这台车把 2D 激光雷达、相机模块、语音模块、射击模块全部挂到 ROS 上，定位是给巡航类机器人赛项做算法验证的底盘平台。它适合两类人：赶赛期、需要一台能直接跑 gmapping、cartographer 和 move_base 的车来验证上层策略的队伍；以及想从底盘层看懂 SLAM 与导航链路、而不是只调一个仿真包的工程师。下面按上电、远程、建图、导航、外设的顺序拆，每步都给可抄的命令和会翻车的地方。

2. 摘掉 10 寸屏之后：远程桌面链路的搭建与自检

2.1 无头运行才是这台车的常态

出箱第一次上电，HDMI 接 10 寸屏、插上鼠标键盘，这套动作只在首配阶段有意义。真正跑建图和导航时，车是要在地上移动的，拖着显示器和线缆既跑不快也容易扯到激光雷达的供电线。所以合格的用法是：显示器只用来完成两件事——连上网络、确认主控正常启动；之后所有操作走远程桌面。

远程方案的选择上有几个现实约束。X11 转发（ssh -X）延迟高，rqt_image_view 这种图像窗口基本没法看；纯 ssh 命令行能跑 roslaunch，但看不到 RViz 的地图，建图时等于瞎跑；远程桌面类软件把整个 X 会话搬过去，RViz 能正常拖拽交互，代价是占带宽。局域网内常见做法是用一款远程协助类软件，车机端装好、开机自启，电脑端输入识别码和验证码连上去。要提醒的是识别码每台机器不同，以车机界面上显示的为准，不要照抄别人教程里的码。

网络这一步最容易卡住新手。手机热点是最省事的办法，注意两点：热点频段尽量选 2.4G，部分车机的无线模块对 5G 信道支持不全；热点的名称别用中文和空格，后面用命令行配网时会省很多事。如果场地里有多台车同时上线，务必给每台车改一个能一眼认出的主机名，否则远程窗口开多了根本分不清在控哪台。

2.2 上电顺序与联网的固定动作

顺序错了会出玄学问题，比如主控先于底盘上电，驱动节点起来时找不到串口设备，robot_with_imu.launch 里那一路就直接挂了。固定动作是这样：先接好 HDMI 与外接显示器供电，按下车身电源开关等 5 秒左右，让底盘电控完成自检，再按主控制器开关，等系统进桌面。

网络配置在图形界面里点两下就行，但熟手一般直接用 nmcli，因为可以脚本化、可以复现。下面这几条是我每次换场地都会重新走一遍的：

# 1) 看无线网卡状态，确认 wlan0 存在且未被 rfkill 关闭 nmcli device status rfkill list # 2) 扫描周边热点，确认目标 SSID 可见（信号值看 SIGNAL 列） nmcli device wifi list # 3) 连接热点，SSID 与密码换成自己的 nmcli device wifi connect "FIELD_HOTSPOT" password "12345678" # 4) 确认拿到地址，记下这个 IP，远程桌面和 ssh 都用得上 ip -4 addr show wlan0 | grep inet # 5) 设成自动连接，下次上电不用手动点 nmcli connection modify "FIELD_HOTSPOT" connection.autoconnect yes

第 1 步的 rfkill 是很多“WiFi 图标灰着点不动”的元凶，硬件开关或软阻塞把无线关了，图形界面不会有任何提示。第 3 步连接成功后 nmcli 会把配置写进 /etc/NetworkManager/system-connections/，第 5 步只是把 autoconnect 打开，不改密码等敏感字段。第 4 步拿到的 IP 建议写在车身贴纸上，多车联调时非常省事。

连上网之后不要急着开建图脚本，先做一轮静态自检，确认底盘、雷达、IMU 都在。

2.3 远程会话里的三项自检

远程桌面能看到画面，不代表 ROS 侧是健康的。我习惯在远程终端里按下面三段过一遍，三十秒内能排掉大半问题：

# 1) 系统与 ROS 环境，确认 ROS_DISTRO 有值（空值说明没 source 环境） lsb_release -a echo $ROS_DISTRO ls /opt/ros/ # 2) 底盘驱动起来后应该能看到这几类话题 rostopic list | grep -E "scan|odom|cmd_vel|imu|tf" # 3) 雷达与里程计的实际频率，雷达一般 7~10Hz，里程计 20~50Hz rostopic hz /scan rostopic hz /odom

第 2 步里 /scan 是激光雷达、/odom 是轮式里程计、/cmd_vel 是遥控指令入口、/tf 与 /tf_static 是坐标变换。这五类里少任何一个，后面的建图都跑不起来。第 3 步的 rostopic hz 是最省事的健康检查：/scan 长期为 0 说明雷达网口没通或者 IP 段不对；/odom 为 0 说明底盘串口没被驱动占用，常见原因是上电顺序不对或者上一次进程没退干净。

TF 树也值得单独看一眼，尤其在导航阶段出现“机器人位置在 RViz 里乱飘”的时候：

# 生成 TF 树 pdf，看 base_link -> laser -> odom -> map 是否连成一条链 rosrun tf view_frames evince frames.pdf

正常状态是 map → odom → base_link → laser（或 base_footprint）一条链下来，中间断开就说明某个节点没发布。frames.pdf 里出现两个独立的树，基本可以断定是同时起了两套 bringup，重复发布同名 TF。

2.4 电池、抬车与传感器的物理红线

硬件上的几条红线，比任何软件参数都值得记。抬车时双手放在前后轮胎之间托底，不要单手拎激光雷达那一侧，雷达的转轴和皮带经不起这个力；雷达上方不要压放任何东西，遮挡会直接反映成建图里的鬼影；不要往车身上倒任何液体；相机模块不要用手或尖锐物体去碰，镜头划伤后视觉识别那一环就只能换件。

电源管理上有一条很实用的规则：电量显示掉到一格就去充，不要等关机。充电器用 DC12.6V / 2.0A，红灯是充电中，绿灯是充满。长时间（半个月以上）不用，也要补一次电，锂电池亏电放久了会鼓包，那台车基本就废了。

私自拆解这条也写清楚：车身上的螺丝有防拆标记，拆了之后标定参数（尤其是雷达外参和相机内参）会漂，出问题责任自负。要改结构，先在软件侧确认是不是真的硬件问题。

3. 激光雷达建图的三种跑法：gmapping、hector 与 cartographer 怎么选

3.1 三条路线的差别不在命令，在输入

三个 launch 文件的命令长度差不多，背后的假设完全不同，选错了会浪费一整晚。

gmapping 是粒子滤波，强依赖轮式里程计，把 /odom 的位姿当作运动先验，再用 /scan 做观测更新。它的好处是麦轮底盘给的里程计够用、建图稳、参数少；坏处是一旦轮子打滑（场地地板太滑、地毯接缝），粒子发散，地图就会糊。

hector 只吃 /scan，不需要里程计，靠激光扫描匹配估计位姿。看起来更省事，实际上对雷达帧率和角分辨率要求更高，机器人转快了就丢匹配，地图直接撕裂。它适合做“验证雷达本身是否正常”的快速测试，不适合长距离大场地。

cartographer 带子图和回环检测，能闭合回路，长走廊、绕圈场地效果最好，代价是要调 lua 配置、对算力要求高，且回环一旦误匹配，整张图会被拉歪。

我一般的顺序是：先用 hector 起一次，确认雷达数据本身没毛病；再用 gmapping 建比赛场地的主图；场地大且有回环需求时才切 cartographer。

3.2 键盘遥控的按键映射与速度上限

建图过程中车得动，动得越平滑地图越干净。这台车自带封装脚本，但手动起 teleop 更可控，因为能改速度参数：

# 起遥控节点，默认速度偏快，建图时压到 0.2 m/s 左右 rosrun teleop_twist_keyboard teleop_twist_keyboard.py _speed:=0.2 _turn:=0.6 # 另开终端看实际下发的速度，确认没有别的节点在抢 /cmd_vel rostopic echo /cmd_vel

_speed 是线速度上限（单位 m/s），_turn 是角速度上限（rad/s）。建图阶段线速度压到 0.15~0.25 之间最稳，角速度压到 0.5~0.8，转得太猛雷达匹配容易丢。按键布局是 u/i/o 走斜向、j/l 原地左右转、m/,/. 后退，按下 k 立刻停车。从按键里有平移分量这一点能看出来，底盘是全向轮组，所以斜向移动是真实平移而不是转向，这对建图时的贴墙走位很有用。

一个容易忽略的细节：终端必须保持焦点。遥控节点读的是标准输入，鼠标点了 RViz 窗口之后按键盘就没反应了，新手经常以为车坏了。另外如果系统开着大写锁定，u/o 会变成平移而不是斜向，行为看起来完全不一样。

下发指令前先确认没有第二个节点在发 /cmd_vel。遥控和导航同时活着，车会抽搐。

3.3 gmapping 从启动到出图的完整动作

封装脚本 1-gmapping.sh 本质上是开多个终端分别 roslaunch，省事但看不到报错。手动拆开跑一遍，出了问题才知道卡在哪：

# 终端 1：底盘 + IMU + 雷达的 bringup roslaunch abot_bringup robot_with_imu.launch # 终端 2：gmapping 建图节点 roslaunch robot_slam gmapping.launch # 终端 3：RViz 可视化，看 /map 与 /scan 叠加效果 roslaunch robot_slam view_mapping.launch # 终端 4：遥控（参数按上一节压速度） rosrun teleop_twist_keyboard teleop_twist_keyboard.py _speed:=0.2 _turn:=0.6

四个终端的启动顺序有讲究：bringup 必须先起，因为 gmapping 订阅 /scan 和 TF，雷达没上线时它会在等 TF 的阻塞状态里反复重试，日志刷屏但不出图。RViz 顺序无所谓，但建议在 gmapping 之后起，否则 Fixed Frame 报错一串。

判断建图是否正常的标准不是“有没有图”，而是三件事：RViz 里 /scan 的红色点云与墙面重合；车走一圈回到起点时，墙线没有错位超过一掌宽；机器人在 RViz 中的位置与实际位置同步变化。第三条最容易被忽略，如果 RViz 里机器人不动而地图在长，说明 TF 里 odom 到 base_link 没通。

建图过程中记录一下初始位置，这一点在导航阶段是刚需。做法很简单：地上贴一条胶带标出车头朝向和轮轴位置，拍张照。后面导航测试时车必须摆回同一个位姿，否则 AMCL 的初始位姿就是错的。

3.4 保存地图与地图文件的核对

建完图别急着关终端，地图只在内存里。保存命令是：

# 保存地图，默认输出 pgm + yaml 到指定目录 roslaunch abot_slam save_map.launch # 核对产物，两个文件必须同时存在且时间戳是刚生成的 ls -lh ~/maps/ head -n 12 ~/maps/*.yaml

yaml 里要重点看四个字段：image 指向的 pgm 文件路径对不对；resolution 是每像素多少米，室内图常见 0.05；origin 是地图左下角在世界坐标系里的位姿，这个值错了导航时整张图会偏移；occupied_thresh 与 free_thresh 决定灰度到占据/空闲的映射阈值，默认 0.65 和 0.196，一般不动。

pgm 文件也要肉眼看一眼，用图片查看器打开，正常的图是黑白分明的轮廓，墙体黑、空地白、未知区域灰。如果整张图是均匀的灰色，说明建图时雷达数据根本没进来，保存下来的是一张空图，后面导航必然失败。

3.5 hector 与 cartographer 的启动差异

hector 的起法最短，因为它不需要里程计：

# hector 建图：一条命令，扫描匹配全靠雷达自己 roslaunch abot_slam hector_mapping.launch # 另开终端看地图 roslaunch abot_slam view_mapping.launch # 遥控照旧 rosrun teleop_twist_keyboard teleop_twist_keyboard.py _speed:=0.15 _turn:=0.5

注意 hector 的速度要压得更低，0.15 左右，转身也要慢。它的位姿估计完全靠前后两帧扫描的匹配，转太快帧间重叠不够，匹配失败后地图会突然“跳”一下，通常表现为墙线错开一大截且再也接不回去。

cartographer 要多起一个 bringup，且必须先有 IMU 和里程计：

roslaunch abot_bringup robot_with_imu.launch roslaunch abot_slam cartographer.launch roslaunch abot_slam view_mapping.launch

cartographer 首次启动要加载 lua 配置，出图比 gmapping 慢几秒，别以为没起来。它的回环检测在绕圈场地很香，但也容易在结构重复的场地（比如两排一模一样的桌椅）误判回环，把地图拽歪。遇到这种情况，先把回环关掉跑一遍看是否正常，再决定要不要开。

三种方式建完图，保存命令都是同一条 roslaunch abot_slam save_map.launch，且保存前不要关闭建图终端——地图节点一退出，栅格数据就没了。

4. 导航链路跑通：从 2D Nav Goal 到轮子真正转动

4.1 导航栈里到底有哪几个节点在干活

跑 2-navigation.sh 之后，后台起来的是一整套 move_base 体系，理解它才能定位问题。map_server 把上一步保存的 pgm/yaml 加载成 /map 话题；amcl 订阅 /scan 与 /map，用粒子滤波估计机器人在图上的位姿，发布 map→odom 的变换；move_base 里分全局规划器与局部规划器，全局用 A* 或 Dijkstra 在静态地图上算路径，局部用 DWA 或 TEB 在局部代价地图里避障；代价地图分三层，静态层来自 /map，障碍层来自实时 /scan，膨胀层在障碍周围加一圈安全半径。

启动命令拆开是这样：

# 终端 1：底盘 bringup roslaunch abot_bringup robot_with_imu.launch # 终端 2：导航核心（move_base + amcl + map_server） roslaunch robot_slam navigation.launch # 终端 3：RViz，加载导航专用配置 roslaunch robot_slam view_nav.launch

三个终端里，第二个最关键。如果 navigation.launch 起来后 RViz 里地图是空的，先在终端里查 /map 有没有发布：

# 确认地图话题存在且有数据（width/height 不为 0） rostopic info /map rostopic echo -n1 /map | head -n 5

4.2 初始位姿：不摆回建图起点就是在给自己挖坑

AMCL 需要知道机器人当前在地图上的大概位置，这个信息由 RViz 里的 2D Pose Estimate 给出。如果车摆的位置和地图对不上，AMCL 的粒子会撒在错误区域，表现为 RViz 里机器人位置乱飘、激光点云和墙线不重合、导航目标发出去车往反方向走。

实操上最稳的做法就是回到建图时的初始位置。3.3 节贴的那条胶带这时候派上用场：轮轴对齐、车头朝向一致，误差控制在一掌以内，AMCL 基本能自己收敛。如果场地已经变了摆不回原位，就得手动给初始位姿——在 RViz 里点 2D Pose Estimate，在地图上按住鼠标拖出朝向，然后让车原地慢慢转一圈（约 360 度），给 AMCL 足够的观测来收敛。

判断收敛的方法是看 RViz 里激光点云是否与地图墙线贴合。贴上了说明位姿可信；如果点云整体偏移一段固定距离，是初始位姿给错了；如果点云一直在抖，是里程计漂移太大或者雷达外参不准。

4.3 从 2D Nav Goal 到轮子转动之间发生了什么

点下 2D Nav Goal 之后，整条链路是：RViz 把目标位姿发到 /move_base_simple/goal；move_base 的全局规划器在静态地图上算出一条路径，发布到 /move_base/NavfnROS/plan；局部规划器结合局部代价地图和当前速度，输出 /cmd_vel；底盘驱动订阅 /cmd_vel，转成轮速。

知道这条链，排查就有了顺序。目标发出去没反应，先看 /move_base_simple/goal 有没有收到；有目标但没路径，看全局规划器报什么（常见是目标点在障碍层里，规划直接失败）；有路径车不动，看 /cmd_vel 有没有输出（有输出但车不动就是底盘侧问题，比如急停没松、驱动掉了）。

# 逐段验证链路 rostopic echo /move_base_simple/goal # 目标是否收到 rostopic echo /move_base/NavfnROS/plan # 全局路径是否生成 rostopic hz /cmd_vel # 速度指令是否下发

4.4 代价地图与几个真正影响结果的参数

导航能不能跑顺，八成取决于代价地图的膨胀参数和速度限制，而不是规划算法选哪个。

inflation_radius 是最值得动手的一个。设小了，规划出的路径贴着墙角走，实车因为车体宽度直接蹭上去；设大了，窄通道被判成不可通行，全局规划直接失败，RViz 里表现为“点哪儿都不规划”。经验值是车体半宽加上 0.15~0.2 的安全余量。

xy_goal_tolerance 和 yaw_goal_tolerance 这两个也常被忽略。调得太小，车到点附近会反复前后微调，看起来像抽风；调大到 0.15 米左右，到点判定干脆利落。

4.5 导航失败时的判断顺序

遇到车不动，按这个顺序走，比乱改参数快得多。第一步看 RViz 里机器人位姿是否与实车一致，不一致就先解决定位，别碰规划器。第二步看全局路径有没有生成，无路径说明目标点不可达或代价地图把它判成障碍。第三步看局部路径，全局有路径但局部规划失败，通常是被临时障碍困住，可以清空代价地图重试。第四步才去看 /cmd_vel，有指令但轮子不动就是底盘侧的问题。

清空代价地图这个动作很实用，RViz 的 Publish Point 旁边的 Clear costmap 按钮就是干这个的。雷达偶尔扫到一次动态障碍（走过的人），障碍层会把它记住一段时间，车就卡在原地不动，清一下立刻恢复。

5. 避坑与排查：五个把建图导航搞崩的血泪现场

5.1 地图糊成一片，墙线像被泼了墨

现象：建图跑了两分钟，RViz 里墙线开始重影，越走越糊，最后整张图变成一片黑灰，完全没法用。

原因：轮式里程计打滑或者雷达外参被碰过。麦轮底盘在光滑瓷砖上的打滑量很可观，gmapping 把错误的运动先验和正确的观测硬凑，粒子就散了。另一个常见原因是雷达在搬运时被碰歪，TF 里的 laser 位姿和实际安装角度差了几度。

解决：换到有纹理的地面（地毯、防滑垫）或者把速度压到 0.15 以下重跑；用卷尺量一下雷达到车体中心的实际 x/y/偏航，和 URDF 里的值比对，偏差超过 2 度就重新标定；实在压不住，改用 hector 或 cartographer，它们对里程计依赖更弱。

5.2 遥控按了没反应，或者车走的方向和按键对不上

现象：终端里回车确认了，按 u 车不动；或者按 u 车往右前方走，和预期完全相反。

原因：三种情况。一是终端焦点被 RViz 抢走，按键根本没进到遥控节点；二是系统开了大写锁定，u/o 的行为从斜向变成平移；三是底盘驱动的转向符号与 teleop 的约定相反，正角速度对应左转但实际右转。

解决：先用 rostopic echo /cmd_vel 看按键时有没有数据出来，没数据就是焦点问题，点回终端窗口；再检查大写锁定指示灯；如果 /cmd_vel 有数据但车反向，改底盘驱动里的符号或者用 teleop 的 _turn 参数之外单独做一层符号翻转，不要直接改 URDF。

5.3 导航目标发出去了，车原地打转或者往反方向冲

现象：2D Nav Goal 点在地图空地上，车开始原地转圈，转完还是不动；或者直接朝目标反方向全速冲出去。

原因：AMCL 初始位姿错了，或者 TF 里 map→odom 的变换方向反了。原地打转是典型特征——局部规划器认为目标在身后，但全局路径又指向前面，两个约束打架。往反方向冲更严重，通常是地图的 origin 参数与实际世界坐标不一致。

解决：先在 RViz 里看激光点云和墙线是否重合，不重合就重新给 2D Pose Estimate，让车原地转一圈收敛；检查保存的 yaml 里 origin 字段，和建图时的起始位姿对比；把车摆回建图起点重试一次，这一步能排掉八成定位问题。

5.4 相机、语音、射击模块的 launch 报错或者没声音

现象：roslaunch usb_cam usb_cam_test.launch 报设备忙；语音节点起了但耳机里没声；射击模块通电了但不发射。

原因：相机被上一次没退干净的进程占着，/dev/video0 只有一个；语音走蓝牙，连接成功但没切到 A2DP 输出，或者 roscore 没起；射击模块是独立供电，电源开关没开，水弹没泡够时间直接卡弹。

解决：ps aux | grep usb_cam 杀掉残留进程再起；语音先确认 roscore 在跑，蓝牙耳机连上后在声音设置里手动选输出设备，再发 /voiceWords；射击前把水弹在矿泉水里泡足 8 小时以上，模块电源开关打开，测试时枪口不要对人。

5.5 保存地图命令执行了，但目录里没有新文件

现象：roslaunch abot_slam save_map.launch 回车后终端很快返回，ls 看目录还是旧文件。

原因：建图节点已经被关掉了，map_server 里没有可供保存的栅格；或者保存路径写死在一个不存在的目录，launch 静默失败。

解决：保存前不要关建图终端，确认 RViz 里地图还在显示；用 rosmaster 里查一下有没有 map 相关节点活着；检查 save_map.launch 里的 map_file 路径，目录不存在就先 mkdir -p 建出来。养成习惯：跑通一次就立刻保存一份，别指望一会儿再存。

6. 视觉、语音与射击模块联调：一份可复用的验收清单

外设这三块单独看都不复杂，凑在一起时最容易出现“单独测都正常，合起来就抢资源”的情况。我的做法是每次赛前按固定顺序过一遍，顺序不能乱，因为涉及设备节点占用和音频输出切换。

视觉先测，是因为相机占用 /dev/video0，且 rqt_image_view 会开一个图像窗口，远程桌面带宽压力最大的就是它，先确认在这套网络下能用。命令层面：

# 起相机测试节点，确认设备没被占用 roslaunch usb_cam usb_cam_test.launch # 另开终端看图像，选 /usb_cam/image_raw 话题 rosrun rqt_image_view rqt_image_view # 相机反复报 device busy 时，先清残留进程 ps aux | grep -E "usb_cam|image_view"

语音测的是音频链路而不是 TTS 本身。蓝牙耳机连上后一定要在系统声音设置里确认输出设备已经切过去，很多人卡在这一步，节点日志显示播报成功但耳机没声。

# 先起 roscore，语音节点依赖它 roscore # 另开终端起语音订阅节点 rosrun robot_voice tts_subscribe # 再开一个终端发一条测试文本 rostopic pub /voiceWords std_msgs/String "data: '1234'"

射击模块单独供电，测之前把电源开关打开，水弹泡够时间。命令是先起驱动再发一条空字符串触发：

roslaunch abot_bringup shoot.launch rostopic pub /shoot std_msgs/String "data: ''"

这一步我一般放在最后，因为它最容易出意外，枪口方向必须先确认，周围不要站人和放贵重物品。

整套流程跑下来大约二十分钟，比在赛场上临时排查省得多。有一次我在场地里直接改 gmapping 参数，改完忘了保存地图就关终端，一晚上的图全没了，第二天重新建。从那以后我每次建完图都强制先跑一遍 save_map、用图片查看器打开 pgm 确认墙线清晰，再动导航。这个习惯看着笨，但救过不止一次场。希望帮到你。

本文还有配套的精品资源，点击获取