|
|
ETロボコン開発：日々の記録(6月前半)
ETロボコンの開発にあたり，開発記録を残すことは重要であると感じました。 6月4日
ロボット野郎の私としては，実走行もせずに試走会へは望めない。
作業すること3～4時間にて完成！（アウトコースのみですが）
坂道もしっかり再現。
ショートカットまで完備！
このコースにて問題点を見つけつつより良いモデルを作成することが目的。 （今のところアウトコースだけですが･･･） ここでやっとロボット派の僕の役目がやってくる。 目標はショートカット（点線）の突破。 1日で出来るものか？ →「出来る，出来ないじゃない，やるのだ！」という信念が重要なのです。 実際にはアルゴリズムは単純なもので外乱に強いものをイメージ。 頭の中に思い描いているものをいくつか実装する。 この際，先週までにある程度「武器」となるクラスがいくつも設定されているので 制御の追加の時間が物凄く早い！ 直線通過だけの状態からコースを回ることの可能なプログラムに加え， ショートカット通過の目処をつけることが出来た。 事前準備と開発手法が見事にかみ合った瞬間でした。 6月5日
さあ，本日は試走会。
しかも，情報を頂いた「ムンムン」さんも同じ時間帯でやる気度MAX。 こいつら「すげー」と言われることを目標に，走行練習を行う。 （本当の目的はコースのセンサ値の評価や，実走行での調整です） ちなみに，コースの周りをバタバタと走り回っておこられました。 実行委員の皆様ごめんなさい。m(_ _)m 大切なコースを傷つけないようにすることが大事ですよー。 なお，「ムンムン」さんはインコースのオフロード越えを現時点で完成済み。 （越えた瞬間はみんなで「おぉー！」という驚きの声があがっていました） 負けじと点線越えを行う「あまがさきつうしんぶ」（これしか出来ませんが･･･） このアルゴリズムは，東京行きの飛行機の中で突如思いついたもの。 僕の信念は，「制御は必要となったときに考えろ！」です。 まずは動くもの。問題は根本的な解決を探してから最後に制御に至るべき。 ただ，今回の制御はいきなりうまくいったので，作った本人もびっくりでした。 調整時点での最短時間は，なんと32秒！！ 証拠 この状態を維持していきたいです。（既に運を使い果たしたか･･･） また，実装が即座に出来たのは，モデルがしっかり出来ていて， 必要な機能をすぐに取り出せたため。 開発方法による長所を全て生かすことが出来たと思います。 試走会中は，クラッシュ などの迷惑をかけてしまいました。 申し訳ありませんでした。 （ちなみに，こちらが勝ちました←ロボット相撲でないので意味無し） 「競技が違います」といった突っ込みが入りました。 ちなみに今後の目標は，「インコースの実力もアップすること」となりました。 目指せ完全優勝！？です。 6月11日
土日しか作業が出来ないわがチーム。
「eclipse」という統合開発環境を今回のGNU C++の開発に適用しています。 さらにテスト駆動開発を行うための「CPPUNIT」を準備。 ただし，このままではBrickOSのAPIを含めたコンパイルは出来ないので， #ifdefを使用して，「テスト駆動開発」と，「実走行」のコンパイルを分離。 LEGOに実装する最終コンパイルはCYGWIN上で行います。 テスト駆動開発では，まず実際のコードを書く前にテストを書きます。 コンパイルすると当然エラーが生じる（実体が無い）ので，そこで実コードを追加。 実コードの追加によりテストがOKとなることを確認して次のテストへ移行します。 この際，必ずコンパイル，テスト実行をするので，書いた内容にバグがあるかどうかを 確認しながら作業を進めることが出来ます。 また，テストを考える際に，考えて設計を行うため，よく練られた内容となる。 といった品質的に良い点があると考えられます。 今回は，大きな問題が発生することなく順調に開発が進んでいるのは この開発手法がかなりの部分で関わっているのではないでしょうか？ 6月12日
引きこもりPART2。
オフロードは完璧に通過が非常に困難な難関である。通過の確率が低い， その割には通過できるときもあり，一定の挙動を取らないため，対策も講じにくい。 ひとまず目標の漆黒判定＋状態遷移にて通過してみる。 ・漆黒判定にて状態遷移 ・とりあえず通過する ・通過後の漆黒線にて停止 が，怪しげながら完成。 こんな感じ 現状は特にオフロードだからといった特別な制御は無しです。 後は，テスト走行でのひらめき的な制御に期待ですかねー？ モデルも作んなきゃいけないと思いつつ，次の土日までお預け･･･残念。 6月13日
何かが足りない。
前の月（4-5月）へ 次の月（6月後半）へ 
戻る
|
