うごくものづくりのために

技術的な備忘録がメインです。

navigationスタックを理解できそう

やっとぼんやりながら正体が掴めつつあるので、メモを随時残していきます

2016/10/11 追記

座標系のところに、REP 105(座標系についてまとめたROSの文章)の一部翻訳を乗せました。(正確ではない可能せがあります)

wikiのこれ(下画像)の階層構造

f:id:tilt_silvie:20150927185827p:plain だいたいこんな感じ(だと思います)

  • navigation
    • move_base

      • navcore

        • BaseGlobalPlanner Plugins
          • navfn
          • global_planner
          • carrot_planner
        • BaseLocalPlanner Plugins
          • base_local_planner
          • dwa_local_planner
        • RecoveryBehavior Plugins
          • rotate_recovery
          • clear_costmap_recovery
          • move_slow_and_clear
      • costmap_2d

        • voxel_grid
      • (move_base_msgs)

    • map_server

    • amcl

    • fake_localization
    • robot_pose_ekf

move_baseが親玉

move_base - ROS Wiki

move_baseに、種々のプラグインが実装されて、経路生成を行っている

  • global_costmap および local_costmap

  • global_planner

  • local_planner

  • recovery_behaviour


global_costmap および local_costmap

プラグイン実体は、 costmap_2d

http://wiki.ros.org/costmap_2d

障害物の登録

costmap_2dは、LaserScan or PointCloud型のメッセージを障害物として設定することができる

navigation/Tutorials/RobotSetup - ROS Wiki

コレの中ほどに説明あり

マップレイヤー

変わらないマップ map_serverで生成できると思う

PointCloud or PointCloud2 or LaserScan型のtopicを勝手に読んで障害物としてくれるらしい

障害物のサイズも変更できる(というかロボットの安全領域を広げる?)ので、おそらくロボットの中心座標をPointCloudとしてぶちこめばOK


global_planner

プラグイン実体は、move_base/base_global_plannerというパラメータとして与える

デフォルトだと、navfn/NavfnROSになっている

navfn(ダイクストラ)よりも、global_planner(NF1, A*とか?)のほうが良さそう


local_planner

プラグイン実体は、move_base/base_local_plannerというパラメータとして与える

デフォルトだとbase_local_planner/TrajectoryPlannerROSになっている

base_local_plannerよりも、dwa_local_plannerのほうがいいらしい (dwa_local_plannerはbase_local_plannerの焼き直しだとか)

dwa_planner vs. base_local_planner - ROS Answers: Open Source Q&A Forum


recovery_behaviors

障害物にぶつかってスタックしたときに回復するためのやつ

SSLではたぶん必要ないので、move_base/recovery_behavior_enabledパラメータをfalseにしてディスエーブルしよう

座標系

Navigation stackの座標系を確認する: 花岡ちゃんに花束を

以下の3つの座標をtfする

map : 一番上のレイヤ 真のワールド座標

odom : オドメトリ mapレイヤの下にくる オドメトリと真のワールド座標のずれを表現する

base_link : オドメトリでのロボット位置

ワールド座標上でのロボットの真の位置は、

mapレイヤとodomレイヤのずれ + odomレイヤ上でのbase_linkの位置 として表現できる

2016/10/11 追記分

REP 105 -- Coordinate Frames for Mobile Platforms (ROS.org)

  • base_link

"base_link"と呼ばれる座標系は移動ロボットの土台に固定されます。 "base_link"は任意の位置、方向の土台に与えられます。 REP 103[1]に好ましい方向の与え方が明記されています。

  • odom

"odom"と呼ばれる座標系は世界に固定された系です。 "odom"上の移動ロボットの姿勢は時間とともにドリフトします。 このドリフトのため"odom"を長い期間の絶対座標として用いることは出来ません。 しかしながら、"odom"上でのロボットの姿勢は連続であることが保障されます。 これは、"odom"上でのロボットの姿勢が離散的に飛ぶことなく、スムーズに接続されることを表します。

一般的なセットアップでは、"odom"フレームは、車輪オドメトリやビジュアルオドメトリ、慣性センサなどによって計算され、与えられます。

"odom"は短時間には正確な座標系として使えますが、ドリフトがあるため長時間のリファレンスとすることは厳しいです。

  • map

"map"は世界に固定された系で、Z軸は上向きです。 "map"に対して相対的なロボットの姿勢は、時間とともに大きくドリフトすべきではありません。 "map"は不連続です。これは、"map"上のロボットの姿勢が離散的に飛ぶ可能性があることを表します。

一般的なセットアップでは、位置推定を行うコンポーネントが、センサの観測に基づいて"map"上でのロボットの姿勢を計算しなします。 そのため、ドリフトは都度修正されますが、新たなセンサ情報が来た際に"map"上のロボットの位置は離散的に移動する可能性があります。

"map"は、長時間の絶対座標として用いることができます。 しかし、離散的なジャンプが発生するため、センシングやアクチュエーションのために用いる短時間の正確な座標としては適切ではありません。

追記ここまで

シミュレータ上で動かすときはfake_localizationが便利そう

fake_localization - ROS Wiki

実際に運用するときは、robot_pose_ekfでいけそう めちゃ便利そう

ただし、非ホロノミック移動体(自動車や、マイクロマウスのような二輪移動ロボット)のみが対象ぽい

robot_pose_ekf - ROS Wiki

センサ情報のセッティング

tf

navigation/Tutorials/RobotSetup/TF - ROS Wiki

これはSSLには必要ないかも

吐かないといけないもの

ロボット上でのレーザーセンサの取り付け位置

sensors (障害物検知)

navigation/Tutorials/RobotSetup/Sensors - ROS Wiki

吐かないといけないもの

障害物情報としてのLaserScan か PointCloud

odom (オドメトリ)

navigation/Tutorials/RobotSetup/Odom - ROS Wiki

吐かないといけないもの

map->odomのtf

odom->base_linkのtf (本来は、mapとodomのtfからamclが吐いてくれるが、今回は使わないので自分で吐く)