　分散処理方式だと、相対的にハードウェアの難易度が下がる（簡単に「下がる」とは限らないのだが）。全てのモーターを1つのコントローラーで処理するのではなく、極端な話、モーター1つにコントローラーを1つ用意しても良い訳なのでトータルとしてコントローラーの数は増えるし、これに供給する消費電力も増える事になるだろう。

　また実装面積や体積などに制限があるロボットの場合は（省パッケージ版のコントローラーを使うなど）実装がやや面倒な事になるかもしれないが、それでも1つのコントローラーから全てのモータその他の周辺回路に配線が引っ張り出されるよりもずっとスッキリする。

前回紹介した自走式自律制御ロボットの例。集中管理式（左）と分散処理式（右）

ロボットに適した分散処理

　問題はこれを適切に扱うソフトウェア環境がなかなか無かったことだ。

　分散というと、分散OSはかなり昔から研究されており（この分野の良著がAndrew Stuart Tanenbaum博士のDistributed Systems: Principles and Paradigms：邦題「分散システム原理とパラダイム」）、さらにこれを具現化したMINIXを開発している。

　他にも分散OSと呼ばれるものは各種ある（カーネギーメロン大学で開発されていたMachもその一例だし、最近だと開発は止まってしまったがオープンソースのAmoebaが有名である）が、これらはOSそのものは分散構造になっているものの、複数のコントローラーが物理的に分散しているという環境にはいまいちそぐわない。

　というのは、これらの分散OSは（内部が複数コアから構成されているかどうかはともかく）物理的なコントローラーのチップは1つという前提で動いているものがほとんどだからだ。

　ただこうした分散ハードウェア環境の場合、そもそも全体として1つのOSの下に個々のコントローラーをぶら下げる形がそもそも適切か？というあたりから話が始まるわけで、「分散」と名前が付いていれば良い訳ではない。

　もう少し目的に近いものとして機能分散OSもある（RTOS向けの実装例もある）が、こちらも微妙に方向性が違う（処理負荷にあわせて最適なハードウェアを割り当てるという意味合いが強いので、個々のコンポーネントを独立動作させるといった機能ではない）から、そのまま利用するのは難しい。

　結局のところ、個々のコントローラー別に、それぞれRTOSなりOSなりを独立で動かして、OS間通信（要するにネットワークである）で接続する形の実装が多く利用されてきた。

　比較的良く利用されていたのはRPC（Remote Procedure Call）で、これを利用するために（Linuxを含む）UNIX系のOSが選択されることがしばしばあった。もっとも、UNIX系OSが乗せられるようなプロセッサはかなりハイエンドになるため、8bitが主流だったMCUなどではRPCは利用できない。

　そこでMCUに関しては、UARTないしI2Cなどを使ったシリアル通信の形で接続する形態になっていた。要するに、分散システムといっても特に何か特別なものがあるわけではなく、一般的に利用されているものを組み合わせてソフトウェアを構築していたわけだ。