俺のロボット設計指針シリーズ
「下位のサブシステムに状態設定APIを導入しない」
下位のサブシステムに「制御モード」のような状態を気軽に導入してはならない。上位のサブシステムが利用する際に
- 1. モードの設定
- 2. 処理の実行
のような流れでタスクを行う処理は見直して
- 1. ○○モードで××処理をする
という一つのリクエストに変える。ソフトウェア中心の話だけど、電気電子系にも関わる話。
オブジェクト指向的なプログラミングに慣れすぎると、このようなAPIを設計しがちなんだけど、避けられるなら避ける。状態や変数はいずれ負債になる。テストもしづらい。組み込みとのインターフェースもこのルールを検討するべき。
実際、動くものを作ると、ソフトウェアに状態を作るのは避けられないのだが、このノウハウのポイントは「上位のシステムから利用するときに、サブシステムが今どの状態にいるのか、を意識させない」ということ。
そもそもピュアに状態だけを遷移させるような用途は無いはずで、同じタイミングでタスク遂行と同時で呼ぶなら統合しろ、という意味でもある。リクエストが来たら、サービス側で必要に応じで状態を変更して目的のタスクを遂行すればいい。
制御ゲインのような数値もこの状態に含まれる。例えばモータの位置制御で、目標位置を送ると同時に制御パラメータまで送るAPIの方が好ましい。
なかなか受け入れ難い人もいるのだろう。でもそのシステム、最終的にはそうなる。開発が進んで最適化時に「ある時は高ゲイン、ある時は低ゲインのような使い方 (ゲインスケジューリングのような方法) 」をやるようになる。僕の経験ではだいたいそうなる。最初から表に出しておくといい。テストもしやすくなる。
下位のサブシステムの起動パラメータとして、設定ファイルに記述するパラメータも、できれば関連APIを呼ぶ段階で設定する仕様の方が良い。デメリットはAPIそのものが複雑になりがちなのと、引数が多いとオーバーヘッドが大きい。通信方法によっては制限されるが、考えの方向性として持つと良い指針。メリットは、ゲインのようなパラメータを上位システムで一元的に管理できるようになるのが良いところ。
「下位のサブシステムに状態を導入しない」
Quote
Yuki Suga/編み物ラグビー好きフリーランスロボット屋プログラマー
@ysuga
俺のロボット設計指針シリーズ
「メカ電気ソフトのトータルなモジュール化を徹底的にやる」
モジュール化は運用フェーズで強力な武器であるが、開発フェーズでもメリットが大きい。機能を分割すれば開発作業を並列化できる。 x.com/ysuga/status/2…