ソフトウェア構成とコードの整理Ver.2 [ヒューマノイド動歩行]

前回の振り返り

　前回の記事では、静歩行を実装して、実際にWebots上で歩かせることができました。今回は、再度ソフトウェアアーキテクチャに取り組んでいきます。

odome.hatenablog.com

今回の概要

　今回は、動歩行に取り組む前に、新たにソフトウェアアーキテクチャを考えます。理由としては、前前回考えたアーキテクチャにいくつか問題があり、それが原因でオフセットや外乱が全くない静歩行で転倒してしまう問題が発生したためです。そのアーキテクチャの問題を元に、その点を改善したものを考え、改めて実装していきます。

旧アーキテクチャの問題

　以下に、問題のソフトウェアアーキテクチャを簡単に記した図を示します。

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

　静歩行動作が転倒する原因を調査した結果から、このアーキテクチャには以下の問題点が存在する可能性が考えられます。専門用語が乏しいせいで適切な表現ができていない可能性があります。

• FK, IK nodeとWalkingStabilizationController nodeにおいて、複数のclientから同時にrequestされた時に、何かしらのrequestの処理がcallbackの実行待ち状態になってしまい、制御周期に影響を与えている可能性。
  
• 同上nodeにおいて、複数のclientから異なった周期でrequestが送られてくることにより、望まれるcallbackの実行の順番が崩れ、望まないresponseを受け取る可能性。
  
• WalkingPatternGenerator - WalkingStabilizationController間でのpub/sub周期と、WebotsRobotHandler - WalkingStabilizaitonController間でのrequest/response周期と、２重に制御周期が存在していることによる問題に加え、異なる周期で回っていることによる、歩行パターンが正常にロボットに反映されていない可能性。
  
• そもそも、与えている歩行パターンも悪さをしている可能性。ただこれは変更した場合でも正常な静歩行はできていなかったので、根本的な原因ではないと思われる。
  
  

以上のように、多くの原因が考えられる結果となりました。問題を解決するためにはこれらの可能性を潰すように修正を加える必要がありますが、数が多いことに加えてまだ小規模なアーキテクチャなので、１から作り直した方が早いと判断しました。

新しいアーキテクチャ

　以上の原因の可能性を踏まえて、新しいアーキテクチャを考案しました。以下に示します。

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

　見て分かる通り、結構大きく変更しました。以下、主な変更点です。

• ソフトウェア内でのデータの遷移を、シーケンシャルに変更。制御周期が１つになり、分かりやすさを重視。
  
• RobotManager nodeを追加し、制御に関する処理をロボットを直接制御するWebotsRobotHandlerから切り離した。ロボットの環境（シミュレータ、実機）の変更にも柔軟に対応できるように。
  
• FK, IKの処理を含むKinematicsを、共有ライブラリに変更。FK, IKを用いる際の通信によるオーバーヘッドを削減。同時requestによるcallbackの実行待ちも発生しない（シーケンシャルなので構成として発生しないが）。
  
• 通信を全て同期Service通信で行うように変更。これも処理をシーケンシャルに行うため。
  
  

　以上の変更で、旧アーキテクチャでの問題は改善すると考えられます。
　これに加えて、Compornent指向に沿った実行方式への移行や、LifeCycleによる起動順序の調整など、幾つかの改善も考えています。

　以上に示した新しいアーキテクチャに沿って、実装を進めていきます。（絶賛移行中）

まとめ

　今回は、発生した問題からソフトウェアアーキテクチャの問題点を列挙し、それを元に新しいアーキテクチャを考案しました。また、これに沿って移行を進めています。
　次からは、ソフトウェアアーキテクチャの移行が完了し問題が解決した後、本題の動歩行動作の実装に取り組んでいく予定です。