Meridianが完全開通したので

Meridian計画。
調べ物をしていて少し時間が空いてしまいました。
前回の記事で「Unityで計算した制御指示がリアルタイムに反映できるかがやや微妙な感じ」という不吉なことを書きましたが、その修正が済んでいます。恥ずかしいことにデータを送受信する際の小数、整数の変換で凡ミスがあり、1度ずつしか角度を変更できなくなっていたことが原因でした。
今は改善され、サーボの分解能に応じて動作するようになりました。 これで一番最初の目標であった「中間プロトコルのデータを関連デバイス間で循環させ、相互に高速でコミュニケーションさせる」という部分が完成となりました。Meridianは無事、完全開通となりました。

サーボをもっと滑らかにうごかしたい

完全開通はしましたが、動作のカクツキが完全になくなくなったというわけではありません。まだ若干プルプルとした動作になってしまいます。
原因は以前も書いた通りで、サーボモーターが時計の針のように進んでは止まるということを繰り返してしまうためでしょう。

競技でよく使われる各社のサーボの分解能を調べてみると、
KONDO 270度 8000分割 分解能0.03375°毎
FUTABA 300度 3000分割 分解能0.1°
ROBOTIS 360度 4096分割 分解能0.07890625°
となっています。

各社とも0.1度以内なので滑らかに動きそうなものですが、やはり「止まる」という動作が入ってしまうためか若干プルプルとした感じになります。
このプルプルは小型サーボを使っているロボットではよく目にする現象ですが、いかにもクオリティの低いロボットという印象を見た人に与えます。ちなみに動きのクオリティの低さを際立たせるもう一つが、保持力やトルク不足に起因する上体や腕先などのフラフラとした挙動です。マネキン型のロボットでありがちな現象です。これは別途、設計のところで何とか抑え込んでいく必要があります。

もしプルプルとフラフラを完全に抑えることができれば、モーションの完成度はソフト面での頑張り次第になります。いずれディズニーランドのアニマトロニクスのようなしっかりとした挙動も個人で目指せるようになるかもしれません。いや遠いか。。。

このプルプル解消については、今後サーボ設定の微調整や詳しい方へのヒアリングを通じてベストを探っていこうと思います。

データ量を増やさずに各社独自規格対応へ拡張する

各社のサーボのローデータを欠損なく扱いたいというニーズがあるようです。(@Dream_Driveみっちーさんありがとうございました。）
ローデータを扱えれば、サーボの精度面でのパフォーマンスも理論上最大化できることになります。
そこでMeridian92のデータ量のまま、サーボ値のローデータも扱えるようにしてみたいと思います。

現在試しているデータフォーマットのMeridian92では、サーボ値はサーボコマンドとペアになっています。（上図参照）
個々のサーボを制御するコマンドのために-32,768 ～ 32,767（0 ～ 65,535）の値を格納でき、いろいろな使い方ができるように少しデータサイズに余裕を持たせてあります。
当初のプランでは、どのメーカーのサーボを使っているかという情報についてはMeridianの外に持たせるつもりでした。しかしベンダー情報をMeridianの中でも扱えるようにすれば、たとえばD社のロボに最適化されたモーションデータを同じ関節構造のF社のロボでいきなり再生できるという利点も生まれそうです。

コマンドデータの詰め込み方

16ビット分あるコマンドデータにサーボベンダー情報とコマンド情報をどう詰め込むかについては、いろいろな方法が考えられます。
ビットで区切るか、10信数の桁で区切るか。もしくは他の方法か。これは一度決めるとあとから変えにくくなるので、まずは決め切らず仮決めで進めていこうと思います。

16ビットのコマンド用データについて、
1ビット目       ：共通コマンド（0-オフ、1-起動）
2~3ビット目  ：共通コマンド予備（0~3）
4~7ビット目  ：送信単位（0:deg,1:rad, 2:rad/PI,3:K社値,4:F社値など）
8~16ビット目：各社用コマンド（やりくりすれば数値データも格納可能）
と仮決めしてみようと思います。
たとえば、
0000 0000 0000 0001, 0010 1001 0001 1101というペアであれば、そのサーボをオンにして105.25度の数値をdegreeで送信、
0000 0000 0001 1001, 0001 1101 0100 1100というペアであれば、K社のサーボ単位で7500という数値を送るというふうになります。
コマンドに0を入れればサーボトルクオフ、1を入れればサーボトルクをオンしてdegreeで送信、という風にデフォルト状態で使えるフォーマットになりますので、最初は迷わずに使うことができます。

Meridianではラジアンはおまけ程度の扱いにしています。サーボの荒い分解能に対して、ラジアンだと小数点の桁数が増えすぎてしまうためです。ラジアンで計算した結果をサーボに最大限反映させたいということであれば、計算側でサーボ値にしてからデータにすれば最大のパフォーマンスでやりとりできるはずです。

ROS1,ROS2への対応を視野にいれる

現在はWin,Mac,Linuxと主要なプラットフォームをすべて網羅しているUnityをPC側の基盤として開発を進めてきました。
ロボット用のオペレーションシステムであるROSについては、導入のハードルが高いため見送りにしていましたが、ROS2からはWin,Mac,Linuxとなるそうです。ROSとMeridianを接続することができれば、ROS対応のソフトウェア資産を全部使えるようになるので、開発の幅が大きく広がります。
今後は一旦Unity版の開発の手をとめ、MeridianとROSとの接続について探っていこうと思います。

次の記事：

前の記事：

目次：