見出し画像
Photo by kentaro55

第三次リファクタリングが完了

Ninagawa123

Meridian計画。
前回までの記事で書いたような命名規則などを導入し、さらに関数やロジックも大部分を整理する作業の末、ついに、LITE版とTWIN版の間で多くの共通性を持たせた "v1.1.1" が完成しました。（長かった…）

これまでMeridianを使ってきた方も、継続して使われる方は、ぜひこのタイミングで新バージョンを試してみてください。
これから続々と（？）できるであろう新機能の盛り込みが便利だと思います。

LITE版

TWIN版

変わったところ

変更点については第二次リファクタリングの内容をTWIN版に反映させつつ、そこで気づいた点(前々回記事・前回記事など）を盛り込み、さらにLITE版へ反映。その作業で気づいた点を改めてLITEとTWINに反映していく、という作業を何往復かしました。細々と多岐にわたる動作確認がなかなか大変でした。
リファクタリングなので動作結果は変わらないのですが、今後の機能拡張を見通した下準備などを含む作業を行いました。

WIIリモコンの復活

リモコン関連のコードをリファクタリングしており、これまでリモコンごとに開発していたコードを、変換テーブルによるボタン入力組み換え方式に改めました。
その中で、Meridianの動作に影響が少ないWIIリモコンを使えるようにしました。実際にはLITE版で10％ほどの速度低下と通信スキップが発生してしまうのですが、入手しやすく500円程度でも手に入るリモコンは、Meridianの楽しさを実感するにはもってこいです。
これまではペアリングさ成功したりしなかったりと動作が不安定でしたが、起動時のペアリング手続きを強化することで安定的に使えるようにしました。

サーボインデックスとサーボID

これまでは簡略化とわかりやすさのため、Meridian配列のインデックスがそのままサーボIDに対応するようにしていました。
しかしサーボの組み換えをコード上からできるようにしたいというニーズがありましたので、コード上の仮想的なサーボ番号と、そのサーボ番号を実際のサーボに登録されたID番号を分けることにしました。

・インデックス番号：コード上の仮想的なサーボ番号。IXL_, IXR_
・サーボID番号：実際のサーボに登録されたID番号。IDL_, IDR_

サーボIDを使用するのは、コードの流れの中では最後にサーボに指令を出す瞬間の１回だけですのでさほど混乱は起きないと思います。通常は、インデックス番号とサーボIDは同一のものにしておけば問題ありません。

ハードウェアインターバルタイマーに変更

割り込み処理が高速通信処理に与える影響がわからなかったため、これまではmainコード上で本体内蔵のmillis()関数を使い、フレーム数のカウントとの比較を使って時間の管理をしていました。
割り込み処理に置き換えてみたところ、なんとか無事に動いているようなので本採用としました。
ハードウェアタイマーが割り込み処理で刻々とカウントアップを続けるので、その値とフレームのカウントを比較するようにしています。

以前、内部的にMeridianを使用したロボットを長時間展示した際に、タイマーのオーバーフローが発生しシステムが止まるという問題が発生し急遽修正しました。今回はその時の学びからカウンタにunsigned longを使用しているので、値の範囲を跨いだ場合でも堅牢に動き続けてくれるはずです。

TeensyとESPではハードウェアタイマーの関数が異なりますが、ロジックは共通にしてあるので、他のマイコンでも同じ手法で周波数を管理できる見込みです。スッキリ。

EEPROMの読み書き動作

基本は整ってきたのですが、実用面がまだ追いついていません。
取り急ぎはサーボのトリム値を記録したり反映できるようにしていこうと考えています。
PC側のソフトもぐちゃぐちゃになってきましたので、こちらもちょっと手をいれていかなくてはなりません。

基本機能の最後のピースはモーション管理

既存のホビーロボットシステムのようなストップモーションアニメ方式のモーションプログラミングについては最も需要が高いので、ようやくこれに取り組んでいきます。
各社の仕様を調べたのがもう２年近く前になります。(記事[1],[2],[3],[4])
記事を読み返すとCG系のモーションを調べる前のところで調査が止まっており、そこから１ヶ月ぐらいで終わるような感じでリファクタリング作業にとりかかって、そのままなんと2年も時間をかけていたということがわかり愕然としました。時間かけすぎです。
モーションファイルの仕様についてある程度のイメージはすでにありますが、汎用性をしっかり担保できるか、CG用のモーションファイルの調査なども再開しつつ、開発を進めていきたいと思います。
リファクタリングがひと段落しているので、追加機能の開発スピードはかなりアップするはずです。と信じたいです。

python版とUnity版のリファクタリングも必要

ぐちゃぐちゃのpython版も少し整理した方がよいかもしれません。pythonは機械学習や画像認識などでも多様することになるので、ここでリファクタリングを経験しておくと今後の開発にいろいろと便利そうです。
でも大事なのはUnity版で、こちらも２年は開発が止まっているので進めていきます。シミュレーターで自作ロボが動けば絶対に面白いはずで、そこからようやく制御や機械学習などの本丸の研究に入ることができます。

今のところモチベーションは爆発的に沸き続いているので、あとは会社に勤めながらいかに時間を捻出するかです。となると健康面や働き方もリファクタリングが必要そうですね。

次回記事：


前回記事：

目次：


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