つくろとは？
|
基本的にステッピングモータによるオープンループの制御を行っている。ただ、それだけでは誤差の蓄積により、自己位置が迷路の区画の中心からのずれが増えていくので、ロボットに対する前壁の検出を用いて自己位置の補正を行う（動画参照)。普段の姿勢制御は、側壁上面をトレース（という表現は正しいのだろうか？）しながら常にロボットが側壁との距離を一定に保って走行できるようにしている。マイクロマウス関連の競技では、近年この方式は減る傾向にあり壁側面とロボット間の測距方式が主流になってきているが、今回は初参加ということもあり、会場の雰囲気も不明なことから調整が比較的容易（閾値をボリュームで調整するだけ)であるデジタル出力形式のセンサ回路を使用した。また、後述する隣区画の側壁検出のためにも、蛇行は避けたいという観点からもこの制御方法は有効であると思われる。しかし、欠点として今回私達の製作したような検出範囲が狭いセンサ回路（ポート数の制限があるため)の場合、なんらかのきっかけにより車体の向きが大幅にずれてしまった場合、センサが壁のどちら側にはみ出ているのかが判らなくなってしまう。 壁や缶の検出は、ステッピングモータに与えるパルス数（つまり走行距離)に対して、ある区間を設けて行っている。区間の移動中、最初から最後まで検出を継続すると上述の誤差の蓄積により次区画の壁や缶を誤認識してしまう恐れもあるためである。またPSDセンサが以下の写真のように取り付けられている。左側が缶の検出用で右側が隣区画の側壁検出用である。ソフトウェア的に缶を隣区画の側壁として誤検出しないように工夫しているが、場合によっては側壁を検出できないケースも直面している。ただ、その場合はその区画まで行って検出すれば良いだけのことで致命的な問題とは考えていない。 缶の検出は、ロボットの前と側面の３方向対し行い未処理の缶を見つけ次第ひっくり返す動作を行っている。置く場所は、出来るだけその後の探索に邪魔にならないような場所（左手法を用いていることから迷路の外縁に近い方向へ)に置くようにしているが、シミュレーションを見て頂くとわかって頂けるように、もう少し工夫の余地があったのではないと思う。審査員の先生にも、「それではスタート地点への帰還の際に邪魔になる」とのご指摘を受けた。もっともである。特にスタート地点にも置いてしまうのが致命的である。そのことについては、反省の項で触れる。 肝心な缶をひっくり返す仕組みであるが、バックドロップ方式を採用している。ハンドの形状は、写真からわかるように特殊である。これは、動画の中で様子を確認できるが、ある程度の缶配置場所の誤差も許容できる。このアイデアは、昨年本競技で優勝し東京農工大のロボットを参考にさせて頂いている。アーム部については、サーボモータを用いているのだがアーム部の重量もあり振動が無視できないほど大きい。この振動により、動作全体のスピードを下げざる得ない状況である。本来は時間があれば、サーボ内部のポテンションの値を引き出してPID制御をかけたいところである。(そもそも、アームの作りが良くないと言うこともあるのだが･･･) 本ロボットで最重要項目（これを評価していただきニューテクノロジー賞を受けることが出来た)である仮想壁の生成であるが、コの字状の壁に囲まれている（つまり出入り口が一つ）の区画の缶の有無を検出後、その後その区画は袋小路であるため行く必要がないため出入り口を仮想壁によって塞ぐ。その塞いだ仮想壁によって、その方向の隣区画も同様な条件になったとしたら、その区画も仮想壁により封鎖する。同様な作業を再帰的に繰り返し、袋小路を潰していく。この作業を効率的に行うため、具体的にはロボットが訪れていない区画に関しても缶と側壁の有無は隣区画を走行することで確認できるため、通過していない袋小路に関しても潰すことで探索にかかる走行距離を大幅に削減することができる。JAVAによるシミュレーションのサンプル迷路２を実行していただくとその効果を理解していただけると思う。詳しくは、是非下記のシミュレーションを実行して頂きたい。袋小路の多い迷路ほどこの機能を有効に働かせることができる。 左の画像は、ロボットが探索終了後に出力した探索結果。見方としては、壁のある方角に対して、北:1 西:2 南:4 東:8 （つまり各ビットを立てている)となっている。つまり、wall=07というのは7=1(北)+2(西)+4(東)より北西南に壁が存在していて、15のときはその区画は閉じられている。右下のスタート地点である区画がmap[0][0]、左上の区画がmap[2][2]となっており、手前が北の方角、東方向にx軸、南方向にy軸をとっている。 上の二枚の写真であるが、動画と対応していて、左がスタート時、右が探索終了時である。青線をひいた部分が生成した仮想壁である。一見、囲まれて動けなくなっているようだが、シミュレーションの実行して判って頂けると思うが、帰還時には、帰還時に通過する区画の仮想壁は除去する。動画中では、探索終了時に、ロボットは動作を停止させ、探索結果の吸出し待ち(eepromを使っていないので...)をしている。 私達の製作した上の画像にあるような3×3の迷路では、迷路走行アルゴリズムのデバッグ作業を行うことが困難である。そこで、JAVA言語によるシミュレータを作成して、そのシミュレータ上でアルゴリズムの検証を行った。JAVAの制御構造は、Cとほぼ同じと見なせるため、JAVAで製作したロボットクラス(Clipper.class)の内容をマイコン用C言語にほとんど修正なしで移植することができる。このシミュレータは今後、誰でも利用できるように特にJAVAの知識を持たなくとも、C言語の構造体の知識が少しあれば利用できるように工夫している。 誰か利用したい人がいれば言って下さい。出来るだけ早くに、必要なファイルとサンプルソースを公開できるようします。（現在整理中です。）Cでマイコン動かしている人なら誰でも使えると思います。皆でマウス関係の競技を始めませんかー。 迷路の探索は、基本的に左手法で行っている。ただ、ショートカットは出来るだけしている。また、上述した仮想壁も積極的に生成している。見て判るように缶の置く場所をもう少し工夫すべきである。以下のシミュレータでサンプル迷路としているのは、過去のマイクロクリッパーの大会の実際に使われた迷路である。ただ単純な左手法による探索だと、一区画を必ず二回訪れることになるので256×2＝512回のステップ数（区画間の移動数)となるが、私達のアルゴリズムだと、上に挙げたような工夫により大幅にステップ数を減らすことに成功している。是非、サンプル迷路を実行して確かめて欲しい。ただ、ランダム生成される迷路では、ある条件が満たされると大きなループが形成され効率が極端に落ちる。今回は、過去の迷路からそのような状況は起こり得ないとして対策を特にとっていない。 緑色の線は、生成した仮想壁。timesはその区画を通過した際のスタート時から数えたステップ数、visitは訪れた回数である。これらの値をヒューリスティクス(heuristics)として適用し、探索を進める。最後にスタート地点まで戻るときに最短路を求めるべきなのですが、時間が無くて出来ませんでした。今後の課題にしたいと思います。もし、シミュレーションではまるような状況があれば、実際のロボットも同じような条件ではまります。そうしてバグ取りを進めていきます。どうぞ、缶や壁を色々と追加してクリッパーの振る舞いを観察（苛め?)してみてください。(色々と未探索領域の重心を求めてそちらにクリッパーを進めていく方法等編み出しましたが、結局現在の方法がどんな迷路のも安定して結果を出します。こうして、色々とアルゴリズムを思索するのはとても楽しいです。サークルの皆さんもどうですかー？) 4回のトライ中、毎回4個をひっくり返し、同じところで誤動作。再現性100％！（無駄に）。得点の個数的には5位でした。出走順位が2番手で、昨年の大会で4個ひっくり返したロボットが3位に入賞したという事実を知っていた私達は、内心「もしかすると...」という気分になっていたのですが、次第に打ちのめされていきました。ただ、他の参加者のロボットを拝見してとても参考になりました。 ただ、私のたどたどしい仮想壁の生成に関しての説明を理解してくださり、ニューテクノロジー賞を与えてくださった審査員の先生方に感謝をしております。今までの苦労が報われ、私達二人とも、「これからも頑張ろう！」という気持ちにとてもなりました。どうもありがとうございます。次回こそは、新技術を優勝に結びつけられるように奮闘したいと思います。 ・シミュレータを実行して気づく方がおられるかも知れませんが、かなり膨大な計算をしています。そこで、H8/3664では、JAVAで作成したプログラムを最適化せずにを実装することが出来ずに、それまでマイコンのプログラミングでは行ったことの無い最適化オプションをコンパイラにつけることにしました。すると、大会前日に誤動作のオンパレード。プログラムの量を減らすべく努力を徹夜でしましたが、うまくゆかず、会場への出発30分前（午前3:30)になんとか、自作の迷路の上では誤動作を起きない状態にするこができました。しかし実際の大会の巨大迷路では、予期せぬ誤動作が再現性100%で起きました。会場で、調整しようにも、すべてがうまくゆかず間に合いませんでした。どうやら、最適化によって、いたるところでwaitや変数のインクリメントが無視されていたようです。しかし、対策として普段使わないvolatileを付けたのですが、駄目でした。この時点で、最適化についてよくわかっていないのも問題です。 ・それと他の参加者の方のマシンを見ていいると、ハードウェアの完成度が高いと思いました。次回は、もっとハードウェアにも力を入れたいと思いました。（といっても苦手気味なのですが...）。見ていて、安心な走行の出来るマシンを作りたいです。それと、シンガポールの方のスラローム走行には感動しました。マイクロマウスで行われているのは知っていましたが、マイクロクリッパーでも実現しようと思えば、確かに出来るものだと思いました。次回の課題にしたいと思います。それと探索済みの区画は、モードを変えて走行スピードを上げることも可能だと思いました。 ・これは重要です。ルールをしっかり理解しておくべきです。再スタート時に缶をひっくり返したままで、かつロボットの迷路の情報を消去しなくとも良いという重要な事実を理解していませんでした。おかげで、毎回スタート地点に缶を置いてしまい、再スタート不可能という致命的かつ恥ずかしい欠点をさらすことになりました。次回は、このルールをフルに活用して、重ね探索を可能にしておくべきだと思います。 ・マイクロクリッパー競技は、現在の状況では、頑張れば優勝に手の届く競技だと思います。次回こそは、是が比でも優勝を得たいと思います。大会の帰り道の間も沸々とアイデアが浮かんできました。まだ、秘密にしておきます ：）。 ・最後の表彰式でアナウンスされていましたが、次回は会場照明の条件が厳しくなる（つまり照射が強まる）みたいです。その点を踏まえて、センサの選定も行わなくてはと思っています。競技後にご指摘を頂いたのですが、「自分の持つ環境」と「大会会場の環境」との違いを言い訳にすることは出来ません。ある程度の環境の相違は、許容出来る、安定した動作をする知的なロボットを目指したいと思います。 |
[ 97] つくろぼクリッパー報告書
[引用サイト] http://www.stb.tsukuba-ac.jp/tsukurobo/clipper_report/report_index.html
