Navigation stackの座標系を確認する

ROSさんお手やわらかに：ROS青雲編

ナビゲーションスタックにはいろいろと決まり事がある。今回は、座標系の名前と関係を確認しておく。このページに解説があるが、デフォルトでの座標系はこうなっている。

mapは固定したフレーム（座標系）だ。これは、ロボットの置かれた環境（室内など）を表す。ここに投影されるロボットのポーズ（位置と方位）は、その環境でのロボットの状態だ。

odomはmapと同じ固定フレームだが、これはオドメトリから推測されるロボットのポーズを表す座標系。mapとの違いはオドメトリの誤差などを含んでいるということだ。つまりodomではx=1.0,y=2.3でも、実はmapではx=0.9,y=2.0だったりするということだ。以前やったroombaの実験では、odomをrvizでモニターして、目視でmap、すなわち現実の環境とのずれを見ていたことになるだろう。

base_linkはこれらとは異なり、ロボットのセンターを原点とする、ロボットともに移動、旋回する座標系だ。ここから見ると障害物が進行方向の右にあるか左にあるか簡単にわかるので、障害物回避なんかはやりやすそうだ。

親子関係は　map→odom→base_link となっている。

Kinect for WindowsはROSで使えないことに気づく

ROSさんお手やわらかに：ROS星雲編

昨年買って、Windowsで試したままお蔵入りになっていた、Kinect for WindowsをROSで試してみた。参考にしたページはここ。

結果は表題のとおりだ。英語のQAページを調べて分かったが、ここに日本語でしっかり書いてあった。

残念だがKinect XBOX360を買い直した。どうも行き当たりばったり過ぎるような気がする。遊びとはいえ、もう少しよく考えないと、開発費が膨らんでしまう。これでは呑み代に影響が出そうだ。

costmap関連の資料を翻訳する

ROSさんお手やわらかに：ROS青雲編

予定通りcostmapを勉強した。つまりは、shakeyの時代同様の占有マップを取り扱う仕組みだ。以前試作したシェーキーの模型でも同様のマップ作成を試してみた。これのもっといい版という訳だ。

簡単に言えば、その環境のマップ（部屋の構造などを示したマップ）にグリッドをかけ、そのグリッドのセルに危険度に応じた数値を置くことで、障害物マップとするようだ。これをコストマップと呼ぶらしい。

コストマップには、グローバルコストマップという、例えばロボットの置かれた室内全体の大きなグリッドと、ローカルコストマップという、ロボットを中央に据えた移動式の小さなグリッド（これはロボットの方向に会わせて、くるくると回るようだ）がある。

ローカルコストマップは、ロボット近傍の障害物回避に、グローバルコストマップは移動計画の立案に使われるようだ。

costmapのページを翻訳したものは下記に。僕には訳しにくい部分も多く、そういう部分は機械翻訳の結果を突っ込んである。

「costmap.txt」をダウンロード

Navigation stack関連の資料を和訳する

ROSさんお手やわらかに：ROS青雲編

ハード周りは飽きたので、もう一度roombaに戻ってナビゲーションスタックを試して見ようと思う。今までのパッケージとは違って、かなり大規模なモノなので、ちゃんと翻訳しながらやらないといけない。

まずはパッケージサマリだが、これはまあいいだろう。セットアップについてのドキュメントはかなりややこしいので、コレは翻訳しておこう。（Winで書き始めたせいか文字コードがShift-JISになっている）

「nav_setup.txt」をダウンロード

読んでみると、コストマップがキモのようだ。これも結構分量があるので、これも翻訳しておいた方が良さそうだ。

ここまででわかったことは、

●ナビゲーションスタックにゴール位置を何らかの方法で与えると、ロボットがそこへ移動する。

●「コストマップ」というのが、その環境の障害物などの情報を保持している。

●world座標系に乗ったグローバルコストマップと、ロボットの座標系に乗ったローカルコストマップの二つが必要。

URGデータを作ってみる

ROSさんお手やわらかに：ROS青雲編

ここまで来たのなら、Hanabot1に測距センサを載せてturtleBotのようにROSで使えるロボットにしたい。

センサのデータはオリジナルのデータフォーマットを作らずに、sensor_msgs/LaserScanの形で流すようにしたい。これなら、rvizでモニタできるので、開発が楽だ。

試しに、ダミーのLaserScanデータを作成するdmylaser.pyと、これをちょっとばかりオフセットしてTFに設定するtesttf.pyを作ってrvizで見てみた。(この辺を参考に）hanabotパッケージのフォルダに二つのファイルを置いて、rosrunで起動するだけだ。

dmylaser.py

testtf.py

ちっぽけな点々がダミー障害物の位置だ。これはdmylaser.pyの

laser.ranges = [0.5, 0.6, 0.7, 0.8, 0.9, 1.0, 1.1, 1.2, 1.3, 1.4, 1.5]

で、値を設定している。単位はmだ。まだデータの数と方向が思ったようになっていないが、ともあれこんな感じでデータを作れば、レーザースキャナ(URG)よりずっと測定点が少ないセンサでも、データを送れることがわかった。

ただ、レーザースキャナのようにスピーディにマッピングができるわけではないだろう。測定点がすくないのだから。

１／８になったのかな

ROSさんお手やわらかに：ROS青雲編

roombaプラットフォームとの比較はこんな感じ。

上から見るとこんなふう。

もう一回り小さくも組めそうだ。あとは URGさえなんとかなれば、roombaプラットフォームの代わりになるが、どうせならpoor man's turtlebotということで、センサも安いものを開発したいところだ。