ETロボコン2010に出場した。一番先に結果を書くと、地区大会敗退でしかも完走ならずだったので、残念だったけど、得たものや見えたものが色々あったので、ここにまとめておきます。少々長いですが、お付き合い下さい。
初出場の壁
わからないことだらけ
今回ETロボコンには初出場。最初はなんとかなるだろうと、根拠なき自信があったのだが、開発を進めるに従って、あまりにも分からないことが多すぎた。
それは、Lego Mindstorms NXT + NXTOsekというドメインに対してもそうだし、ETロボコンというコンテスト自体に対してもそうだった。
分からなかったことを挙げてみると、こんな感じ。その後分かったことも併記しておく。
- インコースとアウトコースのバイナリーは別にする？
→一緒にできれば一緒にしても良いが、一般的には別バイナリにする - PID制御がオーソドックスのようだが、何の値に対して制御をかけるのか？
→光センサーから取得した値に対して - 走行ログはどうやって取るのか？
→Bluetoothで、サンプルを改造して実現 - マルチタスクにするには、C++での実装で対応すれば良いだけではないのか？
→*.oilファイルも記述しないとダメ？ - デバッグはどうやってするのか？
→基本的には机上デバッグと走行ログの解析 - データをファイル出力できるのか？
→できなそう・・・
これらを実験したり、経験者に聞いたり、ネットで調べてみたりと、調査に結構な時間が取られたように思う。
家庭とロボコンの両立
我らがチームは全員子持ちの既婚者で、自分の時間を取るのが中々難しい。特に、開発最盛期の夏は、子どもの夏休みが重なったりして、夏休みなのに夜なべしてるメンバーもいた。うちは、奥さんがブーブー言いながらも理解を示してくれたのだが、こちらも夏あたりにいい加減つまらないと言われてしまった・・・。
やっぱり家庭とロボコンの両立は難しいなぁ、と後半になるにつれ感じた。これが、ロボコンが若手の登竜門たる所以だろうか。もっと若手メンバーが欲しかった…。
モデルワークショップでの1コマ
モデルワークショップの中で、審査員の方がVDMに対して言われていたこと。「OCLを使えば、VDMを同じような表現がUMLでもできると考えている。」という趣旨。
確かにOCLを使えば、VDMで言う所の陰仕様、機能や構造のシグネチャと制約条件は記述することができる。しかし、OCLではVDMの陽仕様、仕様としての機能詳細が記述できない。また、VDMでは陽仕様を動作させてテストすることができるが、OCLではできない。
OCLというかUMLの弱点はそこにあると思っていて、要は書きっぱなしになりがちだということ。せっかくモデルとして書いたんだから、その確からしさを検証したい、というニーズに応えられないことだと考える。
でもこれは、うちのチームのアピールが下手だったことが原因。UMLを根底に置くETロボコンにおいて、VDMを使うことのメリットやUMLとの違いを伝えられなかったことにある。これは、次回以降の大きな課題になりそう。
ロボコンに求めること
モデル提出の全国共通化
競技は運営委員のスケジュールや人数もあるから、全国一斉は難しいと思う。でも、やっぱりモデル提出や地区大会に1ヶ月のタイムラグがあると不公平感を感じる。せめて、モデル提出は全国一斉でもいいのでは？
試走会場が1回は地区大会本番と同じだと助かる
東京地区大会は日光が入ることがあるような環境なので難しい。これは今回地区大会の午前中に試走して、うちのチームが青ざめたとこ。なにせ、試走会では問題なくコースを回っていたプログラムが、環境が変わっただけで全く走らない。
これを避けるために、できれば本番と同じ場所で試走会ができるとうれしい。これは、実現が難しいことが容易に想像できるので、できたら助かるなというレベル。
情報公開を早く、fixを早く
今回、ミステリーサークル絡みの競技規約が結構地区大会の直前に出たこともあって、ちょっと物議をかもしだしてた。また全体的にMLで流される情報が、もう少し早いといいなと思うことがあったので、できるだけ情報公開を早くしてほしいし、それ以上にfixを早くしてほしい。
モデル提出のファイルサイズ上限
モデルのファイルサイズは1MB以下と定められてた。でも、これがモデルとコンセプトシート合わせて1MBなのか、それぞれ1MB以下であれば良いのか、1MBを超えてしまった場合は失格になるのか、等々分からないことが多かった。
結局、容量オーバーしても罰則はないみたいだし、この制限を撤廃するか緩くした方がいいのではないかと思った。確かにアップするサーバーのディスク容量もあるから、容量制限を撤廃して何10MBもあるようなファイルをみんなアップしたら困ると思う。でも、モデルの枚数は決まってるし、そんなに途方も無いファイルサイズにはならないはずだから、なんとかならないものだろうか？
ファイルサイズは、モデルの本質とは全く関係ないので、1MBに収めるためにあれこれ試行錯誤する時間がもったいなかった。容量制限がなければ、クラス図等の解像度を落とさなくて済むので、審査もやりやすくなるのでは？
もっとネットに情報が出るといいな（自分も含めて）
これは競技という性質上だと思うんだけど、とにかくネットや本などで出ている情報が少ない。今回初出場だったので、そこが大変だった。
中には色々な情報を載せて下さっている方もいるんだけど、やっぱり足らなかった。これからは、自分も含めて、もっと情報が出てくるといいな。
反省点
PM不在によるスケジュール感のなさ
今回は、みんな技術と経験をしっかり持ったメンバーだったため、明確にPMとして動く人がいなかった。当初は、大雑把なスケジュールも立ててあって、そのスケジュールに沿って開発していこうとしていたんだけど、結局全然スケジュール通りに進められなかった。
その原因としては、前半はまだ時間的余裕があったので、議論を多くしてしまったことが挙げられる。これにより、中々興味深い議論はできたんだけど、手が動かず成果がでなかった。
2つ目には、後半にモデルと実装が分離してしまったことが挙げられる。前半議論に時間を使いすぎてしまったために、後半は時間が足りなくなり、モデルの担当と実装の担当が完全に分かれてしまった。
これらは、やはりPMがいないことが原因の1つだと考えられる。よく言うと、チームで動いていたのだが、リーダー的存在がいないことが与える影響を実感した。
コンセプトの早期決定とチーム共有がしきれなかったことで、モデルとコードのトレーサビリティが後付け気味になった
チーム結成当初にコンセプトは決めていた。しかし、そのコンセプトに対してどのようにアプローチするかを決めずに、開発をスタートした。その後、次第に日数がなくなったことで、モデルとコードの担当者がバラバラになってしまう。これにより、モデルとコードのトレーサビリティが後付け気味になってしまったことが反省点。
メンバー募集への積極性不足
当初の予定では、若手メンバー＋ベテランメンバーで、若手を中心に進めていって、ベテランはアドバイザー的な役割にしようと思っていた。でも、メンバー募集を全社のWebサイトでしてみたものの、全く集まらない…。どうやらエンタープライズ系が多いみたいで、「組込み」と聞いた時点で自分とは関係ないと思ったことと、プライベートを犠牲にしての活動に躊躇した様子。
VDMに関して
メリット1 - ソフトウェア構造の確かな可視化
当初の考えで記述し、開発が進むにつれ現実と離れがちなクラス図。1つの原因としては、クラス図の確からしさを確かめる手段が人手に頼ることだと思う。
VDMを使うことで、動作させてテストした構造と振る舞いをベースとしたクラス図を用いることで、開発の初期段階から実現性を確認することができた。また、形式仕様記述言語によって仕様を記述することは、自然と用語の統一をすることになり、メンバー間の意識合わせを確実にすることができた。
メリット2 - 机上シミュレーション
今回、PID制御に関しては、実装に限りなく近いモデルを記述した。これにより、PID制御の計算結果を机上でシミュレートし、テストすることが可能となった。
また、このVDMで記述したPID制御モデルに対し、実走ログをテストデータとして与えることで、より実環境に則したシミュレートが可能であった。
なお、この実走ログからVDMテストデータを得る部分に関しては、変換ツールを作成したため、自動生成が可能となった。
デメリット1 - アピールポイントを定めることの難しさ
形式手法の中では、言語の自由度が高く、様々な粒度でモデルを記述することができるVDM。その自由度が、コンテストにおけるアピールポイントを定める時の戸惑いにつながってしまった面があると感じた。
その点を完全に解消できていなかったためか、モデルへの評価でも、「VDMを用いたことから予測できる性能が読み取れない」という記述があった。自分達からすると、今回VDMと性能を結びつけたのではなく、VDMを軸とした検証された構造と振る舞いモデルを作り、実走の省力化と高品質を実現したいという思いがあった。
常々感じていたことではあったが、VDMをどう見せるか？どう伝えるか？をしっかり考えなければ、自己満足なモデルでしかないと実感した。
デメリット2 - モデル粒度と実装と抽象化のバランスの難しさ
これもVDMが持つ言語の自由度に起因する部分があると思っている。上流に寄り過ぎて机上の空論的なモデルになってしまうことと、下流に寄り過ぎて実走と変わらない抽象度の低いモデルになってしまうことが懸念されていた。特に、NXTOsekのように整ったフレームワークがある場合、実走のイメージがしやすいため、下流に寄り過ぎることが多いと感じている。
今回は、なるべくいわゆる要求仕様、ロボコン用のNXTとして何を実現したいのか？の観点で記述するよう心がけた。その一方で、PID制御に関しては実走レベルに近いモデルを記述したりと、モデルの粒度に関して若干迷走気味な部分があったことは、今後の課題だと思ってる。
最後に
運営委員、審査員の方々おつかれさまでした。色々と大変だった面もありつつ、とても楽しませてもらいました。ロボコンは中毒性がある。今回出場したことで、次はもっとうまくやれるのではないか？こうしたらどうだろうか？という思いが出てきて、機会があれば来年も出たいと思う。
そして、チームのメンバーにも感謝。僕は結局実装にほとんど触らずにモデルを担当したけど、近くで見ていて、利かん坊なNXTに苦労しているのがスゴくよく分かった。みんな家庭を少なからず犠牲にしながらで大変だったけど楽しかった！
0 コメント:
コメントを投稿