近所の実験場

前回のポストからちょっと日が開いてしまいました...7/8日,つくばチャレンジ説明会&試走会一回目参加してきました.
結論としては,,,ボロボロでした(笑)やっぱりいろいろギリギリでやりすぎててる部分が多く,会場に行って一発勝負しても負けますね(笑)
結局今回はロボットの自律走行は全然無理だったので,とりあえずプレステのコントローラでロボットを動かせるようにして,それでデータを取ってくる予定だったのですが,
現地(つくば)でどうもパソコンの調子が悪くなり,結局最後の15分くらいしか有効活用できませんでした.

自分のロボットは結構小さいほうなので,モニターをつけずに別のノートPCからWIFIでリモートアクセスして使ってたんですが,どうやらPCのグラフィックボードがモニターを認識しなければまともに稼働せず,激遅になって話になりませんでした...事前にチェックしとけばよかったんですが,,,あとの祭りですね.一応レンタカーにPCのモニターとかを持参していたので,会場で不具合が発生するたびに駐車場に戻って車のシガーから電源を取って.という作業を繰り返しました.もう汗だくです.でも,同じような問題に直面している人ってやっぱりいるもんですね.AmazonでモニターをつないでいるようにFakeするためのアダプター?が売られていたので,さっそく購入しました.下記の部品つけると,PCがモニターつながってると錯覚して,うまいこと動いてくれました.

で,ほかのチームからすると当たり前のことなんですが,やっぱり近所に実験場を作って実際に動かしまくるしかないですね.でも,問題はその場所があんまりないことと,周りの目がちょっと恥ずかしいんで控えてたんですが,もう恥ずかしいとか言ってられる状況じゃないので近所で実験場を探すことにしました.

で,見つけました.

f:id:rkoichi2001:20170714220801p:plain

近所の月出松公園!とかっていったら住んでるとこモロバレですが(笑),ええ,近所の公園なんです.
まずは公園の赤で線を引いたところの自律走行を目指したいと思います.早速今週末にロボットを持って行ってデータを取ってきます!
あと,試走会一回目を終えて,いろいろなものが欲しくなり,またまたいろいろ無駄金を投資してしまったのですがそれは明日ポストします.

複数 PC に分散したノードの ROS を使った通信

Jetsonを導入したことで,ロボットにくっついているPCが二つになりました.
今までもマイコンは使っていたのですが,マイコンとPCはシリアル通信だったので複数のPCに散らばったROSノードをくっつけるという作業をするのは今回が初めてになります.きっとはまるんだろうな...と思っていたのですが,ROSのチュートリアルを読みながら進めると意外とすんなりと行きました.

ROS/NetworkSetup - ROS Wiki

ROS/Tutorials/MultipleMachines - ROS Wiki

具体的には,添付のスライドのJetsonとINTELPCをつなぐ部分に当たります.

f:id:rkoichi2001:20170702141622p:plain

で、簡単にできたんですが、ちょっとメモって置かないと忘れそうだったので備忘録を残しておきます。

0. ネットワーク環境のセットアップ

それぞれのPCに固定IPアドレスを割り振ります。/etc/network/interfacesを上書きする方法しか知らなかったのですが、これ超めんどくさいので、GUIでなんとかならないかなと思って調べてたんですが、できました。あと、WiredのポートをROSの通信に使って、Wirelessの通信でインターネットにつなげたかったのですが、これもどうにか解決しました。画面右上のネットワーク関連のマークを右クリックして、そこからGUIで設定していけば完結しました。

f:id:rkoichi2001:20170702144336p:plain

上記のNetwork Connections画面でAddしていく感じですが、対象のボードのMACアドレスEthernetのDeviceコンボボックスから選べるので、ここで選択します。で、次にIPV4設定タブに移って、MethodをManualにして、設定したいIPアドレスを追加します。このときに、AddressとNetmaskだけ指定してGatewayは空白にして設定を完了します。これで固定IPのWiredとDHCPのWirelessが共存してネットも繋がるようになりました。ちなみに、これは正しいかわかんないんですが、/etc/network/interfacesの記述は全部コメントアウトしました。

1.SSH環境のセットアップ

おそらく、マスタのPCからスレーブにログインしていろいろと操作をする形になるのかなと思います。なので、リモートログインできるようにスレーブ側にSSHを入れておきます。いれて再起動すれば、ポートを開けて待っててくれました。

sudo apt-get install openssh-server

2.ホスト名の解決

IPアドレスで毎回入れるのも辛いので、それぞれのパソコンにホスト名解決のためにIPアドレス・ホスト名の対を記述します。/etc/hostsファイルにl,0で決めたIPアドレスとそのアドレスのPCの名前の対を記述します。

10.0.0.10 master_pc
10.0.0.20 slave_pc

みたいな感じです。ここで登録しとけば、sshでつなぐ時とかにもtab補完で教えてくれます。

3. PINGで通信の確認。

マスターからスレーブ、スレーブからマスタへPINGをうって、通信確認。

4. ROSノードの起動

複数PCがあっても、ROSのマスタはひとつ出なければいけないので、マスタとなるPC上でroscoreします。

マスタ側でやること。

roscore実行
roscore
システム上で、どいつがマスタか宣言、あと自分のIPをROSに伝える。
export ROS_MASTER_URI=http://master_pc:11311
export ROS_IP=10.0.0.10
roslaunch hogehogemaster.launch

スレーブ側でやること。(SSHでリモートログインすると仮定してます。)

sshログイン
ssh xxxx@slave_pc
(パスワード入力)
export ROS_MASTER_URI=http://master_pc:11311
export ROS_IP=10.0.0.20
roslaunch hogehogeslave.launch

5. Jetsonでステレオの視差計算を実施して、マスタで描画。


f:id:rkoichi2001:20170702164017p:plain

ということで,ひとまずできました.上記添付写真を見てもわかる通り,JETSON使うとステレオの視差計算が自分のPCでやるよりだいぶ早くなりました!
大体10FPS位出てます.能力的にはまだ余裕ありそうなので,どこまでをJETSONの役割にするか,考えてみます.JETSONの性能とか,細かいとこはまた後日エントリで書きます.
うーん.やっぱりやること多すぎで間に合わないな...

NVIDIA Jetson Tx2 + Ubuntu 16.04 + アサヒドライプレミアム

月末のプレミアムフライデー,定時退社日と酒を飲むにはもってこいの状況だったのですが,来週には試走会一回目があり...
かえってひたすら作業に没頭すべきかどうか,非常に難しい判断を強いられました.結果的に,ビールが飲みたくて仕方なく,のみ「ながら」にしました(笑)
朝のエントリで書いたと思うのですが,NVIDIAのJetsonTx2を買って画処理をそれでやろうと思っているのですが,その設定で時間がかかりそうだったので,
少々酔っててもいいいかと思い.
(先日,一人ロボットの孤独に耐えかねて,Facebookでブログのリンクを公開したこともあり,だいぶゆるゆるの雰囲気になってると思いますが,今後はこんな感じで行きます(笑))

で,NVIDIAのJetsonですが,自腹で買いました.10万円なり...やっぱいろいろと金かかりますね...

f:id:rkoichi2001:20170630214850j:plain

Jetpackの最新版3.0を入れて,ホストPCからJetsonにフラッシュしました.Jetson自体は Ubuntu 16.04で動くのですが,HostPCはUbuntu14.04での動作保証しかしていないらしく,なんていけてないんだと思ったのですが,Ubuntu16.04でも大丈夫でした.Jetpackから最新のバイナリイメージをフラッシュして,今ROSをインストールしてます.

で,Jetsonとは何ぞや?という話なんですが,いまDeepLearningのブームもあって並列計算を手軽に実現できるハードウェア?がオタクの間では大流行してます.
何かの仕事(A, B, C)をしないといけないときに,Aを片付けてからBを,Bを片付けてからCをという順番でないと片付かない仕事なら順番にやっていくしかないと思うのですが,仕事の種類によってはAの結果がBには関係なく,Bの結果もCには関係なくみたいなことって結構あると思います.(まさに画像処理とかDeepLearningがそんな感じだとおもうんですが.)この場合,同時にいっぱい仕事ができたほうが早くおわりますよね?こんな感じで,互いの仕事の結果に依存関係がない場合,できる限り同時進行できる数を増やしたほうが早く終わると思うんですが,このJetson,その同時進行できる数が普通のパソコンよりけた違いに多いんです.

もともと,NVIDIA自体はパソコンのグラフィックスを表示するための計算処理ハードウェアを作ってた会社(だと思うんですが)だったんですが,どうやらこのグラフィックス処理のハードウェアというのもいかに並列に処理できる数を増やすか的なことにポイントがあるらしく,今はグラフィックスというよりいろんなとこに進出してます.車載の世界では,Toyota, Audi, BoschNVIDIAのDrive PXというハードを使って自動運転を実現するロードマップを描いていて,車載の分野で存在感が抜群に上がってきてます.

monoist.atmarkit.co.jp

で,このDrive PXですが,個人で買うと200万くらいします(笑)かつ,電気をいっぱい食うので大きなバッテリーが必要で,僕のロボットに乗せると確実にタイヤがつぶれます.で,その廉価版というか,もっと小規模なロボット用に作られたものが Jetson になります.これを今回買いました.こいつにステレオの視差計算とかビジュアルオドメトリの計算とかをさせて,何とか5FPS位出ればハッピーかななんて思ってます.一応,普通のPCっぽくも動くんですが,フラッシュした後,JetsonでUbuntuを立ち上げたのが下記の写真になります.

f:id:rkoichi2001:20170630220606j:plain

今晩ステレオの視差計算をJetsonでできるとこまで行けばいいんですが,,,そこは作業のはかどり具合と酔いの回りの勝負ですね.

f:id:rkoichi2001:20170630220753j:plain

今後の人のために,二つだけ
1.JetpackはUbuntu16.04のホストPCからでもフラッシュできる.
2.Jetpackのフラッシュは若干相性があり,うまくいかないことがある.自分の場合は,手持ちのノートPCでどうしてもうまくいかなかったので,デスクトップでやったらすんなりいきました.

ということで,ステレオを動かすとこまで行けば,またポストします.

一回目試走会(7/8)に向けて

うーん...来週の説明会&試走会ですが,あと一週間になりましたが,,,ロボット走らせるところまでもっていくのはだいぶ難しそうです.
今回を逃すと,次は9/23でだいぶ後ろになってしまうのでどうにか脱初心者コースを達成したかったんですが...

実際に走らせるところまで達成しようとすると...

1.NVIDIA Jetson のセットアップ
2.NVIDIA Jetson のターゲットコンパイル・動確
3.AMAZON で Jetson が動くバッテリーの購入.
4.ステレオデータを用いた ROS AMCL パッケージの変更
5.Navigation Stackの調整

くらいですかね...どう考えても終わらないなあ...
とりあえず週末頑張ります.次はJetsonの記事をアップします.

ステレオカメラを用いた OGM の作成2 @ 大清水公園

やりました!やりましたぞ!くらいのテンションで今日の朝5時にコードをいじってました.
Visual Odometryを使ってセンサドリフトの影響を除去し,そのオドメトリ結果を用いてステレオカメラのデータを使ってOGMを作る.
ということをやってましたが,今日一応できました.やっぱり,バンドル調整とか全体最適化みたいなことをやってないので,部分的にちょっと怪しい
とこはあるのですが,一応マップとしては使えるのではないかと.これでだめだと,ちょっと辛いです.

ステレオデータをマッピングした結果
f:id:rkoichi2001:20170628204550p:plain

Google Earthから取った大清水公園のルート
f:id:rkoichi2001:20170628205447p:plain

Google Earthの赤線は自分がランダムで引いたものなので,実際のロボットの軌道とはちょっと違いますが,木の本数とか歩道脇の花壇の段差とかはある程度拾えていると思います.
これで,大清水公園の全体地図ができたので,今度は実際にロボットが無人走行しているときにデータを取得して,そのデータが「この地図のどこと一番似ているか?」ということことを
利用して「この地図の中で,ロボットはどこを走っているか?」ということをはっきりさせます.

やっていることはGoogle Carもおなじなんですよ!(恥ずかしくなるくらい素朴ですが(笑))

明日からは,その時の時で取ったデータを,上記の地図にどうマッチングさせるかの部分を作っていきます.

Visual Odometry @ 大清水公園

前回の投稿から、ほぼほぼ一ヶ月。。。ちょっとサボり気味になってしまいました。。。
7/8の試走会に向けて、大清水公園のマップ作成をしていました。車輪速センサで生成したオドメトリをベースにZEDとSGBMで生成した測距データを二次元に投影することでOGMを
作ろうとしていたんですが、車輪速センサベースのオドメトリだとどうしてもドリフトの影響が大きくなってしまい、耐えられませんでした。

ということで、
1. Visual Odometry でオドメトリを生成し、そのデータをベースにOGMを作成する。
2. 1で精度が足りてない場合、バンドル調整やSLAMを使う。

という2つのアプローチでマップの精度改善に取り組むことに決めたのですが、Visual Odometryが当初思っていたより難しく、ちょっと時間がかかってしまいました。
ベースとなるコードは下記のリンクで、(OpenCV, FAST Feature, Optical Flow Tracking)ソースコードもシンプルだったので簡単に作れるかと思っていたのですが、
E行列の推定にカメラの位置移動が必要で(単純回転だと方程式が退化してしまう。)あることを知らずにずっとハマってました。

Avi Singh's blog

結果としては下記の通りで、緑線が車輪速センサベースの自己位置推定結果、赤線がVisual Odometryの自己位置推定結果でドリフトの影響が取りのぞけました。
明日からは赤線をベースにステレオの測距データを投影します。試走会一回目(7/8)まであと2週間。。。ちょっと自律走行させるとこまでは間に合わなさそうですが。。。
諦めずがんばります。。。

f:id:rkoichi2001:20170626073302p:plain

大清水公園 + SGBM + Cuda ステレオマッチング

ZEDのSDKについてくるステレオのパフォーマンスがどうもあまり良くないため,オープンソースのSGBMを探して使ってみることにしました.
結果,,,ビンゴでした.ZEDのライブラリよりも,遥かに性能が上がりました.

www.youtube.com

SGM実装
GitHub - dhernandez0/sgm: Semi-Global Matching on the GPU

Stixel実装
GitHub - dhernandez0/stixels: GPU-accelerated real-time stixel computation

上記のリンク先の実装はどちらもCuda化されていて,ちゃんと整理されていたので簡単にラッパーを作るだけで動きました.
本当はStixelのラッパーも作って実験するつもりだったのですが,ちょっと間に合わなかったのでまた明日.
Stixelの地面からの生え際だけを環境地図に取り込んでOGMを作るというのが直近の目標です.
週末までにはアップできると思うので,お待ち下さい!!