　破綻の兆しを見せるのが、モーターからのフィードバックが必要なケースである(図3）。ステッピングモーターはご存じの通り、パルスを与えるとこれに合わせて正確に回転するが、その一方で脱調を検出できないから、監視回路を別途、組み合わせて「本当に正しく回転したか」を監視してやる必要がある。またパルスの与え方も、二相型ならWave/Full -step/Half-stepなどいろいろな方法があるが、Full-stepやHalf-stepだと細かく制御を行う必要があるので、それなりの所要時間が必要となる。

図3　モーターからのフィードバックを導入した

　もっと面倒なのは後輪側で、DCブラシモーターならPWMで周期を適当に変えてやれば速度調整ができるが、もっと細かく制御したいとか効率を上げたいなどの理由でブラシレスモーターを使いたいなどという話になったら、それこそ常にモーター状況を監視する必要が生じる。

　こうなってくると、シングルスレッドで処理ループを廻すのは到底無理で、そのブラシレスモーターを常時監視しながら調整するスレッドをメインの処理ループとは別に回し、定期的にスレッド間通信でパラメータを渡すといったやり方になる。

　これをMCUでやろうとすると、何かしらRTOSを動かさないと大変ということになるし、RTOSなしでやるとなるとタイマーでの割り込み処理ルーチン中でディスパッチするという、「広く使われているが、好まれてはいない」実装が必要になってくる。また、フィードバックを受け取るための回路も別途必要になるので、プロセッサーとして利用できるのは32bitのハイエンド品になるだろう。

　そして破綻をするのが、モーターの数がさらに増える場合だ。

　大体のMCUはせいぜい1つか多くて2つのモーターを制御する程度しか考慮されておらず、これを超えて制御する場合は「MCUの数を増やせ」という事になる。実は今回の例で自律制御の自走式ロボットを4輪で構成した理由は、最小限のモーターで構成できるからだ。これが例えばPepperだとモーターの数が20個にも及ぶ。基本的に関節部の1自由度あたり1個のモーターが必要だから、自由度を上げれば上げるほどモーターが増える。こうなってくると、全てのモータを1つのプロセッサーにつなぐのは非現実的になる。

　図1の際にも説明したが、今回はCMOSイメージセンサーをものすごく賢いものとして扱っている。ところが、実際にはこんな賢いイメージセンサーは存在しない。当たり前だがイメージセンサーは単に画像を撮影して送り出すだけだから、これを画像処理する処理が別途必要である。OpenCVに含まれている“Motion Analysis and Object Tracking”などがこうした用途には良く使われているが、これだって結構な処理負荷になるわけで、実際にはこの処理も必要になる。

ロボット制御に必要なプロセッサー

　結果として、図1～図3で説明してきた、プロセッサー1個でロボットを制御、という構図そのものがあまり現実的では無いことが分かる。この結果、ある程度の規模以上のロボットを作る場合、さまざまなセンサーやモーター類は全て個別にコントローラー（MCUが使われることが多い）を搭載し、それとは別に全体を司るコントローラー（こちらにはMPUが使われる事が多い）をネットワークでつなぐ、という方式が一般的になっている（図4）。

図4　各所のセンサーやモーターをMCUで制御、全体をMPUで制御する

　これは特に、移動をタイヤではなく足を使う（つまり歩行する）ロボットでは欠かせない。4輪タイプのロボットだと、モーター制御の反応が多少遅れたからといってひっくり返る事はさほど無いが、歩行タイプだと足の動きが間に合わなかったらひっくり返るからだ。なので、タイミング的に間に合うようにモーターを制御してやらなければいけないし、そのためには個別にモーター制御を行うのが一番確実である。

　ということで、やっとROSの入り口までたどり着いたところで、以下次回。