実践でまいまい式を使うための改善策

先日の東京連合では、外乱光対策として有力候補の「まいまい式」を実際に使うための改善策について話しました。

結論から言うと、まいまい式の弱点である輝度計算の周期が遅い問題を多少改善できることは分かりましたが、速さを競う競技ではまだまだのレベルでした。ここに調査結果を記しますので、ETロボコン有志が改善策を練ってくれることを期待しています（私は参加者じゃないので^^;）。

調査して何か分かったら、 #maimai #etrobo でつぶやいていただけるとうれしいです^^

■まいまい式について

slideshareにアップしたプレゼン資料にも書いていますが、特に東京地区大会の会場のように太陽光がコースに直接入射する場合、光センサーの仕組み上、地面の反射率が高い（明るい色）なのか、太陽光が強いのか区別できなくなります。そして、レーンが識別できなくまります。

それを回避する手法として、ETロボコン界隈では「まいまい式」がよく知られています。
原理については、すねいるさんのブログを参照してください。

http://www.chihayafuru.jp/etrobo/?p=1349
http://www.chihayafuru.jp/etrobo/?p=1371
http://www.chihayafuru.jp/etrobo/?p=1326

■まいまい式の問題点 - 輝度計算周期が長い

このまいまい式は「効果が絶大」との報告がありますが、1つ難点があります。コースの輝度を早く計算できないことです。サンプルだと20ミリ秒周期になっていますが、倒立制御の周期が4ミリ秒なのに対して、これはあまりにも長過ぎる。

では、何が問題なのか？を考えました。

(1) LED光の点滅周期が遅い

まず疑ったのが、LED光を早く点滅できないんじゃないかということ。普通に考えると、こんなシンプルな回路でミリ秒もかかるわけないのですが、裏を取ってみました。

http://mindstorms.lego.com/en-us/support/files/default.aspx

上記のURLから取得できるNXTの回路図を見ると、LED光の点滅はメインプロセッサのARM側でやっています。LED光を点滅するための回路がARMに直接つながっているシンプルな構成です。回路的には問題ないと思います。

また、デバドラのソースコードはnxtOSEKの下にありますので、探してみてください。レジスタを操作してるだけなの普通のコードです。これも問題ないと思います。

（回路図とデバドラに問題ないので、問題ないと自分の中では結論付けていますが、電気的な特性で何かあると分かる人いましたら、ご連絡ください）

(2) 光センサ測定値の測定周期が遅い

もしかすると光センサの測定値を早い周期で取得できないのではないかと考え、こちらも調べてみました。ハードウェアの仕様書によると、とある事情でAVRのサブプロセッサが3ミリ周期で光センサのA/D変換結果を取得し、2ミリ秒周期でARMのメインプロセッサに送っているようです。

つまりは3ミリ以上は速くなりません。また、ARM側が値を取得するタイミングとARM-AVR間の通信周期が合わない場合もあるので、ARM側の取得が約2ミリ遅れることもありえます。

つまり、以下の3つの周期が噛み合ないと最新のデータが期待するタイミングで取得できません。

• AVRのA/D変換が3ミリ周期
• AVR - ARM間の通信が2ミリ周期
• ユーザプログラム側で光センサ測定値を取得する周期・・・実装次第

ボトルネックはここにも存在することが分かりましたが、20ミリとかのオーダーの問題を調べているので、他にも問題は潜んでいそうです。

(2)' 光センサの測定速度が遅い

ちなみに、光センサのデバドラはAVRのサブプロセッサ側にありますが、こちらも回路図とデバドラともにシンプルで問題ないはずです。ドキュメントによると0.1ミリ秒くらいで処理は終わっているよう。

デバドラのソースコードはこちらで入手できますので、興味ある方は調べてみてください。

http://mindstorms.lego.com/en-us/support/files/default.aspx#Firmware

(3) 光センサがLED光の点滅の影響を受ける

これは調べきれていませんが、点滅と光センサの測定がほぼ同時期に実施されると、何らかの影響を受けてもおかしくはありません。きっちり点灯（もしくは消灯）してから光センサ測定をするように、タスク設計すると良いと思います（まだ調べてないのでなんとも言えません）。

(4) まいまい式の差分計算の計算量が多い

これは、まいまいさんが現実の光センサ値を線形補正するやり方をご紹介しています。
http://www.chihayafuru.jp/etrobo/?p=1371

計算量をおさえるように工夫されていて、問題ないようでした。
ちなみに、ここの補正係数は各自で調整が必要です。

(5) その他のオーバヘッドが大きい

オリジナルの実装ではタスクの生成／破棄を頻繁にやってるので、ここは少し冗長だなと思いました。周期タスクで処理をやりつつ、一切破棄をしない実装だとどうなるのか調べてみました。

ライントレースしての実験ではないので不完全ですが、8ミリ周期でLED光を点滅しながら、光センサも測定し、輝度計算もできていました。

■まとめ

ちょっと工夫したら、少し遅めに走る分には問題ないレベルに改善することが分かりました。ただ、AVRのデバドラを規約上書き換えることができないので、根本的に直すのは無理のようです。

会場からは「マップ走行（光センサを使わず、モータエンコーダ値で位置を計算する方法）をメインに使って、補助としてまいまい式の輝度計算結果を使ってみてはどうか？そうするとまいまい式の計算速度は気にならない」という意見もありました。これはなかなか現実的な提案なので、どなたか試してみてください！