ROS2 自作 Turtlebot3 による 草刈りロボット開発。#15 Robot Localization
---- 機械学習 Object Detection を使った Robot Localization 案 ----
なんとなく PC のブラウザーを見て暇を潰していたら、浮かんできたので、書いてみた。
ロボット Localization に、ロボットに取り付けた RGB カメラの前方画像を 使ってランドマークになる物を検出する
Object Detection をつかてみてはどうか?
検出する Object は、ランドマークになるものだけにする。
道路、家、塔、川、アンテナ、窓、ドア、橋、欄干...
家は、平屋、2階屋、ビルなどに分類する。
おんちゃんの結論は、Object Detection では、ロボットの正確な位置を算出する Robot Localization には、現状不向きか、
やはり、障害物の判定とそれからの退避利用が合っている。
1. 案 I
検出されたObject部分の画像だけを使って、それ以外の部分は、消去する。
ランドマークのみが抽出された画像を、rtabmap_ros に通す。
2. 案 II
SLAM の時は、rtabmap_ros で Mapping しながら、自分でも Localization 情報を構築する。
Navigation モードの時は、自分で Localization した情報を使う。
処理概要は、検出されたランドマークの class id と向きか、depth camera の画像も使って距離情報と、ロボットの位置、向き情報を保存する。
注1) 検出されたランドマークは、ロボットの位置、向きから、Map上の位置に変換して、単純に、保存するだけ。Map(x0,y0)にプロットするイメージ。
実際は、Roboto の 現在の位置(Map)とランドマークの位置(Map) を加えて、SQLite 等で情報として蓄積するか。
注2) Map上の位置に変換するには、距離が必要になる。距離が測定できる範囲のランドマークに限られる。
注3) ランドマークも見る向きによって、形状が変わるので難しいかも知れない。
家であれば、距離は、ロボットの方に向いている壁や屋根までの距離となる。ロボットの位置で、同じランドマークでも形状が異なる。
注4) Map 上の情報も、実際参照されるのは、ロボットの現在位置と向きによってカメラの画角に入る周辺の情報に限定される。
注5)
a. Navigationモード(非SLAM モード) の時は、もしかしたら、その時の各ランドマークとロボットを頂点とする多角形の形状のマッチングになるのかも知れない。
あるいは、多角形の領域の重なり具合を求めるのかも知れない。
しかし、ランドマークが多いと、多角形化が困難になるので、これは、無理か?
SLAM モードの時は、頻繁に ロボットを 360度回転させて、周囲の情報を収集する必要がある。
b. やはり、距離情報を必要としない、Object Detction によるランドマークのマッチングが出来ないものか?
この点だが、単純にObject Detction でランドマークを計測した時毎に、その時のロボットの位置と向き及び、
見つかったランドマークの Class id と RGB 画面上のboxの情報を SQLite で保存するのはどうだろうか?
これなら、マッチング処理の時、ロボットの位置 Map(Xc,Yc,Zc) が、近いレコードを SQL で 抽出して使える気がする?
これを、Map近辺レコード と呼ぶことにする。
Map近辺レコード が select できれば、後は、
『SLAM入門 ロボットの自己位置推定と地図構築の技術 友納正裕(著)』(オーム社)
でも参考に自己位置の補正ができそうじゃ。
注) ただこちらは、基本 2Dのレーザースキャンを使った入門書じゃ。
スキャンマッチング、センサ融合による退化への対処、ループ閉じ込み の３つが主要処理として出ている。
ランドマークとの距離が必須だが、初心者のおんちゃんには、大いに勉強にはなる。
3D LiDar and 3D SLAM は、LOAM があるらしい。
後は、『インターフェイス 2020 3』第3部 自律走行ロボ制御プログラミング実験室 あたりが参考になるか?
以前ぱっと読んで、 あまり理解せずにしていた。もう一度読んでみようと思う。
もし、Depth Camera で、距離が測定できるランドマークであれば、同時に Map 上の位置を計算していっしょに、SQLite で保存しておけば良いかも知れない。
注6) ロボットの位置と向きの参照情報についての整理。
ROS2 においてロボットの位置は、TF システムによって管理される。
ロボットの現在位置と向きは、下記関連で示される、
tf-map -> tf-odom -> tf-basefoot_print
tf-odom -> tf-basefoot_print は通常、ロボットのMoter の単位時間内の直進値や向きの回転値を積分した値で示される。当然、タイアの回転なので誤差が蓄積されていく。
ただし、ロボットの向きは、IMUのBNO086 の 6軸、9軸 DMP のQuatnion を使えば誤差は少ない。
上記誤差を補正するために、正しい tf-map-> tf-basefoot_print をタイア以外の情報も参考に求めて、
tf-map-> tf-odom を補正するのが、localization の目的ぞね。
注7) ロボットの走行と Map について。
ROS2 で、ロボットを走行をさせるには、予め作成した Static Map が必要ぞね。
通常 SLAM で、Static Map を作成するタスクを先に実施する。
Static Map が作成されたら、それをもとに ロボットを走行させることになる。
なので、Localization は、普通は両方で必要になるが、....
ロボットの向きの最近のブログ記事
ROS2 自作 Turtlebot3 による 草刈りロボット開発。#11 ロボットの走行方向がずれる。
副題: ROS2 C++ 自立走行ロボットによる草刈りロボット開発
----- ロボットの走行方向がずれる。------
SBC: Orange pi 5 Armbian Ubuntu 24.04
ROS2: Jazzy
Jazzy 版にして、rtabmap_ros_my/foxbot_nav2_oak-d_depth_gps.launch.py で、自作 Turtlebot3 を動かしたら、最近どうも、ロボットの向きがずれる気がする。
Rviz2 の画面上は、ロボットは、目的地にちゃんと到達しているが、実機のロボットは、結構ずれた位置に行ってしまう。
1. EKF の設定が変わったのかと、いろいりためしていたが、
どうやら、原因は、 IMU ボードの取り付け向きが、ロボットの進行方向にから少しずれているみたいじゃ。
今まで、あまり気にしていなかったが、もしかしたら、DMP 9 の場合の、IMU のキャリブレーションを取っ払ってしまっていたかも知れない。
もとい、これは、単純に、IMU ボードの向きを正すしかない。
あと、ICM-20948 の接続ケーブルの接触が、時々不良になるみたい。そのせいで、急に Device ID が取れなくて、初期化処理でずっこける。
以前は、電源電圧が低下している所為と思っていたが、単純に、接触不良みたいじゃ。
ROS2 自作 Turtlebot3 による 草刈りロボット開発。#10 走行開始時のロボットの向き。
副題: ROS2 C++ 自立走行ロボットによる草刈りロボット開発
--- ros2 nav2_gps_waypoint_follower_demo autonomous は、できるか検討する。 ---
ROS2 自作 Turtlebot3 による 草刈りロボット開発。#9 LSTM で経路計画をする。
が出来たので、自分の部屋で、実機を Auto Mower で走らせている。
その中で、気になりだしたのが、ロボットの開始時の向きのズレが気になる。
注) その前のお断り。
Robot Localization に Navigation2 の AMCL with SCAN を使っていれば、Static Map を参照して自動的にロボットの向きが補正されると思う。
今回は、ekf_localization with no GNSS をつかっているので、こんな問題がでてくると思う。
おんちゃんは、ほとんど AMCL with SCAN を使ったことがなかったから、AMCL Localiaztion の知識が欠落しちょりました。
屋内であれば、AMCL with SCAN は、Roboto Localiaztion の強力な機能じゃった。
Auto Mower で走行するときは、予め作成した、Static Map をベースに走行している。
この時、Static Map 作成時の、ロボットの向きと、 Auto Mower 走行時のロボットの向きがずれていると、具合が悪い。
1度ずれていると、数十メートルそうこうすると、かなりのズレが生じてしまう。
やはり、みちびき等の GNSS でロボットの位置を補正するしかないのかも。
その前に、予備知識として、ekf-localization 、navsat_transform を使ったロボット位置推定の場合の話だが、
robot_localization/navsat_transform_node を使った場合、
navsat_transform.yaml
の、datum: [38.161491, -122.4546443, 0.0] # pre-set datum if needed, [lat, lon, yaw]
で、tf-map の原点の緯度、経度と、x 軸の向きを指定する。
yaw (X 軸の方向)は、通常 東=0 [radian] になるみたい。
通常は、X軸の+方向が、東としているので、地図の X軸の+ 方向を変えたければ、ここで指定する。
Navigating Using GPS Localization
によると、robot_localization は、WGS84(世界測地系) を使うとのこと。
与えられた、GPS の lat,logi から、地表上の平面地図上の距離に変換する処理をしてくれる。
つまり、GPS の lat,logi の現在値から、起点となる、datum からの、地表面上の距離をWGS84を使って、算出して、
それは、tf-map(0,0) からのX軸[M]、Y軸[M] の値として教えてくれる。
結構便利なツールじゃ。
地図から、Map に変換する場合は、この WGS84 の地図を使えば良い。
出力は、odometry/gps で得られる。
$ ros2 topic echo /odometry/gps
で、tf-map からの距離が得られる。だから、 GNSS の値が正確であれば、この odometry/gps だけで、ロボットの正確な位置がわかる。
だから、本来は ekf-localization、ukf-localization は必要がない。必要がなければ、無理して使うこともない。
すでに作成された、Static Mapは、作成時に使用した、datum をnavsat_transform_node に与えれば良い。
ロボットの向きも、Static Map 作成時の向きにあわせる。
手作業で、Static Map を作成した時は、そのマップの起点と X軸(+方向)方向 を、datum を使って、navsat_transform_node に与えれば良い。
このページを書いた時は、予備知識として、navsat_transform この知識がなっかたまま書いたので、書き直しが必要みたい。by nishi 2025.8.10
注1) 部屋の中で、GPS を使わない時は、開始時のロボットの向きが、+X に、必然的になる。
以上が、予備知識である。
ROS2 GPS Localization 時のスタティックマップの東西南北、に関する、おんちゃんの勝手な解釈。
大学、高専でロボット関連の授業を受けていれば当たり前の事かも知れないが、
なにせ、おんちゃんは独学なので、知識のなさを露呈しちょります。
もし間違っていたら、勘弁しとうせ。
ROS2 LC29H-EA GPS RTK を作る。
で、GPS RTK を使って、部屋の中でロボットの走行テストをしているときに、ふと湧き上がってきた疑問な点を、
おんちゃんながらの、勝手な解釈を書いてみました。
部屋の中で、LC29H-EA + RTK で地球上の位置を取得して、ロボットをうごかしているけれど、GPS だと、東西南北があるよね?
これは、スタティックマップでは、どっちら方になるのじゃろ?
申し訳ありません。これにかんする解答は、
ROS2 自作 Turtlebot3 による 草刈りロボット開発。#10 走行開始時のロボットの向き。
の "その前に、予備知識として、ekf-localization 、navsat_transform を使ったロボット位置推定の場合の話だが、" の箇所に書きました。
上記を参照してください。
よって、これ以降の記述は、とんちんかになっています。by nishi 2025.8.14