面向地面移动机器人的自主巡航系统。项目围绕一个受限围栏场地中的实体机器人任务展开：机器人需要完成语音启动、任务信息识别、目标点自主导航、到点播报、终点收束等流程，并在随机挡板、短路径、多目标点和时间限制下保持稳定运行。
这个项目不是一个只在仿真或屏幕中完成识别的算法 demo，而是一次完整的实车系统集成：激光雷达、IMU、里程计、摄像头、语音交互、局部规划、地图定位和任务状态机都需要在同一条链路里协同工作。项目的核心目标不是堆模型，而是让机器人在物理世界里可控、可复现、可解释地完成任务。
任务场景可以抽象为一个小尺度、高约束的地面自主巡航问题：
- 机器人在约 3.6m x 3.6m 的围栏场地内运行；
- 场地内存在多个目标区域和随机挡板；
- 机器人需要读取若干任务信息，并导航到对应目标点；
- 到达识别点、任务点和终点时需要语音播报；
- 运行过程中需要避免碰撞围挡或挡板；
- 整体流程有明确时间约束，不能因为局部失败卡死全局任务。
因此，这个项目同时考验导航稳定性、感知可靠性、任务编排能力和实车调试能力。很多问题并不是单个算法参数能解决的，而是需要在速度、精度、安全边界和任务节奏之间做工程取舍。
- 机器人底盘启动与传感器接入；
- 基于 ROS Navigation Stack 的地图定位与目标点导航；
- DWA 局部规划参数调优；
- 多模式导航参数切换：普通行驶、识别点、任务点精停、终点精停；
- 视觉任务信息识别，结合 OCR/VLM 结果进行任务点解析；
- 识别失败安全返回，避免错误播报和跑错目标点；
- 任务点二阶段导航：先到预到达点，再低速精停；
- 识别点接近即接受，减少不必要的反复微调；
- 识别前 yaw 快速对准，提高摄像头视野命中率；
- 局部最优恢复逻辑，限制在长距离导航途中触发；
- 语音播报与 TTS 服务集成；
- 一键启动脚本，按顺序拉起底盘、导航、视觉、语音和任务节点。
EmbodiedNav-GroundCruise
├── start_ground_cruise.sh # 一键启动脚本
├── src
│ ├── abot_base # 底盘、IMU、模型与雷达滤波
│ ├── robot_slam # 建图、定位、导航、任务状态机
│ ├── abot_vlm # 任务信息识别与视觉语言服务
│ ├── ocr_detect # OCR 识别相关脚本与资源
│ ├── track_tag # 摄像头与标记跟踪
│ ├── TTS_audio # 语音合成服务
│ └── nav_command # 导航指令消息
└── README.md
运行链路大致如下：
语音启动
-> 底盘/IMU/雷达/摄像头启动
-> 地图定位与 move_base 导航
-> 依次前往任务信息识别点
-> OCR/VLM 解析目标点
-> 按识别结果执行任务点导航
-> 到点语音播报
-> 终点精停并结束流程
早期尝试过更复杂的局部规划方案，但在窄场地、短路径、密集挡板和多目标点的实车任务里，轨迹优化类方法对障碍代价、时间参数和局部环境更敏感，容易出现犹豫、贴障或局部不稳定。
最终项目选择以 DWA 为主线：局部采样更直接，参数含义更清晰，实车调试成本更低。这个选择不是“理论最优”，而是面向实体机器人任务的稳定性优先。
调车过程中一个重要转折是意识到：所有目标点不应该使用同一套导航要求。
识别点的目标是让摄像头看到任务信息，不需要像任务点一样精确进框；任务点和终点则需要低速、稳定、可控地进入目标区域。于是系统引入了不同导航模式：
- 普通行驶：保证节奏；
- 识别点：允许更宽的位置和角度容差；
- 任务点：二阶段导航和精停；
- 终点：预到达点加低速闭环收束。
这个改动让系统从“每个点都慢慢磨”变成了“不同动作使用不同控制策略”。
直接导航到任务点时，机器人容易在最后几十厘米出现角度偏差或进框不准。项目改为先到任务点附近，再切换低速精停参数进入最终点位。
这个方案把“快速接近”和“精确到达”拆开，降低了单次导航目标对局部规划器的压力，也更符合实车落点控制的需求。
一开始线索编号按识别成功次数递增：如果第一个识别点失败，后续识别结果会整体前移，导致任务点顺序错乱。
后来改为按物理识别点固定槽位保存结果：
clue_results_by_slot = [None, None, None, None]
识别失败的槽位保留为空，不影响后续线索编号。最终只执行识别成功的任务点，失败项跳过，流程仍然尝试完成终点任务。
面对挡板时，机器人曾出现原地犹豫、不再向目标推进的问题。系统加入了朝地图中心方向小步恢复的逻辑，并通过 /move_base/make_plan 判断是否可以回到原目标。
但恢复逻辑一开始过于泛化，在接近目标点时也可能触发，反而干扰精停和识别。最终策略是严格限制恢复逻辑：
- 只在长距离前往目标途中启用；
- 接近目标后禁用；
- 不用于识别点和精停点附近的微调。
这让我对实车系统有了一个很直接的认识：恢复机制不是越多越好，触发边界比机制本身更重要。
项目中出现过撞挡板、擦碰挡板、避障变稳后速度明显下降等阶段。最后的处理不是简单把速度压低，而是同时调整：
- footprint；
- inflation；
- DWA 障碍物代价；
- 横向速度限制；
- 识别点专用速度和容差；
- 雷达/过滤后的障碍物可见性。
这部分调试让我真正理解到，导航稳定性不是某一个参数的结果，而是感知、代价地图、局部规划和任务节奏共同作用的结果。
这个项目最有价值的部分不是一开始就写出了一个完美系统，而是不断从实车失败里把问题拆开。
一开始，我更关注“是不是用了更高级的算法”。后来发现，实体机器人不会因为算法名字高级就跑得更稳。它只关心当前地图、当前挡板、当前速度、当前传感器能不能支撑这一段动作。于是我开始用实车效果反推方案：DWA 比 TEB 稳，就选择 DWA；识别点不需要精停，就放宽识别点；任务点容易进框不准，就做二阶段导航。
后面的问题越来越像系统工程：识别失败不能让后续线索错位，脱困不能干扰精停，安全边界不能让速度完全丢失，旧 build/devel 缓存不能带着错误路径上车。每一次调车都不是孤立地修一个 bug，而是在学习如何让一个真实机器人系统更可靠。
这段过程让我从“能把节点跑起来”逐步进入到“能解释机器人为什么这样动、为什么卡住、为什么要这么调”的阶段。对我来说，这正是具身智能项目最重要的训练：让感知、决策和运动控制在真实物理环境里闭环。
以下流程假设已经在机器人端安装 ROS Melodic，并完成底盘、雷达、相机、IMU 等硬件驱动环境配置。
cd ~/EmbodiedNav-GroundCruise
catkin_make
source devel/setup.bash
bash start_ground_cruise.sh启动脚本会依次拉起：
roscore- 底盘与 IMU
- 导航与定位
- 相机与标记跟踪
- 视觉识别服务
- TTS 语音服务
- 多目标点任务节点
- 语音启动节点
- RViz 可视化
仓库不会提交真实密钥和本地运行配置。首次部署时需要根据示例文件创建本地配置：
cp src/abot_vlm/scripts/API_KEY.example.py src/abot_vlm/scripts/API_KEY.py
cp src/TTS_audio/scripts/TTS_local.example.py src/TTS_audio/scripts/TTS_local.py然后在本地文件中填入对应服务的密钥。API_KEY.py 和 TTS_local.py 已加入 .gitignore，不会进入云仓库。
- 不要提交或复用旧的
build/和devel/； - 将工作空间复制到机器人后，建议重新执行
catkin_make； - 地图、点位和导航参数强依赖实车环境，换场地后需要重新检查；
- 如果导航变慢，优先区分是避障安全边界过保守，还是识别点精度要求过高；
- 如果识别失败，不应阻塞全局任务流程，应保留安全返回和跳过机制。
ROS Melodic, Catkin, move_base, DWA, AMCL, SLAM, Costmap, LiDAR, IMU, Odometry, OCR, Vision-Language Model, TTS, Multi-goal Navigation, Recovery Behavior, Real-robot Tuning
EmbodiedNav-GroundCruise 是一个面向实体移动机器人的自主巡航系统项目。它的价值不只在于完成导航和识别功能，更在于把算法选择、参数调优、感知失败、局部恢复、任务状态机和实车部署统一到一个可运行的工程系统里。