RTOSを使う制御

　ファームウエアには、自作のRTOS(Real Time Operating System)
　であるUSO(Unvoiced Shadow Operating system)を使っています。

　ライントレーサごときに、RTOSを使う必要があるのかという意見もあります。
　自分では、なるべくゴールに早く到着するため、RTOSを利用するのも
　ひとつの方法だと考えています。
　RTOSを使うと、機能拡張や縮小が簡単にできます。

　今回、ファームウエアを次の４タスクに分割しました。

ハードウエアのテストデバッガ
スタートとストップのトリガー待ち
スタートトリガーを押してからセンサーなし直進走行
センサーによる走行制御

　ハードウエアのテストデバッガと他のタスクは、独立しています。
　それ以外のタスクには、主従関係があります。

　RTOSを利用すると、独立したタスクを、ひとつの機能としてファームウエア
　に脱着するのは、造作もないことです。
　また、主従関係を作るのも、従タスクの状態を、主タスクが管理すれば簡単
　に実現できます。

　今回の場合は、次のように３つのタスクが主従関係をもち、場合により
　動いたり、止まったりしなければなりませんでした。



　wait Eventは、２つのタスクの主タスクになっています。

　従タスクのstraight moveは、起こされても、仕事が終われば
　次に命令が来ない限り、眠っていてほしいのです。

　さらに、move with sensingは、一度起こされると、眠らされる
　まで仕事を続けてほしいのです。

　フラグ利用で、制御を実現できますが、常に判定処理が必要です。
　フラグは２つ必要なので、ファームウエアの設計段階で、神経を集中して
　作業しなければなりません。単純計算で、２の２乗で４回判定処理が必要
　になります。

　もう一つ機能が増えると、２の３乗で８回判定処理が必要になります。
　ネズミ講のような判定をするのは、バグの温床を作りこむのと同じになり
　デバッグのデスマーチに結びつく可能性があります。

　フラグ判定を減らし、考える項目を減らすには、RTOSを入れるのが得策です。

　RTOSを導入して、３つのタスクに主従関係を持たせてから
　カメラ利用の走行は、ステートマシンで簡単に記述できました。

　タスク分けしてしまうと、各タスクの記述はトップダウンで進みました。

　一度RTOSのトップダウンによる開発に馴れると、階層構造に分けた関数を
　記述するようになります。
　階層構造に分割されたソフトウエアは、碁盤の目のように機能が整理され
　バグを発見しやすくなります。さらに、ファームウエアの完成時期を予測
　しやすくなります。

　RTOSでは、あるタスクの機能が不要だと判断すれば、タスクをSUSPEND状態
　にして、使わないだけです。やはり、必要だと思い直せば、READY状態にし
　システムがRUN状態にできるようにするだけで済みます。

目次 前 次