どうなっている、高市政権の農林水産省の米増産の撤回!!
MSN の記事を見ていたら、コメ価格維持へ増産撤回 26年産711万トンに
の記事が舞い込んできた。
とんでもないことだ、これでは、今も 5kg 4,000 円以上 していて、一向に下がる気配がない。
早く、3,000円台で手に入るようにならないか、待ち焦がれている、おんちゃんはどうすればよいのか。
低所得のおんちゃんは本当に生活が苦しいが、高市政権は判らないみたいだ!!
新しい鈴木農相は、今の米価格が高いか安いかも明言を逃げて、米価格は市場が決めるものだとばかなことを言っている。
まるきり価格を下げる考えもないみたいだ!!
いまの米価格が高いのは、子供でもわかる。
ROS2 Turtlebot3 Gazebo で cartographer の SLAM を試してみた。
AMCL with Scan での SLAM and Localization より広域の場所に対応するもので、Cartographer と言うのがあるそうぞね。
おんちゃんも恥ずかしながら、最近知りました。
サンプルをネットで探してみたが、一から書かないといかんみたいで、めんどうだたので、以前 Turtlebot3 の中に
cartgrapher があったので思い出して、早速、探してみた。
Turtlebot3 cartgrapher の例が下記にあったので、試してみた。
turtlebot3/slam/
こちらは、実機 Turtlebot3 だったが、Gazebo でも動くだろうと思って試してみました。
Turtlebot3 Gazebo は、こちら。
@ROBOTIS-GIT/turtlebot3_simulations/
ROS2 自作 Turtlebot3 による 草刈りロボット開発。#16 ソーラ発電所の草刈りロボット案
------ 草刈りロボットへの 3D Map の利用について ----
ROS2 Tugbot Gazebo で 3D LiDAR の SLAM を試してみた。 で、@fishros/LeGO-LOAM-ROS2 を、
Tugbot Gazebo で試してみて、出てくる 3D Map(ただし、現状 3D Map として保存する方は、判らない) が素晴らしい。
これを、Localization として使うのではなく、周囲把握に使えれば面白い気がしてきた。
1. おんちゃんの想定する、ソーラ発電所の草刈りロボットに於ける3D Map の利用。
1) ソーラー発電所で、草が生えていない時に、Rtabamap_ros、LeGO-LOAM-ROS2 等を使って、2D Map と、3D Map を作成する。
3D Map は、草の生え具合の標準データとする。
2) 草刈りのときは、2D Map や GNSS-RTK を使った、Localization を利用する。
3) ロボットは草刈りコースに則って移動する。
この時、走行コースが、草でふさがっている時、そこの場所の 3D Map と草の生え具合の標準データとを比較して、
本来であれば草がない所であれば、その草を避けずに草を刈る。
注) 2D Map でも予め作ったものなら、同じように使えそう。
敢えて、3D Map を使う価値はあまり無いのかも!!
4) また、走行コースは、おおまかなコースとして、ロボットの周囲の 3D Map が、草の生え具合の標準データと比較して、
草が生えている場合は、その周囲の草刈りを行う。
5) ケーブル、支柱などの障害物は、Object Detection で、判定して避ける。
ROS2 Tugbot Gazebo で 3D LiDAR の SLAM を試してみた。
ROS2 Gazebo for Tugbot が使えるようになったので、本題の 3D LiDAR の SLAMのサンプルを試してみた。
3D LiDAR の SLAMのサンプルは、
@fishros/LeGO-LOAM-ROS2
開発環境
PC: Ubuntu Mate 24.04
ROS2 Jazzy
Gazebo Hramonic
1. ビルド。
$ cd ~/colcon_ws-jazzy/src
$ git clone https://github.com/fishros/LeGO-LOAM-ROS2.git
$ cd ..
$ colcon build --symlink-install --cmake-args -DCMAKE_BUILD_TYPE=Release --packages-select lego_loam_sr
$ . install/setup.bash
2.Run。
# term1
$ sudo ufw disable
$ ros2 launch tugbot_gazebo_my warehouse.launch.py
# term2
$ ros2 launch lego_loam_sr run.launch.py
で、問題なければ、動くはず。
ただし、手直ししないと動かなかったので、メモして置きました。
ROS2 Gazebo for Tugbot を作ってみた。
3D LiDAR の SLAM サンプルの、
@fishros/LeGO-LOAM-ROS2
Gazebo で試せないかと思ったので、作って見ました。
一応出来たのだが、3D LiDAR の PointClouds2が、Rviz2 でうまく確認できない。--> 一応対応した。
作るにあたっては、下記の2サイトを参考にさせてもらったぞね。ありがとう!!
@ROBOTIS-GIT/turtlebot3_simulations
@/porizou/tugbot_ros2_pkgs
turtlebot3_simulations/turtlebot3_gazebo が、Gazebo 利用の FrameWork みたになっているので、これのファイル構成を流用させてもらいました。
tugbot_ros2_pkgs は、urdf sdf を参考にさせて貰いました。
開発環境
PC: Ubuntu Mate 24.04
ROS2 Jazzy
Gazebo Hramonic
github に公開しました。
@tosa-no-onchan/tugbot_my
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 は、普通は両方で必要になるが、....