先週までの振り返り
先週の記事では、逆運動学のプログラムを作成・実装し、Webots内のロボットを実際に動かすことができました。
今週の概要
先週までで逆運動学が解けてロボットを動かすところまでいけました。ちょうど一区切りついたことと、今のコードが非常に煩雑になっていることから、今週からはソフトウェア構成の策定と現コードの整理、そして開発環境のバージョンアップをしようと思います。
- ソフトウェア構成の策定
- コードの整理と書き直し
- ROS2のバージョンをFoxyからHumble、Webotsのバージョンを2022bから2023aに、開発OSをUbuntu20.04からUbuntu22.04に移行
進捗記録
~2023/1/26
ソフトウェア構成の第１案を作成（-> 要再検討）
- ソフトウェア構成の第１案を考えた。手書きで超見づらい。
ソフトウェア第１案 - 今回考えているヒューマノイドロボットの制御ソフトウェアは、大きく分けて３つの部品に分けている。以下、私の部品に対する理解。
- ロボット本体
制御対象のロボットそのもので、関節のアクチュエータに対する入力と、姿勢やアクチュエータの現在値などの出力を持っている。 - 歩行パターンジェネレータ
開発中の制御ソフトウェアにおいて、一番のコアとなる部分。次に足を置く場所に脚を動かすために、対象のロボットのアクチュエータに対する命令を出力する。入力は（いまのところ）無いと考えている。安定化を考えなければ、ロボット本体と歩行パターンジェネレータだけで歩行が実現できる。が、現実的ではない。 - 歩行安定化制御系
文字通り、歩行を安定に行うための部品。ロボットを安定して歩行させるために、ロボット本体から出力される姿勢情報を元に、歩行パターンジェネレータから出力される命令に補正をかけて、ロボットのアクチュエータに命令を出力する。つまり、歩行パターンジェネレータとロボット本体の間に置く部品で、ロボットからのフィードバックを元に命令に補正をかける部品。
(制御の構成の参考：梶田秀司、『ヒューマノイドロボット（改訂２版）』)
- この構成には問題がある。
特にTopic通信で同期を取ろうとしているところ。pub/subの周期を合わせれば同期が取れそうだが、遅延が必ず発生するので難しい。フラグで同期を取る方法も、二重に通信が必要になって、疎な通信とは言えなくなっている。
この問題を改善した第２案を考える必要がある。
開発環境のバージョンアップに関する調査
- 開発環境を移行するために、まず現コードをROS2 Humbleでコンパイルしたときのエラーを確認した。
結果、Webots関連の型宣言でエラーが出た。その原因を探るためにwebots_ros2のソースコードとWikiを確認したところ、Webots独自の型宣言の方法が変わっていた。このことから、型宣言方法を変えてやることが必要であることを確認できた。
この結果から、まずは型宣言の箇所を書き換えて、またコンパイラを通してみることにする。
~2023/2/8
ソフトウェア構成の第２、３案を考案
- まず、第１案の問題点を踏まえて、以下の第２案を考案した。Serviceだけでまとめたことで、結構すっきりした。
ただ、歩行パターンジェネレータから歩行安定化制御系への通信は、歩行安定化制御系から歩行パターンジェネレータへのfeedbackは必要ない。また、FK・IKが歩行パターンジェネレータと歩行安定化制御系両方で必要となるであろうことから、FK・IKは別nodeに分けたほうがいいだろう。
- 以上の第２案を踏まえて、以下の第３案を考案した。FK・IKnodeを作り、通信方法も一部変更した。
PluginがClient・歩行安定化制御系がServerとなる非同期のService、歩行パターンジェネレータがPublisher・歩行安定化制御系がSubscriberとなるTopic通信で通信経路を組んだ。こうすることで、歩行パターンジェネレータが司令塔となり、他nodeがそれに従属する形にすることができた。
また、FK・IKnodeを作成し、歩行パターンジェネレータや歩行安定化制御系との間を同期型Serviceで接続した。これでFK・IKの処理プログラムを１つにまとめることができた。（DeadLockには注意が必要だが）
処理の流れとしては、
1. 歩行パターンジェネレータで、その歩行パターンに掛かる時間を計算し、それに合わせて歩行安定化制御系にPublishする。
2. 歩行安定化制御系は定期的にPulginからロボットの姿勢情報のfeedbackを受け、現在の歩行パターンと姿勢情報から安定した姿勢をとるための関節角度をPulginに出力する。
ひとまずは、この第３案をソフトウェア構成として、開発を進めていくこととする。
~2023/2/20
ソフトウェア構成・第３案の整理とより詳細な検討
- 手書きで雑多な構成案をまとめ直した。上記で示した手書きの第３案を、下記のようにきれいにまとめ直した。書かれていることは同じ。
- より詳細な構成の検討。特にROS2まわり。
- 各nodeをそれぞれ別packageで管理する方法。
別にすることで管理のしやすさを確保する。 - FK, IKを含む、Kinematics周りのnodeを、別々に分けるか１つにまとめるか問題。
別nodeに分ければ通信で扱われるmessageが持つ情報を少なくできる（例えば、IKとFKを同serviceにまとめると各関節角度と目標位置をまとめて送受信する必要があるが、別serviceつまり別nodeにすればそのどちらかを送受信すれば良くなり、messageが持つ情報を少なくできる）。しかしこの方法だと、IKでもFKを使うため、冗長にならざる負えない（FKnodeとIKnodeを繋がなかったとしても）。
一方で１つのnodeにまとめた場合、最小限のコードで済む反面、messageが持つ情報量が大きくなってしまう。また、起きない見込みではあるが、DeadLockなど、共通資源であることから通信が競合しないかも問題としてあり、１つのnodeにまとめたほうが競合が起こりやすい。
ひとまず、第３案では１つのnodeに収めるとしたが、現在でも迷っている。いずれにしろ、どちらかの形で開発した後に、検証できればいいと思う。
- 各nodeをそれぞれ別packageで管理する方法。
