「コンテナ」ミッションの攻略：押す

「コンテナ」ミッションの攻略：押す

　別のチームでは、「コンテナ」ミッションを異なる戦略により攻略していた。その紹介の前に、その前提となるアプローチを説明する。

　各ミッションの攻略にだいたいのめどがついたところで、全ミッションを通しで遂行させてみた。ところが、どうしても制限時間（2分30秒）内に完了しない。この対策についてチーム内で議論した結果、ミッション群遂行のフローを考慮し、次のような改善案が出された。

　まずミッションそれぞれで「ロボットのスピードの向上」をはかる必要があり、その方法としてモーターのパワー、ギア比、タイヤの径を大きくすることが考えられる。

　またミッション間では、「アタッチメントの着脱時間の短縮」をはかる必要がある。その方法として、「アタッチメントの数を減らす」「アタッチメントを着脱しやすくする」が考えられた。さらに「複数ミッションをまとめて遂行」するといった方法も検討された。

　ロボットスピードについては、あまり速くしすぎると逆に十分なパワーが出ないケースも考えられたものの、試してみたところ問題のないことがわかった。また、プログラムへの影響が大きいことも問題視されたが、全般的に有効な改善であったため、採用することとした。

　「アタッチメントの着脱時間の短縮」におけるアタッチメント数の削減については、少し頭をひねる必要があったが、いくつかのミッションで採用した。アタッチメントの着脱についても、ほとんどのミッションで同じように、簡単な操作でできるような工夫を行った。これらは、部品やインタフェースの共通化／標準化であり、製品設計の基本である。

　「複数ミッションをまとめて遂行」は、各ミッション遂行後に毎回ベースに戻るのではなく、いくつかのミッションを遂行してからベースに戻るというものである。これを実現するためには、ミッションごとのアタッチメントを共通化するか、複数のアタッチメントを同時に装着する必要があった。まとめて遂行するミッションの組み合わせに関する検討と試行錯誤の結果、いくつかのミッション・グループにまとめることができた。この実現には、プログラムの変更も必要であったが、基本的に、各ミッションのプログラムを接続すればよく、それほど大きな影響はなかった。

　以上の過程を経て、このチームでは「コンテナ」ミッションについて、「押す」ことにより攻略するという方針を決めたのである。なお、図2は、このチームのテクニカルプレゼンテーションの模様である。

複数ミッションをまとめて遂行する総合戦略と「リスク管理」

　複数ミッションをまとめて遂行することにより、何とか制限時間内で全ミッションを遂行できるようになった。ところが、ここで新たな問題が生じたのである。

　というのは、一連のミッションを遂行する途中で失敗することが時々あり得るということである。いったん失敗すると、残りのミッションを遂行することができなくなる。あるいは、残りの1つのミッションを遂行するために多くのムダな動きを余儀なくされることが明らかになった。

　ミッションを1つずつ遂行する場合には、それを失敗してもそのミッションの得点が入らないだけであったが、複数のミッションをまとめて遂行する場合には、途中のミッションの失敗により、得点・時間を大幅にロスするという問題が明らかになった。当然のことながら、複数ミッションをまとめたことにより、失敗する確率も大きくなってしまった。

　これにはチーム全員頭を悩ませたが、チーム内で知恵を出し合った結果、一部のミッションについては、代替手段を用意しておくことにより、得点を確保する手法を採ることとした。基本的には「ベースからまっすぐ前進した後、まっすぐ後退してくる」程度でミッションが達成できるものを対象とした。意外にも多くのミッションがこのシンプルな動きで達成可能であった。

　なお、代替手段のためのプログラムについては、アタッチメントの交換だけで同一プログラムを使用したり、1つのプログラム内に2つのサブプログラムを含めておき、スタート時のタッチセンサのオン／オフに応じて実行するサブプログラムを選択したり、といった工夫により、マインドストームにおけるプログラム数の制約（5個以内）に対応した。

　このように、「何か起きた際に別の手が打てる」ようにしておくことは、実際の仕事でも行っていることである。その必要性を自分たちで考えて手を打ったという経験は、とても価値あることではないだろうか。

　なお、FLL2006では競技内容の特徴も考慮して、基本的に1ミッションずつ遂行する戦略を採用した。この方が確実であり、かつ制限時間内に全ミッションを遂行できたからである。