ETロボコンワークショップ会場なう。WiMAXで無事に接続。 #etrobo

posted at 10:01:06

ワタナベさんからワタナベさんへ司会バトンタッチ！ワークショップでは寝ないように！大事なことなので繰り返しつぶやきます。寝ないように！ でも眠い。。。 ^_^; #etrobo

posted at 10:03:23

モデルも体重もダイエット！って勝手につぶやいています。^_^; #etrobo

posted at 10:04:32

壇上の審査員のみなさんは全員ノートパソコンを開いていますが、リンゴは一台だけかな？組込系はやはりWindows優位？それともLinux？？？ #etrobo

posted at 10:06:32

去年のモデルの振り返り。書き方は進化しているが記載は過密。可読性に劣る。やはりダイエットが大切なのかな？ #etrobo

posted at 10:07:55

去年は、難所ごとに走行クラスを設けて振る舞いを個別に定義るする方法が主流。 DSLなど新しい開発技術の導入も加速。 #etrobo

posted at 10:09:00

アイデアレベル、工夫レベルの記述に留まり、本当に実現できるの？という実現可能性に不備のあるものが前年までは目立った。 #etrobo

posted at 10:10:02

今年からはBluetoothによる分散アーキテクチャーを導入し、新機軸へ。 #etrobo

posted at 10:10:49

今年の参加チームへの期待は「分散アーキテクチャ」、「モデルの可読性向上」、「実現妥当性」の充実など。 #etrobo

posted at 10:11:42

今年のCS大会モデル審査合宿は岩手県花巻温泉。ってつぶやきは不要？？？ ^_^; #etrobo

posted at 10:12:38

５２チームの１次審査に６時間。上位８モデル約１５チームを２次審査で再レビュー。 #etrobo

posted at 10:13:45

本年度の成績優秀モデルの紹介。「R-GRAY NEXT」 要求分析のレベルが高かった。アイコンを使ったモデル間のトレーサビリティが効果的。読みやすい、追跡しやすいモデル。　#etrobo

posted at 10:15:05

ゴールドモデル 「おやじプログラマーず」。しっぽ走行の詳細な解説と検証が高評価。ET相撲やBluetooth通信もわかりやすく記述。 #etrobo

posted at 10:16:19

プラチナモデル「HELIOS」。発散的にあれこれ記述するのではなく、上流工程で注力した課題を下流工程で実現していく過程がモデルから良く分かる。PCとの分散処理などに冗長処理がある。 #etrobo

posted at 10:17:53

過去の大会に比べて、今年は全般的に点数が高かった。参加チームの多くが上位の評価に偏っていた。 #etrobo

posted at 10:19:22

完走率 約90%。非常に高い完走率ですね。ルックアップゲートの成功率も85%。むちゃくちゃレベルが高いですね。 #etrobo

posted at 10:20:26

難所の成功率改善には構造の保守性が向上したからでは。パラメータの調整がやり易かったのか？ #etrobo

posted at 10:21:22

モデル総評：過密化や可読性の悪化は深刻。要求モデルや並行性設計を追加したため、記述内容が増えざるを得ないのは仕方がない？ #etrobo

posted at 10:22:54

モデルで描くべき「振る舞い」などを補足で説明してしまった例が散見された。やはり標準的なモデルで記述すべき。 #etrobo

posted at 10:23:48

分散アーキテクチャは補完的な役割にとどまった？構造が根底から覆るものはなかった。 #etrobo

posted at 10:24:45

粒度小さな走行パターン（前進や旋回など）に分割して、年ごとのルールや難所の変更に強い構造になっている。 #etrobo

posted at 10:26:07

アーキテクチャーは汎用的にすればするほど、そのアーキテクチャの組み合わせを提示すべき。分割したモデルからはET相撲などの難所攻略を実際に実現可能か、モデルから読み取れなかった。アイデアへの思いは伝わるが、検証ができないのが残念。 #etrobo

posted at 10:27:47

性能モデルと構造モデルのつながりに乖離が目立った。その性能は、どういう構造で実現しているのか？実現できるのか読み取れない。ジャンプしている。 #etrobo

posted at 10:28:47

今年の性能のトレンドは「尻尾走行」。これに尽きる。 #etrobo

posted at 10:29:27

DSLやコード生成を使ったチームが目立つ。 #etrobo

posted at 10:30:16

走行に関するアーキテクチャの分類。「責務肥大」型 #etrobo

posted at 10:31:00

アーキテクチャの分類パターンB：難所ごとに責務を切り替える。難所ごとに切り替えを行う走行管理が一手に担う。

posted at 10:31:50

アーキテクチャの分類パターンC:区間ごとに切り替え作業を分割。個々の区間に責務を委譲。 #etrobo

posted at 10:32:32

アーキテクチャの分類パターンD:ネジ釘レベルに走行部品を分割し、それらの部品の組み合わせで全ての区間、難所の走行を実現する。効率性で有利。 昨年度の田町レーシングの影響が派生。 #etrobo

posted at 10:34:11

HELIOSさんのクラス。パターンCに分類。確かに「走行方法」クラスに関係が集中していますね。 #etrobo

posted at 10:35:03

パターンDの「R-GRAY NEXT」さん。難所の名前がクラス図に登場しない。細かなネジ釘レベルの走行パターンの部品を組み合わせて難所をクリアする構造が見て取れる。 #etrobo

posted at 10:36:23

ET相撲のような振る舞いが肥大化する難所が登場したため、ネジ釘レベルの部品からのボトムアップアプローチが有利だった？ #etrobo

posted at 10:37:49

来年に向けての課題：可読性　補足の記述の仕方については再考。まずは質の改善から。 #etrobo

posted at 10:42:01

来年への課題：アーキテクチャ　現行ルールので延長ではアーキテクチャが出尽くした感。大幅な競技ルールの改定があるのかな？？？ ^_^;

posted at 10:42:52

チームナンバーが貼られたロボットを懇親会場に忘れ物。分かりやすいですね。大事なことなので繰り返しつぶやきます。ロボットを忘れちゃダメ！ ^_^; #etrobo

posted at 10:45:37

「要求とは？」 条件や能力だけでなく、何のために、どんな目的のために、というところまで含まれる。 #etrobo

posted at 10:47:23

「要求の種類」 Southwellらによる定義。IEEE std. 610。 FURPS。世の中には色々な要求の定義がありますね。言葉の定義も各々異なっていてコミュニケーションするのが大変そう。。。 #etrobo

posted at 10:49:20

要求分析はそこそこで開発を進めても、なんとなく出来上がる。しかし、早期検証や手戻りの防止につながる。　たとえば無駄な機能を作り込むことを避けれる。 #etrobo

posted at 10:51:12

上流工程で検討しても難しいものも確かにある。能力の必要な作業。完全に要求分析を仕上げようとするのは難しいが、要求を分析しようという意識はやはり重要。 #etrobo

posted at 10:52:42

開発途上での要求変更や仕様変更の影響レベルを把握するには、上流工程での要求分析は重要。 #etrobo

posted at 10:53:45

システムで採用しなかった手段、システム外で実現した機能も、その検討過程を示すために要求分析に記述すべき。 #etrobo

posted at 10:55:28

要求分析のプロセス　：　獲得 => 記述 => 分析 => 管理 #etrobo

posted at 10:56:12

多くのチームで「獲得」と「記述」をしっかりやっている。しかし「分析」が弱いチームが多い。 #etrobo

posted at 10:56:58

「無矛盾性の分析」 日々のお仕事では常に矛盾する要求しか飛んでこないのですが。。。 というか矛盾のない要求は私のところに飛んでくる前にどこかで解決しているみたいです。最終防衛ライン俺、と自信を持つことにします。 ^_^; #etrobo

posted at 10:58:35

「リザルトタイム１０秒以下」 Yes/Noとはっきり判定できる妥当な要求の記述方法。 #etrobo

posted at 10:59:44

マインドマップは astah* で描いているみたいですね。 #etrobo

posted at 11:01:31

要求分析（マインドマップ）で分析した内容が、ユースケースに登場する「キャリブレーションする」、「走行する」などに繋がっていない。 #etrobo

posted at 11:02:52

わーっ。追跡線隊 ICSレッドさんのマインドマップは詳細。洗練されている。色分けして機能やユースケースにつないでいる。一方でマインドマップのツリー構造では表記が難しかったのでは？ #etrobo

posted at 11:05:16

「RITSSAND」さんの要求分析。用語の定義をしっかりと記述してるのが良い。アビリティーとは？セクションとは？要求分析を読み解くときの助けになる。 #etrobo

posted at 11:11:08

どのチームも記述が詳細で拡大表示しないと全く文字が読めないですね。来年からは全員、タブレット持参でワークショップかな？ すみませーん。でも紙への印刷も宜しくお願いします。プリンターメーカーからのお願いです。 ^_^; #etrobo

posted at 11:13:13

正常に動いた場合の記述は簡単。うまく動かなったときの回避策の検討が重要。HELIOSさんは上手くいくように作りこんでいる。決して運任せの博打をしていない。 #etrobo

posted at 11:15:10

要求を分析する心構えを持ちましょう。 #etrobo

posted at 11:17:34

「トレーサビリティについて」 #etrobo

posted at 11:20:43

悪い例：プログラムだけが進化してモデルは保守されていない。開発が終了した後の役立つ成果物はソースコードだけ。よく聞く話です。あくまで他人事です、たぶん。。。^_^; #etrobo

posted at 11:23:17

UMLを使うことでトレーサビリティが確保しやすい。矛盾した内容を発見しやすい。 #etrobo

posted at 11:25:18

“R-GRAY NEXT” さんが全CS参加チーム唯一のA評価。パチパチパチ！ #etrobo

posted at 11:30:10

アイコンを使って丁寧にトレーサビリティーをとっており、とても分かりやすい。でも詳細すぎてプロジェクター画面からは読み取れません。。。 ^_^; #etrobo

posted at 11:31:21

良いソースコードはクラスや変数のネーミングが分かりやすいものですが、”R-GRAY NEXT”さんのアイコンはデザインから一目で意味が推察できますね。グラフィックデザイナーさんがいるのでしょうか・？？？ #etrobo

posted at 11:34:07

“R-GRAY NEXT”さんのトレーサビリティをとっているアイコンは、ピクトグラムと言ったほうが良いのかしら？これも意味不明のアイコンに慣れ過ぎている弊害？？？ ^_^; #etrobo

posted at 11:35:51

「モデルだってダイエットしたい！！」 #etrobo

posted at 11:37:56

ETロボコンにおける「スリムモデル」と「ファットモデル」論争。 #etrobo

posted at 11:38:49

体重が減ると「ダメなもの」も減っていく。でも、「いいもの」、「必要なもの」は残っていく。 #etrobo

posted at 11:43:43

抽象化とは？注目すべき要素を重点的に抜き出して他は無視する思考の手法。 #etrobo

posted at 11:44:39

モデルとは抽象化した結果の成果物！ 僕のIMEはいまだに「青果物」と変換する。八百屋じゃない！ #etrobo

posted at 11:46:17

捨象、車掌、社章。スライドの京浜急行に影響されてつぶやきも脱線。。。 ^_^; #etrobo

posted at 11:49:58

必要なモノを残し、他を削ったり分けたのが良いモデル！ #etrobo

posted at 11:51:38

ダウンロードすると３２Mバイトの超ファットモデル！！！ ^_^; #etrobo

posted at 11:53:03

大野晋著「日本語練習帳」の紹介。ダイエットするのはモデルだけではなく日本語も。 http://t.co/mGtgddn3 #etrobo

posted at 11:57:26

このシーケンス図で何を伝えたいのか？ 削る。隠す。それぞれの局面ごとに関心事を分離する。 #etrobo

posted at 11:59:17

「審査基準もダイエット」　おあとが宜しいようで。。。^_^; #etrobo

posted at 12:00:16

「モデル評価のプロファイル」 チャンピオンシップ大会参加チームの傾向をレーダーチャートでプロット。 どのチームもまんべんなく高得点。オリジナリティと並行性設計がちょっと凹んで（低い）のかな？ #etrobo

posted at 12:03:35

「競技部門のプロファイル」　ベーシックステージの最速タイムはいずれも尻尾走行。地区大会の結果をうけてCS参加チームはみな尻尾走行を仕上げてきた。 #etrobo

posted at 12:04:54

くらっちwinさんの倒立走行 28.9秒もすごい！ 二輪倒立制御走行で30秒の壁を越えた。 #etrobo

posted at 12:06:02

尻尾走行でスピードアップ。 #etrobo

posted at 12:07:51

「おやじプログラマーず」さんは５枚中３枚で尻尾走行に言及。 #etrobo

posted at 12:08:42

尻尾走行による効果（スピードアップ量）を分析。次に尻尾走行のリスクを分析。 #etrobo

posted at 12:10:03

尻尾走行によるライントレース（光センサー）への影響を分析。 #etrobo

posted at 12:10:39

カーブでのコースアウトを避けるために、片側のモーターは全力。反対側のモーターのトルク制御で旋回率を制御。 #etrobo

posted at 12:12:32

「電子くん」のイナバウアー走行（尻尾走行）。タイム短縮効果を実験値で実証。 #etrobo

posted at 12:13:59

「高速まいまいでスピードアップ」 まいまい式の20ミリ秒周期は長すぎる。実験ベースから 12ミリ秒で安定することを見つけた。 #etrobo

posted at 12:15:00

くらっちwinさん。LEDの明滅周期は20ミリ秒。ただし変化中の値も測定して予測。 #etrobo

posted at 12:16:43

「電子くん」はLEGOブロック（光センサー）の電子回路をSPICEでシミュレーションして適切な明滅周期を決めた。電子回路の知識も必要ですね。 #etrobo

posted at 12:18:36

くらっちWinさんのスタート直後の分析。地区大会では「READY, GO」でいきなりコースアウトするチームも散見。 #etrobo

posted at 12:21:18

スタートも実は非常に重要な性能要素。 #etrobo

posted at 12:21:45

ロボットを後ろに傾けてタイヤが空転するリスクを分析。光センサーの測定値が変化するところもしっかり分析。ルックアップゲート通過の詳細な検討。 #etrobo

posted at 12:23:36

タイミングチャートを使って表現。尻尾モーターの駆動力と急ブレーキによる慣性力を組み合わせて、スムースにロボットの姿勢を起こす。 #etrobo

posted at 12:25:43

おやじプログラマーずさん。段差の入り口でタイヤを空転させて入り口（のぼり口）を検知する。 #etrobo

posted at 12:28:35

おやじプログラマーずさんは、シーソーから降りるときは必ず左側にコースをとり、コースライン復帰を確実にした。 #etrobo

posted at 12:29:52

R-GRAY NEXTさん。車速にPID制御を取り入れる。シーソーから降りるときに急激に速度が上がらないように制御。 #etrobo

posted at 12:30:48

シーソーを万一オーバーランした場合にはダブルシーソー得点を諦める対策をあらかじめ組み込んでいる。 #etrobo

posted at 12:32:40

「信頼性」「安全性」への配慮。 HELIOSさん。実際の走りも安定していた。 #etrobo

posted at 12:34:07

HELIOSさんのプログラムは、センサーやモーターの異常を事前に診断。 #etrobo

posted at 12:34:57

ヒューマンエラーによるキャリブレーション測定のミスも、ソフトがしっかりと診断して警告を発する。凄すぎます。 #etrobo

posted at 12:36:03

PCとNXTの分散処理はスタートミスの軽減やET相撲攻略に貢献した。 #etrobo

posted at 12:36:49

パネルセッション終了。お疲れ様でした。休憩を挟んで１２：５０再開。 #etrobo

posted at 12:38:53