ObjectSquare

[レポート]


UML ロボットコンテスト参加レポート

(株)オージス総研
オブジェクトテクノロジーソリューション部
水野正隆

UML Forum/Tokyo 2002 では、UML ロボットコンテストという大会が同時開催されました。オージス総研 OTS 部の "面白そうなこと大好き人間達" がそんなイベントを見のがすはずもありません。新人や旧人、チームや部署も様々な、いろいろな特徴を持ったメンバーが集まって、オージス総研混成チームとしてコンテストに参加しました。そんな混成チームの汗と涙の(?)コンテスト出場までの道のりをレポートします。

UML ロボットコンテスト

LEGO ブロックで作ったロボット

UML ロボットコンテスト(以下、UML ロボコン)は、LEGO Mindstorms (以下、Mindstorms)を使って組み立てたロボットを、決められたコースに沿って走行させる競技会です。ロボットを、白いフィールド(発泡スチロール)に引かれた、黒いライン(ビニールテープ)のコースを 1 つの光センサーで検知しならがら、コースに沿って周回させなくてはなりません。

Mindstorms に付属の RCX ブロックには、LegOS という OS が組み込まれています。そこにはソフトウェアを転送させることが出来、センサーからの信号を読み取ったり、モータを動かして、ロボットの動きを制御することができます。そのソフトを作成し、大会でコースを走らせて、その順位UML で書かれたモデルの評価の優劣で勝敗を競います。UML で記述されたモデルが審査対象となることが、この大会が、UML ロボコンと呼ばれている所以ですね。(ただし、後述のフリースタイル競技では、モデルは審査対象になりません。)

コース
試走会で撮影したコース。2 本のラインは、それぞれインコースとアウトコース。本番では、イン・アウトのコースをそれぞれ 1 回づつ走る。

スプリント競技に出場だ!...チーム名は...えっ!?

大会には、スプリント、ロングディスタンス、フリースタイルの 3 つの競技がありましたが、そのなかで最もシビアな戦いになりそうなスプリントに出場することにしました。スプリントは、大会規定で決められたロボット(走行体と呼ばれる)がコースを 1 周する時間と、モデルが審査対象となります。ちなみに、走行体には Path Finder という名前が付けられていました。

出場するには、チーム名を決めなくてはなりません。センスがあって、カッコ良くって、しかも少し、アバンギャルドな要素も取り入れたい...。いくつか候補が挙がったなか、厳選なる投票で決まったのが、ジャジャーン! 「ビーチくらぶ」。......えー、チーム名に対するコメントは、置いておいて、ここで、我がビーチくらぶのメンバーを紹介しましょう。(落選したチーム名候補ってどんなのだったのやら...^^;;;)

大会連絡窓口係
阿佐美さん
モデリング担当
伊藤さん、赤坂さん、横田さん、岩出さん、桑原さん
コーディング担当
阿佐美さん、森さん、水野
LEGO 遊び係
フジクラ

担当作業以外も、手の空いている人は、他の作業もしました。

モデリング

まず、走行体の概念モデルを考えました。下の図が、概念モデルのクラス図です。

概念モデル

走行体には、2 つのモーターがありました。

センサーも 2 つありました。

概念モデル作成時には、走行体のハード構成を素直にクラスとして抽出し、それらをまとめるユニット(〜部という名前のクラス)もクラスとして抽出しました。概念モデルを作成し、対象ドメインに対するチームメンバーの認識合わせがだいたい出来たところで、分析段階に入ります。

分析

いよいよ走行体の分析です。さっそく、クラス図を見てもらいましょう。(このモデルに行き着くまでに、熱い議論が何度行われたことか...^^)

分析段階のクラス図

分析モデル図(1): UI 部分のクラス図。(クリックすると拡大表示されます)

分析段階のクラス図

分析モデル図(2): ハードウェアとそのコントロール部分のクラス図。(クリックすると拡大表示されます)

分析段階のモデルも、概念モデルの段階と大きな変更はありませんでした。主な変更点として以下の事柄が挙げられます...。

非常に素直なモデルだと思うので、クラス図を見ただけで概ね理解できると思います。さて、クラス図を見るとクラスが色分けされていますね。それぞれ、

に対応しています。分析モデル図(1), (2) をつなげて見ると、上から順番に、UI、コントローラ、ハードウェアラッパ、ハードウェアと階層をなしていることがわかります。それぞれの階層に合わせた抽象度・責務を持ったクラスを抽出することで、階層を跨がった依存関係が少なくなり、変更に強いシステムが作れます。抽象度が異なったクラスが同じ階層にあると、なにかの変更が起こったとき...例えば、ハードウェアや、ハードウェアの構成が変わったとき...にシステムのあちこちを変更するはめになります。分析では、こういった事に注意し、モデリングしました。

オニオンスライス

さて、そうは言うものの、上のクラス図を見ると、一部、階層を崩しているものがあります。ハードウェアが、上の層のクラスと依存関係を持っています。これは、組み込みシステムのようにシステムがハードウェアに密接に関わっている場合には起こることで、ソフトウェアがハードウェア構成にどっしりと載るのではなく、ハードウェアがシステムのアプリケーション部分を取り囲むようになります。これをオニオンスライスと言います(下図)。

オニオンスライス
階層イメージ(左)、オニオンスライスのイメージ(右)

これら 2 つのイメージは、別の事を言っているのではなく、あくまで、「見方」の問題ですので、好みがわかれるところでしょう。自分のイメージしやすい方で考えれば良いと思います。実際、階層イメージは、オニオンスライスイメージの一側面と考えられます。

階層モデルをイメージし過ぎるあまり、今回の分析クラス図のように下位層のクラスが上位層のクラスと依存関係を持つ状態を嫌い、無理な分析・設計になり出したら、立ち止まってオニオンスライスのイメージを思い浮かべると、素直なクラス設計ができます。

コーディング、そして、チューニング、チューニング...

コーディングはできたものの...

分析が終わり、設計が完了すると、後はコーディングをするのみ。システムの規模が小さいので、コーディングはすぐ完了し、とりあえず走るまではすぐに出来ました。ちなみに言語は、C++ を使いました。(Java でも書くことが出来ますが、メンバーの得意言語が C++ だったため)

しかし、ここからが長かった...ひたすら、泥臭い作業が続きます。やることは、走行の性格を変えるパラメータ等の設定です。実際に走らせて設定値を変えます。ただそれだけなのですが、設定値が多くてどこをなおせば良いかがわからない。また、それぞれが複雑に影響しあってなかなか良いポイントが見つかりません。例えば、以下のような設定値がありました。

その他にも、細々したパラメータを追加したり、外したり...。地味な作業でした。重要な部分なんですけどね。(^^;

一番難しかったのは、「センサーの揺らぎをいかに平均化するか?」という問題でした。複雑なアルゴリズムを駆使すれば、揺らぎは押さえられます。しかし、計算に時間がかかると次のセンサーの検知までに時間が開き、ロボットの安定性が失われます。また、あまり平均化し過ぎると、状態の急な変化に弱くなり、急カーブで曲がりきれなくなりました。

そこに気付くのに手間どってしまい、ずいぶん回り道をしてしまいました。やはり、なにかを作るときは健全な環境でやるべきですね。業後に、1, 2 時間ちょこっと開発するだけでは、腹も減ってるし、早く帰りたいわで、能率があまりあがらず、結構無駄なことをやってた気がします (^^;

試走会

大会当日前に、2 度、試走会に行きました。ビーチくらぶのロボットは、最も早い記録で、一周を約 24 秒。まずまずの成績だったのですが、23 秒、22 秒という好記録を出しているチームが数多くありました。「こ、これは当日は、20 秒前後の争いになるかも...。」 参加者のレベルの高さに驚き、なんとかして勝たねばと新たな決意を胸に、チューニングに励むも、チューニングすればするほど遅くなるという事態にみまわれ、気が付くと大会前日の夜でした。ふぃ...(-_-;

大会当日

練習走行

さて、若干の不安はあるものの、意気込んで望んだ大会当日。練習走行で 23 秒とそこそこの記録を出せました。「うん。少しはいけるかも...」 メンバーは少し自信をつけ、試合に臨みました。出場するからには、平凡な結果で終わるより、華々しく勝ちたい。インコース・アウトコースをそれぞれ走り、良い方のタイムが記録になるので、

ことを考えました。(両方とも勝負に出れないのが、肝っ玉の小さいところ...笑)

本番...いざ勝負!

意気込んで望んだ、本番の走行。ビーチくらぶのマシンは完走しませんでした...(涙)。

1 回目、インコースを第 3 コーナーまで順調良く走りましたが、コース脇に設置されたスポットライトの光により光センサーが黒ラインを見失い、脱線。結局、このスポットライトの光により脱線するチームが相次ぎ、完走チームがわずかしかいなかったので、2 回目のレースはスポットライトを切ってレースが行われました。しかし、2 回目のアウトコースでも、カーブから直線に抜けるコースで脱線...今度も、光センサーがラインを見失ったのだと思います(窓際で脱線したので、外の光?)。結局、ビーチくらぶは記録無し。残念な結果に終わってしまいました。

さて、他のチームですが、試走会で良い記録を出していたチームも続々とコースアウトし、記録無しのチームや、思った通りの記録が出ないチームが多く出ました。 「完走さえしていれば、上位に食い込めたのに...」とも思いましたが、どのチームも同じことを思っていますよね(笑)。本番で、問題なくモノを動かすことは難しいことです。業務では、必須条件ですけど!

いざ勝負
さぁ、勝負だ! スタート地点にマシンを置いている筆者(右側の奥)。

モデリング

さて、レースが行われている横には、モデルが張り出されいる場所があり、出場チームのモデルを自由に見ることが出来ます。審査、大会参加者、見学者はそれぞれ自分が一番良いと思うモデルに投票します。

モデルを真剣に見る人たち
張り出されているモデルを真剣に見る人達...「どれに投票しようか...」

どのチームもしっかりとモデリングしていました。自分達がモデリングしたドメインの"違うチームのモデル"を見るのは大変参考になり、勉強になります。状態の抽出ができているモデルや、振る舞いがしっかりと記述されているモデルは理解しやすく、よく出来ているなと感じました。また、筆者は、責務がしっかり分割できているモデル、理解しやすいモデルが好きなので、そういったチームのモデルにも関心を持ちました。

ドメイン理解をするために、モデリングする訳ですから、パッと見て意図の分かりにくい(伝わりにくい)モデルは、筆者は好きではありません。そのときの設計者や、チームメンバーにとっては構わないかもしれませんが、システムの拡張や、後の保守の事も考えると、懲り過ぎたモデルは決して優れているとは思えません。一般的に、保守フェーズに入ると、メンバー交代が行われるのが常ですから。やっぱり、わかりやすくないとね(笑)。

ところで、ビーチくらぶは、モデリング部門で 2 位と健闘。ゴールドモデル賞を頂きました。(心の中では、自分のところのモデルが 1 位と思っていたんだけど...笑)

ito&watanabe
ゴールドモデル賞の賞状を持つ伊藤さんと、渡辺さん。伊藤さん、もっと笑って笑って。

下が提出したコンセプトシートです (クリックすると拡大表示します)。

コンセプトシート1 コンセプトシート2 コンセプトシート3

大会を終えて

自主的に動くロボット制御の難しさを痛感しました。自分自身が動くので、周囲の環境と自身の状態の変化に対応して、細かい制御をしてあげなくてはなりません。しかも、今回のロボットのように高速で走行する物は状態変化が激しいので、細かい時間間隔でセンサーをチェックする必要があります。Mindstorms はあまり早く動作しないので、状態制御には苦労しました。

試走会で高速に走っていたチームが、本番でコースアウトしたのも、本番会場の環境(光)の変化がセンサー感知のタイミングに比べて激しかったので、状態の制御がその変化に追いつけなかったのだと思います。

また、部品が、壊れやすい LEGO ブロックだったというのも、難しさの要因のひとつでした。駆動する部分はどうしてもブロックが緩むんですよ...。

小さなプログラムで、実際に動くモノを作ることは、とっても楽しい体験でした。普段の業務では、大きなシステムの一部や、目で見える形では動かない(動いても実感しにくい)モノを作ったりしているので、なかなか実感がわきません。Mindstroms の場合、自分の書いたコードが、即、小さなロボットの動きに反映されるので、モノを作るという、本来のソフトウェア開発の面白さを感じられます。「やっぱりソフト作るって面白いなぁ」と再確認できた良い機会でした。敷き居が高いかもしれませんが、プログラムを作れるようになった新人さんの研修にもいいのではないかと思いました。

おまけ:『ビーチくらぶ』メンバーから一言

さらにおまけ (^^;

弊社の組込みトレーニング担当者から一言

この記事を読んで、UMLでLEGOを動かしたいと思ったアナタ !!! オージス総研では、今回のロボコンと同じような経路探索ロボットを、モデルから実装( C++)まで体験できるコースをご用意しています。

トレーニングコース「組み込みオブジェクト指向体験」https://www.ogis-ri.co.jp/learning/c-02-04.html

来年のエントリーに向けて、ここで技術を磨いてみませんか?
#営業モードですいません...。

参考




© 2002 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP