ETロボコンの要素技術。

ETロボコンの要素技術、特に、基本となる走行の技術について、ちょっと掘り下げた話なんかを。

前回、前々回のエントリでnxtOSEKの話なんかをちょろっと書いてますが、実はETロボコンというのに参加していました。
結果はまぁそれなりかなという感じだったのですが、やっている中で、ネット上ではあまり書かれていなくて、そのくせ走行でキーとなるような技術ノウハウがいくつか手に入ったと思うので、備忘録を兼ねてちょっと書いておこうかなぁ、と思います。
上位の方々にはほとんど役に立たない情報かと思いますが、「うまく走んないよ〜」と嘆いている方々には、知っておいてもらいたいかなあ、と。

まず、最初に認識しておかなければならないこと。
「ハードウェアのばらつきは、想像以上にある」
複数の走行体を持っていて実際に走らせると分かりますが、全然違います。
また、このことから、モデル面だけで理論的には正しく走るようになっていたとしても、実際には泥臭いパラメータチューニングが絶対的に必要です。
（それが嫌なら、ハードウェア層で隠蔽するなり、フィードバックのアルゴリズムを入れるなりの仕組みが必要。）

理屈から言えば、倒立振子APIに角度0を指定すれば、まっすぐ走りそうなものですが、全然まっすぐ走らないんですよ。
うちの走行体でいうと、本番で使った方はちょっと左曲がりになり、予備の方はけっこう右に曲がります。
おまけに言うと、電池残量の違いでも、その曲がり方が変わってきます。（電池残量がたくさんある方が、曲がりがきつくなっていました。）
だから、例えばですが、P制御をしているとして、目標のラインの明るさが0.5であるときに（※0〜1に正規化しています）、0.3でした（＝差分の絶対値は0.2）、というときの曲がり具合と、0.7でした（＝差分の絶対値は同じく0.2）、というときの曲がり具合の絶対値は理屈の上では一緒ですが、実際には異なります。
こういった事実を知らないと、リスク管理や対策の考察で、「理論だと正しいはずなのに、なんでダメなんだ……orz」と、かなりハマることになります。

じゃあ、各論に。

PID制御

なめらかなライントレースをしよう、となると必ず出てくるのが、PID制御です。
説明を単純化のために、とりあえず今はP制御だけする場合を考えます。
このとき、ネットでよく見る式は
　（角度）＝（定数）×（光センサ入力値ー目標値）
ですよね。
つまり、「ラインからの離れ具合に比例するように、角度を調整しよう」と。
けどね、これは簡略化された式なんですよ。
本当は、
　（角度）＝（定数）×（光センサ入力値ー目標値）＋（角度ベース）
なんです。
（※学術的な記述だと、x(t) - x_o = K_p (y(t) - y_o)と、差分が比例、と書きますね）

じゃあ、なんで最初の式のように簡略化されるかというと、これは角度ベースの意味を考えると分かります。
光センサ入力値＝目標値とすれば分かりますが、角度ベースというのは、意味的には「差分が０のときに、指定されるべき角度」となります。
つまり、ラインのちょうどいいところに乗っているときに指定されるべき角度です。
そうすると、理論的には0になるので、簡略化されて、最初の式になります。

でもね、「理想と現実は違う」のですよ。
角度0にしたって、まっすぐ走りません。
目標との差分がないから角度0にしたのに、そのせいで目標値から外れて行ってしまうというこの悲しさ。

それと、そもそも論を考えてみます。
コースって直線だけじゃないですよね。
カーブを考えると、「差分が0のときに角度0を指定」なんかしたら、コースアウト一直線（角度0だけに言葉通り一直線）じゃないですか。
上位チームが高速ライントレースをするためにコースの曲がり具合によってPIDのパラメータをいじってくる、なんて話がありますが、本質的なことを言えば、曲がるべき所で「曲がれ」という指示が入っていない（＝コースの曲がり具合に応じての角度ベースの指定がない）から、PIDのパラメータ側でなんとか実質的に角度ベースという量を入るようにしているにすぎません。

この「角度ベース」という項を無視すると、最悪、全然走ってくれなくなります。
（うちのチームの実績（角度ベース項のある／なしの差）をあとで書きますね）

さて、じゃあ角度ベースをどうすればいいのか、という話です。

一番単純なのは、実験的に定数を入れてしまう方法です。
ただ、これだと電池残量の影響を補正して入れないといけないですし、走行体ごと・カーブごとに定数を調べる必要が出て、かなり大変です。

オススメなのは、モーターエンコーダとカーブの曲がり具合の情報を使って、走りながら動的にフィードバックを加える方法です。
つまり、光センサ値によるPID制御とは別に、モーターエンコーダ値によるPID制御を行なうことで、この角度ベースの値を導出します。
例えば、直線だったら、
　（角度ベース）＝（定数）×（左の進み具合ー右の進み具合）
という感じです。（※P制御だけの場合）
先程と同じで、本当は「角度ベースのベース」という項がありますが、これは0でも構いません。
なぜかというと、左の進み具合＝右の進み具合のとき、角度ベースは0になりますが、ここで実際にはまっすぐ進まなかったとしたら、即座に差分が生じてフィードバックが入るからです。
（この「即座に入るフィードバック」というのが、「角度ベースのベース」の働きをしてくれます）
カーブとかの場合は、
　（角度ベース）＝（定数）×（左の進み具合ーカーブ比率×右の進み具合）
という感じになります。（カーブ比率は、左の進み具合が右の進み具合に対して何倍であるべきか、という値）

結果的に、
　（角度）＝（光センサ値によるPID制御）＋（モーターエンコーダ値によるPID制御）
と、ハイブリッドな構成になります。
これ、見方を変えると、モーターエンコーダ値によるPID制御での角度ベースが、光センサ値によるPID制御で算出される、とも読めるんですよね。
お互いがお互いの角度ベースを補完しているという関係があります。
そして、ちゃんと角度ベースというのを無視しないで考えると、これが理論的にも正しいはずなんですよね。
はっきり言って、光センサ値によるPID制御単体とか、使い物になりませんよ。
特に、後述するまいまい式とか使おうとすると。

ちなみに、上記考えに至ったとき、構造モデルを考えると、光センサ値を使わないでモーターエンコーダ値だけで走るという場合も十分に考えられるので、構造的には「角度制御」というクラスを作って、それを継承した「光センサ角度制御」と「モーターエンコーダ角度制御」、および、「ハイブリッド角度制御」を用意して、「ハイブリッド角度制御」は「光センサ角度制御」と「モーターエンコーダ角度制御」の集約にする、というのが、自然な考えです。
全国大会のモデルはざっとですが全部眺めたのですが、実はうちのチームの他にあと１チーム、この「ハイブリッド角度制御」を明記しているチームがいて（シルバーモデルをとったR-GRAY NEXTさん）、まさに上に書いた構造になっていました。

そして、このハイブリッド角度制御を入れるか入れないかの違いですが、うちのチームの実績でいうと、試走会１でハイブリッド制御なしの状態で臨んだときは、まずスタートがボロボロ。
これは、走行体は最初後ろによっかかった状態になっているので、スタートすると少し後ろにズレるんですが、モーターエンコーダによる角度制御がないので、ラインに対して急な角度になりすぎて、復帰が全然出来ないからです。
角度がズレた状態でラインの目標値を踏んだとしたとき、進行方向がラインの方向を向いていないにも拘わらず、倒立振子APIに渡す角度は0になってしまいます。

スタートを上手くやったとしても、まいまい式を採用していたこともあり、スピードをあげるとすぐに暴走。
まいまい式では16msec毎でしかラインの明るさがとれないので、すぐにオーバーシュートしてしまうんです。
なんとか走るスピードにして、結果、ベーシックステージで120秒いっぱいかかる感じでした。

そして、ハイブリッド角度制御を入れての、地区大会。
スタートで失敗するとかは全然ありませんでしたし、ベーシックコースも40秒ちょっとで走れました。
「まいまい式を使って」ですよ。

全国大会は、尻尾走行が凄かったので霞んでしまいましたが、「まいまい式を使って」ベーシックを35秒程度で走れました。
キャリブレーション？　何それおいしいの、ですね。
今日のモデルワークショップで、モデルツアーのときに審査員の方は「きっと、コンディションによって、まいまい式を使うかどうかを切り替えているんでしょうね」とおっしゃっていましたが（そして、多くの審査員の方がそう思っていらっしゃったと思うのですが）、ぶっちゃけた話、切り替えてなかったというわけです（＾＾）

さらに、区間ごとにPIDのパラメータ値の調整なんかやっていません。
走行体ごとの基本となるパラメータの調整はやっていますが、区間ごとに行なっているのは、カーブ比率の指定だけです。
それだけやれば、ちょうどいい具合にカーブを曲ってくれます。

ちなみに、実は尻尾走行も可能でした。
チャンピオンシップ大会の試走会のときに、尻尾走行が速かったので、一通りチェックが終わった後に、お試しでベーシックコースを尻尾走行で走るようにしてみたのですが、まいまい式使っていてもちゃんと走りました。
微調整はしてないですが、30秒弱という感じでしたね。
ただ、尻尾走行で調整するためには、コースがピンと張られているというのが絶対条件で、その条件を会社では満たせなかったので、リスク管理の観点から、採用は見送っています。

まいまい式

さて、もうすでにエントリがおそろしく長〜くなっていますが、次の話題。
まいまい式。

東京地区大会で非常に困るのが、外乱光。
これに対抗するために編み出されたのがまいまい式です。
簡単にいうと、光センサのLEDを明滅させて、そのそれぞれの値を使うことで外乱光をキャンセリングしようというもの。
効果は絶大！　といろいろ書かれているのですが、実際のところ、分からんのですよ。

それは何かというと、
・ネットに上がっているサンプルの係数の導出方法が不明。
・妥当性検証がどう行われたのかが不明。
・サンプルだと20msecごとにLEDの明滅をさせているけれど、この根拠が不明。
というところ。

実際、暗闇、室内、曇り、晴れ、という環境でサンプリングを行い、サンプルの係数をそのまま使って検証をすると、曇りくらいで値がズレてきてしまいます。
「理想と現実は違う」ので、ハードウェアごとに係数を調整しないと、どうにもならないっぽいんですね。
けど、係数を出すためのモデルも、方法論も書かれていないので、全く分からない。
これは困った、となりました。

また、20msecごとにしか値を取れないというのは、かなりの制約です。
ハイブリッド角度制御の導入でクリアはされましたが、これはなんとかならないものか、というのがあります。

そこで、いろいろと調査しましたが、そこで分かったことを書いておきます。

まずですが、係数の算出。
これは全く不明のままです。
無理ゲー。

そこでとった手段は、実際のデータを頑張って分析という手法です。
ワードで黒の段階を100,75,50,25,0として紙に出力し、暗闇、部屋、曇り、晴れという環境で実際のデータをサンプリングして、分析しました。
Excelで、
・x軸にLEDのon/offでの光センサ値の差分
・y軸にLEDのoffでの光センサ値
をとるようにプロットしたところ、
・各色が対数関数で近似できた
・x軸を固定した場合に、y軸の変化がほぼ線形
という、いい特徴が出てきました。
これを使って、式が導きだされました。

分かりやすく、方法論だけ書いておきますね。

1. 暗闇、室内、曇り、晴れ、という複数の環境で、布の白い部分の上でLEDを明滅させながら、LEDがoffの値とonの値をとる。


2. Excelを使い、それぞれの環境のデータを「光センサ値の差分」と「offの値」の2軸の相関図でプロットする。


3. 対数関数で近似。この対数関数をwhite(x)とする。（きれいに近似できるはず。出来なかったら、なにか間違っているかも）


4. 布の黒い部分で、同様のサンプリングを行い、対数関数black(x)を出す。


5. （路面の黒さ）＝（y - white(x)) / (black(x) - white(x))　で、計算。（xは光センサ値の差分、yはoffの値）

という感じです。
正規化もされるので、値の使い勝手もいいです。

次に、周期の問題。
結論からいうと、16msecが限界です。

12msecという結論を出しているチームもありますが、自分で試したところだと、たしかに12msecでの明滅でも、offとして得られる値、onとして得られる値は安定するのですが、フェッチするタイミングがズレます。
offの値は、LEDをONに切り替える瞬間にフェッチすれば問題ない（＝遅延は12msec）のですが、onの値は、LEDをOFFに切り変えて4msec後にフェッチする（＝遅延は16msec）必要があるようでした。（※今手元に資料が無いので、逆かもしれないです）
回路シミュレータを使われているチームがありましたが、立ち上がりと立ち下がりで差があったという報告もあったので、その報告を聞いて「あ、あの実験結果は、そこが原因なのか」と非常に納得しました。
立ち上がりと立ち下がりが対称だなんていうのは、幻想にすぎないのですよ。
現実は違うわけです。

さて、じゃあ、フェッチのタイミングがズレてでも、12msecごとで明滅させるべきなのか、という話です。
これは、光センサ値の影響力が非対称になるという影響が、読みきれません。
12msecで明滅させているわけですが、実際には16msec, 8msec, 16msec, 8msec, ... という周期で値は読めることになります。
そうすると、影響力に差が出てきます。
タスクの動きも複雑になります。
さらに、積分制御、微分制御を行なっている場合には、単位時間についてちゃんと考えてあげないといけなくなります。

そこまでやるくらいなら、16msec周期で明滅させたほうが、リスクが低いです。

----
(2011-11-19 追記)
すみません、上記の12msecでのフェッチのタイミングがズレる、というのは、当時の調査結果の資料を見ないで書いたのですが、たぶん間違っています。
あとで調査資料を見直して、修正します。
----

ジャイロオフセット値操作

まず、最初に書いておくと、これについては全然調査していないです。
噂では聞いていましたが、チャンピオンシップ大会で目の当たりにして、その効果に驚きました。
なので、「こういう要素技術があるんだ」というメモとして、書きます。

ジャイロオフセット値操作が何かというと、走行体を急加速・急停止させるための技術です。
ジャイロオフセット値をあえてずらすことで、倒立振子APIに「前のめりになっている！」「後ろのめりになっている！」と勘違いさせ、それをリカバリーするために算出されたモーター入力値を使用することで、急加速・急停止を実現させています。

実際に使っているチームの走行体の振舞いを見ると、ハッキリと分かります。
シーソー・階段という3D難所をクリアするためには、必須の技術ですね。

実際に実験を出来ていないので、あまり深く書けないのですが、まいまい式とかと同様に、当たり前の要素技術として紹介されるべきなんじゃないかなぁ、と思います。