プロジェクト「ロボットの頭」 (0) 序

自社開発の機器を開発しようとしています。

どういった機器かと言えば、「ロボットの頭」です。

まぁこの画像は箱だけなんですが、作るのはこれの中身です。

背景

プロジェクトを起こした主観的な背景は、特にここで書く程のことではないので、私(生越)の個人ブログの方に書いておきますので、そちらをご覧下さい。

構想

いきなり壮大な計画を立てても実現は難しいので、「目先の目標」をまず考えてみます。

「遠いゴール」としては個人ブログの方に書いたような「自分の代わりに徘徊してストリーミングしてくれる雲台」なのですが、目先のゴールとしては「mayumiの作っていたおもちゃロボットのインテリジェント化」に置こうと考えています。また、その途中のステップとして「ルンバのTurtleBot化」も出来るのではないかと思います。

他方、弊社のお客さんから、「ある製造機器の故障診断」のために何らかの手段でカメラで画像を見たいという要望がありました。

もちろん画像で見る以外にも、PLCの中に割り込んでセンサーの指示値をネット経由で収集するという「まさしくIoT」というようなことは当然のように行うわけですが、実際に故障が起きた場合は物理的に何が起きているかを見てみたいというのは、開発者としては当然に思うことでしょう。そういったことの応用も考えると、「機器にとりつけて観察したい場所を見ることの出来るカメラ」に出来ると良いのではないかと思いますし、開発費もその方向から捻出出来るかも知れません。

「弊社のお客さん」ということで考えるなら、「画像を認識してPLC的な動作をする何か」という需要もあるだろうなと考えられますし、多分世間にもそういった需要はあるでしょう。このプロジェクトは「おもちゃ」的なものを作ることだけではなく、「現代の技術ベースの上に作られる制御機器(PLC)」という商品開発でもあります。

要求のまとめ

構想を元に要求をまとめてみます。

カメラ

普通は「ロボット用」だとせいぜい1つなのですが、HMDで使うこととかdepth mapのこととか考えて、二眼にします。ちょうどmayumiの書いていたStereoPiがいい感じなので、今回もこれを使います。

単なる認識用なら1つで足りるのですが、どうも一眼のロボットは「可愛さに欠ける」という気がしてます。とは言えダミーの目をつけるとか感情表現用にディスプレイを使うのは何か違う気がします。やはり二眼の方が良いんじゃないでしょうか。

マイコン

マイコンに要求されることは多くあります。

カメラからの情報処理すること。これは大きくストリーミングのための処理と画像を認識するための処理に分けられます。どちらも結構な重さのあるタスクです。

通信をすること。これはいわゆるホストとの通信だけではなくて、各種デバイス(サーボモータとか)との通信もあります。さらには、他の制御機器との通信もあるかも知れません。たとえば、弊社の製品のCAN/Ethernet対応周辺機器につなげられると、拡張性も確保されます。

デバイス

「つなぐだけで手軽に使える」という機器を目指したいので、ある程度のデバイスは直接制御したいと考えています。たとえば、前述のサーボモータとか直接接続したいものです。車輪を動かすために使われるであろうモータも、直接駆動出来るくらいの容量があれば使いやすくなりますし、PWMで速度制御が出来ると便利でしょう。

USB

ストリーミングの類の動作、あるいは自律性のあるリモコンといったものを考える時に、「通信」は必須の機能となります。

このような場合まず考えるのはWi-Fiによる通信なのですが、屋外に出た場合や遠距離のことを考えると、4G/5Gによる通信とか出来ると良いかも知れません。また、Wi-Fiも速度の速いWi-Fiモジュール(内蔵マイコン)だと、技適の問題があります。そういったことまで考えると、内部に通信モジュールを持つより外部のモジュールを簡単に使えるものの方が便利だろうと考えられます。こういった用途を考えるとUSBが外部に出ていると便利でしょう。

リアルタイムとインテリジェンスの両立

ロボット制御は本質的にリアルタイム制御です。と同時に、インテリジェンスも求められます。これらが両立しないと、実用的な「ロボットの頭」の実現はできません。

予定される仕様

要求と「現実」とを睨んで、以下の仕様を考えました。

マイコンはRaspberryPiとOpenCR互換(？)のデュアルCPUとし、USBで接続する
StereoPiには元々RaspberryPi Compute Module 3(lite)があって、RaspberryPi互換のI/Oヘッダが出ています。このため、インターフェイス用のHatさえ作ればRaspberryPiで直接デバイスを動かすことができます。
しかし、そうすると元々それ程パフォーマンスのないCM3に多くの処理をさせることになる上、リアルタイム制御までしなければならなくなって、実用的には不安があります。CPUが複数に分かれるとプログラムが面倒臭いことになるのですが、ROSは元々プロセス間通信を基本に置いた設計になっているので、CPUが分かれることで問題は起きないだろうと判断しました。また、TurtleBotも元々そういった構成になっているので、多分その方が「似ている」ということで問題が起きにくいだろうとも思います。
USBは元々StereoPiにはピンヘッダでUSBが出ていることから、これでインターフェイスすれば余分な配線が不要な上に、通信速度が期待出来るということで選択しました。
デバイス制御のマイコンはOpenCRから一部機能を除いたものにする
TurtleBotを作っているROBOTISから、OpenCRというインターフェイスボードが出ています。これは、STM32F7が載っているROSシステム用の制御ボードです。回路からファームまで公開されています。これは汎用性が高くて、Arduino互換のコネクタがついていたりします。
とは言え、Arduinoとして実用にするためには、この上にそれ用のシールドを載せる必要があります。今回作る「ロボットの頭」にはそのためのスペースはありません。ですから、このコネクタがあっても実際に使われることはないでしょう。それ以外にもOpenCRには汎用のGPIOが出ていたりするのですが、これも「その先」を用意しないと使えません。多分「ロボットの頭」では使われないと思います。それ以外にも「ここでは使わないな」というコネクタがいくつかあり、またそのデバイスのためにマイコンもSTM32F746ZGT6という144ピンのものが使われています。
今回はこの辺のコネクタを全廃しました。その代わりいくつかの入出力は強めのバッファをつけた上でターミナルブロックで接続できるようにします。給電されスイッチされるターミナルブロックであれば、モータをつなぐだけでとりあえず動かせるようになりますから、手軽にロボット的なことが出来るでしょう。また入出力が減ったため、STM32F765VITという100ピンのマイコンが使えます。
元のOpenCRと比べるとかなり汎用性は下がりますが、現実的には違いはないでしょう。実際、TurtleBot3では今回除いた汎用I/Oは使われていません。
インターフェイスの割り振り
CPUがデュアルなので、役割分担を考える必要があります。CPUの能力に依る分担は自明なこととして、インターフェイスでどちらでもつけられそうなものについて考えておきます。
LANやWiFi、USBといったパソコンっぽいインターフェイスはRaspberryPi側のものを使います。また、オーディオについても同じです。オーディオについてはかなり悩みましたが、RaspberryPiの方がいろいろ楽そうです。LANもSTM32側につけることも考えましたが、RaspberryPiとの通信にはUSBを使うことにしたので、STM32側につけることはやめました。まぁどうせRaspberryPiのLANはUSBの先についているので、速度の点で不利になることはありません。
CANやUART、RS485といったものはSTM32側につけます。これらは直接デバイスを制御していることが多いので、リアルタイム性を期待されるためです。

この他にも、RaspberryPi側にはいろいろな開発環境はノーコードに近い開発ツールも載せようと思っています。そうすれば、特にホストとなるパソコンを用意しなくても、これ1つで開発も出来るようになりますから。もちろんもっと速く動いて欲しい人は、パソコン用意してクロス開発すれば良いわけですけど。

また、当初の予定の中にはPLC的な動作をすることも考えているため、ROS/ROS2のファームだけではなくてPLCで使われるための諸々も用意しようと思います。具体的にはModbus関係のプロトコルとOpenPLC関係のツール群を動かすということです。

現在のところ、「目」の側にはStereoPi = RaspberryPiを使うことにしていますが、将来的にはJetson(nanoとかNXとか)にするかも知れません。その時であっても、基本設計はそんなに大きく変わらないと思います。もっとも、つい昨日にStereoPiのCompute Module4対応のものが出るというニュースがあったので当面それで十分かも知れません。

参考までに、STM32CubeMXに定義したピンを挙げておきます。

STM32はF3, F4とボードを作って来ましたが、F7は初めてです。ここに挙げた機能だけであれば、F4でも問題ないとは思いますけど、「用途が決まっていて大量生産する必要があるもの」ではないので、「パワーは力」ということでF7にしました。元のOpenCRもF7だったということもありますし、使ってみたかったということもあるのですけど。

なお、これはオープンなプロジェクトとして始めているので、このような機器を開発して欲しいとかの要望には、積極的に対応して行きます。また、このようなものが欲しい、あるいは販売したいというような声があれば、優先的に対応したいと思いますので、弊社までご連絡下さい。