 |
[2013 年 2 月号] |
|
[2013 年 2 月号] |
［ レポート ］
株式会社 オージス総研
組み込みソリューション第一部 松村康弘
組み込みソリューション第二部 森淳郎
本記事は、ET ロボコン 2012 に参加した新人のレポートであり、2 部構成の 2 部目の記事にあたります。これまでの経緯は、東京地区大会編 も併せてご覧ください。
本記事は「東京地区大会編」と異なり、ET ロボコンについて少なからず前提知識を持っている方を対象としています。そのため、ET ロボコン未経験者の方は、以下のリンクを参照しながら読み進めることをおすすめします。
チャンピオンシップ大会編では、一つ一つの項が独立して読めるように構成しています。時間のない方は、気になる項だけをピックアップして読んでいただくことも可能です。 (東京地区大会編同様、新人の葛藤をより生々しく感じていただくため、ここからは常体（「である」調）でお送りします)
東京地区大会で提出したモデルシート は「性能面のオリジナリティ (独自性) が足りない」という大きな課題を残していた。 確かに、自分たちのモデルシートは過去の要素技術をベースにして書いたものがほとんどだった。アイディアレベルではいくつか案はあったが、どれも適用するメリットを見出だせないか、実現するのが困難なものばかりだった。(突飛なものでは、学習機能を用いて最適な難所攻略法を覚えさせよう、なんて案もあった) 現実的なレベルで、オリジナリティをアピールできる要素技術……そんな都合の良いモノがすぐに出てくるだろうか？ 文量を増やすと紙面の問題が出てくるため、それも解決しながら進めなければならない。
まずは、活動を進める上で現在問題となっていることから考えてみることにした。その結果、コース上において途中でラインを外れた場合、そのままコースから転落してしまうので、人間が追走する手間がかかっていることが分かった。（時にそのまま走行体が転落してしまうことも） これを回避するために着目したのが Bluetooth による遠隔操作だ。リモートスタートのために Bluetooth で端末と走行体が接続されているので、リモートで割り込むことができれば、コースを外れた際に停止させることで転落を防げるのではないか。さらに、リモートで停止させるだけでなく、リモートで動かすことができれば、コースの中央で走行体が立ち往生してしまっても手元まで動かせばよいので回収する手間が削減できるのではないか。 これらのことを実現するため、図 1 で示すようなリモコン機能を実装した。東京地区大会時に思いつきで実装していた機能であったが、実際に運用してみると思っていた以上に回収の手間を減らすことができ、後々まで重宝した。
図 1 : リモコン機能により走行体回収の手間を軽減
チャンピオンシップ大会では、ほとんどのチームが難所を全て攻略してくる。そのため、上位入賞を果たすためには、ベーシックステージの走行タイムを如何にして縮めるかが課題となっていた。 タイムを縮めるには当然、速く走れればいい。しかし、そう単純な話ではなく、速度を上げると転倒するリスクが増えるのだ。(例えば、路面の曲率が変わる瞬間などは走行体が横揺れし、そのままラインを見失うことがある) リスクがあっても、常時フルスロットルで走るしかないのだろうか？ 駄目だ。本番環境において、理想的な環境よりも走行が不安定になることは東京地区大会で身に染みている。危ない橋は渡れない。
そこで、走行安定 (基準としている白と黒のラインの境目を走っている) 時に、前進駆動量を最大にする方法を考案した。 実際にバッテリー値 90 〜 95 で 20 回試行し、ミニターボを使うことで走行の安定感を保ちつつタイムを縮めることに成功した。(表 1 参照)
| 条件 | 平均タイム | 完走率 |
| 速度 100 | 24.0 秒 | 90% |
| 速度 90 + ミニターボ | 24.9 秒 | 100% |
| 速度 90 | 26.7 秒 | 100% |
各難所の攻略方法を説明する「走行戦略」の記述には、アクティビティ図が直感的に読めて効果的だと考えていた。だが、アクティビティ図は記法に忠実に書こうとすると、紙面を大幅に占領してしまう。そこで、凡例を示した上で、分岐を省略した表記を図 2 のように行った。
図 2 : アクティビティ図本来の記述 (左) と、モデルシートに用いた記述 (右)
チャンピオンシップ大会では、ミニターボの項で記述した通り、ベーシックステージでのタイム短縮が鍵となっていた。ところが、パラメータチューニングによるタイム短縮は 25 秒を切るあたりで既に限界が来ていた。
―――チャンピオンシップ大会前の試走会にて 松村 「ショートカット採用しているチームはやっぱり速いなあ。もう、自分らもリスクを取ってショートカットしかないか？」 森 「いやいや、流石に今からそんな博打は打てないよ。今年のコースだと、他チームが走行しているコースを乗っ取る形のショートカットしかできない」 松村 「他チームの走行体と接触すると失格だから危険すぎるか……」 森 「うーん……ん？ あのチーム、明らかに直線のトップスピードがうちより早くない？」 松村 「ほんとだ！ あれ。もしかしてモータの個体差って、馬鹿にできないのでは……。」
早速、モータを最大駆動量で 30 秒間空転させる実験を行ったところ、良いモータと悪いモータではエンコーダ値 (※) が 1000 異なることが分かった。 半径 5cm のタイヤが 1000°回転すると (5cm + 5cm) * 3.14 * (1000°/360°) ≒ 87.3cm 異なるため、モータの性能はタイムに大きく影響する。(なお、空転させたデータであるため、走行体に取り付けて走らせると距離は異なる) 実際に高性能なモータに変更したところ、ベーシックステージのタイムも 1.5 秒ほど短縮され、23 秒台前半を叩き出すようになった。 また、左右で性能差が少ないモータを採用することで、プログラムに頼らなくてもある程度直線で走るようになった。 トップスピードが高い分、トルクが弱い、というモータもあったが、今回はトルクを考慮せずにトップスピードを最優先にして採用することにした。 (トルクは、坂上で細かな動きが要求されるシーソーの攻略で特に重要になってくるが、走行戦略・プログラムの改善でリカバリーできるため、優先度を下げた)
※ エンコーダ値：モータが回転した角度の値。NXT のモータエンコーダは 1°から検知できる。エンコーダ値が 10 の場合は、モータが 10°回転したことを示す。
東京地区大会では、エンコーダ値から現在どこを走行しているのか自己位置推定 (※) し、ストレートやカーブを判断していた。が、後半まで来ると、エンコーダ値が想定と異なってしまい、カーブを曲がらなければならないのにストレートの挙動をしてしまいコースアウトすることが多々あった。 アウトコースは階段やシーソーのへりに車輪をぶつけることで、エンコーダ値の修正を容易にできていたものの、インコースは修正できるポイントが見つからず苦戦していた。 運頼みか……と諦めていたところ、ヒントは意外と近いところにあった。
松村 「ドリフトターンでのペットボトル検知って、ほぼ 100% 成功しているよね。」 森 「検知→前進を慎重に繰り返してやれば、超音波センサは精度高いよ。」 松村 「これって、ルックアップゲートのゲート検知に流用できない？」 森 「確かに。リンボー体勢を始める位置もこれで一定化されるね。」
こうして、ルックアップゲートをエンコーダ値ではなく超音波センサで読み取る方式に変更し、エンコーダ値の修正もここで行うことで、ルックアップゲート以降の攻略精度が大きく向上した。
※ 自己位置推定：車輪の回転数から走行距離がわかるため、コース構成と突き合せることで、現在どこを走行しているのか推定することができる
東京地区大会の時と異なり、上記対策を施し、難所攻略成功率もモデルシートに書いた目標成功率を叩き出している。あの時の自分たちとは違う！ 満を持して迎えたチャンピオン大会当日だったのだが……。
チャンピオンシップ大会には魔物が潜んでいた……。
会場に着いた際には、特に違和感を覚えなかった。 試走が始まり、各チーム調整する中、私たちも会場の輝度や、カーブの曲がり具合を調整し始めた。東京地区大会の際にも、試走時の調整にはかなり難儀したが何とか調整ができていたため、今回もそのようなものだろうと考え調整を続けていた。 しかし、何度調整しても坂においてラインを外れ、またカーブでもコースアウトしてしまうなどの問題は解決せず、そのまま前半の試走が終わってしまった。他のチームも同じように調整に難儀しているように見えた。 センサの値を確認すると、練習環境とまったく異なる輝度を示していた。(図 3)
図 3 : 本番環境と練習環境の輝度の違い
この照明によって起こった問題については「5.1 インコース失敗の分析 」、「5.2 アウトコース失敗の分析 」で詳細を記述する。
こういう時に事件は続くもので、二回目の試走が始まるなり、インコース、アウトコース共に一回目の試走時よりも挙動がおかしくなっていた。 インコースは第一カーブ手前で前のめりに転倒し、アウトコースは坂頂上で前のめりに転倒していた。 どちらも尻尾の角度が原因だと分かったが、尻尾につながるモータにつながるケーブル接触や、走行体のフレームの歪みなどを確かめたが問題は無い。 試行錯誤の末、何故かエンコーダの値が半分になっていることが判明した。しかし、そこで試走が終わってしまった。 試走終了後、プログラムにおいてエンコーダ値を取得する部分を変に修正してしまったのではないかと調べたが問題は無く、他に修正した部分もエンコーダ値に影響するような部分は無かった。 ソフトウェアに問題が無ければハードウェアだと考えるが、モータは正確に回転している。 よく見ると、モータのケーブルが半挿しとなっているのを発見した。そこで、奥まで挿し込んでみるとエンコーダ値を正確に取得するようになった。 原因はケーブルが半挿しとなっており、電力の供給線だけが接触し、エンコーダ値を取得する 5,6 ピンは接触していなかったことだと考えられる。このコネクタの接触問題について、より詳しく知りたい方は以下の参考リンクを参照していただきたい。
参考リンク：
「4.1 会場の照明問題 」に対して効果的な対策を打てないまま完走できるほど、チャンピオンシップ大会の魔物は甘くなかった。インコース・アウトコースともに諦めずに調整を行ったが……結果は以下の通り。競技面では結果を出せずに終わってしまった。
チャンピオンシップ大会では、残念な結果に終わってしまった。何故、普段は完璧に走っていたものが、本番では走らなかったのだろうか。
まず、前提知識として、基本となるライントレースを簡単に説明すると、右モータと左モータに異なる回転量を与え、車輪の回転速度に差をつけることで「右旋回」「左旋回」を実現している。 私たちは、目標としている輝度と、現在読み取っている輝度がどれほど離れているかで旋回量を決定するプログラムを記述していた。 しかし、今回の会場では図 3 で示したように黒と白の輝度の差が少なく、十分な旋回量が得られない。 よって、試走の際は、以下の図 4 のように旋回量が低すぎてコースアウトしてしまっていた。
図 4 : 本番環境では輝度の差が少ないため、十分な旋回量を得られない
本番では、左への旋回量を思い切って大きく設定した。しかしそれが仇となった。カーブに入った瞬間に左への旋回量を大きく設定しすぎてラインから外れてしまい、ラインに急角度で接触してしまったため、図 5 のようにコースアウトしてしまった。
図 5 : 急場のチューニングが効かず、本番でもコースアウト
東京地区大会でも同様の現象は起きていたが、旋回量を地道にチューニングすることで、試走時間内での調整が間に合っていた。しかしながら、チャンピオンシップ大会では、前述したコネクタ半挿しというトラブルもあり、調整が間に合わなかった。
アウトコース失敗箇所の坂道においても、インコースと同様に輝度の影響を大きく受けていた。尻尾走行を採用している場合、坂道登りや平地に比べ、坂道下りでは光が多く差し込んでしまうのだが、この現象が想定以上に大きな影響を及ぼしていたのだ。このことは、チャンピオンシップ大会終了後、本番に近い環境 (蛍光灯に加え、白熱電球が真上から照らされている) で実験することにより分かった。
この問題は、平地の場合、坂道登りの場合、そしてコースアウトをした坂道下りの場合の三つに分け、一つずつ整理して行く。
まずは図 6 に示す平地での走行である。 平地においては、キャリブレーションで記憶した目標輝度と、走行時に読み取るエッジの輝度 (白と黒の境界) が同じになるため、当然問題は無い。
図 6 : 平地でのライントレースの様子 (蛍光灯 + 白熱電球 の環境)
次に図 7 に示す坂道登りでの走行である。 尻尾走行を採用している場合、頭上から差し込む光に対し、走行体を少し傾けることになるため、エッジを読んだ際の輝度が、目標輝度よりも少し明るくなってしまう。つまり、走行体からすると同じ黒いラインを読み取っていても、平地を走行していた時よりも白っぽく見えてしまうのだ。
図 7 : 坂道登りでのライントレースの様子 (蛍光灯 + 白熱電球 の環境)
問題は図 8 に示す坂道下りの場合の走行だ。 尻尾走行を採用している場合、下り時は走行体を大きく後ろに傾けることになるため、光センサがどうしても路面に対して斜めになってしまう。そのため、走行体の影となる部分が少なくなり、光の影響を大きく受けることになる。結果、黒色を読んだ時の輝度さえ、目標輝度から外れてしまい、走行体はホワイトアウトを起こしてしまっていたのだ。
図 8 : 坂道下りでのライントレースの様子 (蛍光灯 + 白熱電球 の環境)
なお、インコースでは坂道を問題なく走行できていたが、これはアウトコースに比べ、基準値を白寄りにしていたためではないかと考察している。 (他チームとの接触事故を避けるため、インコースではエッジより外側をライントレースするようにプログラムしていた)
今回、私たちは練習環境でどれだけ速く、正確に走行できるかに力を入れていた。 しかし、理想的な環境でどれだけ速く走れていても、別の環境でコースアウトしてしまっては意味が無い。遅くてもいいので確実に走れるように切り替えられる機構の準備をしておいた方が良いと感じた。 例えば、今回のチャンピオンシップ大会を想定すると……会場の照明がとても明るい。対策手段として、走行体自身の影の影響を受けにくい倒立振子で走るプログラムや、外乱光の影響をキャンセルできる「まいまい式」 (※) に切り替えられるようなプログラムを用意しておくと、スピードは犠牲になるが、安心できるだろう。 上で例示した「手段」が適解であるとは言い難いが、大切なのは「最悪の状況を想定する」こと。要求分析の時点で最悪のケースを想定できていなければ、そもそもそれに対応した「手段」など出てくるはずがないのだから。
※ まいまい式：光センサ内蔵の LED を明滅させることで、外乱光の反射だけを測定し、外乱光の影響をキャンセルする方法。詳細は考案者・すねいる吉田さんのブログ記事を参照
要求から構造、構造から機能とトレーサビリティが取れているモデルを描こうと目標を掲げていたが、チャンシオンシップ後のモデル相談所においてこのようなやりとりがあった。（モデル相談所では、モデル審査員から 5 〜 10 分程度でアドバイスを受けることができる）
森 「今回、競技だけでなくモデルでも取り立てて突出して評価いただいた部分があったとは思えません。」 審査員 「うーん。そんなことはないよ。全体的に押さえるところは押さえているし、パッと見て悪いモデルには見えない。」 松村 「基本を押さえる所で留まっていて、その先に踏み込めていないと思うのです。」 審査員 「そうか。じゃあ、厳しく行くよ……例えば、振る舞いモデルだけど。ステートマシン図って、この『システム全体の状態遷移』だけだよね？」 森 「はい。ユースケースが確かに実現できていることを示すために、一番大きな粒度のものを冒頭に示しています」 審査員 「そこを抑えているのはいいことだね。ただ、それ以上ステートマシン図を細かい粒度で書かなかったのはどうして？」 松村 「どうしてって……実際に部品単位でどう協調して動くかはシーケンス図・コミュニケーション図で例示すれば良いかと思いまして……」 審査員 「例示ならばそれで十分かもしれない。ただ、人によっては、何故この構造で他のケースでも動くのか？という疑問が出てくる。君たちのモデルシートの場合、審査員は他のケースを検証するためにどうすると思う？」 森 「クラス図を見ながら……個々のクラスがどう動くのか想定するしかないですね」 審査員 「そうだね。全体から詳細を検証するためには、他に何が必要だったのか考えてみようか」
相談の結果、以下の図 9 に示すように「システム全体の状態遷移」という状態遷移図が、どのクラスの状態遷移に対応しているのか、という所まで考慮できていなかったことに気が付いた。よりモデルに説得力を持たせるためには、要求から構造、構造から機能といったマクロな視点でのトレーサビリティだけでなく、一つ一つの図から図といったミクロな視点でのトレーサビリティが必要になってくる。要素技術の斬新さだけで負けている、と最初は考えていたが、モデルの見せ方でも捻りが足りなかったのだ。
図 9 : 大きい粒度の図から小さい粒度の図へとブレークダウンされていない
（クリックすると拡大します）
チャンピオンシップ大会で提出したモデルシート（PDF : 約 1.5MB）
「拡張性が高いモデルにする！」と目標に掲げてモデリングをしていたが、新たな機能 (Bluetooth を用いた通信機能やデバッグ機能) を付加する際にどうしても構造を変えざるを得ない場面が多かった。先の項で挙げた「あらゆる状況を想定する」というのも当然、構造に表れてくるだろう。 設計原則に従って拡張性が高いモデルを目指すことは有効なアプローチだったのだが、それに加えて、事前に必要となる機能の洗い出しを入念に行えていれば、構造を大きく変更させることなく機能の実現が容易になっていたはずだ。
――機能の洗い出しができていれば、構造を大きく変更させることなく機能の実現が可能。
私たちだって、機能の洗い出しをサボっていたわけではない。しかし、終盤になるに連れ、メンバー間の意識に差がなくなり、知見が蓄えられてくると、機能の洗い出しが漏れていたことに気がつくのだ。そうして仕上げられた綺麗なモデルシートには、泥のような試行錯誤は反映されていない。
上記のことを回避するためには、早い段階でプログラムもモデルも一度仕上げてしまい、プログラムとモデルのセットを壊しては作り……壊しては作り……という地道なプロセスを繰り返していくのが適しているのかもしれない。
私たちは組み込み系の開発経験がほとんど無く、 「電池の残量やモータの性能によって動作が異なる」 「外乱光や路面の状態が走行へ影響を与える」 など、当たり前のことが全て新しい経験となっていた。 難しいと思う反面、どうすれば解決できるかとトライアンドエラーを繰り返すことは非常に楽しかった。 チャンピオンシップでは芳しくない結果に終わってしまったが、今回で得た知識、経験、成功体験、失敗体験は今後に活かせると感じている。振り返ってみると、短い期間だったが実りの多い活動だった。
以上で東京地区大会編・チャンピオンシップ大会編と続いてきた ET ロボコン 2012 の新人チーム参戦レポートは終了です。 お楽しみいただけたでしょうか？ この記事を読み、「ET ロボコンに参加してみたい！」「アツいイベントということはよく分かった！」何かしら感じていただけたならば幸いです。
もうじき、ETロボコン2013の開催概要が発表される時期です。 さあ、あなたもETロボコンの世界に飛び込んでみませんか？
| ©2013 OGIS-RI Co., Ltd. |
|
