ROS2 与 TurtleBot3 学习实操记录

2301_79754268

33人浏览 · 2026-09-05 22:38:22

2301_79754268 · 2026-09-05 22:38:22 发布

ROS2 与 TurtleBot3 学习实操记录

学习目标：为机器人测试岗位打基础，能建立仿真环境、观察机器人通信与传感器数据、控制机器人，并留存可用于定位问题的证据。

本文只记录本人已经完成的 ROS2 学习和实操。SLAM 建图、定位、Nav2 导航、故障注入、自动化报告尚未完成，不将其写成已掌握。

1. 当前学习路线

ROS2 基础
  -> TurtleBot3 / Gazebo 仿真
  -> AGV 建图、定位、导航测试
  -> 故障注入与排障
  -> pytest 指标采集与测试报告

当前进度：已完成前两段的大部分基础实操，正在进入 SLAM、地图、定位与导航测试。

2. 实际环境

项目	实际使用内容
主机	Windows + WSL2
Linux	Ubuntu 24.04 LTS
Linux 用户	`yjw`
ROS2	ROS 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 负责读取和处理硬件数据；/scan Topic 负责传输扫描消息。
查询一次配置参数应使用 Parameter 命令或相关 Service，不是 Action。

3.2 TF 的作用

TF 是机器人各坐标系之间的位置和姿态关系。例如 odom、base_link、laser。

测试时，TF 用来判断“雷达数据、机器人本体、里程计数据是否处在正确的空间关系中”。TF 缺失、断链、时间不一致都可能造成 RViz 显示异常、定位异常或导航失败。

本次曾用静态 TF 做学习示例。该静态 TF 只用于理解命令和坐标变换，不能当作真实机器人已完成建图或定位的证据。

4. 本人使用过的 ROS2 命令

4.1 发现和检查 ROS 图

ros2 node list
ros2 topic list
ros2 topic info /scan -v
ros2 topic echo /scan --once
ros2 service list
ros2 action list
ros2 param list
ros2 param get <node_name> <parameter_name>
ros2 doctor --report

4.2 看消息频率和坐标变换

ros2 topic hz /scan
ros2 run tf2_ros tf2_echo odom base_link

4.3 录制和检查证据包

ros2 bag record -o ~/tb3_motion_001 /cmd_vel /odom /scan /tf /tf_static
ros2 bag info ~/tb3_motion_001

5. TurtleBot3 / Gazebo 仿真实操

5.1 启动仿真

先设置机器人型号：

export TURTLEBOT3_MODEL=burger

启动 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 --rate 10 /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 topic echo /scan --once

再使用下面命令测频率：

ros2 topic hz /scan

本次实际观测结果：

指标	实测值
`/scan` 平均频率	约 `4.59 Hz`
平均消息间隔	约 `0.218 s`
间隔标准差	约 `3.90 ms`

测试理解：频率低、抖动大、长时间没有消息都可能影响建图、定位、避障或控制。是否合格必须按具体产品需求判断，当前实测数据仅作为仿真学习记录，不能当作正式验收门槛。

7. RViz2 和 TF 实操

使用仿真时间启动 RViz2：

rviz2 --ros-args -p use_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_static

ros2 bag info ~/tb3_motion_001 的实际结果：

项目	结果
录制时长	`102.57 s`
总消息数	`11841`
`/cmd_vel`	`68` 条
`/odom`	`4706` 条
`/scan`	`470` 条
`/tf`	`6595` 条
`/tf_static`	`2` 条

本次证据链已经具备：

控制指令：/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 确认已移动。

经验：控制不生效时，先查话题是否存在、订阅者是否存在、消息类型是否一致，再判断控制器或底盘故障。

案例 2：RViz2 看不到预期数据

排查重点：RViz 需要使用仿真时间，否则可能与 Gazebo 的时间不一致。

修复命令：

rviz2 --ros-args -p use_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。

已理解，仍需复习

Node、Topic、Service、Action 的选择边界。
TF 坐标树、时间戳与 RViz 显示的关系。
Twist 和 TwistStamped 的区别，以及先查接口类型再调用的习惯。
频率、延迟、抖动、超时在机器人测试中的含义和测量方式。

11. 未完成内容和下一步

以下内容尚未完成：

使用 SLAM 建图并产生真正的 /map。
在地图中显示机器人位姿，完成定位验证。
使用 Nav2 下发目标点并验证 Action 的 Goal、Feedback、Result。
设计 AGV 导航、重规划、避障和异常恢复测试用例。
故障注入：断网、雷达异常、TF 中断、数据延迟或频率下降。
使用 pytest 自动采集指标、判定结果并生成报告。

下一次学习任务建议：

启动 TurtleBot3 的 SLAM，手动遥控机器人走出一张地图。
确认 /map、/tf 和机器人位姿可在 RViz2 中正确显示。
保存地图并重新加载，验证地图可复用。
进入 Nav2，向目标点发送导航任务，记录成功、失败、取消和重规划证据。

12. 用机器人测试语言复述本次学习

我在 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。控制异常时，我通过 ros2 topic info -v 发现消息类型不匹配并修复。下一步会做 SLAM 建图、定位、Nav2 导航和故障注入测试。