見出し画像

ロボットの体内にデータを高速循環させる

Meridian計画。
ロボットを動かすなら、ギクシャクとした動きではなく、生き物のようにぬるぬると動かせるようにしたいですよね。

やわらかく曲線的な動作は、ロボットの身体表現をより豊かなものにします。さらにセンシングで周囲の環境と呼応しながら動くようにすれば、ちょっとした仕草にも知性が宿ったような印象にできると思います。

動画の中でなめらかに踊っているQRIOは20年近くも前のロボットです。CGやゲーム開発環境の進化を考えれば、これ以上のロボットを個人で作れる時代になっていてもよさそうなものです。
まだそうなってはいないようですが、たぶん必要な要素はもう世の中に出揃っています。あとはその要素をつなぎ合わせるだけ。ということでそれを少しずつ進めていこうというのがこの計画です。

時間的な分解能を上げておきたい

ロボットの動きを環境の変化に柔軟に対応させようとした場合には、高い時間分解能が必要になります。
競技ロボットのように高速に動くものは一瞬の時間での移動量も多くなってくるので、時間分解能は高ければ高いほど助かります。
比較的低速で動かす場合においても、時間分解能が高ければそれだけ精度の高い制御ができるようになります。特に動作を計算で決定していく場合には、高い時間分解能はより効果を発揮します。
ホビーロボットであっても通信や処理の周期は最低でも1/100秒以上の分解能が欲しいところです。

サーボモーターに一連の動きを指示する場合、時間単位で刻々と目指す角度を指定していくことになります。
高速で動作するサーボモーターは、制御の分解能が低いと時計の秒針のようなカクカクとした動きになってしまいます。これは指示位置に素早く到着しては停止して次の指示を待つ、ということを繰り返すためです。もちろん電流を細かく設定して速度を調整し、目的地に到着する直前に次の目的地を受け取るように制御する、とすれば動きをなめらかにできると思いますが、とにかく分解能さえ上げておけば、速度を細かく設定しなくとも見かけ上の動きをなめらかにすることができます。
応時間分解能を上げることのメリットは多いと思います。

分解能を上げると通信速度がネックになる

ネットで動画をガンガン見ても全然大丈夫なくらい通信速度が進化しているので、素人が何も考えずに通信プロトコルの設定を作っても性能的には余裕かな?と思っていたのですが、そうはいきませんでした。
前々回の記事でも触れましたが、ホビーロボットに使える小型ボードは、いかに性能がアップしたとはいえ通信速度や性能には限界があります。
使用するメインボードはTeensy4.0。600Mhzという高速な処理速度が強みで大量のサーボ制御やメイン処理は任せられますが、無線機能を持ち合わせていません。
もう一つの候補であるESP32は高速なWifiを標準搭載している上に処理速度も240Mhzとかなり高速です。ただしシリアル通信が弱点で、速度やチャンネル数に制限があります。
まさに一長一短で、理想的な高速通信を実現するにはこの2枚を組み合わせる必要があります。

Teensy4.0とEPS32を連携させると、2枚を連携させるところで大きなタイムロスが発生してしまいます。となるとMeridianで扱うデータパケットも小さければ小さいほどよいという結論になります。

画像2

中間プロトコルの"Meridian 100"へのデータの詰め込みは現時点では上図のようにしてあります。
市販のホビーロボットを動かせるデータ量の倍ぐらいの領域を確保してありましたが、もう少し絞ってUDP通信の1パケットに収まるデータ量にしたほうがスッキリするというアドバイスをいただきまして、1472バイトに収まる92個にしてみました。(@FrostyDesign_JP さんありがとうございました。)
今日から"Meridian 100"は"Meridian 92"になりました。

つなぐだけでもやっぱり大変だった

前々回の記事のあとでUARTシリアル通信の速度アップをいろいろと試しましたが、速度を上げていくとESP32側の取りこぼしが多くなることがわかったので、SPI接続に変更しました。

ESP32のSPI接続はUARTよりも高速通信が可能な上、パケットデータの区切り記号も不要になるのでとても便利です。ただしTeensy4.0とESP32をSPIで接続する前例があまりなく、調べるところでかなりの時間がかかってしましました。

結果としてそのものスバリなライブラリを作成されていた方に辿り着き、使わせていただくことでかなりの高速化が実現しました。このライブラリで本当に見通しがよくなりました。@hideakitai_さんありがとうございました。

また、PC/Unity側とのUDP通信についても詳細な導入事例にものすごく助けられました。@deveminさんありがとうございました。

さらに、サーボとの高速通信についても導入のコツを教えていただきました。@kedtnさんありがとうございました。

ライブラリや資料があるとはいえ、前提知識が足りずマニュアルや解説文だけではわからないところも多く、一行一行精読し、理解を深めていきました。ライブラリの不具合の指摘という開発者への貢献機会が2度あったのは小さな自慢です。
進めたパートを後で振り返れるよう、都度Qiitaに記事としてまとめていく作業も並行して行って行きました。検索で簡単に答えが出ないようなMeridianの要素技術はここに解説が集約されていきます。

データ連携の現状の構成をまとめると下記のようになります。
中間プロトコルの"Meridian 92"がデバイス間をぐるぐると循環します。
いまのところは1/200秒周期以上のスピードでデータが回っており、ロボットの"経絡"が軽量なデータで満たされた状態になっています。

画像2

Meridian 92は一つのデータフォーマットにサーボへの命令とサーボ状態の両方の情報を乗せることができるので、それぞれの段階で受信時は実行コマンドとして、送信時は情報発信として機能します。
サーボ信号やセンサーといったロボットのハードウェア情報が無線でPC/Unity上にほぼリアルタイムに反映されるところも、楽しく便利なところです。

この先も自分的には未経験のことだらけ

ようやくできたのはMeridian計画の中でも最低限の基本の中の基本です。
使えるようにするにはソフト、ハード、設定とももう少し練っていかなくてはなりません。
次のステップに進む前に、スクリプトの整理や基板づくりといった地味に時間がかかる工程が入ります。
できるだけ早くデモをお見せしたいので、基板づくりをまず進めてみようかと思います。


次の記事:

前の記事:

関連性の高い記事:

目次:


この記事が気に入ったらサポートをしてみませんか?