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 绕过组播检查：

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 加速的兼容性问题。在启动前强制使用软件渲染可以解决大部分画质崩坏问题：

export LIBGL_ALWAYS_SOFTWARE=1

指令测试如图(显示多行数字表示摄像头在正常工作):

ros2 topic echo /camera/image_raw --once

---

3. 实操步骤复盘

1. 设置环境变量：

   echo 'export TURTLEBOT3_MODEL=waffle_pi' >> ~/.bashrc
   source ~/.bashrc
   

2. 启动 Gazebo 仿真世界：

   ros2 launch turtlebot3_gazebo turtlebot3_world.launch.py
   

3. 手动召唤机器人（针对模型加载不全的补救）：

   ros2 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
   

4. 开启遥控节点验证控制链路：

   ros2 run turtlebot3_teleop teleop_keyboard
   

5. 新开一个终端，测试相关组件是否成功启动;
   

---

4. 具身导航的第一步：视觉验证

通过 ros2 run rqt_image_view rqt_image_view 订阅 /camera/image_raw 话题。虽然因为渲染问题画面不够精细，但在旋转小车时，观测到了像素数值的剧烈跳动。

这标志着：机器人的“眼睛”（感知层）和“脚”（执行层）已经逻辑连通。

---

5. 总结与展望

今天最深刻的体会是：不要被不完美的 UI 表现迷惑。 在 ROS 2 开发中，只要 Topic（话题）里有数据，你的逻辑代码就能跑。

下一步计划：
我们将编写一个 Python 节点，通过 OpenCV 处理这些“跳动的数字”，实现一个简单的“视觉避障”功能——当机器人看到前方黑色像素占比过高时，自动紧急停车。

---

如果你也遇到了 Gazebo 启动黑屏或者模型加载不出来的问题，欢迎在评论区交流！

---