ROS2 Jazzy Gazebo Harmonic で、Mini Pupper2 ROS を試す。
ふう!! 今回は、結構つかれたが、
表題通り、Gazebo Harmonic で、mini_pupper_ros の Mini Pupper2 を、なんとか、動かせたので、記載しました。
実機が、8万ほどするので、びんぼうなおんちゃんには、高値の花!!
Gazebo で、ちょっと試してみようと思ったのが、まちがいじゃったか!!
本当は、もっと大きな、犬ころロボットを試してみたいと思ってはいるが、さきだつものが...
本格的犬ころロボットは、今は、中ちゃんメーカー1強みたい。
30万から40万らしいが、4足歩行 Policy を自分で開発してつかう版だと、100万オーダーらしい。
べつのメーカーが、安価なモーター版を開発中と言うが、そういったものが出てこないと、なかなか、開発に踏み込めない。
環境
PC: Ubuntu Mate 24.04
ROS2 Jazzy
Gazebo Harmonic
Git Source
Jazzy 版
@mangdangroboticsclub/mini_pupper_ros
上記 jazzy 版 ソースを、git clone して、Gazebo Harmonic で動作するように修正する事が、今回の手順になる。
楽な方法は、無い。Jazzy 版でも、Gazebo は、古い版のままじゃ!!
はっきり言って、そのままでは、動かん!!
基本的な作りが、ROS2 対応になっていない。
robot URDF modelの top link が、 base_link なのが、そもそも問題で、おまけに、
stanford_controller_node.py が、そもそも使いづらい。
こいつの誤差の大きさで、本当に苦労した。
もともとが、Humble 版なので、Jazzy版へ移行するさいに、Gazebo が、かなり違ったので、これを、吸収しないといかんが、
ここは、ほとんど Google Ai に聞きぱなっし。しかし、以前、WearHouse Tugbot を作った経験があったので、随分前の事で、ほとんど記憶に残っていなかったが、
部分的に、思い起こして、なんとかできた。
1. Gazebo での動作の現状。
Gazebo Harmonic で、mini_pupper_ros の必要パッケージを動かして、
Rtabmap_ros 、Depth Camera、RGB Camera、 IMU と ekf_node で、なんとか、
RVIZ2 上で、 2D Map、3D Map を描く所までは出来ています。
後は、teleop_keyboard や、 Navigation2 や、自立走行 APP を組み込めば、Active SLAM と Localization モードでの走行ができると思う。
ただ、mini pupper ros2 での、SLAM は、止めたほうが良いと思う。別の diff drive robot で、SLAM をするか、
やっぱり、最終は、実機で、屋外で、 gnns-rtk で、自己位置推定をさせて、自立走行になるのか?
やっぱり、大きな犬ころロボットが欲しくなるか!!
2. ソースビルド。
2.1 まず、オリジナルの git clone と buildを行う。
$ cd ~/colcon_ws-jazzy/src
$ git clone -b ros2-jazzy https://github.com/mangdangroboticsclub/mini_pupper_ros.git
$ cd ..
必要 package のチェック、ばあいによっては、インストール
$ rosdep update --rosdistro=jazzy && rosdep install --from-path src --ignore-src -r [-y] [-s]
$ colcon build --symlink-install --cmake-args -DCMAKE_BUILD_TYPE=Release --parallel-workers 2
2.2 おんちゃんがパッチをいれた版を、も src/ へ clone する。
$ cd src
$ git clone https://github.com/tosa-no-onchan/mini_pupper_ros_my.git
おんちゃんのソースのなかの、mini_pupper_ros-patch ディレクトリー下の各ディレクトリーを、それぞれ、オリジナルのソースへコピーする。
おんちゃんが、修正したファイルのみ上書きコピーすれば、OK だとおもう?
再度、 build
$ cd ~/colcon_ws-jazzy
$ colcon build --symlink-install --cmake-args -DCMAKE_BUILD_TYPE=Release --parallel-workers 2
3. Gazebo で、 動かす。
$ colcon build --symlink-install --parallel-workers 1 --packages-select mini_pupper_ros_my_ap
$ . install/setup.bash
起動は、
$ ros2 launch mini_pupper_ros_my_ap pupper_rtabmap_depth_sim.launch.py SBC:=true
起動手順があるので、
mini_pupper_ros_my/mini_pupper_ros_my_ap/launch/pupper_rtabmap_depth_sim.launch.py
の上部に、全て記載しているので、それに従ってください。
teleop_keyboard で、操作できると思う。
うーーん。疲れた!! by nishi 2026.7.20
4. 後書き。
stanford_controller.launch.py が、ロボットの移動と、/odom/raw で、位置情報をだしてくれているが、
これの誤差が、半端じゃない。
移動距離の誤差も大きいが、回転時の pose.z の誤差も、なまはんかじゃない。
幸い、IMU がついているので、 IMU の pose.z を信用して、今回は、/odom/raw から、
/odom/raw_fixed を別途、生成して、これを、 ekf の odom0 で、フィードする。
IMU の pose.z を使った、向き補正と移動距離(これは、補正定数での補正)補正を、自作 tool で、なんとかごまかした。
imu_noise.py
直進時の距離の補正は、下記で、行っているので、自分で調整しとうせ!!
self.slip_rate = 0.67
屋外で、gnss-rtk が使えるのであれば、ekf filter で、gnn-rtk と IMU だけで、フュージョンすれば、解決するのだろうが!!
その時は、間違っても、/odom/raw は、使わない事!!
4.1 実機使用時の注意!!
Gazebo シミュレーションに合わせて、強引に修正した部分があるの、実機使用時は、下記を変更してください。
1) mini_pupper_ros/stanford_controller/launch/stanford_controller.launch.py
実機の場合は、
default_value='false'
に、しとうせ!!
これくらいだと思う!!
4.2 rtabmap_ros 使用時の、床の面が、実際の床より、高くなる(8 [cm] ほど) 件
これは、 mini pupper2 urdf の top link が、 base_link に設定されている所為です。
本来は、上記 top link を base_footprint にして、高さ=0 にすれば解決するのだが、
生憎、stanford_controller.launch.py が、/odom/raw での frame_id を、 base_link にしている所為で、これが出来ない。
なんとも残念じゃ!!
もしかして、imu_noise.py の /odom/raw_fixed の frame_id=base_footprint にすれば、
解決したのかも!!
5. 実機での使用に関して。
一応、Gazebo Rtabmap_ros + Depth Camera + IMU で、mini_pupper_ros の world で、SLAM での 3D Map ができるのが確認できた。
結構、いい感じ。
次は、これを、実機に移行させれば、良いが、Gazebo と 実機環境では、おおきく違う。
これを、Google Ai に話したら、いくつか対策方法を教えてくれた。
以下、その対策を、書き留めておきます。
ご心配されている通り、「シミュレーションでうまくいっても、実機（リアル環境）に持っていくと3D SLAMがぐちゃぐちゃに崩れる」というのは、ROS開発における『お約束』であり、最大の壁です。
実機に移行した際にマップが崩れる原因（シミュレーションとの違い）と、今からできる実機向けの「崩れ対策パラメータ」をあらかじめ共有しておきますね。
🚨 実機で3Dマップがぐちゃぐちゃになる3大原因と対策
1. ロボットの歩行による「激しい振動」と「ブレ」
mini pupperのような4足歩行ロボットは、車輪型と違って歩行時にカメラが上下左右に激しくシェイクされます。これにより、カメラ画像がブレて特徴点を見失ったり（オドメトリのロスト）、3D点群が歪んで斜めに積み重なったりします。
効くパラメータ（ブレの許容）:
'Odom/Strategy': '0', # 0=Frame-to-Map (実機のブレに強い傾向)
'Vis/CorType': '0', # 0=Features Matching (実機での特徴点追跡を強固に)
'GFTT/MinDistance': '10', # 特徴点同士の距離を離して、ブレによる誤マッチングを防ぐ
2. 実機センサーの「測定ノイズ」と「死角」
GazeboのDepthカメラはノイズのない完璧な距離を返しますが、実機のDepthカメラ（Intel RealSenseなど）は、「光沢のある壁」「黒い物体」「太陽光が入る場所」で距離が測定できず、データが穴あき（砂嵐）になります。また、遠くのデータほど誤差が大きくなります。
効くパラメータ（信頼できる距離だけに絞る）:
'Grid/RangeMax': '3.0', # 実機では3M以上先の信頼性の低いDepthデータはマップに使わない！
'Grid/CellSize': '0.05', # グリッドの解像度を少し粗め（5cm）にしてノイズを吸収させる
'Cloud/NoiseFilteringRadius': '0.05', # 点群の浮遊ノイズを除去する
'Cloud/NoiseFilteringMinNeighbors': '5',
3. ループクロージャ（位置補正）の誤判定
実機環境で似たような景色（白い壁、同じ形のドアなど）が続くと、RTAB-Mapが「過去のあの場所に戻ってきた！」と勘違いし、マップを無理やりねじ曲げて結合してしまう（誤ループクロージャ）ことがあります。
効くパラメータ（判定を厳しくする）:
'RGBD/OptimizeMaxError': '1.0', # シミュレーションの2.8から「1.0」などに下げて、ズレた結合を厳格に弾く
'Vis/MinInliers': '20', # ループ判定に必要な共通特徴点の最低数を増やして慎重に判定させる
🛠️ 実機に持って行くときの「おすすめの進め方」
まずは「オドメトリ（自己位置推定）」だけをチェックする
いきなりマッピングをせず、RVizで実機ロボットを動かし、/odom（またはRTAB-Mapの odom）の軌跡が、実際の動きとズレずに追従しているかだけをまず確認します。
最初はゆっくり動かす
実機での最初のマッピングは、ロボットの歩行速度をかなり遅く設定するか、手動でゆっくり旋回させてカメラに周囲の景色（特徴）をじっくり覚えさせてあげてください。
実機テストに入ると、またシミュレーションとは違ったエラーやログ（Odom lost! など）が出るかもしれませんが、それもパラメータのチューニングで必ず乗り越えられます！
との事ぞね!!
まあ、全てが有効かどうかは、試してみないとわからんが、
興味のある方は、試してみては、いかがかね!!
Mini Pupper2 での、SLAM は、パスした方が賢明だとは、思うが。
5.1 Mini Pupper 2 の IMU(QMI8658C)だけど、Motion processor が入っているようだけど、pose.z のドリフトがあるみたい。
これだと、実機での走行は、ちょっとむりかな?
QMI8658C に替えて、BNO086 を、ESP32-S3 につなげられるみたい。
BNO086 で、DMP 6軸フージョンで、自動キャリブレーション時の、pose.z の暴れをフィルターして使えば、実機でも使えそうだが、そこまでする?
これは、 ESP32-S3 の中のコードを修正する事になりそう。
Google ai だと、ekf で、吸収できるみたいに言っているが、どうか?あまり期待はできないと思う。
やっぱり、もっと実際の業務でも使える、四本足 犬ころロボットが、必要か!!