今回の課題は下図のような幅20mmの線を書き、AからSを決められた順序で通り、道中の決められた箇所でコップを取り別の箇所へ移動させるというものだ。禁止事項として�[~秒後に~の行動をする]というプログラミングはしないこと。�線の太さを変えないこと。写真A(全体)写真B(前後のタイヤ位置)ロボットのタイヤはセンサーが地面に直接、接しないようにするためにRisの基本的な構造から前後のタイヤを逆につけることで機体の傾きを調節した。急なカーブをすることが必要とされたため、前後のタイヤを互いの距離が近くなるよう(写真B)につけることで急なカーブができるようにした。写真C(アーム)アームはモーターに対してギアを噛ませずに直接つけたため勢いが出てしまった。初めはブロックで作ろうとしたが、アームが地面についた際に勢いで壊れてしまう可能性があった。そこで、柔軟性があり、軽い素材で作ろうということになった。チューブと棒というシンプルな作りにすることで、軽さと柔軟性が出てモーターに対しても優しい作りにすることができた。写真D(アームの先端)また、アームの先端に上記のような部品をつけることで、コップを下した際も十分な高さを確保することができ、コップを取った際にアームからコップが出てしまうことを防ぐことができた。この部品をつける以前は、軽すぎたの鞭のように地面に当たった時に跳ね返ってしまったが、その問題も防ぐことができた。写真E(センサー位置)線とセンサーの距離をなるべく近づけることで、余計な情報が入らないようした。初めは高い位置につけていたが、余計な情報が入ったことで正確なライントレースができなかったので低い位置につけることにした。このセンサー位置を決定するまでにずいぶんと苦労したので、その過程は最後の苦労した点で記す。�黒っぽい(THRESHOLDの値=およそ(38+47)/2)ならば左へ�黒(THRESHOLDの値=38)ならば左急カーブとした。基本的なライントレースは、ifとwhileを用いた。while(FastTimer(t)<=26)ならば0.26秒の間は同じ行動を繰り返すので、ifを用いて白ならば左へ、黒ならば右へ、黒と白の間なら直進と動くことで線の境界線をジグザグに動くことでコースを進んでいった。この時に、それぞれの行動の後にClearTimer(t)を入れることでそれぞれの行動が0.26秒を越さない限りはwhileの行動を繰り返すことができた。上記のifとwhileの性質を利用して交差点の判断も行った。Dを出発してすぐにある交差点Cでは、真っすぐに進んでも、左、右に行ってもセンサーが黒と判断する時間が0.26秒(while(FastTimer(t)<=26)の場合)を超えてしまい、whileのループから外れてしまう。この図においてはオレンジの円がセンサーに該当するが、移動する前のセンサーの位置から機体が前進や右へとそれぞれ移動すると仮定してみても、黒の域から外れないため最終的にはセンサーは黒を感知して左へと移動しようとする。この際にセンサーは矢印のような軌跡をたどっていくが、黒の域を超えないまま連続して左へ行こうとするため、ループの条件としていた「0.26秒より多く同じ行動を繰り返さない限りタイマーをリセットしてループする」から外れている。この時whileのループから外れているということはこれが交差点だという証明になっている。よって、交差点の判断を行うことができた。下記に実際に使ったものを例として挙げておく。Off(OUT_AC);}このサブルーチンにおいても、これまで説明してきたことが実際に使われているのが分かる。}}上記のサブルーチンの説明E-Fを超えるために、初期段階では急カーブのみだと越えることが出来なかったため、ライントレースする側を左から右に交互に切り変えることによって越えようとしていた。発表直前までには急カーブのみで超えることができたため上記のサブルーチンを使うことはなかった。left_Line()は特殊な場合を除いて、今回のライントレースにおいて主として用いたものだった。left_Linehalf()はP-Qなどの円の箇所をライントレースする時に、他と同じようにライントレースをするだけではQを交差点として判断してくれなかったために、FastTimerの時間を短くするなどの変化を持たせたものだ。今回、私が最も苦労した点はP-Sのプログラミングだった。P-QにおいてセンサーがQの交差点部分を交差点と判断させることが出来なかったことだ。初めは、禁止事項�の[~秒後に~をする]というプログラミングを組んでいたものの、途中で禁止と通達があり断念。(そもそもそれでP-Qを通ることが出来たかは不明だが)プログラムの要素やロボットの改良を行うことで、この課題をクリアしようとした。�’THRESHOLDに加減する数値を徐々に大きくすることでQに垂直に入るようにし、他の交差点部分と変わらない条件にさせる以上の改善後の結果を以下に記す。�’は、どれだけ時間を短くしても良い結果は得られなかった。�’は、Qに関しての直接的な結果は得られなかったが、全体的なライントレースの質が向上した。これは、無駄な情報が省かれたために1回ごとに結果が変わるということが少なくなったためと考えられる。�’は、ある程度プラスの結果が得られた。�’は、加減する数値をどれだけ変えても良い結果は得られなかったが、THRESHOLDの値事態を変えることである程度プラスの結果が得られた。結果としては、上記の改善をしてもQを交差点として判断させることはできなかった。それがロボット自体の問題なのか、プログラムの問題なのかは分からないが本番までにクリアーすることが出来なかったのは悔やまれる。今回の課題は、ロボットの機体よりもプログラミングに関しての障害が多かったように感じられる。なると、相方とほとんど同じ機体で変わっているのはプログラムだけとなってくるので、相方ができて自分が出来なかった時はとても悔しかった。相方と協力し、知恵を出し合いながらする作業はとても楽しかったし、やりがいがあった。欲を言えば最後まで何の問題もなくゴールしたかった。他のグループを見ていると、プログラミングの技術の高さだけでなく、見た目まで凝っているチームがあり見ていても楽しむことができた。締めとして、これまで受けた刺激、悔しさを最後の課題では十二分に発揮してロボテイクスゼミを終了できるようにしたいと思う。