2010年4月27日火曜日

navigationスタック探訪その2(move_base)

ようやくnavigation stackの全容が分かってきました。

まず、pluginlibパッケージをご存知ですか?
common stackの中にあるのでこれは必須科目でしょう。

知らなければまずそれを勉強してください。
はい、僕は知りませんでした。

次にmove_baseパッケージを見ます。
これがPR2のnavigationの実体です。

しかし、ここでは部品を実体化しているにすぎません。
中身はプラグインになっているのでいれかえが可能です。
それらはパラメータでプラグイン名を指定します。

設定は以下のようになっています。


~base_global_planner (string, default: "navfn/NavfnROS" For 1.1+ series)
~base_local_planner (string, default: "base_local_planner/TrajectoryPlannerROS" For 1.1+ series)
~recovery_behaviors (list, default: [{name: conservative_reset, type: clear_costmap_recovery/ClearCostmapRecovery}, {name: rotate_recovery, type: rotate_recovery/RotateRecovery}, {name: aggressive_reset, type: clear_costmap_recovery/ClearCostmapRecovery}] For 1.1+ series)


recovery_behaviorsはちょっと理解できていないので後で見るとして、
global_plannerはnavfnパッケージ、local_plannerはbase_local_plannerパッケージに
定義があることが分かります。
それらはnav_coreで定義されるインタフェースを満たすプラグインになっている。
ということになります。
いやー、複雑ですね。

つまり、pluginlib、navfn、base_local_planner、*_recovery、move_baseという感じで見ていくのが良さそうです。
あとはamcl(自己位置推定)ですね。こっちは独立してるようです。

自律移動(navigation)は形をROSのメッセージで規程するのではなく、nav_coreで決めた形にプラグインを作ってもらい、それを集めて実体化する、というやり方になっています。

全然ROSっぽくないです。
これでいいんでしょうか?
形を規程できるからこの構成がいい?
それとも結合度が強すぎてよくない?
それとも地図を同一プロセスで持ちたいとか(パフォーマンス)の問題??

Player関係の構成をひきずっているんじゃないかと思うんですが、
Player詳しい人教えてください。

1 件のコメント:

  1. はじめてコメントします.Web 系技術者からロボティクスに転身中で,今は米国の日系企業で働きながら学んでいる者です.日本人の上司もよくこのブログを reference として与えて下さいます.

    本記事の最後の ROS の問いは,↓ここの議論が近いかも知れませんね.
    http://answers.ros.org/question/2284/what-is-the-reasoning-behind-current-architecture
    とはいえ ”ROS っぽくない” という点をクリアにする回答はありませんが,一応私も回答を投稿してみてます.

    ロボティクスまだ初心者マークを抜け切れてないですが,よくありがちなロジックを,流れだけを定義して実装をプラグインにする,というのはあまりやらないのでしょうか?

    返信削除