見出し画像

ROS入門 (59) - MoveItのコンセプト

「MoveIt」のコンセプトの概要をまとめました。

前回

1. MoveItのシステムアーキテクチャ

下図は、「MoveIt」のシステムアーキテクチャです。「move_group」と呼ばれるノードがアーキテクチャの中心となります。このノードは、ユーザーが使用できるROSのアクションとサービスを提供します。

◎ move_groupのユーザーインターフェース
move_groupは、次の3つのインタフェースで利用できます。

・C++ : move_group_interfaceパッケージ
・Python : moveit_commanderパッケージ
・Rviz : Motion Planningプラグイン

◎ move_groupのコンフィギュレーション
move_groupは、パラメータサーバー経由で、次の3つの情報を取得します。

・URDF : パラメータ名「robot_description」で取得。
・SRDF : パラメータ名「robot_description_semantic」で取得。
・MoveIt構成パッケージ : パラメータサーバー経由で、関節の制限、運動学、動作計画、知覚などの情報を取得。

◎ move_groupのロボットインターフェース
move_groupは、ROSのトピックとアクションを通じてロボットと通信します。 ロボットから関節角度やセンサーデータなどを取得し、それを元にコントローラでロボットを制御します。

move_groupが送受信する情報は、次のとおりです。

・JointStates
move_groupは、「/join_states」トピックで現在のロボットの関節角度を取得します。move_groupは、独自のJointStatesパブリッシャーを提供しないため、各ロボットで実装する必要があります。

・TF
move_groupは、「TFライブラリ」を使用して「TF」を取得します。ロボットがTFを公開するには、「robot_state_publisher」ノードを実行する必要があります。

・FollowJointTrajectoryAction
move_groupは、「FollowJointTrajectoryAction」を使用してロボットを制御します。 ロボットはこのアクションを処理する必要があります。

・PlanningScene
「move_group」は、「PlanningSceneMonitor」を使用して、ロボットの世界と現在の状態を表す「PlanningScene」を維持します。 これによって、ロボットの状態に、ロボットにアタッチされているオブジェクトを含めることができます。

・MoveIt Setup Assistant
move_groupが送受信する情報は、簡単に機能を拡張できます。「ピックアンドプレース」「キネマティクス」「モーションプランニング」など、個々の機能は、個別のプラグインとして実装されます。多くは、「MoveIt Setup Assistant」によって設定します。

2. モーションプランニング

◎ モーションプランナー
「MoveIt」のモーションプランニングでは、プラグインを介して様々な「モーションプランナー」を使用できます。デフォルトは「OMPL」で、「Pilz」と「CHOMP」も選択できます。

◎ モーションプランニングのリクエスト
モーションプランニングのリクエストは、モーションプランナーに実行させたいことを指定します。 通常、「アームの移動」または「エンドエフェクターの姿勢」を指示します。衝突判定は自動的に行います。また、制約を付加することもできます。

・位置の制約 : 任意の領域内にリンク位置を制限。
・方向の制約 : リンクの方向を任意のロール・ピッチ・ヨー範囲内に制限。
・可視性の制約 : リンク上のポイントを任意のセンサーの可視性コーン内に制限。
・ジョイントの制約 : ジョイントの制限。
・ユーザー指定の制約 : ユーザー定義のコールバックで独自の制約の設定。

◎ モーションプランニングのレスポンス
move_groupは、モーションプランニングのリクエストに応じて、目的の軌道を返します。この軌道により、アームが目的の位置に移動します。move_groupから得られる結果は、単なるパスではなく軌道であることに注意してください。

◎ モーションプランニングのパイプライン
モーションプランニングのパイプラインは、「モーションプランナー」と「プランニングリクエストアダプタ」を繋ぎます。「プランニングリクエストアダプタ」を使用すると、モーションプランニングリクエストの前処理と、モーションプランニングレスポンスの後処理が可能になります。

・FixStartStateBoundsアダプタ : 開始状態をURDFで指定されたジョイント制限内に修正。
・FixWorkspaceBoundsアダプタ : プランニング用のデフォルトのワークスペース(10m x 10m x 10m)を指定。
・FixStartStateCollisionアダプタ : ジョイント値を少しだけ摂動させることにより、指定された衝突中の設定の近くで、新しい衝突のない設定をサンプリング。
・FixStartStatePathConstraintsアダプタ : モーションプランニングの開始状態が指定されたパス制約に従わない場合に適用。

3. プランニングシーン

ロボットの周囲の世界を表すために使用され、ロボット自体の状態も保存します。これは、move_groupノード内の「PlanningSceneMonitor」によって更新されます。


「PlanningSceneMonitor」は、以下をリッスンします。

・関節角度 : joint_statesトピック。
・センサー情報 : WorldGeometryMonitorを利用。
・WorldGeometry情報 : planning_sceneトピック。(ユーザー入力)

◎ WorldGeometryMonitor
ロボットのセンサーとユーザー入力からの情報を使用して、WorldGeometryを構築します。占有マップモニターを使用して、ロボットの周辺の3D表現を構築し、planning_sceneトピックでそれを補強します。

◎ 3D Perception
占有マップモニターによって処理されます。 占有マップモニターは、上の図に示すように、プラグインを使用して、様々な種類のセンサー入力を処理します。特に、MoveItには、次の2種類の入力を処理するためのサポートが組み込まれています。

・点群 : 点群占有マップアップデータプラグインによって処理。
・深度画像 : 深度画像占有マップアップデータプラグインによって処理。

4. キネマティクス

◎ Kinematicsプラグイン
MoveItは、プラグインインフラストラクチャを使用します。特に、ユーザーが独自の逆運動学アルゴリズムを記述できるようにすることを目的としています。 このプラグインは、「MoveIt Setup Assistant」によって自動的に設定されます。

◎ IKFastプラグイン
多くの場合、ユーザーは独自のキネマティクスソルバーを実装することを選択できます。 PR2には独自のキネマティクスソルバーがあります。 このようなソルバーを実装するための一般的なアプローチは、IKFastパッケージを使用して、特定のロボットで動作するために必要なC++コードを生成することになります。

5. 衝突判定

MoveItでの衝突判定は、CollisionWorldを使用してPlanningScene内で構成されます。主にFCLパッケージを使用して実行されており、ユーザーが衝突判定がどのように行われているかを、気にする必要がないように設計されています。

◎ 衝突オブジェクト
MoveItは、様々なのオブジェクトの衝突判定をサポートしています。

・メッシュ
・プリミティブ
・Octomap

◎ Allowed Collision Matrix (ACM)
衝突判定は非常にコストのかかる操作であり、モーションプランニング中の計算コストの90%近くを占めることがよくあります。 Allowed Collision Matrix (ACM)は、ボディのペア間を衝突判定する必要性に対応するバイナリ値をエンコードします。 ACMで2つのボディに対応する値が1に設定されている場合、これは2つのボディ間の衝突チェックが不要であることを指定します。 これは、2つのボディが常に遠くにあり、互いに衝突しない場合に発生します。

6. 軌道処理

◎ 時間のパラメータ化
モーションプランナーは通常、「パス」のみを生成します。つまり、パスに関連付けられたタイミング情報はありません。MoveItには、これらのパスを処理し、個々の関節に課せられる最大速度と加速度の制限を考慮して適切に時間パラメーター化された軌道を生成できる軌道処理ルーチンが含まれています。これらの制限は、ロボットごとに指定された「joint_limits.yaml」から読み取られます。

次回



この記事が気に入ったらサポートをしてみませんか?