見出し画像
Photo by planetarian_t

Meridian TWIN 公開

Ninagawa123

Meridian計画。
前回のLITE版リリースに続き、おまたせしましたの第二弾です。

ついにType.Kでも通信エラー率0.0%を達成しました！

Type.Kというのは最初にリリースした基板で、Teensy4.0とESP32DeckitCを２枚挿しで使うMeridian計画のフラグシップ機です。
Meridian TWINはこの２枚差し用の新しいプログラムです。
ソースコードの全面刷新により血液サラサラの健康的な状態が達成できています。

え、いまさら？

Meridian（経絡）という名前を冠している以上、データの流れの円滑さは最も重視されるべき点です。
最初のType.Kの完成発表はエラーがほとんど検出されないことを確認してから行なっており、当時は完璧なものができたと思っていました。

しかし、基板から直接サーボを制御した場合にくらべて、通信経由で指示したサーボ動作はどうもギクシャクするという問題が残っていました。
フラグシップ機なのに本来のパフォーマンスを発揮できておらず、これが気になっていました。

何度試しても通信エラーが検出されないので動作不良の原因がわからず。
サーボの通信配線を付け替えたり、基板を目視して断線を確かめたり、かなり頭を悩ませました。

しばらく経ってからようやくデータパケット自体が届いていないという可能性に気付きました。試しに連番のデータを送ってモニタリングしてみたところ、相当量のパケットが通信中に消失していたという事実を確認できました。
届いたパケットだけに対してチェックサムを行なっていたため、この問題を見落とし続けていたのでした。

そこで改めてMeridim配列の中にシーケンシャルカウンタを設定しました。データが連番で届いているかをチェックできるようにし、その上でソースコードの再調整を行いました。
SPI、UDP、Bluetooth、I2C、各経路それぞれ単機能での通信テストを行い、チューニングによりかなりの安定高速通信が達成できました。
しかし、いざ全体をつないでみるとどうしてもパケットロスが発生してしまいます。
調整を重ねましたがこのバグが完全に消えることはなく、これまでの発表でも少しモヤモヤした感じがありました。

急がば回れのLITE版

開発進捗が行き詰まっていたので先にLITE版を作成することにしました。
前回の記事の通り、LITE版はESP32単体で動く基板です。構成がシンプルな分、ESP32のポテンシャルを最大限に発揮するためのノウハウが得られることを期待して開発を進めました。
ESP32について調査を進めると、WIFIの送受信とBluetoothが内部的に干渉している可能性に気づきました。また、豊富な入出力PINについても同時使用が推奨されない組み合わせが多数あることがわかりました。
LITE版はガンダムで言えばジム。ユーザビリティ重視のバージョンです。
機能や選択肢を極端に減らすことが使いやすさにつながると考えていたので、ESP32の問題箇所を回避するような使い方ともちょうどマッチしていました。これは2ヶ月ぐらいで完成しました。

ふたたびType.Kのバグフィックスに挑む

昨年にくらべて少し知識が増えていたので、ゼロから作るぐらいの気持ちでソースコードを見直しました。いつのまにか視野も広がっていたようで、半年前には気づけなかった部分が見えるようになっていました。

最初はリアルタイム制御のために細かくスレッドを分けて処理することを試みていたのですが、通信系のスレッド同士がハードウェア的に干渉している可能性もありました。理論上は動くはずが、実機ではそうはならない、という場面に悩まされました。

そこで、プロセスの順番が決まっているものについては無理にマルチスレッド化せず、同じスレッドにまとめるようにしてみました。
待ち受けが必要な部分は、そのスレッドの中に小さいループを作るようにしました。
こうすることで処理順を遵守しつつ、CPUや無線の使用についても干渉しないようにすることできました。

結局普通のプログラミングのような制御に落ち着きましたが、中身はだいたいこんな感じのフローになっています。

データの流れ

図で見るとゴチャついて見えますが、ソースコードはかなりシンプルに、見通しがよくなったと思います。

リポジトリもリフレッシュ

ようやく最初の完成形といえる状態になりましたので、リポジトリも新たに立てました。
最新のType.K用プログラムは上記にて使える状態になっています。

プロジェクトが増えてきたので今後は、

  • Meridian_TWIN (Teensy&ESPのコンボ版, Type.K等)

  • Meridian_LITE (ESP単体版, -LITE-等)

  • Meridian_console (PC用アプリ)

  • Meridian_Unity (Unity版)

  • roid1_urdf (デモ用ロボットモデル)

  • Meridian_protocol (仕様書関連)

のような感じでリポジトリを役割ごとに切りわけていこうと思います。
今後すこしずつ整理していきます。

システムが複雑なので最小限の構成で試せるクイックスタートもあったほうがいいかもしれませんし、改善すべき点はやまもりです。

開発環境はPlatformIOに一本化

Teensy4.0もPlatformIOで使えることが分かったので、勝手ながら開発環境をPlatformIOに一本化します。
Arduino IDEについて、優先順位は下げますが併用もできるようにはしておこうと思います。

実は通信エラー率0.000%ではない…

まだ0.01%ぐらいのエラーが出てしまいます。送受信のエラーはまだ見たことがないので、パケット消失もしくはボードの動作遅延などによるデータの取りこぼしだと思います。
この問題については、対処済みと考えたいと思います。
MeridianはUDPによる双方向データストリーミング形式を採用しており、データを受信しそびれたら次のデータでカバーするという仕様です。
今後なんらかの理由でエラーが1%以上になるようであれば、改めて対策を考えようと思います。

完成だけど思ったように動かない部分もある

PS4リモコンの受信について、マルチスレッドでの処理を試みましたが、BluetoothとWIFIが干渉回避がまだできていません。ESP32を利用して成功させるにはPS4リモコンのライブラリの改修までする必要があるかもしれません。
一方、Wiiリモコンの場合は処理が軽いためかエラーがほとんど出ません。しかし最初のペアリング確立があやしいところがあり、こちらも調整の余地があります。
Teensy側に接続して使うタイプの近藤科学の白リモコンKRC-5FHについては問題なく動いています。
別途ESP32STAMP PICOなどを汎用のBTリモコン受信機とする案も検討しています。

センサー類や他社製サーボについても、今後徐々にデフォルト対応していくようにします。

そんなMeridianですが、Type.Kの在庫あります

↑いまだに半導体不足が続きますが、まだちょっと在庫があります。

次にやること

LITEでFUTABAサーボを使えるバージョンが公開できるよう調整しようと思います。
Unity版のURDF準拠化もすすめます。

次回記事：

前回記事：

目次：

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