ソフトウェア構成
motoman_projectのソフトウェア構成の概要を図で示します。
下図のようになっています。プライマリとなるのがmotoman_projectです。
ざっくり下図の通りです。
ざっと比較できるように、それぞれの構成図を併記します。実機側の作りがかなり異なることが見て取れると思います。シミュレータ側はGazeboを使うので、当然変わりはありません。
このIssueでの議論とソースコードを参照して書いてあります。変なことが書いてあったり、ここが分からないとかあれば、遠慮なくご指摘ください。
本リポジトリのソフトウェア構成について最も注意すべき点は、Motoman側のコントローラがros_controlに適合していないという点です。そのため実機・シミュレーションで、共通のros_controllerとHardwareInterfaceを用いるという、一般的なros_controlの設計思想とは異なる作りになります。
YaskawaのROS-I版コントローラであるmotoman_driverに関しては、MotoPlusなるソフトウェアの仕様に合わせてそのような構成になるとのことです。
とはいえ多分、これはYaskawaだからという話ではなく、おそらくメーカ問わず手っ取り早くROS-I対応させようとしたときに生じてしまう問題です。ros_controllerを作るとなると、既存の制御器をまるごと作り直しになりますし、パソコンでしかもROSの不安定な周期で制御するとなった瞬間に既存のリアルタイム性を担保できなくなるとか、結構な色々な問題を抱えることになるかと。
-
robot_state_publisherとTFメッセージはなんとなく追加。
-
RobotHWを使用しない。- そのかわり、中身はブラックボックスに。
- 会社の技術資産だから守っているのと、流用したほうが楽ちんだから。
-
ControllerManagerを使用しない。 -
JointStateControllerを使用しない。
-
ROS-Iのmotoman_driverを使用する。 -
Moveit!のactionlib_msgをハンドリングするためのmotoman_control_nodeを使用する（研究室オリジナルで作っている）。-
motoman_driverが指令値としてサブスクライブするtopic_msgに変換をかけている。 - 目標到達判定もここでやっている。
action_serverのgoal状態を判定するため。
-
-
JointStateControllerの代わりにjoint_statesをパブリッシュしているのは、多分motoman_driverだよね（それ以外この情報を持っている人がいないと思う）。