|
[2013 年 7 月号] |
ETロボコン特集
| 聖望学園高等学校 | |
| 科学部部長 石川 公一 | |
「高校生に活躍してもらうことで組み込み業界を盛り上げていきたい」という弊社支援メンバーの思いと、 「モデリングの本質を理解して、もう一度、チャンピオンシップ大会の雰囲気を味わいたい」という科学部顧問の永澤先生の思いが重なり、 2012年3月から弊社メンバーが高校生に対してモデリングの教育を行っています。
C言語とUMLの利用経験がある高校生たちが、いかにしてC++、オブジェクト指向、モデリングを習得し、ETロボコン2012の北関東大会で全部門1位を獲得し、 チャンピオンシップ大会に出場したのか、その活動過程と成果を前編と後編に分けてお届けしたいと思います。前編は、活動成果である チャンピオンシップ大会に提出したモデルの紹介です。メンバーの一人である石川さんに渾身の力を振り絞って執筆していただきました。
なお、本高校生チームは2013年度のETロボコン大会にも新しいメンバーでチャレンジしています。
モデリングを始めたのはいつからですか？この質問に、「高校生からです」と答える人はいないのではないでしょうか。しかし、最近の高校生対象のロボット大会では難易度が高く複雑なプログラムが要求されます。そのため、モデリングで整理しながらプログラミングすることができれば、開発が楽になり、大会でも有利になると思います。
今回は、高校生である私たちのモデリングへの挑戦を紹介します。他の高校生たちにもモデリングを取り入れてもらいたいと思っています。
私たちは、埼玉県にある聖望学園高等学校科学部に所属している高校生チームです。私たちは毎年、ETロボコンや電子ロボと遊ぶアイデアコンテスト（WRO予選会）、ロボカップジュニアというロボット大会に参加しています。これらの大会では、ブロックを組み立ててロボットを作るレゴマインドストームを使用します。ロボットは、人が操縦するのではなく、搭載されたセンサーを用いて判断して適当な動きをする自律型であるので、複雑なプログラミングが要求されます。私たちの日々の活動は、これらの大会のためにロボット制御のプログラミングをしています。
今回のテーマであるETロボコンには2008年から参加し、2011年と2012年にチャンピオンシップ大会に進出しました。
私たちのチームメンバーは受験勉強で忙しい高校3年生は参加しないので、プログラムやモデルを習い始めた1年生と、1年かけて知識をつけた2年生で構成されています。こんな私たちでも地区大会で優勝することができ、チャンピオンシップ大会に出場することができました。
|
2012年度の私たちの目標は「後輩に残せるモデルを作る」ことです。新入生として入部してくる後輩は何も知らない初心者なので、分かりやすく、開発しやすいモデルにすることが部活の発展には必要になります。
2011年まではオブジェクト指向っぽいモデル（オブジェクト指向をちゃんと理解していなかったため）であったため、変更しにくく、再利用性のないモデルでした。2012年はしっかりとしたオブジェクト指向を取り入れ、できるだけ保守・拡張性を高くし、難所の競技内容が大きく変更されても同じ構造が使えるように設計・開発することを目標としました。
|
| 2011年度のオブジェクト指向っぽいモデル |
|---|
| （クリックすると拡大した画像が見られます） |
これからETロボコンで提出した５ページのモデルをページごとに紹介していきます。
なお、2012年度のチャンピオンシップ大会に提出した「コンセプトシート」と「モデルシート」については以下よりダウンロードしてください。
|
|
| モデルシート１枚目：要求分析 |
|---|
| （クリックすると拡大した画像が見られます） |
以前までは、必要な動作などを必要に迫られたときに、その場その場で考えて実装していました。
そのため、ある程度まではよかったのですが、いつの間にか難解になり、仕舞いには自分は何を直しているのかもよく分らなくなることがありました。
そこで、1ページ目では今まで検討をしなかった要求分析を取り入れました。私たちはマインドマップを利用して、「優勝」をするためにシステムに何が求められているかを洗い出しました。
すぐに要求を洗い出すのではなく、ETロボコンの走行システムの本質を見直してみました。ETロボコンには様々な人々が関係しており、様々な視点の関心事があることに気付きました。その関心事からシステムに関する要求を洗い出すべく、利害者関係分析を行いました。
ETロボコンに登場する人物は、大会を運営する「主催者」、大会で競い合う「競技者」、走行システムを作る「開発者」の三者と考えました。
それぞれの関心事は以下のように考えました(図1-1参照)。
|
|
| 図1-1. 利害者関係分析 |
|---|
関心事から走行システムの要求をマインドマップで洗い出しています。ここでは、走行戦略・要素技術に関わるレベルまで細かく、深く洗い出しを行いました。深く洗い出しを行うことによって、開発途中に分析に戻ることが少なくなり、設計中にどのような機能が必要なのかを確認することができます。
要求をより洗い出しやすくするために、FURPS（機能性、使いやすさ、信頼性、性能、保守性） というソフトウェア品質の観点を用いました（図1-2参照）。「この品質を満たすためには～」というように、品質をどう満たすかも考えていくと、洗い出せる要求の幅も広がっていきます。やはり、品質のよいものを作りたいですからね。
|
|
| 図1-2. FURPSによるソフトウェア品質 |
|---|
例えば、「ベーシックの走行タイムを少なくする」から「速度を上げる」と「PID制御する」をブレークダウンさせた場合、前者はおおざっぱなこと（粒度が大きい）に対して後者は詳細なこと（粒度が小さい）になってしまいます。ブレークダウンする前の要求は、ブレークダウンした後の要求にとって「なぜ」の部分になります。その「なぜ」の部分がなくなると、要求が洗い出しにくくなってしまいますし、「なぜ」この要求が必要なのかがわからなくなってしまいます（「なぜ」PID制御を使うかの答えは、「なめらかに走行する」であり、「走行タイムを少なくする」ではない）。粒度を意識して洗い出すようにしましょう（図1-3参照）。
|
| 図1-3. 粒度を意識した要求の洗い出し |
|---|
この段階の分析では実現できるかどうか（実現可能性）は考えないようにしましょう。「要求」分析ですので、「何が必要なのか」「何をしたいのか」を中心に考え、後の段階で実現可能性については考えるようにしましょう。
|
| モデルシート２枚目：構造 |
|---|
| （クリックすると拡大した画像が見られます） |
2ページ目が2011年と比べると一番変わった部分が多いです。
それは「オブジェクト指向」を取り入れた構造を設計したことです。今回の目標は「後輩に残すモデルを作る」ですので、分かりやすく、保守・拡張性の高い構造の設計に取り組みました。
オブジェクト指向を理解するのは非常に大変でした。今までは「このクラスでこう動かすにはこういうクラスが必要だからつけちゃおう」という考えで設計を行っていましたが、その考えがすべてひっくり返ったような感覚でした。
特にこの構造で精査に時間がかかったのは、「コースパッケージ」のクラス構造です(図2-1参照)。
|
|
| 図2-1. コースパッケージ |
|---|
|
|
| 図2-2. コースパッケージのクラスの概念図 |
|---|
まず、ロボコンのコースを「走行コース」、「走路」、「走行区画」というように分けて考えます(図2-1, 図2-2参照)。
「走行コース」がコース全体という考えで、それを難所などの大きな区切りに細分化したものが「走路」、さらにそれを走行方法と終了条件をもつように細分化したものが「走行区画」といった感じです。
この「走行区画」は終了条件を満たしたら「走路」が次の「走行区画」に切り替えていきます。
また、各走路の開始地点で走行体の向きや走行体の走行距離などの値をリセットするための「心機一転走路」を用意しています。
しかし、これらの概念だけではドリフトターンを走破することはできないのです。なぜなら、「走行コース」の走路を切り替える処理だけでは「ペットボトルを検知した」という一つの終了条件に対して一つの走路に切り替えることしかできないからです。
「ペットボトルが右にあるからAの走路に切り替える」、「ペットボトルが左にあるからBの走路に切り替える」というような条件に応じて複数の走路に切り替えるには別途対応が必要です。
そこで、ドリフトターンにおける走行では「PB探知区画」、「PB探知結果」、「分岐走路」という概念を作り出し、各クラスで次のような役割分担をさせました。
クラス間の関連は、静的（意味的・物理的）な視点で考えた方が関連が安定し、要求の変更に対して強いものになります。値を取得するためだけの関連など、処理上のつながり（○○をやりたいから××とつながっている、など）は変更に弱い構造になってしまいます。関連名が意味的・物理的なものになっているか考えながら作りました。
なお2011年のクラス図では、ほとんどのクラス間の関連名が「取得する」となっていました。（汗）
クラスとは、役割をもっているものです。もちろん、複数の役割を持たすことも可能なのですが、私たちは一つの役割を持ったものとして考えて設計しています（クラス名がその役割）。１つの役割しかもたないので、他のクラスと協調しながら働きます（クラスとクラスを結ぶ線が協調する関連）。また、一つ一つのクラスが単純なので変更も楽です（複雑と感じる場合は、複数のクラスに分割できる可能性もあるので検討を）。クラス同士の関連も少なくしておくとクラス役割を変更しても影響が少なくなります。
オブジェクト指向で設計に取り組んだところまではいいのですが、モデルからソースコードを作成した後に変更が必要になり、モデル検討をせずにソースコードから先に変更してしまいました。その結果、モデルとプログラムが一致しないことが起きてしまいました。この場合、他の人達がこのモデルで開発しようとするときに、正しく開発できなくなります。正しくモデル駆動開発ができなかったのが反省点です。来年以降はモデルからソースコードを作ることに徹底したモデル駆動開発を目指していきます。
|
| モデルシート３枚目：振る舞い |
|---|
| （クリックすると拡大した画像が見られます） |
振る舞いでは設計した構造で本当に動かすことができるかを検証します。
まず1ページ目で機能として抽出したユースケース間の関係性を示しています(図3-1参照)。
 
|
| 図3-1. ユースケース間の関係性 |
|---|
この構造で「コースを走行する」には、図3-2の基本的な走行の振る舞い通りに実装すれば走行できます。では、この振る舞いでドリフトターンの難所も走破できるのでしょうか。図3-3はドリフトターンを走破するために用意した「分岐走路」、「PB探知区画」、「PB探知結果」のクラス間の振る舞いです。ドリフトターンでの処理内容は図3-2とは異なりますが、「走路」、「走行区間」の継承関係にあるクラス（分岐走路、心機一点走路、PB探知区間）へのメッセージは基本的な走行の振る舞いと同一であるため、ドリフトターンの難所であっても、基本的な走行の振る舞いのパターンで走破できます。
|
| 図3-2. 基本的な走行の振る舞い |
|---|
|
| 図3-3. ドリフトターン走行時の振る舞い |
|---|
並行性設計にも取り組みました。並行設計で重要なのが、周期と競合と優先度です。周期が同じでよい場合は、そもそも別タスクにする必要がなく、タスクが多すぎてもよくないので、本当に必要なのか考えます。競合は、あるタスクは動けと命令しているのに、他のタスクで止まれと命令してしまっては動作がおかしくなります。
倒立制御は4ミリ秒周期で動作させないと正しく倒立ができないので、4ミリ秒周期に設定しています。ログ・UIに関してですが、nxtOSEKのロギングAPIを使用してログデータを取得してるのですが、周期が不明なため（ログを取ると倒立動作がおかしくなるので４ミリ秒より長くなっている可能性が高い）、またUIで使用する音は、APIの仕様で鳴らすのに１０ミリ秒必要であるため、これらのことを考え別タスクで設計しました。別タスクにしたことでログや音を鳴らしても倒立動作がおかしくなることがなくなりました。
異なるタスクから同じクラスに対して指示を出したとき、データが上書きされてしまっては正しい処理ができなくなる可能性があります。例えば、Aタスクがモータに対して動けと命令をだし、Bタスクが止まれと命令したらどうなるでしょうか？どちらにしろ求める動作をしてくれません。
今回は、「走行タスク」と「ログ・音タスク」から、音クラスに対して音を出すという命令を出したいのですが、この場合、先に述べたとおり競合を起こしてしまうのでできません。
解決策として、まず、「走行タスク」内の条件クラスが音クラスに対して「音を鳴らす」指示を出します。しかし、ここでは音は鳴らさず、音クラスのメンバである「音の有無」を「有」にして書き込みます。その後、「ログ・音タスク」の処理に遷移し、「音を鳴らす」処理をしますが、先ほど設定した「音の有無」の情報を読み込み、スピーカークラス（nxtOSEKのデバイスクラス)に音を鳴らす命令を出します。このようにタスク間の競合を回避しています(図3-4参照)。
|
| 図3-4. タスクの振る舞いについて |
|---|
実行すべき処理を優先させなければ、適切なタイミングで処理ができない可能性があります。「倒立制御」は、確実に４ミリ秒周期で実行させないとふらついてしまったり、最悪の場合は転倒してしてしまったりします。なので、タスクごとに実行の優先度を与えています。
ここでは、倒立制御のことを考えて、「走行タスク」の優先度を一番最高にしています。「ログ・音タスク」は多少遅れても走行には全く問題がないので、優先度を低くしました。
クラス間がどのように動作するかは示せましたが、クラス内部の振る舞いは示せていませんでした。これではまだ構造の振る舞いの検証が完全にできておらず、本当に開発に使えるモデルとは言えません。次回からはクラス内部の振る舞いも検討して開発していきたいです。
|
| モデルシート４枚目：要素技術 |
|---|
| （クリックすると拡大した画像が見られます） |
ETロボコン2012に、私たちのチームで新たに導入した要素技術を紹介します。特に「段差のぼり」や「走行対傾斜検知」は難所を攻略するための重要な要素技術となっています。
走行体の傾き具合を検知する方法です。坂やシーソーなど路面の傾斜に変化があると、それに合わせて走行体も傾きます。傾きの変化に対して適切に対応しないと、転倒やスリップをしてしまいます。そこで、この傾きの検知が重要なのです。
傾きを検知する直接的なセンサーはないので、角速度が測定できるジャイロセンサを利用します。ジャイロセンサは倒立制御で使用するために走行体についていたので、これを利用します。
角速度とは、瞬間の角度変化ということなので、それを積分（足していく）すると変化した角度が求められます。これから走行体の傾きがわかるのです（実測データはモデルをご覧ください）。
この検知方法を導入したことで、今回の難所であるシーソーをクリアすることができました。
加速・減速時にジャイロセンサが反応してしまうので、傾きがずれてしまうことです。現在の方法では、等速度時のみしか使用できません。なので、車輪の角速度と関連させて、精度を上げたいです。
1段登るための方法です。段差を走行するにあたり、倒立走行で行くか、3点走行（尻尾走行）で行くか考えるはずです。ためしに、走らせてみると、倒立走行ではたまに登りますが、転倒してしまいます。3点走行では、尻尾が引っ掛かり登れません。そこで、私たちは転倒回避に重点をおき、転倒しない3点走行を選択しました。
尻尾が引っ掛かるなら、引っ掛からないようにすればよい。ということで、試行錯誤がスタート。考えた末、「段差に走行体がぶつかると走行体が傾くので、それをジャイロセンサーで検知します。そして登るときに走行体の重心が後ろにくるので、尻尾を下げて走行体を垂直に保ちます。段差部分が尻尾にあたる直前に尻尾を上げて、引っ掛かるのを回避します。」という流れになりました(図4-1参照)。あとは実際に動かして調整しました。ハイスピードカメラで撮影して、タイミングと尻尾角度を微調整しながら完成させました。
この成果として、すべての場所で3点走行（尻尾走行）を実現することができ、転倒するリスクがほとんどなくなりました。
|
| 図4-1. 段差のぼりの技術 |
|---|
とことん尻尾走行にこだわったので、尻尾制御について理解が深まりました。代償として、大会前に尻尾に使用したモーターが故障してしまうアクシデントが・・・。
今回の方法は、計算で値を出している訳ではないので、条件が変わってしまえば１から調整し直しですので、もっとよい方法を考えていきたいです。
一定曲率で旋回する走行方法です。ラインなどの目印がない場所を走行するときに、この走行が重要になります。
旋回なので、左右の車輪をそれぞれの速さで回転させれば一定の角度で旋回するのではないかと考えるかもしれません。しかしながら、モーターの個体差や力のかかり具合などで回転しやすい方に流れてしまいます。そのため、左右の車輪の回転数を比べながら、確実に一定角度で旋回するようにしなければなりません。
方法は、「左車輪の回転数に係数を乗じた値と、右車輪の回転数の値が同じになるように制御する」というものです。左車輪はその時の速度で回転させるだけ。右車輪は、P制御を使用して、回転を加減します。係数は、モデルに書いてある通りに算出します(図4-2参照)。
この方法を考え始めた段階では、sinやcos、テーラー展開などが案として出てきました。私たちには難しすぎてあきらめかけたのですが、よくよく考えたら、簡単な計算でできることを思いつき、この方法になりました。高校生でも自分でできる範囲で考えれば、なんとかなるものです（笑）。
また、おまけとして係数を１にすると、左右車輪の回転数を同じにしようと制御するので、まっすぐきれいに進みます！副産物だったのですが、重宝しました。
|
| 図4-2. 等回転比走行の技術について |
|---|
何か良い技術を思いつけば、それだけで走行が楽になります。私たちは今までの大会では、練習段階でも最後まで走行することができませんでした。それが、上記に書いた技術を導入したところ、完全に走行することができました。
技術を身に着けるには、他チームのモデルを参考にしたり、他のチームの方と議論したりすることが重要です。いろいろなアイデアがあるので、そこから自分たちなりに工夫すればよいのです。
審査でのポイントは、自分たちが考えた技術をモデルに書き、その技術が納得できるものなのかということです。実現可能性をみられるので、ここで審査員にアピールしましょう。
審査員の方から自分たちが使っている技術はすべて記述したほうがよいと指摘されたので記載したのですが、ペットボトル検知などは信頼性のないデータしかなく、これでよいのかと自問自答することがありました。提出日ギリギリでやるのではなく、余裕をもって信頼性のあるデータを取ることが重要だということが分かりました。
|
| モデルシート５枚目：走行戦略 |
|---|
| （クリックすると拡大した画像が見られます） |
走行戦略はアクティビティ図を用いて示しています。しかし、アクティビティ図は紙面スペースを大幅に取ってしまいます。更に、構造とのトレーサビリティが取りにくいという点があります。なので、私たちはアクティビティごとの「アクション」と「ガード」のそれぞれをクラス図で示した「走行方法」と「条件」のクラス名に合致させて記述しました(図5-1参照)。記述法はETロボコン2011の参加チーム「HASH UFO」さんのものを参考にしました。他のチームの良いところは積極的に取り入れましょう！
|
| 図5-1. アクティビティ図の見方について |
|---|
ここでは先ほど紹介した「段差のぼり」を有効に活用しています。 まず、段差のぼりの技術を使って、スムーズに段差を登っていきます。ここで、段差を登った後、倒立走行モードに切り替えます(図5-2参照)。なぜかというと、尻尾を下ろしたままでは、引っかかってしまい、転倒してしまうからです。降りた後はまた尻尾を降ろして尻尾走行に切り替えて、ライントレース走行を開始します。
|
| 図5-2. 階段の戦略 |
|---|
・ライン復帰について
階段を降りた後のラインに復帰するときの動作についてですが、降りる前のライントレースをゆっくり正確に走行させることで、階段を降りた後もライン上に機体がくるようにしたので、そのままゆっくりライントレース走行を開始すればラインに復帰して走行します。
「倒立走行」or「尻尾走行」どちらでいくか
まず、シーソーダブルは、段差を降りるとき以外は尻尾を降ろしたまま動作します。なぜなら、倒立走行で攻略するよりも、尻尾を降ろしたままの方が、シーソーの傾斜に合わせやすく、転倒するリスクが圧倒的に低くなるからです。
・走行体傾斜検知
さらに、「走行体傾斜検知」の真価を発揮します。まず、階段と同じように「段差のぼり」の技術を使ってシーソーに尻尾を下ろしたまま登ります。上った後、低速ライントレースで走行します。ある程度進むと、シーソーが傾きます。このときの急な傾きによって走行体の傾斜角度も急激に変化します。先ほど紹介した「走行体傾斜検知」の技術を利用し、傾いた瞬間に尻尾の角度を上げて斜面に寝るような態勢にして、転落を防ぎます。また、後退時も同様に傾斜を検知しますが、転落・転倒しないように、尻尾の角度を下げて、斜面に対応できるようにしています。
シーソーから降りる際は、階段と同じように、倒立走行にしてからシーソーから降りる予定でしたが、実際に作った時には尻尾走行のまま降りるように作っています。尻尾で降りるとシーソーの跳ね上がりで走行体が転倒してしまいそうですが、走行体の重心を後方にしておけば、跳ね上がりを遅らせ、走行体と接触しないようになります。モデル提出後から大会までの間で、思いつき、プログラムに取り入れました。
・超音波センサを使わない戦略
私たちの戦略では、超音波センサを使用しませんでした。尻尾走行で機体を傾けて走行しているため、超音波センサーはゲートの紙の部分を検知できないことが多々あったからです。なので、ゲートの手前のカーブを、機体の向きの変化で検知して、そこからの距離でゲートを認識しました。
・速度を下げずに通過する
ポイントは「速度を下げない」ことです。まず、左右モータの回転数の差よりゲート前のカーブを曲がったことを検知します。そこから一定距離進み、速度を下げずに走行体を傾け、そのまま通り抜けます(図5-3参照)。ここで速度を下げずに通り抜けるのは、静止したまま走行体を傾けると重心が後方に位置し、尻尾で走行体を支える状態になり、タイヤに負荷がかかりにくくなって空転が発生しやすくなるからです。そうすると、走行体が思いもよらぬ方向に回転するなどのトラブルを引き起こす可能性が出てきます。
そして、速度を下げずに一定距離すすみ、機体の傾きを直し通常走行に戻ります。
|
| 図5-3. ルックアップゲートの戦略について |
|---|
・尻尾走行 or 倒立走行
全て尻尾走行で行きます。ペットボトル検知（以下PB検知）は倒立走行の方がよいと思われるかもしれませんが、実は尻尾を下ろした状態のほうが検知率はいいです。
・リカバリーの効くペットボトル検知
検知の成功率は上がったものの、それでも失敗することがあります。なので、ペットボトル検知は2回やるようにしています。一回検知してから、少し進み、また検知します。なお、ペットボトル検知をする際は、片方だけ見るようにしていて、ペットボトルが左側にあるかないかでルートを決定しています。
・どうやってライン消失を検知するか？
要素技術の「端点検知」を利用して、ラインの消失を検知します。ライントレースをしたまま、ライン消失に向かうと、ラインがなくなるので、走行体の向きが急激に変化するので、それで消失を検知します。
・円を描くようにペットボトルの間を抜ける
私たちの戦略では、走行体は円を描くように走行して、PBの間を抜けます。なぜ直進で走行せずに、カーブ走行で円を描くように走行するかというと、直進走行だけだと、動作の切り替えが大きく、大きい誤差が出てくる可能性が高く、安全に攻略できないからです。逆に、円を描くように走行すると動作の切り替えが少ないので、誤差がとても少なくなります。なので、PBの間を抜けるときは円を描くように走行します。
・灰色検知
ガレージまでの距離を検知するには自己位置推定や灰色マーカー検知など、色々な手段がありますが、私たちは灰色マーカー検知を利用しました。灰色マーカー検知は、先ほど紹介した端点検知と原理は同じです。灰色も白色として認識するようにライントレースを設定しておくことで灰色に入った瞬間、走行体の向きは急激に変化するので、それを利用して検知します。
・スムーズだけど確実に
ガレージに入る際、低速で入ります。低速にすることによりライントレースの精度を上げます。速度は落ちますが、ゴールの壁に触れずに確実にガレージにインすることができます。
・リカバリーも
モデルには記述していませんが、ガレージに入った後に一定の間隔で少しづつ前進する機能を後から付け足しました。 こうすることによって、1度ガレージの中でストップした時にガレージに完璧に入ってなくても、2度目でガレージに完璧に入ることができます。しかし、そんなことをしてガレージにぶつからないのか？という疑問があると思います。ゴール判定の時間だけ停止すれば、そのあと移動してぶつかっても大丈夫・・・と思って、CS大会用のプログラムに付け加えたのですが、競技規約には「ガレージに走行体の一部が入った後、完全停止状態が2秒以上継続した最初の1回がボーナスタイム付与対象」と書いてあったので、この戦略でリカバリーをするのは無理ということがCS大会終了後に判明しました。
今回の戦略では、戦略にリカバリー性や冗長性がなかったように思います。たとえば、シーソーダブル中にシーソーを降りてしまったときに、シーソーシングルに移行するなどの対策がないなど、戦略が単調になってしまいました。その対策として、構造面で複合条件などを取り入れるなどして、戦略を単調にしないように様々な面で取り組んでいきます。
競技規約をよく読んでなかったので、せっかく考えたガレージインでのリカバリーも意味のないものになってしまいました。2013年ではこのようなことはないようにしていきます。
チャンピオンシップ大会の審査コメントです。
| モデル総合評価 | Ｃ＋ | ||
|---|---|---|---|
| モデル審査 | 良かった点 |
デザインに凝らない為にシンプルで見やすい色合いになっていると思います。 要求分析では、利害関係者分析やFURPSにより、要求の網羅度が向上しています（利害関係者⇒要求、FRUPS⇒手段・仕様）。 |
|
| 気になった点 |
クラス図で記述されているクラスが、実際にどのようなオブジェクトとして実現されているかが、モデルからは読み取れませんでした。
一部、多重度に間違いがあると思われます（走行方法の倒立制御と尻尾制御からみた走行方法は＊では？）。 振る舞いは、 記述が中途半端なため実現性が判断できません。また、構造のクラスの責務が不十分なため、この振る舞いモデルを見ても妥当かどうか判断できません。 並行性設計では、 設計指針は明確ですが、それをどのように実現しているかがモデルとして記述されていません。 |
||
| 性能審査 | 良かった点 |
戦略面の記載もしっかりとされていて良いと思います。
等回転比走行など、他のチームにはない発想で難所攻略に使用しており、工夫が見られます。 | |
| 気になった点 |
データによる裏付けが弱い為、確実性に不安が残ります。要素技術の裏付けを走行戦略にしっかりと結びつけるとより良くなると思われます。
要素技術に一部記述が不十分な点があり、難所攻略の妥当性に疑問が残ります。
＜要素技術＞ ライントレースで輝度PDを採用する様だが、制御式やゲイン設定に関する記述がなく、妥当性が確認できません。
等回転比走行を実現するための制御技術の記述が見当たりません。回転中、比率を維持するための制御方法の説明が必要です。
＜走行戦略＞
階段：コーナーの検出方法が不明確で、実現性に疑問が残ります。
シーソー：シングルになったときのバックアップがあるとよいです。 ルックアップゲート：②と③、④と⑤の違いが不明です。 ドリフトターン：等回転比走行で180度以上の旋回が必要な理由が不明です。 ＜並行性＞ タスク分割の必要性に関する説明がありません。
|
||
私たちはソフトウェア品質評価であるFURPSと、大会に関係している人から分析した利害関係者分析は、網羅的に要求を洗い出すために導入したのですが、それが思った以上に評価されて嬉しかったです。それが評価されたのは、審査員の方が面白いと思ってくれたからだと思います。
また、要素技術で新しく考えたアイディアである等回転比走行が認められたのはうれしかったです。ただ、もう一つの売りで、シーソーダブルの攻略で非常に有効であった走行体傾斜検知が評価されなかったのは残念です。今後はさらに難所クリアに有効な要素技術を開発していきたいと思います。
全体的に、実現可能性が示せていなかったという評価なので、次回は「なぜ」に重点 を置いて分かりやすい説明と図を入れながらモデルを作っていきたいです。また、クラスごとの責務が明示できていないという評価があり、この点についてもどのようにすればわかりやすく明示できるのかをしっかり分析して次回に生かしてきたいです。
自分たち自身では、今回も非常に満足しているモデルなのですが、審査員の方々から見たらまだまだのようです。今後は本当に開発に使えるモデルを目指します。
| © 2013 OGIS-RI Co., Ltd. |
|
