前回の振り返り & 今回の概要

　前回の記事では、動歩行動作を完成させました。前々回の実装における問題点を改善し、足を引きづらない動歩行動作を完成させました。
　今回からは、理論の話よりも、歩行パターン生成器とその周辺ソフトウェアの開発について主に進めていきます。
　今回は開発するソフトウェアの構成、ソフトウェアアーキテクチャの話をしていきます。

前回の記事↓

odome.hatenablog.com

開発リポジトリ↓

github.com

何を開発するのか

　一言でこれから開発していくものを示すと、汎用性・拡張性を考慮した歩行制御ソフトウェア、です。
　前回まで開発してきたのは、歩行パターンを生成してシミュレータ上のロボットに適用するソフトウェアです。これを歩行パターン生成器として扱って来たわけですが、現状ではあまり整備されておらず、他の人に使ってもらえるような状態になっていません。加えて、現在の理想的な環境ではない場合に有効な歩行安定化制御系など、歩行パターンを生成する以外に必要なソフトウェアが含まれていない、あるいは不十分であったりします。
　これら不足しているソフトウェアを含んだ全体を、歩行制御ソフトウェアとして開発していきます。

開発するソフトウェアアーキテクチャ

　ソフトウェアを開発する場合、（特に私が思う）重要な要素として、そのソフトウェアの構成・構造が挙げられます。ここで、ソフトウェアの構成、構造、そして拡張性や再利用性などの性質を含めてソフトウェアのアーキテクチャと呼ぶことにします。
　このソフトウェアアーキテクチャを決めるために、以下の要素に重点を置きます。

シンプルに、わかりやすく
- ヒューマノイドロボットの初学者にわかりやすい設計にする。
- UserがREADMEやWikiを見て、すぐに構造、設計がわかるようにする。
- 入り組んだ設計にせず、必要最低限の要素のみを含んだ設計にする。
拡張性の確保
- 歩行パターン生成手法など、制御や実装に関する複数の要素をUser側で独自に実装できるようにする。
汎用性の確保
- 根幹や大幅な変更を加えることなく、User側はパラメータ調整とロボットモデルの提供のみで、様々なヒューマノイドロボットの歩行を実現できるようにする。

　以上に重点をおいて考えていく中で、以下などのトレードオフ問題にあたり、今回の答えを設定しました。（このトレードオフから判断するのが一番苦労しました。答えがないので...）

問題：要素間の組み合わせに自由度をもたせる vs 要素間の流れを固定して通信のオーバーヘッドを減らす
- 答え：要素間の通信を固定して、各要素をプラグイン化し、プラグインで他Nodeとの通信を行えるようにする。
問題：シミュレータ及び実機の搭載するソフトウェアにも汎用性をもたせる vs User側で用意してもらい此方側では制御ソフトウェアのみを提供する
- 答え：基本的にUser側で用意してもらうが、実装例をいくつか用意し、制御ソフトウェア側から提供するインターフェイスを明示する。

　ここで”答え”と表現していますが、理論的に明確で普遍的な答えが用意されているわけではなく、あくまで私が今回選択したことです。ですので、より最適な答えも存在するかもしれません。

　これらのことを踏まえて、以下のソフトウェアアーキテクチャを考案しました。

ソフトウェアアーキテクチャ

(少し雑ですが...)

　（Pluginは、PluginlibというROS 2のライブラリを用いて開発しています。）　ここで、各要素＝各Pluginの役割は、以下のとおりです。

Foot Step Planner
- ロボットが移動する軌跡から着地位置を決定するPlugin。
Walking Pattern Generator
- 着地位置を元に歩行パターン（重心軌道、ZMP軌道）を生成するPlugin。
- 前回まで開発していたものは、ココに当たる。
Walking Stabilization Controller
- 安定した歩行を実現するための制御を行うPlugin。現在の姿勢から姿勢修正量を歩行パターンに反映させる。
IK(path -> joint) == Convert To Joint States
- 歩行パターンから脚の全関節角度・角速度を生成するPlugin。

　また記されていませんが、以下の要素もPluginとして提供することを考えています。

Inverse Kinematics
- 逆運動学を解くPlugin。様々な解き方があるのでPlugin化したほうが拡張性・汎用性の向上に良いだろう。
Forward Kinematics
- 順運動学を解くPlugin。あまりPlugin化する恩恵はないだろうが、あることに越したことはないだろう。
Jacobian
- ヤコビアン（ヤコビ行列）を解くPlugin。これもいくつか解き方があるのでPlugin化したほうが良いだろう。

　以上の様にこのソフトウェアアーキテクチャでは、１つのROS 2 Nodeに複数の制御Pluginを読み込ませて１つの制御ソフトウェアとし、ロボットに動作指令を送るNodeと通信を行う、というようにしました。また、Rviz2などの可視化ツールやLoggerを用いることで、開発やデバッグがしやすいようにしました。
　このようなアーキテクチャにすることで、以下のような利点があると考えています。

Plugin形式にすることで、User側で自由に独自Pluginを開発し、組み替えることができるようになる。
Pluginとすることで入出力インターフェイスを固定し、独自Pluginを開発しようとするUser側で入出力を考える必要がなくなる。加えて各Pluginは独立しているため、１つのPluginを変えても他Pluginに直接的な影響が及ばない。
歩行制御における各要素を、Nodeごとの通信ではなくPluginとして１つのNodeに集約させているので、通信で発生するオーバーヘッドや情報の欠損などの、通信によって発生するリスクを抑えることができる。
歩行制御ソフトウェア（今回では、robot_manager Node）とロボットに動作指令をするソフトウェアを別Nodeとすることで、歩行制御ソフトウェア側はロボットのハ特定ハードウェア環境に依存させないことができる。