0. 前言
作为一名大三在读的计算机学生,在学习 ROS 2 Humble 的过程中,我发现仿真环境的搭建往往比写代码本身还要折磨人。今天在虚拟机(Ubuntu 22.04)上尝试搭建 TurtleBot3 仿真环境时,经历了一场从"断网卡死"到"模型透明"再到"成功获取视觉数据"的拉锯战。
特此记录,希望能帮到同样在具身导航坑里摸爬滚打的同学。
1. 环境准备
- 系统:Ubuntu 22.04 (VMware 虚拟机)
- ROS版本:ROS 2 Humble
- 机器人模型:TurtleBot3 Waffle Pi (带相机型号)

2. 核心踩坑与解决方案
坑点一:Gazebo 启动报 Network is unreachable
现象 :启动仿真时,终端疯狂报错 Exception sending a multicast message,且一直卡在 Waiting for service /spawn_entity。
原因 :Gazebo 默认会连接 OSRF 模型库同步资源。在虚拟机网络不稳或断网时,它会因为请求超时而处于"假死"状态。
解决 :
手动指定本地模型路径,并设置本地 IP 绕过组播检查:
bash
export GAZEBO_MODEL_PATH=$GAZEBO_MODEL_PATH:/opt/ros/humble/share/turtlebot3_gazebo/models
export GAZEBO_IP=127.0.0.1
坑点二:机器人成了"透明人"(幽灵模型)
现象 :Gazebo 界面打开了,地图出来了,但中心只有几个灰点,看不到三层的小车模型。
验证逻辑 :在具身智能开发中,"数据流优于渲染流" 。
我通过 ros2 topic list 发现,虽然看不到车,但 /camera/image_raw 和 /scan 话题是存在的。使用 ros2 topic echo /camera/image_raw 能看到大量跳动的数字,证明传感器已经在工作了。
坑点三:虚拟机 3D 渲染导致的"全灰画面"
现象 :rqt_image_view 看到的画面是一片灰色,只有移动小车时才会偶尔闪过黑色像素。
解决:这是虚拟机 GPU 加速的兼容性问题。在启动前强制使用软件渲染可以解决大部分画质崩坏问题:
bash
export LIBGL_ALWAYS_SOFTWARE=1
指令测试如图(显示多行数字表示摄像头在正常工作):
bash
ros2 topic echo /camera/image_raw --once

3. 实操步骤复盘
-
设置环境变量:
bashecho 'export TURTLEBOT3_MODEL=waffle_pi' >> ~/.bashrc source ~/.bashrc -
启动 Gazebo 仿真世界:
bashros2 launch turtlebot3_gazebo turtlebot3_world.launch.py

-
手动召唤机器人(针对模型加载不全的补救):
bashros2 run gazebo_ros spawn_entity.py -file /opt/ros/humble/share/turtlebot3_gazebo/models/turtlebot3_waffle_pi/model.sdf -entity waffle_pi -x 0.0 -y 0.0 -z 0.01 -
开启遥控节点验证控制链路:
bashros2 run turtlebot3_teleop teleop_keyboard -
新开一个终端,测试相关组件是否成功启动 ;

4. 具身导航的第一步:视觉验证
通过 ros2 run rqt_image_view rqt_image_view 订阅 /camera/image_raw 话题。虽然因为渲染问题画面不够精细,但在旋转小车时,观测到了像素数值的剧烈跳动。
这标志着:机器人的"眼睛"(感知层)和"脚"(执行层)已经逻辑连通。

5. 总结与展望
今天最深刻的体会是:不要被不完美的 UI 表现迷惑。 在 ROS 2 开发中,只要 Topic(话题)里有数据,你的逻辑代码就能跑。
下一步计划 :
我们将编写一个 Python 节点,通过 OpenCV 处理这些"跳动的数字",实现一个简单的"视觉避障"功能------当机器人看到前方黑色像素占比过高时,自动紧急停车。
如果你也遇到了 Gazebo 启动黑屏或者模型加载不出来的问题,欢迎在评论区交流!