|
[2010 年 3 月号] |
［レポート］
本連載は、ETロボコン2010に参加する方々に向けてETロボコンにおけるモデリングのポイントやノウハウを提供するため、モデル座談会で議論した内容に解説を加えて紹介しています。
オブジェクトの広場2010年2月号で掲載した前編記事では、「モデル審査で評価されるシートの書き方」やモデルシート1～2枚目の「機能分析・構造分析」のポイントをご紹介しました。後編にあたる本記事では、モデルシート3～5枚目の「振る舞い分析」や「難所攻略」、さらに議論のまとめとして「ETロボコン2010で勝つためのポイント」をご紹介します。
なお、本記事では、「田町レーシング」チームが作成した東京地区大会とチャンピオンシップ大会のモデルを度々引用します。ぜひ、実際のモデルを手元に印刷して記事を読み進めてください。
前編記事では、最後の「構造分析」でクラス構造について議論しました。モデルシート3枚目にあたる「振る舞い分析」では、このクラス構造で機能要求を満たせることを検証しました。ただ、振る舞い分析のコミュニケーション図において、読みやすさを考慮して独自の表記を採用したことが、かえって読み手の誤解につながる可能性があることが指摘されました。
手嶋：3枚目の振る舞い分析では、構造分析で得られたクラス構造でシステムの機能が実現できること、つまり機能要求を満たしていることを検証しています（図1）。各コミュニケーション図は1枚目のユースケース分析で挙げたユースケースの具体的なシナリオに対応しています。例えば、シート左下にある「コースを走行する」に対応したコミュニケーション図では、アウトコースにある1つの区間を走り始めてから区間が切り替わるまでのシナリオを検証しています（図2）。このようにユースケースごとに具体的なシナリオで実現性を検証することは、機能要求を満たしていることを読み手に示すエビデンスとしても効果的です。
図1 振る舞い分析（チャンピオンシップ大会のモデル）
（クリックすると拡大します）
図2 「コースを走行する」のコミュニケーション図（チャンピオンシップ大会のモデル）
（クリックすると拡大します）
手嶋：また、単純にユースケースの実現性を検証するだけでなく、クラス構造を洗練するためにも振る舞い分析は重要です。「コースを設定する」のユースケースを検証している際に、「コースリストクラス」を抽出してモデルをすっきりさせたことは構造分析の時にお話しましたね*1。
森原：コミュニケーション図を使って、ユースケース駆動で分析クラス図を洗練していることはICONIXプロセス*2でいうロバストネス分析*3に相当するね。
山内：コミュニケーション図をよく見ると、シーケンス番号の振り方が標準の表記と違っているよね（図2）。1番のメッセージがアクターからではなくシステム内部の「走行体」から始まっているし、シーケンス番号の桁が繰り上がる箇所が少しおかしい。例えば、「走行体」から「アウトコース2」に流れている「3：開始する」のメッセージは、外部イベントがあった訳でもないのにシーケンス番号が繰り上がっている。
山内：UMLの仕様に正しく書くと、アクターとシステムのやり取りごとに番号を繰り上げることになる。だから、アクターからシステムに対して最初に出すメッセージのシーケンス番号が1、次に呼び出すのは2となるはず。そしてメッセージ番号1を起点にして「1.1」「1.2」のメッセージが続いていく。
時岡：このコミュニケーション図は、ユーザがタッチセンサを押して、実際に走行が始まる前もシナリオに含まれています。だから、起点となるのは「走行体」で、「1：コースを実行する」が始まってから「2：走行画面を表示する」でスタート画面を出します。システム外部からのイベントは「2.2：押下する」の1回きりで、ここから本当に走行が始まるという流れです。
手嶋：シーケンス番号の振り方に関しては、「2.1.1.1.1・・・・」とネストが続くとドットが長く連なってメッセージの順番が分かりづらくなるので、意味のある単位で切りました（図3）。
図3 UMLの仕様に従った場合の「コースを走行する」コミュニケーション図
（クリックすると拡大します）
森原：UMLの仕様をそのまま使うかどうかは現場次第。合意が取れていれば使いやすいようにカスタマイズしても良いとは思うよ。ただし、「このプロジェクトでは、こういうシーケンス番号の振り方をしていますよ」とルールを明示しておかなきゃ、外から見た人には意図が伝わらないよね。
山内：確かに、コミュニケーション図で標準と異なるシーケンス番号の振り方をした場合、メッセージの呼び出し順が意図通りに読み手に伝わるか保証はできないよね。コミュニケーション図は、クラスと関連による構造の軸とメッセージによる時間の軸という3次元の情報が描かれているから、シーケンス番号の振り方に気を使わないと読み手に時間の流れを誤解させてしまう。それに比べると、シーケンス図はクラスとメッセージによる時間の軸だけで整理されている2次元の図だから分かりやすいと言えるかもね。
3枚目の「振る舞い分析」までで、モデル審査基準の「設計品質」に位置付けられているソフトウェアの機能・構造・振る舞いを一通り見てきました。4枚目のシートである「難所攻略」からは、特に、モデル審査基準の「性能」にある「走行戦略やアルゴリズムの有効性や実現可能性」をアピールするシートに移ります。
「難所攻略」では、UML以外の新しいモデリング技術としてSysMLのパラメトリック図を採用し、走行の判定処理に使う属性間の制約関係を分かりやすく視覚化した点はモデル審査において評価されました。一方で、パラメトリック図の使用や独自の走行戦略を含む性能面のアピールが、ETロボコンの目標である「リザルトタイムの短縮」に直接貢献しないこと指摘されました。
時岡：チャンピオンシップ大会のモデルシート4枚目以降は、各難所の走行アルゴリズムを説明しています。4枚目ではアウトコースにある「トレジャーハント」とインコースにある「ツインループ」の2つ（図4(a)）、5枚目ではアウトコースの「新ショートカット」を例にして説明しています（図4(b)）。資料中にある「クリフハンガー」、「ワンループ」、「バレリーナ走行」というのは各難所の走行方法の名前です。
 |
 |
| (a) 4枚目：トレジャーハント・ツインループの攻略方法 | (b) 5枚目：ショートカットの攻略方法 |
図4 難所攻略（チャンピオンシップ大会のモデル）
（クリックすると拡大します）
山内： 4枚目の左側で「インスタンスの組み合わせを変えることで、走り方を柔軟に変更できる」という構造分析のメリットを説明しているね。
時岡：はい。そして SysML*4 を用いたことも1つの特徴になっています。SysMLにはUMLにない独自のダイアグラムが含まれており（図5）、UMLでは表現できなかった切り口での可視化が可能です。そこで私たちのチームでは、パラメトリック図（Parametric Diagram）を用いて制御に関するパラメータの制約を可視化しました。
手嶋：UMLと比較してSysMLでしか表現できないダイアグラムとして、パラメトリック図の他に要求図（Requirement Diagram）もあります。要求図は要求の階層関係や依存関係を表現できるのと同時に、要求をSysMLの基本単位である「ブロック（Block）*5」まで関連でつなげられる良さがあります。ただ、ETロボコンのソフトウェアぐらいの小規模なシステムだと要求の規模も小さくて、可視化するメリットも小さいと考えたので要求図は使いませんでした*6。
図5 SysMLのダイアグラム
時岡：パラメトリック図は、システムのプロパティ間の制約を数式で表現するためのダイアグラムで、性能上で重要なパラメータの制約関係を分析するときに使えます。ETロボコンでいうと、判定処理時のクラス属性の関係がこれにあたると思います。うちのチームでは、光センサの「測定輝度」や「輝度変化閾値」といったクラス属性間の関係を視覚的に分かりやすく表現できるのではないか？と考えました。このような組み込みで重要な制御に関する知識や制約をUMLで表現する場合、ノートでコメントを書くかOCLで記述するしかありませんでした。SysMLのパラメトリック図だと、ダイアグラムとして可視化することで複数者間の検討が行いやすくなります（図6）。
 |
 |
| (a) クラス属性の制約関係を記述したパラメトリック図 | (b) 輝度変化時のグラフ |
時岡： 資料では、どのクラス属性の制約をパラメトリック図で描いているか分かりやすく示すために、横にクラス図を配置しています（図6(a)）。SysML本来の書き方であれば、ブロック定義図（Block Definition Diagram）*7上の制約ブロック（Constraint Block）で制約を予め定義して*8、そのインスタンスをパラメトリック図に配置するため、本当はこんな関連付けは不要です。今回、その制約ブロックを定義していないため、特殊な描き方をしている点に注意してください*9。
森原：クラス属性の関係が分かりやすく示せることは良く分かる。「SysMLの使いどころはここ！」と示すのはETロボコンの趣旨とも合っているから、チャンピオンシップ大会のモデルでもパラメトリック図での制約の記述を大きくフィーチャーしても良かったとは思う。
森原：でも、結局は早く走るための工夫が評価される訳だから、「早く走ることにどう役に立つの？」ってところのアピールが少し弱いよね。それに、PD制御はどこのチームでも実践しているし、実際の開発では、これを畳み込んで1個のブロックにしてライブラリとして提供されちゃうようなものだから、PD制御の中身はライブラリ作成者以外にアピールできない。
手嶋：そこは審査員の方にも指摘されましたね。新しいモデリング技術としてSysMLを使ったことは審査員の方にも評価されましたし、メディアに取り上げられるきっかけにもなりました*10。ただ、そもそもパラメトリック図を使った目的や使ったことによるメリットのアピールが不足していたようです。
三村：地区大会のモデルにあるPD制御エッジ走行のパラメトリック図では、「制御偏差制約」・「駆動速度制約」・「旋回速度制約」がeというパラメータで結んであります（図7）。光センサの測定輝度がsvというように他の制約は説明があるのですが、eの箇所だけ説明がありません。eって何でしょう？
図7 PD制御エッジ走行のパラメトリック図（地区大会のモデル）
（クリックすると拡大します）
手嶋：これは「制御偏差制約」の計算結果がeなんですね。その計算結果が他の式の中で使われています。
山内：UMLでいう派生属性に近い感じですね。”派生制約”みたいな感じなのかな。
時岡：そうですね。要は、ある瞬間の属性の関係を4つの式からなる連立方程式で表現したということです。eはその変数になります。
山内：そう考えると、おもしろいのはどの単位で一つの制約として見るか？だよね。
時岡：そうそうそう！それが大事なんですよ！今回はチーム独自で考えた制御の仕組みを分かりやすく伝えたかったので、それぞれの要素は意味が伝わる範囲で一番大きな粒度で出しました。
森原：どの単位で1つの制約として見るかは、本当にいろんな分け方があるよね。受験数学で関数を公式に当てはめたり計算しやすくしたりするために式変形したでしょ? 要はあれだよ。因数分解・加減乗除・数式展開とかの工夫をすれば、目的に応じて数式の形を色々と変えることができる。
森原：人間からすれば、できれば状況の理解に便利で、挿げ替えたい単位でブロック化したいよね。でも、動かすことを考えると、全部つないだものを変形して演算回数を減らした方が速いし、誤差が拡大しないように割り算をなるべく最後に処理するように式変形した方が良い。だから、実行して優秀な数式と人にとって見やすい数式というのは別物と考えた方がいい。
森原：再利用性が高くても性能が出なければ意味ないし、再利用性の高い単位で分けないと開発が回らなくなる。だから抽象度で階層化して、別々に分ける。人間は人間にとって見やすい形で管理して、機械はそれを変換したもっと効率の良い形で処理すれば良い。両者が同等のものかは理論で固めてテストで確認するから、人間は変換した結果を見なくていい。今もコンパイラが吐き出したオブジェクトコードは、よっぽどのことがないかぎり見ないでしょ?
森原: 最初に思いついた式やブロックから、やり方次第では保守性や再利用性ががらっと変わってくる。それがクリエイティブな作業で、やりがいがあるんだよ。
山内：こういう問題を考える時の観点は再利用性と分かりやすさですよね。人にとって理解しやすい単位が最小構造としてあって、それに対して図を使う用途によってどこを注力して書くか、誰に対して見やすいかによってどの単位にまとめるかを考える。再利用に関しても、使い方を想定してどの括りにまとめるかを考える。
手嶋：5枚目のシートでは、新しい走行体の特徴を生かしたバレリーナ走行を解説しています。今回は新しい走行体でしかできない走行を見せたい*11 、何かユニークなものを作りたいと考え、この走行を考案しました。若干、ETロボコンの目標であるリザルトタイム短縮からは逸れている感もありますが、結果的には会場を盛り上げたとの評価で@IT MONOistから名誉ある賞をいただきました（笑）*12。
手嶋：バレリーナ走行でポイントとなるのは、左右2輪であることを活かしてその場で回転することです。ショートカット区間を通常のエッジ走行で進むと、点線のスリット部分で逸れてしまいます。その時に、その場で回転して逸れる前の状態に戻り、スリット分進んだ後、また通常のエッジ走行で進みます。これを繰り返すことで、スリット部分でバレリーナのようにクルクル回転しながら点線を追従できます（図8）。
図8 バレリーナ走行
（クリックすると拡大します）
手嶋：4枚目下部には、バレリーナ走行を実現する上で重要となる「片輪ターン」について書いています(図9)。左右の車輪モータには個体差があるため、その場で両方の車輪を動かして回転すると、同じ位置にきちんと戻ってくるのが難しくなります。片方どちらの車輪を完全に停止させて回転することで、軸を中心にしてきれいな回転が可能になります。ただ、提供されている倒立振子のライブラリは片方の車輪を固定するような指定ができません。そこで、資料のブロック線図に書かれているように、ライブラリの使い方を工夫して出力値（モータPWM出力値）を入力値（旋回速度）にフィードバックさせ、片方のモータPWM出力値を相殺することで、片輪ターンを実現しています。
図9 バレリーナ走行のための片輪ターンの実現
（クリックすると拡大します）
手嶋：私たちのチームは、基本的な流れが分かりやすいように基本フローにフォーカスして説明し、代替フローや例外フローの説明は可能な限り省きました。ただ、審査員の方からは「例外への対処が不足している」との指摘を受けました。トレジャーハント部分で言えば、「コースをエッジ走行する時に進行方向に障害物が置かれた場合のケースが検討されていない」というものです（図10）*13。実際には、障害物が置かれて通れない場合はトレジャーハント自体にチャレンジしないという対策をとるのですが、その記述は見易さを優先して省略していました。
図10 トレジャーハント区間の走行
時岡：実際、当日、本当にぎりぎりの場所に障害物が置かれて通れませんでした。結局、走り方を2パターン用意して、行き止まりの方を行かずに、メインのラインをずーっと走りました。そういうこともあるので、やはりモデルシート中に例外系の検証が全く書かれていないと、実現性に疑問を持たれてしまうようです。
森原：しかし、例外系はそんなに書きれるの？他のモデルはみんな書いていたの？
手嶋：審査員の話だと、「全ての例外系を網羅することは無理だから、気になるところをちゃんと書けていれば大丈夫」という話らしいです。
山内：審査員がどこを気にするかは分からないよね。特に重要な例外系にフォーカスして1個を書けば、「我々は例外系をちゃんと意識して開発している」ということが示せるかな。
森原：何が重要で何を枝葉と見るかだろうね。キャリブレーションは枝葉ね*14。要はそういうことになる。
（一同笑）
森原：読み手が求めていることを理解することは、いつでも非常に大事だよ。誰が読み手なのかという読み手の性質に対するドメイン分析が必要になってくる。
山内：そこをうまくアピールするなり評価してもらうためには、「ここが大事です。特に、こういうところを注目して我々は振る舞いを分析しました」とアピールして、そこを詳細に説明できれば良い。
大西：「PIDコントローラ」クラスはありますが、「PDエッジ走行」クラスの名前を見るかぎりでは、実際にはPID制御*15のうちP制御*16とD制御*17しか使わないんですね（図11）。
図11 走行クラスのサブクラス
（クリックすると拡大します）
時岡：クラスの名前に深い理由はなくて、ちょっとだけ汎用的なクラスにしました。「PDコントローラ」でも良かったと思っています。「I制御*18が要らない」というのは、ETロボコンでは前から言われています*19。
時岡：PID制御のうちどの制御も入れない場合、黒の時は右に曲がり、白の時は左に曲がるというように単純な制御をします。同じ力でずっと曲がるから一番単純です。しかし、首振りが安定しなくて走行がガクガクしてしまいます。 P制御を入れて、出力値と目標値の偏差が大きい場合は強く、偏差が小さい場合弱く制御するようにすると、もう少し走行が滑らかになります。でも、P制御だけでも収束するまで時間がかかってしまいます。 収束を早くするためには、D制御を入れて目標軌道付近では力を弱めるようにします。反対側に力をやって、逆の力でもっと押さえ込めば、もっと滑らかな制御ができるようになります。
森原：車の運転なんかでも例えられるよね。P制御は「今どれだけずれているか」を基準にしていて、PD制御は「ズレの変化量」を見ている。だから、道なりにゆったりしたカーブを曲がるときはドライバーも少しずつハンドルを回せばいい。でも、いきなり急カーブが来たら激しくハンドルを切らなきゃいけない。
手嶋：一方でI制御が役に立つのは、一方向から目標値に近づける制御をする場合です。どうしても最後のあと少しで目標値に届かないという時に、出力値と目標値の偏差を足し込んでいって、溜まった力であと目標値にぴったり合わせる制御をします。ただ、ライントレースみたいに目標値周辺を発振し続けていい場合、目標値にぴったり合わせる制御は考えなくてもいい訳です。だから、私たちのチームではI制御は入れませんでした。
手嶋：そういう理由もあって、ETロボコンの中ではI制御を入れてないチームが多いんですね。I制御を入れるとしたら、きれいにコースの円弧を回りたい時です。例えば、コースのカーブは同半径の円弧で作られているため、コースの円弧を綺麗に回りたい時にPD制御で曲率をだいたい合わせて、あと少しが足りない時にI制御を使うと良いと思います。基準値の周辺を行ったり来たりする時は、I制御の効果が出ないのかなと思います。
三村：新人チームでは、I制御を導入して逆に変な走行になりました。恐らく偏差の積算値が制御パラメータに反映されるタイミングが常にバラバラで、変なタイミングで反映されると走行が不安定になります。1周なら走れますが、ずっと走らせるのは難しい状況でした。
森原：誤差が溜まっていくのか。でも、それって本当にそうなの？本当にI制御が不要なのか、実装の仕方がまずいのか判断がつかないな。実際のところは検証できていないってことか。
これまで「田町レーシング」チームのモデルを通して、ETロボコン2009でのモデリングのポイントやノウハウを一通り議論してきました。ここからは、モデル座談会やモデリングワークショップでの議論の内容を踏まえて、ETロボコン2010で勝つためのポイントについて議論を行いました。
大西：これで一通りモデルシートは目を通したことになります。これからは、座談会のまとめとして、ETロボコン2010で勝つためのポイントを議論していきたいと思います。まず、競技部門では、どのような走行戦略を取ると良いと思いますか？
時岡：ETロボコンの競技規約では、リザルトタイム*20を一番短くしたチームが最終的に勝ちます。結局は、リザルトタイム減らす方法で走行戦略を進化させると良いと思います。1つ目は速く走って走行タイム*21を減らす方法、2つ目はボーナスタイム*22をたくさん取る方法です。
手嶋：まず、走行タイムを減らすには走行距離を短くすることでしょうね。最近のETロボコンでは、走行タイムを短縮するためにハードウェアの性能を引き出す方法を競う傾向にあり、競技部門が専門的になっています。来年の傾向として「ショートカットを多用して走る距離を短くした結果、走行タイムを短くする」という戦略が出るのかなと思っています。
手嶋：モデルに関して審査員の方が話していたことは、「ハードの性能を引き出してリザルトタイムを短縮する方法を強く訴えることが重要になる」 ということです。チャンピオンシップ大会の上位チームの間では要求分析から設計までのモデルは大きな差はなく、そこで優劣は決まりません。モデルシート3枚目の「振る舞い分析」の箇所までで僕たちが議論してきた内容は、チャンピオンシップ大会上位チームでは当たり前の話だと感じています。
手嶋：性能面でのアピール例としては、ETロボコン2009の上位チームは、走行結果のデータをグラフで出して走行戦略の改善成果を示したり、既存の制御ライブラリを有効活用する方法をブロック線図で示したりするなど、コース走行の制御アルゴリズムを前面にアピールしていました*23。
手嶋：一方、田町レーシングチームのモデルでは、光センサの輝度変化やバレリーナ走行など、リザルトタイム短縮にはつながらない部分でしか性能面の解説を書いていなかったため、性能面での評価は低かったと思います。
手嶋：ボーナスタイムをたくさん取る戦略に関しては、審査員の方が「来年は全てのボーナスタイムを取るのが主流になるだろう」とモデリングワークショップ*24で予想していましたね*25。ETロボコン2009では、インコースを走っていたらインコースのボーナスタイムしか取らないチームが多かったですが、チャンピオンシップ大会で勝ったチームはコース上の全てのボーナスタイムを取る作戦を取っていました。来年は、それが当たり前になるだろうという話です。
森原：あれかな? アパレルの流行色みたいに誘導しているのかな?
（一同笑）
時岡：ETロボコン2009では、走り方を色々と変えることで、ボーナスタイムをたくさん取ることはできます。しかし、コース上に多数の障害物が置かれるなどの制約がありました。来年以降はコース自体のバリエーションに変化が出てくると予想しています。速さを追求するだけじゃなくて、ボーナスタイムをたくさん取るためにコースを自由に捉えるという方向に可能性が広がるんじゃないかと感じています。
大西：コースの捉え方に自由度が広がるとなると、来年以降もコースの捉え方をドメインモデルで示すことは有効になりそうですね*26。自由度が上がる分、走行戦略の難易度は上がりそうです。
手嶋：走行タイムを短縮して、さらに全てのボーナスタイムを取らないといけないとなると、どうしても走り込んで、走行データを集取して制御アルゴリズムを改善する作業が必須になります。そうなると、かなり手間と時間がかかります。だから、最近では本気で勝ちに来るチームと興味本位で参加するチームで二極化が進んでいます。今の方向で行くと、結構学生さんとか大変だろうね。
森原：だから、「ハードウェアの性能をいかに引き出すか？」じゃなくて、来年は走行戦略に頭を使う方にルールが変わるんでしょう。
時岡：ETロボコンの面白いところでもあり怖いところでもあるんですが、モデル審査の傾向は開催年によって違います。
森原：開催年によって違うというのは、例えばどういうこと？
手嶋：今回、僕らのチームはシンプルなモデルにすることを重視していました。それは、去年のモデル審査の傾向をまねたからなんです。去年は、「情報盛りだくさんなモデルばかりを見るのがつらい」ということで、審査員の方がシンプルなモデルを評価したそうです。
手嶋：そういうことがあったので、今年もシンプルなモデルが評価されるんじゃないかと考えたら、今年のモデル部門の優秀チームは、びっしりと説明を書いていました。モデル審査では、説明を書いている分、検証がしっかりできているというところが評価されていました。昨年と今年でモデル審査のトレンドが逆転した訳です。
（一同笑）
時岡：過去の評価に合わせようとすると逆効果かもしれない。昨年の審査を気にするのはもう意味ないですね。
森原：それはP制御しかしていないからだね。
三村：最大のメタゲームじゃないですか。
（一同笑）
森原：いや、商売ってそれですよ。僕らの商売もそうだし、僕らがコンサルティングする相手もそう。でも、みんなそこ外すのよ。だからコンサルタントはそこにアドバイスをするのよ。
三村：それは外れないのですか？
森原：いや、外れるよ。
（一同笑）
森原：外れるからPID制御、少なくともPD制御をして、外れたことがすぐに分かるように、ちゃんと修正の手を入れられるようにして、ようやく価値が出る。「これからはオブジェクト指向だぜ！」ってやりたい人がいても、「いや、あなた達が作っているものにはオブジェクト指向は合いませんよ」っていうことは、ちゃんと言わなきゃいけない。
大西：結局は、昨年のモデル審査を気にして振り回されるよりは、チャンピオンシップ大会で勝つための戦略をチームで練りにねって、それをチャンピオンシップ大会に持ってくる方が良いのでしょうね。これまで新しい要素技術*27を打ち出して来たチームは、トレンドは関係なく「勝つためには、この戦略が必要だった」ということをアピールしていたように思います。
大西：そして、モデル審査に対してPD制御をする1つのポイントが地区大会のモデル審査になるんでしょうね。田町レーシングチームも、地区大会のモデル審査の結果を受けて、チャンピオンシップ大会のモデルを大きく修正していました。
山内：最後に一つ質問。コンセプトシート*28に書いてあった時岡くんの息子さんは何に参加していたの？（図13）
図13 コンセプトシート（チャンピオンシップ大会）
（クリックすると拡大します）
時岡：打ち合わせに5回くらい参加しました。妻が毎週末ずっと子供の面倒を見ていて、どうもストレスがたまってきているようだったから。
手嶋：今10ヶ月くらいで、寝返りもできないようなときから打ち合わせに来ているから、会う度に子どもの成長の過程が見えるんですよね。
山内：あら、そうなんだ。本当にそんなことしている人もいるんだね。俺も会社に連れていけとか言われるけど（笑）
大西：ちゃんと家庭とロボコンを両立してすごいです！
山内：ふふふ、よく頑張りました！
（一同笑）
山内：いい感じでまとまったところで締めましょうか。
（モデル座談会 完）
本連載では、「田町レーシング」チームのモデルを元に、「ETロボコン2010で勝つためのモデリングテクニック」を議論してきました。読者の皆様にとって役に立つアイディアは見つかったでしょうか？
筆者自身は、この座談会を通じて個々のテクニックより、「チャンピオンシップ大会で優勝する」という目標に向かってチームが試行錯誤して築き上げた成果を、「参加者の皆さんに分かりやすく伝えたい！」という姿勢が重要だと気づきました。逆に言うと、「チーム目標と成果を伝えるために適切なテクニックを選ぶ」ことが重要だと言えます。
ETロボコンに、「こうすれば勝てる！」という公式はありません。ETロボコン2010に参加される方々は、個々のテクニックだけに囚われることなく、「チームの目標がモデルに表現されているか？」や、「モデルの読み手にチームのやりたいことが伝わるか？」などを常に考え続け、ただし楽しく、モデリングに取り組んでください。
モデル座談会の記事は今回で終了となりますが、2010年5月号にて「プロジェクト運営」の視点でのポイントやノウハウについて記事を公開する予定です。ETロボコンでは、チャンピオンシップ大会で優勝するという目標に向かって、チーム一丸となって成果を出すプロジェクト活動を行います。そのため、モデリングや競技のノウハウだけでなく、プロジェクト運営のノウハウも重要となります。次回の記事でも、今回と同様に「田町レーシング」チームの活動を通じて、成果を上げるためにどのような「プロジェクト運営」をすべきか議論していきます。お楽しみに。
*1前編記事の「5. 構造分析」で振る舞い分析の結果、新たなクラスを抽出したことを議論した。
*2 ICONIXプロセス：「ユースケース駆動」で進める軽量な開発プロセス。分析・設計・実装の各段階の前後のトレーサビリティを重要視する。
*3 ロバストネス分析：ユースケースのように文章で記述された要求から分析レベルのオブジェクトを見つけ、適切な単位にまとめる手法。詳細はオブジェクトの広場の記事を参照。
*4 SysML（System Modeling Language）はシステムの仕様化・分析・設計・妥当性確認・検証のために利用できるモデリング言語。ソフトウェアモデリングのデファクトスタンダードであるUMLをベースにOMGが仕様を策定した。現在、自動車、航空宇宙、通信分野などで幅広く活用されている。SysMLの概要については@ITもしくは組み込みプレスVol.18の記事を参照。
*5 ブロックはSysMLの構造における基本単位であり、UMLのクラスに相当する。ハードウェア、ソフトウェア、設備、人その他のシステム要素を表現するのに用いられる。
*6 実際には、2009年のモデル部門優秀チームの中に、要求図を使って「早く走る」などのチームの目標を具体的な戦略の実現方法までブレイクダウンしたチームがいた。
*7 ブロックやブロック間の関係を定義するためのダイアグラム。詳細は@IT MONOistの記事を参照。
*8 ブロック定義図での制約ブロックの定義についてはSparx Systems社のチュートリアル「SysMLを利用した組み込みシステムの設計開発」の「第5章 オーディオプレーヤーの制約とパラメトリック」を参照。
*9 SysMLの標準的な記法では、ブロック定義図とパラメトリック図をペアとして使う。ブロック定義図で各ブロックの制約を数式で表現する。パラメトリック図ではブロック定義図で定義された制約間の関係を記述する。
*10 SysMLを使った例として、「田町レーシング」チームのモデルがモデリングワークショップで取り上げられた。また、@IT MONOistの記事でも紹介されている。
*11 走行体変更のポイントは@IT MONOistの記事を参照。
*12@IT MONOistの記事を参照。練習と本番でのバレリーナ走行の動画と解説が掲載されている。
*13図10の②や③の場所に障害物がある場合の対処方がモデルシートに書いていなかった。
*14 前編の記事で、キャリブレーションする機能をユースケースとして出すかどうかについて議論している。
*15 PID制御：古典的なフィードバック制御の一種。入力値の制御を出力値と目標値との偏差、その積分、および微分の3つの要素によって行う方法。本記事はモデリングにフォーカスを当てるため制御の詳細な説明は割愛する。
*16 P制御（PはProportionalの略）：出力値と目標値の偏差に比例して入力値を変化させる制御方法。比例制御ともいう。
*17D制御（DはDerivativeまたはDifferentialの略）：急激な出力値の変化が起こった場合、その変化の大きさに比例した入力を行うことで、その変化に抗しようとする制御方法。微分制御ともいう。
*18I制御(IはIntegralの略)。出力値と目標値の偏差のある状態が長い時間続けば、それだけ入力値の変化を大きくして目標値に近づけようとする役目を果たす。 この偏差の積分に比例して入力値を変化させる制御方法。積分制御ともいう。
*19@IT MONOistに、2008年の関東地区大会のモデリングワークショップでの議論が掲載されている。ここでは「I制御が不要」ではなく、「PD制御で十分」という説明がなされている。
*20 最終的な競技結果であるリザルトタイムは次の計算式で求める。リザルトタイム = 走行タイム - ボーナスタイム。詳細は競技規約を参照。
*21 コースを周回した時間。
*22 リザルトタイムから減算される時間。難所を通過する際にボーナスとして取得できる。
*23 ＠IT MONOistの記事を参照。
*24https://www.jasa.or.jp/et/conference/program_ro.html
*25 チャンピオンシップ大会終了直後のモデリングワークショップで、これまでのモデル審査のトレンドを総括し、来年のモデル部門のトレンドの予想が発表される。
*26前編の記事でソフトウェアのエッセンスをドメインモデルで表現する手法について議論した。
*27 要素技術とは走行制御、旋回制御、ライン検出といった走行戦略の部品にあたる技術。@IT MONOistで紹介されている要素技術は、これまでの大会であるチームが発明した技術がモデル審査を通じて大会全体に広がったもの。
*28モデルシートとは別に、チームの紹介や開発のコンセプトをまとめた資料。A3紙1枚のシートに記述する。図13にある通り、「チーム紹介」、「組み込み、そしてETロボコンの未来にひとこと」、「コンテストにかける意気込み」、「ここに注目（チームやモデルの注目点）」、「設計思想」を記述する。
| © 2010 OGIS-RI Co., Ltd. |
|
