ROS2 与 TurtleBot3 学习实操记录学习目标为机器人测试岗位打基础能建立仿真环境、观察机器人通信与传感器数据、控制机器人并留存可用于定位问题的证据。本文只记录本人已经完成的 ROS2 学习和实操。目前已完成 SLAM 建图、地图保存与加载、AMCL 定位和 Nav2 基础到点导航故障注入、指标自动采集和自动化报告仍未完成不将其写成已掌握。1. 当前学习路线ROS2 基础 - TurtleBot3 / Gazebo 仿真 - AGV 建图、定位、导航测试 - 故障注入与排障 - pytest 指标采集与测试报告当前进度已完成 ROS2 基础、TurtleBot3/Gazebo、SLAM 建图、AMCL 定位和 Nav2 基础导航正在进入导航测试用例、故障恢复与指标采集。2. 实际环境项目实际使用内容主机Windows WSL2LinuxUbuntu 24.04 LTSLinux 用户yjwROS2ROS 2 Jazzy Desktop仿真机器人TurtleBot3 Burger仿真平台Gazebo可视化RViz2、rqt_graph证据工具ros2 bag、终端日志、话题数据、截图已完成rosdep update。它用于根据 ROS 包的依赖声明安装系统依赖后续编译或安装源码包时会用到。3. 已理解的 ROS2 核心概念3.1 Node、Topic、Service、Action、Parameter概念一句话理解机器人示例Node执行具体工作的程序单元激光雷达驱动节点读取雷达并发布数据Topic持续传输消息的数据通道/scan持续发布激光扫描/cmd_vel持续接收速度指令Service一问一答的请求/响应接口查询一次当前参数或请求一次状态Action耗时任务支持目标、过程反馈、最终结果“导航到目标点”过程中反馈距离和状态最后返回成功或失败Parameter节点可查询或调整的配置值最大速度、地图路径、雷达配置记忆方法Node 谁在干活 Topic 连续广播的数据通道 Service 问一次答一次 Action 下达一个耗时任务持续汇报最后交结果 Parameter 节点的配置项已能纠正以下常见混淆/scan是Topic不是 Service。雷达持续发布扫描数据。“导航到目标点”更适合Action不能只靠 Topic因为任务耗时且需要反馈、取消和结果。激光雷达 Node 负责读取和处理硬件数据/scanTopic 负责传输扫描消息。查询一次配置参数应使用 Parameter 命令或相关 Service不是 Action。3.2 TF 的作用TF 是机器人各坐标系之间的位置和姿态关系。例如odom、base_link、laser。测试时TF 用来判断“雷达数据、机器人本体、里程计数据是否处在正确的空间关系中”。TF 缺失、断链、时间不一致都可能造成 RViz 显示异常、定位异常或导航失败。本次曾用静态 TF 做学习示例。该静态 TF 只用于理解命令和坐标变换不能当作真实机器人已完成建图或定位的证据。4. 本人使用过的 ROS2 命令4.1 发现和检查 ROS 图ros2nodelist ros2 topic list ros2 topic info /scan-vros2 topicecho/scan--onceros2servicelist ros2 action list ros2 param list ros2 param getnode_nameparameter_nameros2 doctor--report4.2 看消息频率和坐标变换ros2 topic hz /scan ros2 run tf2_ros tf2_echo odom base_link4.3 录制和检查证据包ros2 bag record-o~/tb3_motion_001 /cmd_vel /odom /scan /tf /tf_static ros2 bag info ~/tb3_motion_0015. TurtleBot3 / Gazebo 仿真实操5.1 启动仿真先设置机器人型号exportTURTLEBOT3_MODELburger启动 TurtleBot3 Gazebo 世界ros2 launch turtlebot3_gazebo turtlebot3_world.launch.py启动后确认存在的关键 Topic 包括/cmd_vel /scan /odom /tf /tf_static /imu这些话题基本覆盖了机器人测试中“控制指令、传感器、位置、坐标关系、惯性数据”五类重要证据。5.2 控制机器人并由里程计验证检查发现当前/cmd_vel的消息类型是geometry_msgs/msg/TwistStamped。正确的前进指令如下ros2 topic pub--rate10/cmd_vel geometry_msgs/msg/TwistStamped\{header: {frame_id: base_link}, twist: {linear: {x: 0.10, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 0.0}}}停止指令ros2 topic pub--once/cmd_vel geometry_msgs/msg/TwistStamped\{header: {frame_id: base_link}, twist: {linear: {x: 0.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 0.0}}}通过查看/odom确认机器人实际发生位移position.x约为1.0589 m。本次验证链路发布 /cmd_vel 速度指令 - 仿真底盘接收并运动 - /odom 持续发布里程计 - 通过 position.x 看到位移这就是一个最小的“指令是否生效”的测试闭环。真实项目中还要结合底盘日志、电机状态、编码器和视频判断。6. 雷达数据与频率实测使用下面命令确认激光雷达持续有数据ros2 topicecho/scan--once再使用下面命令测频率ros2 topic hz /scan本次实际观测结果指标实测值/scan平均频率约4.59 Hz平均消息间隔约0.218 s间隔标准差约3.90 ms测试理解频率低、抖动大、长时间没有消息都可能影响建图、定位、避障或控制。是否合格必须按具体产品需求判断当前实测数据仅作为仿真学习记录不能当作正式验收门槛。7. RViz2 和 TF 实操使用仿真时间启动 RViz2rviz2 --ros-args-puse_sim_time:true本人完成的操作将 Fixed Frame 设置为odom。添加TF显示项观察坐标系关系。添加LaserScan显示项并选择/scan。添加RobotModel状态正常。成功看到红色激光雷达点云/扫描点。当前观察到的现象RobotModel 状态正常但机器人身体网格没有明显显示。这更像 RViz 的网格或显示问题不等同于 ROS 数据链路故障因为/scan、/odom、TF 已正常工作。RViz 排障优先顺序Fixed Frame 是否存在 - 是否启用 use_sim_time - Topic 名称和消息类型是否正确 - TF 是否连通、时间戳是否匹配 - RViz 显示项配置、模型网格和缩放8. rosbag 证据留存实操录制命令ros2 bag record-o~/tb3_motion_001 /cmd_vel /odom /scan /tf /tf_staticros2 bag info ~/tb3_motion_001的实际结果项目结果录制时长102.57 s总消息数11841/cmd_vel68条/odom4706条/scan470条/tf6595条/tf_static2条本次证据链已经具备控制指令/cmd_vel 运动结果/odom 传感器输入/scan 空间关系/tf、/tf_static这套 bag 可以用来回放和复盘某一时刻下发了什么指令、机器人有没有位移、雷达是否还在发数据、坐标变换是否正常。9. 本次排障案例案例 1发布速度指令后机器人不动现象按常见示例向/cmd_vel发送geometry_msgs/msg/Twist后机器人没有按预期运动。排查ros2 topic info /cmd_vel-v根因当前仿真环境中的/cmd_vel要求的类型为geometry_msgs/msg/TwistStamped不是Twist。修复按话题实际类型重新发布TwistStamped指令随后通过/odom的position.x确认已移动。经验控制不生效时先查话题是否存在、订阅者是否存在、消息类型是否一致再判断控制器或底盘故障。案例 2RViz2 看不到预期数据排查重点RViz 需要使用仿真时间否则可能与 Gazebo 的时间不一致。修复命令rviz2 --ros-args-puse_sim_time:true经验可视化异常不等于传感器异常。应同时用ros2 topic echo、ros2 topic hz和 TF 检查数据链路。10. 当前掌握情况已完成ROS2 的 Node、Topic、Service、Action、Parameter 基本概念和常用命令。turtlesim、rqt_graph和静态 TF 学习练习。TurtleBot3 Burger 在 Gazebo 中启动。查看/cmd_vel、/scan、/odom、/tf、/tf_static、/imu等关键话题。发布正确类型的速度指令让机器人运动和停止。通过/odom验证位移。查看一次/scan数据并测量/scan频率和抖动。RViz2 中显示 TF、LaserScan 和 RobotModel看到雷达扫描点。实际录制并检查一份含控制、里程计、雷达和 TF 的 rosbag。使用 SLAM 生成地图并保存为tb3_map_001、tb3_map_002。重新加载tb3_map_002.yaml通过 AMCL 设置初始位姿。使用 Nav2 完成多次到点导航观察 Goal、Feedback、Result 和取消操作。已理解仍需复习Node、Topic、Service、Action 的选择边界。TF 坐标树、时间戳与 RViz 显示的关系。Twist和TwistStamped的区别以及先查接口类型再调用的习惯。频率、延迟、抖动、超时在机器人测试中的含义和测量方式。11. 未完成内容和下一步以下内容尚未完成完成并执行至少 10 条建图、定位、规划、避障和异常恢复测试用例。形成包含成功、失败、取消和重规划的完整导航记录。故障注入断网、雷达异常、TF 中断、数据延迟或频率下降。通过 rosbag 计算定位误差、终点误差、路径长度、耗时和任务成功率。使用 pytest 自动采集指标、判定结果并生成报告。下一次学习任务建议建立 10 条导航测试用例矩阵并给出可量化判定规则。对一次到点导航同步记录/odom、/cmd_vel、/scan、TF 和 Nav2 Action。执行可达目标、不可达目标、取消、动态障碍物和传感器异常测试。汇总终点误差、路径长度、耗时、重规划次数和任务成功率。12. 首次 Nav2 导航实操结果12.1 本次完成内容在加载tb3_map_002.yaml后完成了以下操作启动 Nav2并确认地图正常显示。使用 RViz 的2D Pose Estimate设置机器人初始位姿。通过Startup激活导航组件。使用顶部Nav2 Goal在地图白色可行区域设置目标点。机器人按规划路径移动并到达目标位置。12.2 RViz 最终结果截图中的Navigation 2面板显示指标结果NavigationinactiveLocalizationactiveFeedbackreachedDistance remaining0.07 mETA0 sRecoveries012.3 结果判定本次导航判定为通过Feedback: reached表示目标点已到达。Distance remaining: 0.07 m表示剩余约 7 厘米属于目标到达容差内不代表失败。Navigation: inactive是因为本次导航任务已经结束不是导航组件出错。Localization: active表示 AMCL 定位仍在工作。Recoveries: 0表示本次没有触发恢复行为。本次测试闭环加载地图 - AMCL 设置初始位姿 - 下发 Nav2 Goal - 规划路径并运动 - 到达目标 - 自动停止 - Feedback: reached12.4 仍需补充的测试证据本次已有 RViz 截图和运行过程现象。后续复习时还应补充Nav2 终端日志中的目标发送、执行和完成时间。/odom中的起点、终点和实际位移。/cmd_vel中的速度变化和停止状态。导航过程 rosbag便于计算耗时、路径长度和停止误差。13. 用机器人测试语言复述首次导航在 TurtleBot3 Gazebo 仿真中加载保存的栅格地图使用 AMCL 设置初始位姿后通过 RViz 下发 Nav2 目标点。机器人能够按照规划路径移动并到达目标RViz 显示Feedback: reached剩余距离0.07 m恢复次数为0最终自动停止。本次完成了“地图加载—定位—规划—控制—到达判定”的基础导航闭环。14. 用机器人测试语言复述本次学习我在 Ubuntu 24.04 的 WSL2 环境搭建了 ROS 2 Jazzy 和 TurtleBot3 Gazebo 仿真。通过/cmd_vel下发TwistStamped速度指令并使用/odom确认机器人产生约 1.06 米位移同时检查/scan雷达数据并测得约 4.59 Hz 的频率。我在 RViz2 中完成 TF、激光扫描和机器人模型的基础可视化并录制了包含/cmd_vel、/odom、/scan、/tf的 rosbag。随后完成 SLAM 建图与地图复用、AMCL 初始位姿设置以及 Nav2 多次到点导航。排障时识别了消息类型不匹配、Nav2 生命周期状态不一致和雷达时间戳差异问题。下一步完成导航测试矩阵、故障注入、指标采集和 pytest 自动化报告。16. 第二轮 Nav2 导航与生命周期排障16.1 已完成的测试结果场景结果证据/指标正常到点导航 1通过Feedback: reached剩余距离0.07 m恢复次数0正常到点导航 2通过Feedback: reached剩余距离0.12 m恢复次数0正常到点导航 3通过Feedback: reached剩余距离0.06 m恢复次数0困住/无法继续前进观察到异常恢复剩余距离0.12 m恢复次数由19增至31任务最终aborted导航取消已操作点击Cancel后任务停止后续需使用 Action result 或终端日志补充正式取消证据16.2 生命周期故障现象与原因现象RViz 仍能显示地图但Navigation: inactive下发目标提示navigate_to_pose action server is not available。检查后发现启动进程和 RViz 仍存在但部分 Nav2 生命周期节点状态不一致map_server、amcl、controller_server、smoother_server已经是activeplanner_server、bt_navigator等节点仍是inactive再点击Startup会尝试重新配置已经 active 的节点出现Transition is not registered并中止。处理保持 Gazebo 和地图不变按生命周期顺序激活缺失节点并验证/navigate_to_pose 可用 bt_navigator active map - base_link TF 正常机器人测试结论界面存在不等于后台服务可用。导航异常时应同时检查 Action 服务、生命周期状态和 TF 链路。16.3 雷达时间戳异常观察一次成功导航期间collision_monitor报告/scan与当前时间相差约0.21~0.23 s并交替输出Robot to stop due to invalid source Robot to continue normal operation这表示安全模块会在雷达数据超时或时间不同步时先停车数据恢复后继续。该次导航最终reached且恢复次数为0功能结果通过但时间同步警告应作为后续“传感器延迟/超时”专项测试的问题线索保留。15. 复习自测题激光雷达持续发布/scan应该用 Topic、Service 还是 Action为什么为什么“导航到目标点”通常选择 Action而不是只发一个 Topic机器人不响应/cmd_vel第一轮应检查哪些内容/cmd_vel - /odom的链路分别说明了什么/scan的频率、间隔、抖动各代表什么正式测试的合格线从哪里来RViz2 看不到雷达点时为什么不能直接结论为雷达坏了rosbag 中录制/cmd_vel、/odom、/scan、/tf各自为了证明什么静态 TF 练习为什么不能证明已经完成地图定位