自作 Turtlebot3 自律走行に向けたプログラム。#15
--- 自作 Turtlebot3 (foxbot_core3) で、屋外での走行 ---
1. 屋外走行に向けて。
いま、おんちゃんの頭の中には、屋外で、自作 Turtlebot3(foxbot_core3) を走らせる為のハード機器の構成をどうするかで、
一杯ぞね。
ロボット自体のコントロールは、C++プログラムから行うので、自律走行になりますが、せめて、ロボットの Start、Stop、
Go back home くらいは、PC タブレットから、WiFi 経由で ロボットに指示したいです。
Windows PC タブレットを安く手に入れて、其れに Ubuntu 20.04 をインストールして、今、部屋で PCに載せている部分を、
それに入れられれば、一番簡単そうですが。
なかなか、安い Windows PC タブレット だと、荷が重いかも?
最終的には、ロボットカーの方に、全部乗っけて、Start/Stop の操作コマンドだけを送る構成にしないといかんぞね。
なんと、Linux デスクトップアプリが動く、 Linuxスマホ - pinePhone がありました。
これなら、簡単にできそう。
取り敢えず、おんちゃんは、メルカリで、 ASUS TransBook T100TA をそれなりの価格で買ったきに、
Xubuntu 辺りが乗りそうなので、これでトライしてみます。
ASUS TransBook T90chiにXubuntuを入れてみました。キーボードドックも使えるようになりました。
T100TA ubuntu インストールは、下記が参考になるみたい。
T100TA_guide.md
OSをふっとばされたタブレットPCにUbuntuを入れてみた
なるべく早く、実機で屋外で試してみたいぞね。
結局、Xubuntu 20.04 を入れて、Sound は、使えませんでした。WiFi 、Mouse、キーボードが使えるので、ノートPC 代わりです。
Xubuntu 20.04 の Desktop lightdm だと、Screen Keyboard が使えないので不便なので、ubuntu-desktop を追加インストールして、
$ sudo apt install ubuntu-desktop
text login で立ちあげて
$ sudo systemctl start gdm
注) Desktop パッケージを変更しても、既存のユーザには、反映されないので、その後、新しくユーザを登録して、起動すれば、反映されます。
2. Ubuntu 20.04 Desktop にする。
Ubuntu 20.04 Desktop として使うことにしました。
これだと、タブレットの操作ができます。但し、遅いかも。
Desk Top の変更は、下記が参考になります。
Ubuntu 20.04の起動時CUI、GUI設定
注2) 最終的に、Ubuntu 20.04.5 Desktop を、新規インストールしました。
注3) Ubuntu 20.04 にしたら、catkin build がなくなってしまったみたい。
こちらに、記載がありました。
ROS noeticでcatkin buildを使う
注4) T100TA での、catkin のビルド。
$ catkin build -j1
でないと、メモリー不足で、ハングします。
swapfile を、2GByte にしていますが、それなりに使えそうです。
注5) Firefox での、タッチスクリーンの設定方法は、下記にありました。
Firefox and touch screen scrolling with Ubuntu
スライド、ズームイン、ズームアウト うまく動く様です。
3.1 ASUS T100TA タブレットを、Turtlebot3 リモートPC として試す。
ASUS T100TA での、Ubuntu 20.04.5 Desktop での、タブレットとしての設定がそれなりに出来たので、
Turtlebor3 のリモートPC としての設定と、rtabmap_ros のインストール等、一通り行って、早速、
従来の Ubuntu Mate PC の代わりに、T100TA をリモートPC として、動かしてみました。
OKでした。CPUの負荷は、4CPU で、 50[%] 程です。
4. 屋外での走行。
いよいよ、屋外での走行です。
さて、T100TA か、Jetson Nano 2G のどちらかの、Wifiを APモードにしないといけないのだが、できるのだろうか?
インターネットに接続しないので、うまくいくのだろうか?
Hotspot と言うらしい。下記に、Ubuntu 18.04 の例だが、有ります。
Ubuntu 18.04 LTSでWiFiアクセスポイントを作成するにはどうすればよいですか？
nm-connection-editor で、細かい設定をするみたいだ。
但し書きに、"ネットワークを介して共有するインターネットを備えたケーブル接続がない限り、アクセスポイントは機能しないことに注意してください。"
とあるのが問題だ。
だとすると、クローズした、プライベート wi-fi ネットワーク はできないのだろうか?
但し書きの意味が、"インターネットに接続するアクセスポイントとしては、機能しない。" 事だけの意味だろうか?
おんちゃんは、これが今必要だが。下記には、単純に、wifi router の設定で、ISP へ接続しなければ良いと書いているのだが。
Does Wi-Fi Work Without Internet
理想は、単純に USB Dongle with ap で、ISP を使わないで使用する。事ぞね。
おんちゃんの求めている物は、単純に wifi router ポータブル(電源がUSB) みたいぞね。
下記辺りの商品を、T100TA から、電源供給すれば、それで、OKか。
WRH-300BK3-S
Amazon だと、
エレコム WiFiルーター 無線LAN ポータブル 300Mbps USBケーブル付属 WRH-300BK3-S
地元のヤマダ電機で、特売で 2,158円 で購入して早速試してみました。
WRH-300BK3-S は、ディフォルトの、router モード でOKでした。
T100TA を、リモート PC として、rtabmap-nishi_stereo_outdoor2_bz3_navi_gps.launch を試してみましたが、
どうやら、T100TA と、JetsonNano 2G の時刻がずれていて、ワーニングが出てうまくいきません。
手動での時刻設定では無理の様です。
どうやって、時刻合わせをするか?
ROSのために複数PC間で時刻同期する方法 が参考になりそうです。
その前に、JetsonNano 2G の中で、ほとんど全てのノードと roscore を起動させて見ましたが、CPU 使用率 90[%] 程になりました。
これでも、動くかと言えば動くようだが、Rviz と、rosrun turtlebot3_navi_my multi_goals4_move_base は、リモートPC からです。
やはり、2台に分散したほうがよさそうです。
4.1 試走。
T100TA とJetsonNano 2G に chrony を導入して、やっと時刻合わせが出来たので、試してみました。
ポータブルルータを使った時は、まだ動作が安定していないようです。
rviz の画面が一瞬消える現象が出ます。
Home wifi router だと生じないので、ポータブルルータ時の現象だろうか?
これから、調整しないといかんぞね。
試しに、ポータブルルータで、GPS を使わない従来の構成を試してみました。
こちらも、同じように動作が安定しません。これは、今までの実績があります。
T100TA とJetsonNano の時間同期に問題がありそうです。
tf トピックのいずれかの timestamp のずれが大きくて、いくつかは無視されているような気がします。
JetsonNano 2G の方の /etc/chrony/chrony.conf を少しいじって様子をみてみます。
/etc/chrony/chrony.conf 抜粋
T100TA は、192.168.1.45
minpoll、maxpoll は、ディフォルトは。
minpoll = 6 2**6 = 64[sec]
maxpoll = 10 2**10 = 1024[sec]
注1) chrony は、時刻のズレが大きすぎると、時刻合わせをしない様です。
maxdistance 3 [sec default]
で決まるようですが、Jetsoon Nano は、30[日] 位ずれてしまいます。
強制的に時刻合わせをする方法がありました。
"Leap status Not synchronised" - On running 'chronyc tracking'
launch ファイルを実行する前に、
$ sudo systemctl stop chronyd
$ sudo chronyd -q 'server 192.168.1.170 iburst'
$ sudo systemctl start chronyd
を実行して、時刻合わせします。定期的には、4分毎にします。
注2) 192.168.1.170 は、Ubuntu 20.04 PC の IP です。ところが、ここでエラーになる様です。
$ sudo chronyd -q 'server ntp.nict.jp iburst'
だと、うまく行きます。どうやら PC の chrony のサーバー側の問題の様です。
サーバー側の chrony の設定に、
local stratum 10
が、必要でした。
サーバー側の設定をまとめると。
1) port= 123/udp を開ける。
2) /etc/chrony/chrony.conf に記述(サーバー側)
local stratum 10
allow 192.168.1.0/24
3) /etc/chrony/chrony.conf に記述( Client側)
port 0
にすると、chrony は、Client モードになるみたい。
また、chrony の同期間隔を短くすると、これが一番の曲者でした。こいつの所為で、ロボットが瞬間移動をしきりにしたりします。
iburst が、問題なのかもしれない。
一応、上記で、chrony は、なんとか同期が取れるようになりました。
話を、rtabmap-nishi_stereo_outdoor2_bz3_navi_gps.launch の方に戻しますが、
最終的には、GPS の Publish Rate: 1[Hz] を、もっと上げないと行かない。
4[Hz] に上げました。が、下記ワーニングが、出ちょります。
rtabmap_ros のパラメータの
wait_for_transform_duration=0.2
で変更すれば、簡単だが。遅れている、tf odom -> base_footprint を早くしないといけない。
gysfdmaxb_gps、robot_localization/navsat_transform_node、robot_localization/ekf_localization_node が関係しているので、
多分、ekf_localization_node の tf 出力が遅いのではと思います。
ekf_localization_node の設定を変更
frequency: 4 -> 5
rtabmap_ros_my/launch/param_foxbot/config/ekf_localization/mode1.yaml
これに合わせて、gps rate = 5[Hz] にしました。
gps の rate を上げると、ekf_localization_node で、 gps_odom が、wheel_odom より優先されて、gps の誤差が顕在化するのではと、
感じています。
結局、GPS の精度が低い機器では、あまり使わない方が良い気がします。
いまは、ekf_localization_node で、 wheel odom + IMU で動作しているのと同じかも知れません。
しかし、未だ、下記ワーニングがでちょります。
下記ページに記載があるみたい。
Robot Localization Package: Transform from base_link to odom was unavailable for the time requested. Using latest instead. (IMU+GPS)
EXF に与える、IMU topic と、navsat_transform_node から来た odom topic の timestampの、時間差が多いのが問題みたい。
ekf のパラメータを調整すると良いみたい。
1. Change your transform_time_offset EKF parameter to some small positive value. This will future-date its transform it's generating.
2. Set predict_to_current_time to true for the EKF. That will force the EKF to make a prediction to the current ROS time before publishing,
rather than just publishing the state estimate at the time of the most recent measurement.
1. 少し、時間を+ して、将来の時刻にする。
2. exf に ros の今の時刻を使わせるか。
おんちゃんは、1. の設定にしました。
mode1.yaml
transform_time_offset: 0.2
しかし、これで timestamp が +0.2 されるのは、exf が publish する /odom_fusion (odometry/filtered) ではないのかな?
これで改善するのは、rtabmap_ros の 2つ入力トピックの、Stereo camera からきたトピックと、exf が出力する
odom topic の timestamp のズレではないかと感じるのだが?
ともあれ、これで、ワーニングが消えました。
以上の設定で、なんとかテストできる状態になりました。
ポータブル Wifi router 環境も、ハードの問題はないようです。一番の問題は、chorny の設定でした。
注) T100TA と、Jetsonnano 2G とは、定期的に(今回は、4[分]) に時間合わせをしないと、Stereo Camera の Topic の timestamp が、
ずれたりして、Rviz 上の表示が停止してしまいます。
以前も、テスト途中で、実際のロボットは動いているのに、急に Rviz 上のロボットが停止して、カメラの映像だけが送られてくる。現象に見舞われました。
多分その原因は、時刻のずれだったのかも知れません。
5. Remote 操作。
ROSRemote に遠隔操作に関してのページがあります。どうやら、Spacebrew と言うのを使えば、できるようです。
しかし、こちらの ROS講座21 複数のPCでROS接続2 方が、簡単の様です。
おんちゃんは、やっぱり、python - wsgiref.simple_server を使って API Server を作って、Jetson Nano 2G で、処理させる事にします。
その方が、制約なしに自由にできそうです。
但し、上記 Jetson nano 2G 上の API Server を起動するのに、やっぱり ssh を叩いて、Jetson nano にログインしないといけない。ので、
此処も、Python paramiko を使って、python ssh client で実現します。
python - wsgiref.simple_server で、Jetson Nano 2G 上で動かす、ros api server は、簡単に出来ました。
機能としては、今まで、手動でしていた launch の実行、/dev/ttyTHS1 パーミッションの設定、chorny 時刻合わせなどを、
Web Brouser 上からできるようになりました。
次に、paramiko を使って、ssh client で、jetson nano 2G にログインして、上記 ros api server をリモート PC から起動するのは、
paramiko の不具合で、ssh client で、Jetson Nano 2G にログインした時に、環境変数がまるっきり引き継がれません。
自分で、明示的に環境変数を設定すれば良いようですが、なかなか、これが面倒で、
途中で止めました。
結局、Jetson Nano 上で、sysytemctl で ros api server を自動起動できるようにしました。
こちらも、環境変数が継承されないですが、自分で設定するのは、もっと楽です。
未だ、動作が不安定で、Stereo camera のトピックが Publish されない事があります。
これは、自分で Build した版の OpenCV のライブラリーを、最近、再ビルドせずに、そのまま使っているせいかも知れません。
ともあれ、Jetson Nano 2G が起動した時に、自動で、ros api server が起動するのは便利です。
後は、Remote PC から、簡単に、Jetson Nano 2G の launch ファイルを起動できます。
ここの所は、後日、github で公開する様にします。
まず最初に、おんちゃんは、Remote PC(T100TA) から、自作 Turtlebot3(foxbot_core3) を遠隔起動できるようにしてみます。
次に、Remote PC(T100TA) に、タブレット操作がしやすいように、Python Tkinter で GUI プログラムを作って、
Turtlebot3(foxbot_core3) を遠隔起動、停止をできるようにするぞね。
其れまでは、T100TA の小さいターミナルで、text を 叩いての操作じゃ。
そうすれば、やっと、屋外で走行させることが出来ます。
16. この後。
T100TA で、動かしていましたが、どうも、動作が安定しない、信頼性が無い気がして、ROS2 での開発に入りました。