BROKEN's Advanced Vehicle Laboratory

プロジェクト / UML ロボコン 2004

UMLロボコンは、UMLで描いたモデルとそれに基づいて実装されたLego Mindstorms上で動くライントレースプログラムの出来をきそうロボットコンテストです。このプロジェクトでは、UMLロボコンに参加することでUMLの使い方やオブジェクト指向の考え方、開発の流れを学んでいきます。

目次

  1. はじめに
  2. 開発経緯（日報より抜粋）
  3. 技術的なポイント
  4. 結果と反省
  5. おわりに
  6. 関連リンク

1.はじめに

1.1 UMLロボットコンテストとは

UMLロボコン、あまり聞き慣れないロボットコンテストですね。まず、UMLというのはUnfied Modeling Languageの略で、ソフトウェア開発時に開発対象をモデルとして分析・設計する際に使用するモデルの表記方法のことです。そして、そのUMLを冠したロボットコンテストは、UMLロボットコンテストのホームページによりますと、

組込み分野で広く教育に利用されている「LEGO Mindstorms」でロボットを作り、UMLで分析・設計されたソフトウェアの実装競技会です。

と紹介されています。簡単に言えば、まったく同じハードウェアを使用して、ソフトウェアの優劣を競う大会です。ここでいうソフトウェアとは、実装されたプログラムだけでなく、要求仕様から分析、設計までの成果物（つまり、プログラムの設計図）も含みます。それゆえ、タイムトライアル部門とモデリング部門があります。

UMLロボコンはオブジェクトテクノロジー研究所が主催するUMLフォーラムの併設行事として2年前から開催されており、今年で3回目を迎えました。UMLロボコンはRT系／組み込みソフトウェア開発へのUMLの適用を推進することを目的とした教育的意味合いの強いロボットコンテストで、参加者はUMLモデリングの講習を受けることができるという特典があります。

1.2 参戦のきっかけ

私がUMLロボコンを知ったのは、昨年マイクロマウスの制御ソフトを作成していたときです。UMLを使ってマイクロマウスをモデリングするのに、参考になりそうなものはないかとgoogleで検索していたときに、オージス総研のオブジェクトの広場で「第2回UMLロボットコンテスト参加レポート」を見つけました。その後、UMLロボコン参加募集のお知らせが今年の1月末にオブジェクトの広場MLで流れて、参加するに至りました。

普段（仕事でも趣味でも）私一人でモデリングしていると、そのモデルがよいのか悪いのか全然分かりません。なので、大会参加を通して他人のモデルを読み、どのようなモデルがよいのか、自分のものと比較することを目的としてUMLロボコンに参加しました。

2. 開発経緯（日報から抜粋）

1月
1/30 オブジェクトの広場MLで第3回UMLロボコン開催のお知らせが流れる。
2月
2/12 第3回UMLロボットコンテストにエントリー。
2/18 ツクモロボット王国に Lego Mindstorms基本セットを注文。
UMLロボコン参加者用MLスタート。
2/21 3回UMLロボットコンテスト資料CD-ROMが到着。
開発環境の準備を開始。
Mindstorms基本セットはまだ届かず。
2/23 Mindstormsが届いた。
MLCad（レゴブロック用３DCAD)を見ながら走行体の組み立てを完了。
先日配布されたCD-ROMの中身がいくつか壊れているとの情報がMLに寄せられた。
Mindstormsの箱を開けるとこんな感じ。 デフギア内蔵。
組み立て半分終了。 できあがり。
2/24 第1回モデリング基礎教育に参加。
2/25 LegOSのインストール＆コンパイルにてこずる。
参加者用MLでも、LegOSのインストールが上手くいかない等の話がよく出ている。
2/28 LegOSを断念。
BrickOSのインストール＆コンパイルに成功。
BrickOSのインストールはhttp://brickos.sourceforge.net/docs/INSTALL-cygwin.html　を参照。
3月
3/1 モデリングしつつ、Mindstormsはどんなものなのか要素実験開始。
3/3 実験用の初めてのプログラムで、なんとかライントレース成功。でも、すぐにラインを見失ってしまう。
3/9 仕事のため、第2回モデリング基礎教育への参加を断念。
3/16 UMLロボコンの準備が進まない。
3/? 自宅コース作成。
3/30 第1回試走会。ほとんどのチームがまともにコースを１週できていない。
パワーを落とせば何とかラインに沿って走るが坂を登りきれない。
パワーを上げると首振りが発散してコースアウトしてしまう。
4月
4/3 モデリング部門提出物を仕上げて速達で郵送。締め切りは 4/5の正午。
郵送後にモデルの拙い所を発見・・・。
4/4 第2回試走会。まったく進展無し。
4/5 昨日の試走会の反省や新しく試してみたいことをいろいろと実験。
自宅コースA（最小半径２０cm）でも自宅コースB（最小半径３０ｃｍ）でも、まあまあ走れるようになった。
4/10 さっぱり進まず。でも、とりあえず自宅コースで走ることは走る。
4/12 大会前日。時間がなくなってきたのでコースアウトからの復帰機能の実装を断念。下り坂で走行速度が上がりすぎると、蛇行してしまい、コースアウトする。スポットライト対策はOK。
4/13 大会当日。遅刻しました。結果は2回ともリタイア。

3. 技術的なポイント

UMLを使えばソフトウェア開発が上手くいくと勘違いされている方がたまに（というか、よく）います。しかし、UMLは単なる図の描き方のルールに過ぎません。ソフトウェア開発に必要な知識・技術を大別すると、以下のようになります。

大学の授業では、OSの仕組みやプログラミング言語については教えますが、開発手順（プロセス）や分析・設計技術、テスト・デバッグ方法についてはあまり教えません。これらについては、実際の開発を通して身につけていくべきものだと、私は思っています。（教えてくれると大助かりですが。）

3.1 問題領域に関する知識・理解

問題領域を、コース、プラットフォーム、ライントレーサ制御戦略の３つに分けて考えてみました。

3.1.1 コースについて

第３回大会のルールが、競技規約のところに書いてあります。競技規約の5ページ目にトラックの構造に関する説明があります。ポイントだけ抜き出すと、こんなことが書いあります。

3.1.2 プラットフォームについて

先ほどの競技規約には、ハードウェアとして Lego Mindstorms を用い、参加者全員が指定された同じ構造の走行体（ライントレーサ）を使用することになっています。また、大会運営委員会から開発環境のCD−ROMが配布されており、これを使用してプログラムを実装することになっています。

Mindstormsで作った走行体のポイントをいくつか挙げておきます。

開発環境についてもポイントをいくつか。

3.1.3 ライントレーサ制御戦略

制御ロジックをどうするかという、問題領域の中心部です。思いついたものだけ上げても、こんなにあります。

これらの問題点をどのように攻略するかは、コースや走行体の特徴を十分に理解した上で決定する必要があります。私はMindstormsがどのようなものなのかあまり理解していなかったため、特徴を把握するために幾つかの基礎実験をしてから設計方針を決めました。

失敗事例になりますが、私が審査用に提出したモデルでは操舵角度をなんとか計測しようとしていますが、やってみてそれは困難であることがモデル提出後にわかりました。

3.2 開発手順（プロセス）

UMLの表記法を覚えたとしても、ソフトウェア開発の流れを知らなければ、どこでUMLを使ってよいのかわからず、覚えた意味がありません。そこで、要求仕様からプログラムのソースコードになるまでの作業の流れ（開発プロセス）が必要となります。私はこれまで定まったプロセスにしたがってソフトウェア開発を行ったことが無かったため、今回はOctopusを参考にしながら開発を進めました。（といっても、徹頭徹尾ではありません。）

4. 結果と反省

結果は、試走２回ともリタイアでした。自宅コースではバッチリ走れても、本番コースでは勝手が異なるようです。インコース、アウトコースとも、何とかがんばってコース１周最後の上り坂までは上れたのですが、下り坂でスピードがつきすぎてしまい、ステアリングが左右に大きく触れてコースアウトしてしまいました。

今回の反省点をここではライントレーサ制御方法の反省点と、実装上の反省点にわけて考えてみます。

4.1 ライントレーサ制御方法の反省点

リタイアした直接の原因は、「下り坂でスピードがつきすぎてステアリングが左右に大きく振れてコースアウトしたこと」です。これをもう少し分解してみると、以下の３点がでてきました。

  1. ステアリングの制御が甘い。
  2. スピードの制御が甘い。
  3. コースアウトしたら戻ろうとする機能が無い。

これらの問題点について私が取った方策その反省について述べます。

4.1.1 ステアリング制御の問題

走行速度があがるとステアリングが暴れてしまうという問題点を解決するために、私は

という方法を取りました。これは自宅コースでは十分に効いたのですが、本番のコースでは

といった結果に終わりました。

速いチームのステアリング制御を見ていると、かなり早い周期で細かくステアリングを振っているのが判ります。どうやって細かく振っているのだろうと思って大会会場に掲示されていたモデル図をみてみたところ、どうもステアリングを振る角度に制限をかけているようでした。

4.1.2 スピード制御の問題

ステアリングを暴れさせないためには、走行速度を抑えるためにモータのパワーを抑えればよい、というのがもっとも単純な発想です。しかし、今回私は漆黒線による難所判定を無視していたため、モータのパワーを抑えると上り坂が登れなくなるというジレンマに陥りました。やはり、難所判定は必要なようです。

今回私がスピード制御で試してみた作戦では、

ことで、ロボットがカーブでラインを横切ってコースアウトするということを防ぐことができました。ただし、ライン上でどこまでパワーを落とすか匙加減が難しく、自宅コースでは最低でも１００〜１２０ないとカーブが曲がれないという状態でした。

4.1.3 コースアウトからの復帰

私はこの機能は余裕があったら実装すればいい、くらいに考えていましたが、これはほぼ必須な機能なのだと大会本番で思い知らされました。確実には走るチームは、コースアウトからの復帰機能が当たり前となっていました。私も必要だとは思っていたので、大会の３日前くらいから設計・実装に挑戦したのですが、実装上の問題と時間的余裕がなくなったことにより、実装を断念しました。

4.2 実装上の反省点

実装にはC++を使用しました。C++は、大学４年のときに本を読みながら独学で文法を覚えましたが、当時はオブジェクト指向の考え方や分析・設計方法を知らなかったため、C++によるオブジェクト指向の実装まではできなかったのが実情です。なので、今回が実質的なC++デビュー戦でした。

UMLでクラス図を描くのはできたのですが、それをどうやってC++のソースコードに落とすのかが判らず困りました。特に、クラス間の関係をどう実装するのか、「状態」を表すためにStateパターンを使用する場合それをどう実装するのかなどです。

「関係」の実装については、「ソフトウェアパターン」（中谷、青山、佐藤編：共立出版、2001）の第４章実装パターンに具体的な例が示してあったため、それを参考に実装することができました。しかし、Stateパターンについては、GoF本に例となるソースコードがあることはあるのですが、その例どおりに実装しただけでは動作するまでには足りない部分があることに、実装しながら気づきました。

いずれにしても、いきなり本番用のソースコードに盛り込むのではなく、簡単な例題で肩慣らしをしてから本番用にとりかかったほうがよかったかもしれません。

5. おわりに

今回のUMLロボコンに参加したことは、

という点で有意義だったと思います。

次回大会でそれなりの成績を収めるためには、

の２点が重要だと感じています。

以上の報告を以って、２００４年度のUMLロボコンプロジェクトを終了とします。

関連リンク