[レポート]
(株)オージス総研 |
オブジェクトテクノロジーソリューション部 |
水野正隆 |
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 つありました。
- コースの黒いラインを読み取る光センサー
- 柁がまっすぐになると車体本体と接触し、センサー値が ON になるタッチセンサー
概念モデル作成時には、走行体のハード構成を素直にクラスとして抽出し、それらをまとめるユニット(〜部という名前のクラス)もクラスとして抽出しました。概念モデルを作成し、対象ドメインに対するチームメンバーの認識合わせがだいたい出来たところで、分析段階に入ります。
分析
いよいよ走行体の分析です。さっそく、クラス図を見てもらいましょう。(このモデルに行き着くまでに、熱い議論が何度行われたことか...^^)
分析モデル図(1): UI 部分のクラス図。(クリックすると拡大表示されます)
分析モデル図(2): ハードウェアとそのコントロール部分のクラス図。(クリックすると拡大表示されます)
分析段階のモデルも、概念モデルの段階と大きな変更はありませんでした。主な変更点として以下の事柄が挙げられます...。
- ハードウェアをラッピングするラッパークラスを用意した。
- 走行の振る舞いを変えるパラメータ設定の UI が加わった。
- 操舵部の責務分割...光センサーをラップする監視部と、タッチセンサーをラップする操舵部とに分離。
非常に素直なモデルだと思うので、クラス図を見ただけで概ね理解できると思います。さて、クラス図を見るとクラスが色分けされていますね。それぞれ、
- 緑:UI
- 青:コントローラクラス
- クリーム色:ハードウェアのラッパクラス
- 水色:ハードウェアに対応するクラス
- 赤:その他
に対応しています。分析モデル図(1), (2) をつなげて見ると、上から順番に、UI、コントローラ、ハードウェアラッパ、ハードウェアと階層をなしていることがわかります。それぞれの階層に合わせた抽象度・責務を持ったクラスを抽出することで、階層を跨がった依存関係が少なくなり、変更に強いシステムが作れます。抽象度が異なったクラスが同じ階層にあると、なにかの変更が起こったとき...例えば、ハードウェアや、ハードウェアの構成が変わったとき...にシステムのあちこちを変更するはめになります。分析では、こういった事に注意し、モデリングしました。
オニオンスライス
さて、そうは言うものの、上のクラス図を見ると、一部、階層を崩しているものがあります。ハードウェアが、上の層のクラスと依存関係を持っています。これは、組み込みシステムのようにシステムがハードウェアに密接に関わっている場合には起こることで、ソフトウェアがハードウェア構成にどっしりと載るのではなく、ハードウェアがシステムのアプリケーション部分を取り囲むようになります。これをオニオンスライスと言います(下図)。
階層イメージ(左)、オニオンスライスのイメージ(右)これら 2 つのイメージは、別の事を言っているのではなく、あくまで、「見方」の問題ですので、好みがわかれるところでしょう。自分のイメージしやすい方で考えれば良いと思います。実際、階層イメージは、オニオンスライスイメージの一側面と考えられます。
階層モデルをイメージし過ぎるあまり、今回の分析クラス図のように下位層のクラスが上位層のクラスと依存関係を持つ状態を嫌い、無理な分析・設計になり出したら、立ち止まってオニオンスライスのイメージを思い浮かべると、素直なクラス設計ができます。
コーディング、そして、チューニング、チューニング...
コーディングはできたものの...
分析が終わり、設計が完了すると、後はコーディングをするのみ。システムの規模が小さいので、コーディングはすぐ完了し、とりあえず走るまではすぐに出来ました。ちなみに言語は、C++ を使いました。(Java でも書くことが出来ますが、メンバーの得意言語が C++ だったため)
しかし、ここからが長かった...ひたすら、泥臭い作業が続きます。やることは、走行の性格を変えるパラメータ等の設定です。実際に走らせて設定値を変えます。ただそれだけなのですが、設定値が多くてどこをなおせば良いかがわからない。また、それぞれが複雑に影響しあってなかなか良いポイントが見つかりません。例えば、以下のような設定値がありました。
- 光センサーの黒感知レベル、白感知レベルの値の兼ね合い
- 直線でのスピード、カーブでのスピード
- 直線かカーブかを判断するためのタッチセンサーの検知と、値の平均化をするための計算
- 柁をきるモータのスピード
その他にも、細々したパラメータを追加したり、外したり...。地味な作業でした。重要な部分なんですけどね。(^^;
一番難しかったのは、「センサーの揺らぎをいかに平均化するか?」という問題でした。複雑なアルゴリズムを駆使すれば、揺らぎは押さえられます。しかし、計算に時間がかかると次のセンサーの検知までに時間が開き、ロボットの安定性が失われます。また、あまり平均化し過ぎると、状態の急な変化に弱くなり、急カーブで曲がりきれなくなりました。
そこに気付くのに手間どってしまい、ずいぶん回り道をしてしまいました。やはり、なにかを作るときは健全な環境でやるべきですね。業後に、1, 2 時間ちょこっと開発するだけでは、腹も減ってるし、早く帰りたいわで、能率があまりあがらず、結構無駄なことをやってた気がします (^^;
試走会
大会当日前に、2 度、試走会に行きました。ビーチくらぶのロボットは、最も早い記録で、一周を約 24 秒。まずまずの成績だったのですが、23 秒、22 秒という好記録を出しているチームが数多くありました。「こ、これは当日は、20 秒前後の争いになるかも...。」 参加者のレベルの高さに驚き、なんとかして勝たねばと新たな決意を胸に、チューニングに励むも、チューニングすればするほど遅くなるという事態にみまわれ、気が付くと大会前日の夜でした。ふぃ...(-_-;
大会当日
練習走行
さて、若干の不安はあるものの、意気込んで望んだ大会当日。練習走行で 23 秒とそこそこの記録を出せました。「うん。少しはいけるかも...」 メンバーは少し自信をつけ、試合に臨みました。出場するからには、平凡な結果で終わるより、華々しく勝ちたい。インコース・アウトコースをそれぞれ走り、良い方のタイムが記録になるので、
- スピードの出にくいインコースを安定したスピードで走って 23 秒の記録を残し、
- アウトコースでは勝負をするため直線のスピードを上げ、20 秒近くのタイムを出す
ことを考えました。(両方とも勝負に出れないのが、肝っ玉の小さいところ...笑)
本番...いざ勝負!
意気込んで望んだ、本番の走行。ビーチくらぶのマシンは完走しませんでした...(涙)。
1 回目、インコースを第 3 コーナーまで順調良く走りましたが、コース脇に設置されたスポットライトの光により光センサーが黒ラインを見失い、脱線。結局、このスポットライトの光により脱線するチームが相次ぎ、完走チームがわずかしかいなかったので、2 回目のレースはスポットライトを切ってレースが行われました。しかし、2 回目のアウトコースでも、カーブから直線に抜けるコースで脱線...今度も、光センサーがラインを見失ったのだと思います(窓際で脱線したので、外の光?)。結局、ビーチくらぶは記録無し。残念な結果に終わってしまいました。
さて、他のチームですが、試走会で良い記録を出していたチームも続々とコースアウトし、記録無しのチームや、思った通りの記録が出ないチームが多く出ました。 「完走さえしていれば、上位に食い込めたのに...」とも思いましたが、どのチームも同じことを思っていますよね(笑)。本番で、問題なくモノを動かすことは難しいことです。業務では、必須条件ですけど!
さぁ、勝負だ! スタート地点にマシンを置いている筆者(右側の奥)。モデリング
さて、レースが行われている横には、モデルが張り出されいる場所があり、出場チームのモデルを自由に見ることが出来ます。審査、大会参加者、見学者はそれぞれ自分が一番良いと思うモデルに投票します。
張り出されているモデルを真剣に見る人達...「どれに投票しようか...」どのチームもしっかりとモデリングしていました。自分達がモデリングしたドメインの"違うチームのモデル"を見るのは大変参考になり、勉強になります。状態の抽出ができているモデルや、振る舞いがしっかりと記述されているモデルは理解しやすく、よく出来ているなと感じました。また、筆者は、責務がしっかり分割できているモデル、理解しやすいモデルが好きなので、そういったチームのモデルにも関心を持ちました。
ドメイン理解をするために、モデリングする訳ですから、パッと見て意図の分かりにくい(伝わりにくい)モデルは、筆者は好きではありません。そのときの設計者や、チームメンバーにとっては構わないかもしれませんが、システムの拡張や、後の保守の事も考えると、懲り過ぎたモデルは決して優れているとは思えません。一般的に、保守フェーズに入ると、メンバー交代が行われるのが常ですから。やっぱり、わかりやすくないとね(笑)。
ところで、ビーチくらぶは、モデリング部門で 2 位と健闘。ゴールドモデル賞を頂きました。(心の中では、自分のところのモデルが 1 位と思っていたんだけど...笑)
ゴールドモデル賞の賞状を持つ伊藤さんと、渡辺さん。伊藤さん、もっと笑って笑って。下が提出したコンセプトシートです (クリックすると拡大表示します)。
大会を終えて
自主的に動くロボット制御の難しさを痛感しました。自分自身が動くので、周囲の環境と自身の状態の変化に対応して、細かい制御をしてあげなくてはなりません。しかも、今回のロボットのように高速で走行する物は状態変化が激しいので、細かい時間間隔でセンサーをチェックする必要があります。Mindstorms はあまり早く動作しないので、状態制御には苦労しました。
試走会で高速に走っていたチームが、本番でコースアウトしたのも、本番会場の環境(光)の変化がセンサー感知のタイミングに比べて激しかったので、状態の制御がその変化に追いつけなかったのだと思います。
また、部品が、壊れやすい LEGO ブロックだったというのも、難しさの要因のひとつでした。駆動する部分はどうしてもブロックが緩むんですよ...。
小さなプログラムで、実際に動くモノを作ることは、とっても楽しい体験でした。普段の業務では、大きなシステムの一部や、目で見える形では動かない(動いても実感しにくい)モノを作ったりしているので、なかなか実感がわきません。Mindstroms の場合、自分の書いたコードが、即、小さなロボットの動きに反映されるので、モノを作るという、本来のソフトウェア開発の面白さを感じられます。「やっぱりソフト作るって面白いなぁ」と再確認できた良い機会でした。敷き居が高いかもしれませんが、プログラムを作れるようになった新人さんの研修にもいいのではないかと思いました。
おまけ:『ビーチくらぶ』メンバーから一言
- チームメンバーのモデリングに対する情熱を肌で感じることができました。実装では、チューニングポイントが多くあり、チューニングする度に改悪していってしまいました。今回はLEGOに振り回された感がありましたが、この経験を生かし次回は優勝を狙います!次も参加するつもりでいる・・・(阿左美)
- モデリング担当なのに、ほとんど客先常駐状態だったので、全然モデルを描けませんでした。たまにオフィスに帰ったとき位しか打ち合わせに参加できませんでしたし、迷惑かけてばかり。でも、お陰でカッコいいモデルになったし、完走こそ逃しましたが、結構いい感じで走るようになったし、とても楽しかったです。(坂坂屋.comの兄イ)
- モデリング部門で賞をいただいたのは素直にうれしいです。あまり凝ってはいませんが、わかりやすいモデルが描けたと思います。反省点としては、コースアウト時のアルゴリズムも多少考えていたのですが、練習走行でちゃんと走っていたため設計・実装を怠ってしまい、当日完走できずに終わってしまいました。エラー処理の重要性をあらためて実感しました。(伊藤)
- 大会当日、受付の近くでUMLオブジェクトがオバールの中で幟をキコキコ揺らしてる姿が、なんとも健気。コースを読み取るセンサーが1つのみ、というのは新鮮。(横田)
- 今回モデリングチームに参加しましたが、対象システム(LEGO)の規模が小さいのですぐにできるだろう、という甘い予想とは裏腹に、モデリングミーティングでは議論、議論の連続でした。次回は完走と、モデリング部門1位を目指し頑張ります!(岩出)
- あぁ、動いてる!組み立てたレゴブロックが、モデリング+コーディングした結果で動いてる、ということに、ただただ感嘆するのみ。(お子様)
- テスト用の走行体を組み立てただけです.あとはモデリングのときに茶々を入れただけ。すみません。(フジクラ)
- もっと明確な指針を持ってアルゴリズムの実装すれば良かった。Cording and Test 自体は良かったけど、手当りしだいという感は否めなかったので、バランスのとれた設定を見つけるのに手間どってしまい、結果的に走行テスト時間が短くなってしまった。(水野)
- 組み込み系未経験の新人で、テスト用走行体の組立と、コンセプトシート作成には(少し)貢献できましたが、ただただ勉強させていただくことばかりでした。ビーチくらぶのみなさまには本当に感謝しています。(桑原)
さらにおまけ (^^;
弊社の組込みトレーニング担当者から一言
この記事を読んで、UMLでLEGOを動かしたいと思ったアナタ !!! オージス総研では、今回のロボコンと同じような経路探索ロボットを、モデルから実装( C++)まで体験できるコースをご用意しています。
トレーニングコース「組み込みオブジェクト指向体験」https://www.ogis-ri.co.jp/learning/c-02-04.html
来年のエントリーに向けて、ここで技術を磨いてみませんか?
#営業モードですいません...。参考
© 2002 OGIS-RI Co., Ltd. |
|