中国机器人竞赛的技术栈这几年变化很快。前几年大家还在纠结底盘选型和舵机控制现在的主流做法已经变成“ROS2 做中间件、仿真平台先跑通、导航栈直接复现、视觉和遥操作做上层应用”。如果你要带队参加机器人竞赛或者准备做工业机器人预研这篇博客可以帮你在半天内把整套本地开发环境搭起来并跑通建图、导航、避障和任务响应这四个核心动作。这里的重点不是某一款机器人而是一套可复用的开发链路环境怎么准备、仿真怎么启动、导航参数怎么调、四个轮子和四足平台在接口上有什么差异、进度卡住时怎么排查。全文按“环境准备-部署启动-功能测试-接口调用-性能观察-问题排查”的顺序展开所有命令都是通用模板实际路径和型号需要按你的开发板或竞赛平台替换。1. 核心能力速览先给结论。这套技术栈并不是单一开源项目而是竞赛机器人开发中最常用的一组组件组合你可以在项目里按需裁剪。技术模块常见方案硬件门槛启动方式主要作用中间件ROS2 Humble / Foxy4 核 CPU、8G 内存命令行启动节点通信、话题订阅、任务调度仿真平台Gazebo / Webots / Isaac Sim独显或不独显均可命令行启动建图、导航、视觉算法验证导航栈Nav2建议 4G 以上显存命令或 launch 文件全局规划、局部避障、路径跟踪定位AMCL / 卡尔曼滤波 / RTKCPU 即可节点启动机器人位置估计视觉感知OpenCV YOLO 系列CPU 可跑GPU 更稳Python 脚本目标检测、视觉引导运动控制底盘 SDK / 四足 SDK取决于硬件原生接口前进后退、转向、步态切换遥操作WebRTC / 游戏手柄 / VR需要额外设备浏览器或客户端远程接管、人工介入批量任务launch 文件 Python 脚本无特殊要求脚本批量执行多场景自动跑测试从材料看当前机器人竞赛相关的热词集中在四足机器人、人形机器人、视觉引导、资源受限机器人、仿真平台选型这几个方向。也就是说竞赛的考察点已经从“能不能动”升级成“能不能感知、能不能规划、能不能在有限资源下稳定运行”。2. 适用场景与使用边界这套技术栈适合三类人第一类是参加机器人竞赛的队伍。比赛通常要求机器人在未知环境里自动导航、避障、识别目标并完成指定动作ROS2 Nav2 视觉方案是应对这类任务的通用组合。第二类是做工业机器人预研的工程师。ABB、KUKA、发那科等工业机器人在产线里的动作逻辑和竞赛机器人的状态机在思路上是相通的先感知再规划最后执行。区别只是工业场景更强调安全互锁和重复定位精度。热词里出现的“ABB机器人怎么优化条件等待卡顿”“发那科机器人干涉区DI信号触发时反应”本质上都是任务调度的边界条件问题在 ROS2 里对应的是生命周期节点和状态机设计。第三类是搞移动机器人算法研究的学生。仿真平台可以在没有实体机器人的情况下先验证 SLAM 和导航算法降低开发门槛。使用边界也要讲清楚不要在公开赛场外使用摄像头采集未授权的人脸数据。视觉感知模块只能处理合规获取的视觉素材。机器人遥控和遥操作必须限定在测试场地内远程接管时要有人工确认机制避免失控。工业机器人调试时干涉区和急停信号必须保留硬件优先级软件层不能覆盖。仿真平台训练出来的模型在真实环境里会有 sim-to-real 差距不能直接批量部署到产线。3. 本地开发环境准备在装任何机器人框架之前先把基础环境确认一遍。这里不会写死版本号但会给你一套通用检查流程。3.1 操作系统与资源检查ROS2 对 Linux 支持最好如果你是 Windows 环境建议用 WSL2 或者虚拟机。先确认 CPU 和内存够不够# 查看 CPU 核心数和内存 nproc free -h # 查看磁盘剩余空间 df -h / # 查看 GPU 信息 nvidia-smi如果你要在本地跑 Gazebo 仿真内存建议 8G 以上如果还要训练或推理视觉模型建议有 NVIDIA 显卡显存 4G 以上。没有独显也能跑只是视觉推理会慢一些纯 CPU 跑 YOLO 检测单帧可能要几百毫秒到秒级具体要按模型和分辨率实测。3.2 安装 ROS2ROS2 的安装尽量用官方源不要混合多个发行版的软件源否则依赖会乱。# Ubuntu 22.04 安装 ROS2 Humble 的通用步骤 sudo apt update sudo apt install -y \ ros-humble-desktop \ python3-colcon-common-extensions \ ros-humble-navigation2 \ ros-humble-nav2-bringup \ ros-humble-gazebo-ros-pkgs # 配置环境变量 echo source /opt/ros/humble/setup.bash ~/.bashrc source ~/.bashrc如果你用的是 Ubuntu 20.04对应版本是 FoxyUbuntu 24.04 对应 Jazzy。具体版本要按你的系统选择和官方支持矩阵确认。3.3 Python 与开发工具视觉和任务脚本建议用 Python 3.8 以上版本并创建独立虚拟环境python3 -m venv ~/robot_dev_venv source ~/robot_dev_venv/bin/activate pip install numpy opencv-python torch torchvision \ transforms3d pyserial pymodbus注意这里不要和系统自带的 ROS2 Python 环境混在一起。ROS2 节点用系统 Python视觉脚本可以走虚拟环境通过 ROS2 话题进行数据交换。硬混在一起容易出现symbol already defined或者版本冲突。4. 机器人竞赛开发环境部署环境准备好之后开始部署开发环境。这里包括仿真平台、导航栈以及一个最简单的机器人模型。4.1 创建 ROS2 工作空间先用colcon创建自己的工作空间mkdir -p ~/robot_ws/src cd ~/robot_ws/ colcon build source install/setup.bash以后每次新增功能包都在src目录下创建包cd ~/robot_ws/src ros2 pkg create my_robot_bringup --build-type ament_python4.2 启动 Gazebo 仿真环境仿真平台的选择没有绝对标准快速验证用 Gazebo视觉和强化学习可以用 Isaac Sim 或 Webots。Gazebo 的优势是 ROS2 对接成熟启动一条命令就能带上机器人和环境# 启动空世界后续再加载机器人 ros2 launch gazebo_ros gazebo.launch.py world:worlds/empty.world启动后可以用ros2 topic list验证节点通信是否正常ros2 topic list # 预期看到/clock /gazebo/link_states /rosout 等话题如果你有实体机器人也可以在这个阶段通过底盘 SDK 启动一个base_driver节点把电机数据发布成 ROS2 话题。这样仿真和实车共用一套上层导航代码后续切换成本最低。4.3 一键启动整个机器人假设你的机器人包带有了 launch 文件可以这样启动ros2 launch my_robot_bringup robot_sim.launch.py \ use_sim_time:true \ map_file:maps/training_map.yaml这段命令启动后应该能看到以下节点/robot_base底盘驱动或仿真底盘/lidar激光雷达数据发布节点仿真里是gazebo发布/map_server地图服务/amcl定位节点/bt_navigator导航行为树如果你的平台没有雷达也可以仅用视觉或轮式里程计做导航但室内竞赛场景里激光雷达在稳定性和精度上依旧是最优先选项。5. 机器人导航功能测试导航是整个竞赛机器人开发里最容易出问题、也最值得反复验证的部分。下面按测试目标拆开讲。5.1 SLAM 建图测试在未知赛场环境中一般先手动遥控机器人走一圈生成环境地图。常用的方式是slam_toolbox。# 启动 SLAM 建图 ros2 launch my_robot_nav slam_toolbox_launch.py use_sim_time:true # 启动遥控节点用手柄或键盘控制机器人移动 ros2 run teleop_twist_keyboard teleop_twist_keyboard操作建议速度先调到 0.2m/s 以下。建图过程保持匀速避免频繁原地旋转否则激光匹配容易漂移。建图完成后保存地图ros2 run nav2_map_server map_saver_cli -f maps/training_map保存后确认目录下出现training_map.pgm和training_map.yaml两个文件。地图文件需要在后续导航启动时使用如果文件缺失或者大小为 0导航无法启动。5.2 Nav2 导航启动测试导航栈启动后主要验证三个能力全局路径规划、局部避障、到达目标点。ros2 launch my_robot_nav navigation_launch.py use_sim_time:true map:maps/training_map.yaml在 RViz 里点击“2D Goal Pose”给机器人一个目标点观察机器人是否规划出路径并执行。判断成功的标准机器人能生成从起点到终点的全局路径。机器人实际运动轨迹没有穿过障碍物。到达目标点后状态变为“Succeeded”。终端日志里不出现Cannot find a valid path或PathPlanning failed之类错误。如果路径规划失败优先检查 costmap 参数中的 footprint 半径是否大于机器人实际半径以及地图文件路径是否有效。5.3 避障与重规划测试在 Gazebo 仿真环境里人为添加几个圆柱体或箱子障碍物再次发送目标点观察机器人是否能在遇到障碍物时重新规划局部路径。操作步骤# 在仿真环境中摆放障碍物 ros2 run gazebo_ros spawn_entity.py \ -entity obstacle_box \ -file obstacles/box.sdf \ -x 1.5 -y 1.0 -z 0.1导航过程中如果局部代价地图的膨胀半径设置得太小机器人容易贴着障碍物走存在碰撞风险设置得太大窄通道就过不去。调整inflation_radius参数时要反复试# costmap_common_params.yaml 中的局部代价地图参数 robot_radius: 0.20 inflation_layer: inflation_radius: 0.55从实践经验看先设一个偏大的膨胀半径确认安全再逐步收窄寻找通过能力。不要一开始就追求极限贴边通过。5.4 定位精度验证机器人导航不是每一次都从同一起点出发AMCL 定位节点要能在运行中修正里程计漂移。测试方法启动导航 launch让机器人停在已知位置。手动给一个初始位姿估计2D Pose Estimate。反复发送目标点记录导航起点和目标点的误差。在机器人运动一段距离后先不动观察/amcl_pose是否稳定。如果定位误差持续增大需要检查里程计发布频率是否够高。激光雷达是否固定牢固有无抖动。地图本身是否有闭环回环位置是否对齐。环境特征是否足够丰富长走廊和空旷场地的 AMCL 效果会差很多。热词里的“机器人定位”在竞赛中通常是失分重灾区多花时间做定位鲁棒性测试比调高最大速度更划算。6. 四足与人形机器人的开发要点竞赛里四足机器人和人形机器人的出现频率越来越高热词里也有“四足机器人”“宇树机器人”“pico4遥操宇树机器人”“人形机器人”等方向。这类平台的开发和轮式机器人有明显区别。6.1 硬件接口与 SDK四足和人形平台一般都会提供自己的 SDK常见接口包括电机控制接口控制关节角度、速度、力矩。状态反馈接口机体姿态、足端力、电压电流。外部通信接口通过 Ethernet、CAN 或 ROS2 与主控连接。遥控协议手柄、手机 App 或 VR 设备。拿到平台后第一步不是跑导航而是先通 SDK。确认能读取到关节状态、姿态角能控制机器人站立和走几步。如果这个链路不稳定后续所有上层算法都无法开展。6.2 运动控制与步态切换四足机器人运动控制的关键点是步态切换。静止站立、小跑步、跨越步态、转向步态的切换要顺滑不能出现瞬间断电一样的姿态突变。应用层建议把所有步态封装成统一的服务接口比如walk_to(x, y, yaw)、stand_up()、sit_down()。上层视觉和导航代码不需要关心底层关节控制细节只需要调用接口。# 示例调用步态控制服务按实际 SDK 调整 ros2 service call /gait_control my_robot_msgs/srv/GaitControl \ {command: walk, target_x: 1.0, target_y: 0.0, target_yaw: 1.57}6.3 视觉引导竞赛场地里的目标识别通常用 YOLO 系列。典型流程相机采集图像。YOLO 检测目标并输出目标类别和像素坐标。通过相机内参和外参将像素坐标转换为机器人坐标系坐标。导航到目标附近。机械臂或执行机构完成抓取、击打或按压动作。在资源受限机器人上建议降低输入分辨率、减少模型通道数、用 TensorRT 或 ONNX 加速。不要追求高精度大模型帧率稳定比单帧精度更重要。一个只跑 5FPS 的检测模型在实际导航里会因为反应延迟而频繁错过目标一个 15FPS 的轻量模型反而好控制。6.4 遥操作与安全接管比赛过程中如果机器人卡在墙角或目标识别混乱人工接管是最后的兜底手段。热词里提到的“pico4遥操宇树机器人”说明 VR 遥操作已经进入竞赛实验阶段但低成本方案依然是游戏手柄或网页端 WebRTC。开发时要保证一条核心原则人工接管优先级最高任何自动导航指令在接管后都必须立即失效。7. 接口 API 与批量任务机器人系统不是单机脚本竞赛和工业场景都会用到服务接口。ROS2 本身就提供了服务调用和动作通信机制下面给一段通用示例。7.1 通过 Python 调用导航目标import rclpy from rclpy.node import Node from geometry_msgs.msg import PoseStamped, Quaternion from nav2_msgs.action import NavigateToPose from rclpy.action import ActionClient import math class NavClient(Node): def __init__(self): super().__init__(nav_client) self._client ActionClient(self, NavigateToPose, navigate_to_pose) def send_goal(self, x, y, yaw): goal_msg NavigateToPose.Goal() goal_msg.pose.header.frame_id map goal_msg.pose.header.stamp self.get_clock().now().to_msg() goal_msg.pose.pose.position.x x goal_msg.pose.pose.position.y y q Quaternion() q.z math.sin(yaw / 2.0) q.w math.cos(yaw / 2.0) goal_msg.pose.pose.orientation q self._client.wait_for_server() future self._client.send_goal_async(goal_msg) future.add_done_callback(self.goal_response_callback) def main(): rclpy.init() node NavClient() node.send_goal(2.0, 1.5, 0.0) rclpy.spin(node) node.destroy_node() rclpy.shutdown()启动前确认导航节点已运行并且地图已加载。调用失败时可以先查看/navigate_to_pose/_action/status话题确认 action server 状态。7.2 批量测试任务竞赛前需要批量验证不同起终点组合下的导航成功率。建议写一个 Python 脚本把测试点组合做成 JSON 文件然后循环调用上文的导航客户端每次调用后等待固定超时时间记录成功或失败。{ test_cases: [ { start: [0.0, 0.0, 0.0], goal: [2.0, 1.5, 1.57], timeout: 30 }, { start: [0.0, 0.0, 0.0], goal: [-2.0, -1.5, 0.0], timeout: 30 } ] }发现连续失败时不要只调导航参数先回放录制的 bag 包确认失败原因是定位漂移、路径规划失败还是执行端电机响应延迟。定位问题只能在建图和初始位姿上找执行问题才去调底盘 PID。8. 资源占用与性能观察竞赛开发中一个常见误区是只在实机上调试不做资源预算。实际环境中机器人主控可能是 Jetson Orin、树莓派或者一台功耗受限的小主机计算资源非常紧张。建议这样观察资源占用# 实时查看 CPU、内存占用 htop # 查看机器人各节点资源排序 ps aux --sort-%cpu | head -20 # 查看 GPU 显存和占用 nvidia-smi -l 2 # 查看话题发布频率 ros2 topic hz /scan ros2 topic hz /odom重点观察/scan和/odom两个话题的频率。激光雷达话题频率掉到 5Hz 以下导航的实时性会明显变差里程计话题频率不稳定定位和路径跟踪都会出问题。降低资源占用的手段降低激光雷达话题发布频率从 20Hz 降到 10Hz不影响中低速导航。视觉推理优先用 TensorRT/ONNX而不是直接在 PyTorch 里跑。地图分辨率不要盲目调高5cm/pixel 在大多数竞赛场地足够。关闭控制台日志输出等级减少磁盘和 CPU 负担export RCLCPP_LOG_LEVELWARN在 Gazebo 仿真里如果 CPU 占用过高可以适当减少模型的多边形数、降低物理引擎更新频率。不过要注意仿真速度太慢会掩盖真实机器人的时序问题建议仿真跑出结果后至少做一次实机低功耗验证。9. 常见问题与排查方法问题现象可能原因排查方式解决方案ROS2 节点启动后没有话题环境变量未 source运行ros2 topic list查看是否为空重新source install/setup.bashGazebo 仿真启动后锁死CPU 不足或模型太复杂查看htop占用简化模型、降低物理引擎频率导航规划失败costmap 参数错误或地图损坏查看日志是否有PathPlanning failed调整 footprint、膨胀半径定位漂移激光雷达扫描异常、里程计不准查看/amcl_pose和/odom对比检查雷达安装、标定里程计视觉检测卡顿模型过大、推理在后端太慢查看 GPU 和 CPU 占用用轻量模型、TensorRT 加速机器人撞到障碍物局部避障失效或传感器数据不可信查看 costmap 中障碍物是否叠加调小最小速度、增大膨胀半径批量导航任务卡住action 超时设置过长查看 action 状态话题设置合理超时并增加失败重试手柄遥控失效数据线或蓝牙断连查看teleop_twist_keyboard日志优先使用有线连接电机响应抖动供电不足或 PID 参数不合适查看电机电流反馈降低加减速度、检查电池电压仿真与实车行为不一致sim-to-real 差距对比相同参数下的轨迹分步迁移先验证底盘再叠加导航最容易忽略的问题其实是供电。四足和人形机器人在高负载运动中瞬时电流很大如果供电不足SDK 里的电机控制会出现随机重启或位置回跳表现形式很像是软件 bug。排查时优先看电池电压和稳压模块输出不要一上来就调导航参数。10. 最佳实践与使用建议把这几年竞赛和工业机器人开发里值得沉淀的做法整理成清单。版本管理优先。整个工作空间从第一天就纳入 Git 管理launch 文件、参数文件、地图文件分目录存放。地图属于竞赛环境建议单独用 Git LFS 管理避免仓库膨胀。保留一套最小可运行配置。在src里独立维护一个robot_minimal包只包含底盘驱动、激光雷达驱动和键盘遥控三个节点。以后任何改动出了问题先回到这套配置确认硬件链路正常再逐步叠加功能。小参数测试先行。第一次测试导航时速度设置为 0.1m/s膨胀半径偏大目标距离不超过 2 米。整套链路跑通后再逐步提高速度最后才到比赛场地考真实性能。批量任务必须加日志和重试。批量导航脚本每次运行都写 JSON 日志记录时间戳、目标点、路径规划耗时、到达时间。失败时自动重试 2 次重试仍失败则跳过避免卡死在单个用例上。竞速不是唯一目标。很多时候机器人稳定跑完 3 个任务比高速但中途卡死 5 次要更值得。不要为了节省几秒去调激进的速度参数先把成功率稳定在 90% 以上。合规和安全边界不能省。视觉模块采集的数据只用于测试环境如果涉及人脸或声音数据必须提前确认授权范围。机器人遥控演练要在隔离场地进行。工业级调试时传感器和安全继电器信号必须保持硬件接线优先级或者明确验证过软件互锁的响应时间符合现场安全要求后才能调整。11. 总结与下一步中国机器人竞赛能接触到的技术密度很高但这套技术栈的核心并不神秘先建图再定位然后规划路径最后执行动作。四足、人形、工业机械臂的底层逻辑都一样只是关节数量和执行方式不同。最先应该验证的能力是“建图 导航闭环”。如果在没有实机的情况下先在 Gazebo 里手动遥控一段保存地图然后下发目标点让机器人自己跑通这套闭环就意味着你已经掌握了机器人竞赛里最核心的工程能力。最容易踩的坑集中在三个地方ROS2 环境变量没 source 导致节点通信失败、地图文件路径配错导致导航无法启动、供电不足导致的电机随机响应异常。遇到问题时先确认最小链路再逐步排除上层算法不要一上来就动参数。下一步可以考虑扩展的方向是视觉导航融合。当前大多数竞赛队伍还是激光雷达导航为主视觉主要做目标识别。如果你能把视觉检测结果作为动态目标点直接送到 Nav2机器人就能在识别到目标后自动切换导航目标这是很多队伍还没做好的能力也是提升比赛成绩最明显的切入点。这套开发链路建议先收藏备用。等拿到比赛机器人的 SDK 之后直接按本文第 3 节到第 5 节走一遍半天内可以把基础环境跑通剩下的时间全部留给导航参数和任务逻辑打磨。