navigationスタックを理解できそう
やっとぼんやりながら正体が掴めつつあるので、メモを随時残していきます
2016/10/11 追記
座標系のところに、REP 105(座標系についてまとめたROSの文章)の一部翻訳を乗せました。(正確ではない可能せがあります)
wikiのこれ(下画像)の階層構造
だいたいこんな感じ(だと思います)
- 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
- BaseGlobalPlanner Plugins
costmap_2d
- voxel_grid
(move_base_msgs)
map_server
amcl
- fake_localization
- robot_pose_ekf
move_baseが親玉
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
コレの中ほどに説明あり
マップレイヤー
- Static Map Layer costmap_2d/hydro/staticmap - ROS Wiki
変わらないマップ map_serverで生成できると思う
- Obstacle Map Layer costmap_2d/hydro/obstacles - ROS Wiki
PointCloud or PointCloud2 or LaserScan型のtopicを勝手に読んで障害物としてくれるらしい
障害物のサイズも変更できる(というかロボットの安全領域を広げる?)ので、おそらくロボットの中心座標をPointCloudとしてぶちこめばOK
- Infration Layer costmap_2d/hydro/inflation - ROS Wiki よくわかってないけど、たぶんロボットの安全領域を広げる的なやつ
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が便利そう
実際に運用するときは、robot_pose_ekfでいけそう めちゃ便利そう
ただし、非ホロノミック移動体(自動車や、マイクロマウスのような二輪移動ロボット)のみが対象ぽい
センサ情報のセッティング
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が吐いてくれるが、今回は使わないので自分で吐く)