Gazebo — シミュレータの概要と問題点

Gazebo (旧 Ignition) の構成・機能一覧と、実務でハマる問題点をまとめた一般知識ノート。

要点 #

Gazebo は Open Robotics 製の OSS ロボットシミュレータ。Classic (gazebo11 で EOL) と新 Gazebo (旧 Ignition、Fortress / Harmonic) の 2 系統があり、混在して情報が散らかっている。物理は DART / Bullet、レンダリングは OGRE 2、ROS 2 とは ros_gz_bridge で接続する。CPU 単一プロセスで動くため、多接触・多ロボット・高解像度センサでは重い。

概要 #

項目	内容
開発元	Open Robotics (現 Intrinsic / Google 傘下)
初版	2002 年
ライセンス	Apache-2.0
系統	Classic (gazebo9 / gazebo11、2023-01 EOL) / 新 Gazebo (Citadel → Fortress → Garden → Harmonic → Ionic)
LTS	Fortress (2022-09〜2026-09)、Harmonic (2023-09〜2028-09)
モジュール	`gz-sim`, `gz-physics`, `gz-rendering`, `gz-sensors`, `gz-transport`, `gz-msgs`, `gz-gui`
物理	DART (default) / Bullet / TPE
レンダリング	OGRE 2 (OptiX ray tracing あり)
通信	gz-transport (ZeroMQ + Protobuf)
モデル記述	SDF (ネイティブ) / URDF (sdformat 経由で読み込み)
ROS 2 連携	`ros_gz_bridge`, `ros_gz_sim`, `ros_gz_image`
センサ標準対応	RGB/Depth/Thermal Camera, 2D/3D LiDAR, IMU, GPS, Contact, Force-Torque, Magnetometer, Altimeter
公式アセット	Gazebo Fuel (https://app.gazebosim.org/fuel)

ROS 2 との対応 #

ROS 2 distro	推奨 Gazebo
Humble	Fortress (LTS)
Iron	Garden / Harmonic
Jazzy	Harmonic (LTS)
Rolling	Ionic

ros_gz パッケージが distro ごとに配布され、apt install ros-${ROS_DISTRO}-ros-gz で入る。

問題点 #

1. バージョン混乱 #

Classic (gazebo コマンド、gazebo_ros_pkgs) と新 Gazebo (gz sim コマンド、ros_gz) が混在
Web の日本語チュートリアルの多くが Classic 前提で、コピペしても動かない
Classic 用プラグイン (gazebo::ModelPlugin) は新 Gazebo (gz::sim::System) では動かない (ECS 化されたため)

2. 物理精度 #

DART は剛体・単純関節では実用十分
多点接触 (脚ロボット、多指ハンド、粒状物、ソフトボディ) で振動・貫通が出やすい
MuJoCo / Isaac Sim (PhysX 5) と比べ接触解決の安定性が劣る
URDF の inertia が不正 (質量 0、慣性行列非正定値) だと即発散する

3. 性能・スケーラビリティ #

CPU 単一プロセス。GPU 加速なし
複数ロボット (> 5 台) や高解像度 LiDAR (> 128ch) で RTF (Real-Time Factor) が 1.0 を切る
並列環境 (RL 用途で数百〜数千環境同時) の仕組みはない

4. レンダリング #

OGRE 2 ベース。実写風にはならない
Sim2Real で画像入力を扱う強化学習には不向き
HDR / Global Illumination 弱い

5. アセット不足 #

Fuel のモデル数は数千規模。Unity Asset Store (数十万規模) と桁が違う
都市・屋内環境、人物、車両などの高品質アセットが乏しい

6. ROS 2 Bridge のオーバーヘッド #

ros_gz_bridge を挟むため 1〜数 ms の遅延
QoS マッピングが限定的 (Reliability / Durability を細かく制御しづらい)
カスタムメッセージ型は自前で bridge を書く必要あり
parameter_bridge の YAML 記述が煩雑

7. OS 対応 #

実質 Ubuntu 22.04 / 24.04 のみ
Windows は experimental、macOS は brew でビルド可だが不安定

8. GUI・デバッグ #

GUI が重い (起動 10〜30 秒)
レイアウト設定の保存先が散らばる (~/.gz/sim/, ~/.config/)
内部状態 (joint の実 torque、接触点、拘束力) の可視化が弱く、gz topic -e で生値を追う羽目になる
ステップ実行・ブレークポイントの概念なし

9. プラグイン開発 #

API が Classic → 新 Gazebo で全面刷新 (ModelPlugin → System の ECS モデル)
Python API (gz-python) はまだ薄い、基本 C++ 前提
プラグインのビルドが colcon に馴染まず、cmake を直接叩く場面が残る

10. 決定性 (Determinism)#

同じ seed でも実行ごとに微差が出る (物理ステップ内の並列処理起因)
強化学習の再現性を厳密に取りたい用途では不利

11. ドキュメント #

公式チュートリアルは基本のみ、応用は API リファレンスと GitHub Issue を読む前提
Classic の記事が SEO 上位に残り続け、初学者がハマる

実務での頻出トラブル #

症状	原因	対処
ロボットが起動と同時に飛ぶ	`<inertia>` が非物理的 (質量 0、慣性行列非正定値)	URDF に `check_urdf` / `check_inertia.py` を通す
joint が震える	`<damping>` / `<friction>` が 0、PID ゲイン過大	SDF に damping を追加、gain を下げる
センサトピックが ROS 2 側に来ない	`ros_gz_bridge` の型指定ミス、QoS 不一致	`ros2 topic info -v` で QoS を確認、bridge YAML を修正
RTF が 0.1 まで落ちる	LiDAR 解像度過大、rendering が CPU に落ちている	`visualize: false`、`update_rate` を下げる、GPU rendering を確認
`gz sim` 起動が固まる	Fuel からモデル DL がタイムアウト	ローカルに落として `GZ_SIM_RESOURCE_PATH` を通す
URDF が読み込めない	`<mesh>` の `package://` パスが解決できない	`IGN_GAZEBO_RESOURCE_PATH` / `GZ_SIM_RESOURCE_PATH` にパッケージパスを追加

何に向くか / 向かないか #

向く

ROS 2 ネイティブ機能の統合試験 (nav2、moveit2、control)
URDF / SDF ベースのロボットの動作確認
単一〜数台のロボットでの制御則 (PID / MPC) 検証
SLAM / navigation のセンサパイプライン試験

向かない

画像入力の強化学習 (Sim2Real) → Unity, Isaac Sim
多指ハンド・脚ロボットの接触精度が要る場面 → MuJoCo, Isaac Sim
数百〜数千環境の並列 RL → Isaac Sim, Isaac Lab
大規模な都市・屋内アセットの活用 → Unity, Unreal