久々にROS.
ROSのActionLibとかActionServerとかSimpleActionServerについて
http://wiki.ros.org/actionlib/DetailedDescription
をベースにメモ.
(https://github.com/ros/actionlib がgithub レポジトリ)
ActionLibの役割(Simple Action Serverベース)
ROSのActionLibは一回のserviceとかやmsgでのやりとりよりももっと融通効くように状態遷移を持ってタスクを実行できるようにする機能.
ActionLibでの登場人物は「ActionServerの役割を持つNode」と「ActionClientの役割を持つNode」の二つ.
ServerはClientに言われたタスクを行うだけだが、中断できる、タスクの結果も返す、Abortもありうる等いろいろと便利.
ActionLibはそこらへんを一つのライブラリのようにまとめてくれている.
このActionLibを実際に実装したものの一つがSimpleActionServer.これはActionLibが本来想定しているより柔軟な動きを、ActiveとPendingとDoneの3状態だけに絞って実装した名の通りシンプルな受け口にしたもの.有名なActionLibを使っているパッケージはこのSimpleActionServerで事足りている.以下で紹介するjoint_trajectory_actionもSimpleActionServerベース.
以下はActionLibの本来の状態遷移の上にSimpleActionServerベースでの状態遷移を上塗りしている.どこをそれぞれの3状態に要約しているかわかる.
簡単な流れは以下 (ページ一番したの図を見てからの方がいいかも)
1. ActionServerとなっているNodeは、他のActionClientであるNodeからmsgで「ゴール」を与えられて、ActionServerはそれを実行する(大概すぐには終わらない処理).
2. ActionClientはその間何をしててもいい.ActionServerはGoalに向けてタスクを進めつつ、Feedbackのtopicにずっと今の実行状態を吐き出し続ける(実装による)
ActionServerは途中でキャンセルをいつでも受け付ける状態なので、ActionClientからキャンセル命令が出たら今のタスクを中断する.
3. もしキャンセルが来なければ「ゴール」にたどり着くまでタスクを実行して「ゴール」にたどり着いたら終了したことをResultのtopicに投げる
こんな感じ.
joint_trajectory_actionとかは頻繁に使われるNodeだけど、これもActionLibを使って実装されている.
joint_trajectory_actionの場合、例えばロボットがある関節角度Aになるように腕を動かしたいとしたとき.
「Aの状態にして」というmsgをjoint_trajectory_actionに送り、
joint_trajectory_actionは腕を動かしながらその腕の状態をFeedbackのtopicに投げ続ける.このとき、joint_trajectory_actionはいつでもCancelのtopicを受け付ける状態なので、「キャンセルして」というmsgを受けたらそこでタスク終了.
言われることなければ関節角度Aになるまで腕を動かし終わったらresultのtopicに結果を返す.(腕が障害物に当たって諦めることもあるので必ずしも成功とは限らずAbordの可能性もある)
絵で説明するならこんな感じ.
本来のActionServerは,ActionServer自体に状態遷移があるのではなく、
各Goalに状態遷移を持つ. ActionServer自体は複数のゴールを実行してこなしていくことを想定している.
しかし、実運用されているNodeのほとんどはタスク実行中に実行されているGoalは一つだけで、新しいGoalは古いGoalが終わるまでPending状況になる.
