スケジューラ(しゃちょ〜)

最近はPCがコンパクトになってきたので、ロボットにそのままPCを組み込むことが多くなってきました。ロボットの業界では、PCにインストールするOS(オペレーティングシステム)は圧倒的にLinux系が多いです。何でなんでしょうね？
その理由は大きく2つあるかと思います。(他にもいっぱいあるとは思いますが)
1つ目は、Windowsが出始めた頃(Windows95など)、Windowsは不安定だったので敬遠されがちだったからだと思います。WindowsもUnixの派生系ではありますが、マルチメディアを主眼に置いたため、時間管理が自由にならなくなりました。もちろん商用なのでソースコードは公開されず(一部、限定で公開されていますが)、ロボットに必須な、時間管理が出来ないということです。
2つ目は、上記理由で、既にLinux系の資産が膨大になり、いちいちWindowsに移植するのが面倒というものです。
ただ、ソフトウェアの充実というところでは、Windowsの方が圧倒的に勝っているので、そのようなツールを使おうと思うとWindowsでシステムを組むことになります。

では、今からロボットをゼロから開発しようと思った時、どっちを選択すればよいのでしょう？これは作るロボット次第ではありますが、一般的なサービスロボットを作る上ではWindowsの方が楽かもしれません。トルク制御や、非常に高速に動作するロボットの場合はLinuxの方が良いでしょう。
その判断基準をどこに置くか？という問いに対しては、私は「スケジューラの最小単位」に注目しています。Windowsの場合は10msが最小単位です。つまり100Hz。これで制御しきれない系の場合はWindowsでは実現が困難になります。
Linux系の場合も、デフォルトは10msです。しかしLinux系はソースコードが公開されていて、スケジューラの最小単位を1に変更してカーネルの再構築をすることで、これを1msにすることが出来ます。

ただ、どちらの場合も、スケジューラの最小単位がその値というだけで、それを保証してくれるものではありません。もっと重要なものは「スケジュールの管理が出来るか？」ということになります。PCは、マルチメディア、マルチタスクといってもCPUは1個しか搭載されていません。ということは、瞬間瞬間では1個の処理しかできないんです。それをOS側で巧く切り分けて、あたかも複数のプロセス(処理)が同時に動いているように見せているんです。なので、仮に1ms間隔で動作させるようなプログラムを組んだとしても、それより優先度の高い処理が頻繁に実行されると、そのプログラムは一時的に待たされることになります。そうすると1msという値の信頼性が揺らいできます。
そのスケジュールの管理まで可能にしたOSが「リアルタイムOS」といわれているものです。古くはVxWorksから、RT-Linux、ART-Linuxなどがそれに当たります。ということは、逆にRT-Linuxを入れたからリアルタイム性が保証されるというものでもありません。ちゃんと、スケジュールの管理をしなくてはダメです。
ということで、私の「リアルタイムOS」の定義は「スケジュール管理が出来るOS」と言うことになりますね。仮に1秒間隔であっても。。。

大学などでは、好んでRT-Linuxなどを使われているようですが、意外と、苦労して導入している割に、本当にRT-Linuxが必要なの？と思われるロボットシステムが多いです。それなら、もっと簡単なOSを選定して、開発環境や周辺機器が充実している方が良いような気が。。。
RT-Linuxは、Linuxのカーネルが出た後に、そのカーネルに対してPatch(パッチ：差分ファイル)を当てるような感じの導入の仕方になります。ということは、最新のデバイス(USBカメラや無線LANなど)には意外と対応が遅いです。Linux自体、最新デバイスへの対応がやや遅いので、Windowsに比べると、2世代前の周辺機器しか使えないという問題が残ります。
我々も、無線LANでは苦労しました。秋葉の在庫処分セールなどを頻繁にチェックし、使えるチップの物を買い占めたりしてました。
普通に動くロボットなら、Windowsが楽で良いなぁ。