ロボクロス2013でのオーロラロボット車

こんにちは、Habr！
ロボクロス大会で講演した後、チームレポートを公開するのが伝統になりつつあります。
昨シーズンはNAMTおよびMobRobチームからの報告がありましたが、今、私たちのチームの仕事についてお話したいと思います。

ロボットをどのように作成したのか、なぜそのようにしたのかについてお話します。 他のチームのメンバーにとって興味深いものになるか、同様のトピックが好きになることを願っています。

私の名前はウラジミールです。私は大学院生で、リャザンのラジオ大学（AURORA）の自律ロボットチームのメンバーです。 私の主な関心は人工知能であり、チームワークの方向性はソフトウェア開発です。 チームは、私たちの大学の学生設計局（SKB）を代表しています。

職務内容

ロボクロス2013大会は、7月17日から20日まで、GAZ工場（ニジニノヴゴロド）のベレゾヴァヤova濫原モータートレーニンググラウンドで開催されました。 レースのために、「スポーツ」サークルのセクション、約100mの長さが割り当てられました。
タスクの本質：ロボット車は、遅い速度（約5-7 km / h）で人の後に自律的に移動し、ルートを記憶します。 次に（手動モードまたは自律モードで）展開し、オペレーターのコマンドで自律的に開始点に戻る必要があります。 同時に、帰り道で、裁判官は、前進するときに存在しなかったいくつかの障害物を道路に置きました（プラスチックの樽）。
タスクはラバの行動に似ています-彼を山に連れて行かせると、彼は道を見つけて群れに戻ります。 このタスクは、ELROB-2012（ヨーロッパのロボット車の競争）のタスクの1つとの類推によって行われました。
タスクを完了するときに、開始から終了まで移動するのにかかる時間と、取り除いた障害物の数を推定しました。 勝者は、完全に自律的な制御を備えたロボットのみです。
見かけの単純さにもかかわらず、タスクに対処したチームはわずかでした（フィニッシュラインに到達しました）。

機構と電子機器の説明

ロボットカーに取り組んでいる人は少数です。 約3-オーバーメカニックス、エレクトロニクス、トップレベルプログラミング。 明確な投稿はありません-誰もがいくつかの分野を理解できるはずです。 チームは、2か月間ロボットを作成し、日曜日でも作業を行い、21.00までにラボを離れました。

力学と電子機器は、ロボットの「筋肉」と「末梢神経系」です。

力学

力学は、車の制御を駆動するアクチュエータのセットです。 メカニックを開発する際の主な要件は、すべてをすばやく分解できるように簡単に取り外し可能な構造を作成し、マシンを通常のガゼルに変えることでした。
ガス/ブレーキ/クラッチペダルとギアセレクターを制御するアクチュエーターユニットは、運転席のシート下のマウントにあります。 つまり 運転席に座ることができます（ただし、足はあまり快適ではありません）。

ペダルブロック

ペダルを接続するには、特別なステープルレバーが使用され、ペダルに投げられます。
ステアリングホイールはモーターによって駆動され、チェーンを介してステアリングホイールカルダンに接続されています（私はそれを切断してギアを溶接しなければなりませんでしたが、これは数年前に行われたため、そのままにしておくことにしました）。

ここでは、モーターと同じシャフトの青いエンコーダーがチェーンによってステアリングカルダンに接続されています（フードの下）

点火回路には2つのモードがあります-キーで車を始動するとき（通常）、またはリレーと安全ボタンを介して接続すると、自律的に始動できます。 この切り替え方法については、支払い後、モードの切り替えを忘れてしまいます。制御が失われた場合、車を停止することはできません。 しかし、何も起こりませんでした。

エレクトロニクス

すべてのロボットプロジェクトでは、独自の電子機器を使用しています。 そして、それを開発します。これはゼロから呼び出されます。 Arduino、NI RIO、およびある種のモーターコントローラースレッド、またはそのようなものを購入すると、安くて速くなると思われます。 しかし、いくつかありますが。 何かを設定する方法、またはさらに良い方法を学ぶためには、すべてがどのように機能するかを知ることができるだけです。 システムを「感じる」と呼ばれるもの。 そして、これを行うには、自分でそれを繰り返し、何を、なぜ、どのように理解するのかを一歩ずつ試みることができます。 すでに開発の経験があり、数年にわたってこの分野の開発を続けてきました。 そして、最初のシーズンに既製のソリューションを使用してチームに遅れをとった場合、今では経験豊富な回路設計者、デバッグされたソリューションがあり、あらゆるニーズに完全に適応できます。

モーター制御ボード

エレクトロニクスと「低レベル」のソフトウェアは、当社のソリューションであるエンジン制御ボードによって完全に表されています。 各ボードのファームウェアは、特定のタスク（クラッチ/ブレーキまたはステアリング制御）に適合しています。 それぞれにおいて、対応するアルゴリズムは「縫い付けられます」。 絶対および相対エンコーダー、フィードバックスイッチ、エンジン回転数に関するフィードバック。

制御ボードは格納式スタンドに取り付けられており、ガゼルの運転席の下で簡単に清掃できます。

さらに、ボードには「ドライ接点」またはリレーが装備されており、プログラムでイグニッションまたは光/音信号をオンにし、他のアクチュエータをオンにします。

興味深い問題は、車が発進することです。これは、上り坂を運転するときに特に顕著です。 車が失速しないように、エンジン速度を監視し、クラッチ/アクセルペダルを操作する必要があります。 ドライバーはこれを直感的なレベルで行いますが、自動的に行うことは非常に困難です。

「低レベル」コントローラー（ARM7アーキテクチャーでLPC NXPコントローラーを使用）は、「高レベル」プログラム（i386 arch）から受信したコマンドに基づいてアクチュエーターを制御します。 通信インターフェース-RS232、通常のCOMポート。 制御コマンドは、一連のパラメーター{ステアリング角度、移動速度、ブレーキ、追加リレー}です。 コントローラーは、現在のエンジン速度と決定に必要なその他のパラメーターも「上位レベル」に送信します。

プログラムのアーキテクチャとアルゴリズムの説明

最後に、彼は直接作業した部分に移りました。
何年も前、それが始まったばかりの頃、すべての大学はチームのためにNIコントローラを購入しました。 当時、彼らには資金がなかったので、i386アーキテクチャでロボットの「頭脳」を作ることが決定されました。 通常のラップトップまたはデスクトップPC。 しかし、Linuxや組み込みLinux、および有名なOpenCV画像処理ライブラリなどの開発経験はほとんどありませんでした。 （私はNIを怒らせたくありません、RIOも最近登場しました-奇妙なことです）。

センサーセット

これらの競技に使用されるセンサーのセット：

• ステアリングホイールおよびプロペラシャフトエンコーダー（位置決め用）
• 耐候性IPカメラ（タグ検出用）
• SICKリニアレーザースキャナー（クロスカントリーマップの構築用）
• オリエンテーションボード（ジャイロスコープ+加速度計）（位置決め用）
• GPS受信機（測位用）

センサーは、RS232およびイーサネット経由でPCに接続されます。
感覚データを処理するために、ガゼル本体に通常のPCがインストールされています。 コンピューターは、体の下に外部に取り付けられたガソリンジェネレーターによって駆動されます（反対側のガスタンクと対称）。

使用するライブラリ

オペレーティングシステムとして、Ubuntuを使用し、開発環境はQtCreator、言語はC ++、guiのライブラリはQt、画像の取得と処理はOpenCV、レーザースキャナーのデータ処理はPCL、Boostはファイルとネットワークの操作用です。 その結果、クロスプラットフォームソリューションが実現します。 ただし、システムはより予測可能であるため、Ubuntuを引き続き使用しています。バックグラウンドでは、ウイルス対策またはファイルインデックス作成が誤って機能し始め、他のすべてのプロセスの速度が低下することはありません...はい、全体的なパフォーマンスはわずかに高くなっています

フォロータグ

競技のタスクには、2つの要素の実装が含まれます-マークに従うとルートに従う。 したがって、プログラムは2つの主要な動作モード-タスクの各要素ごとに提供されます。
マークをたどるモードでは、プログラムの一般的なアルゴリズムは非常に単純です。オペレーターがマークを削除するまで、マークの後ろに移動し、ウェイポイントを覚えておく必要があります。 移動中の舵の位置は、フレームの中心に対するマークの位置に比例します。
タグが失われた場合、ロボットはビープ音を発し、しばらくすると（0.5秒）減速し始めます。 これはセキュリティの目的で行われ、論理的には悪くないことがわかります-車が停止する必要がある場合、マークは削除されます（裏側で裏返されます）。
マークは、ポール上にあるサインです（安全のため）。 この色は自然界ではめったに見られないので、黒い輪郭のピンクの円を使用しました。

マークの背後にある移動アルゴリズムを確認する

いくつかのライブラリがラベルを検索しようとしましたが、その結果、独自のソリューションが実装されました-フォーム+色分析による検索。 これにより、標識と色が異なる交通標識やその他の丸いオブジェクトを拒否できます。

ラベル検索アルゴリズムのデモ

ルートの座標は、リスト{GPSポイント、方向（回転角度）、半径（ヒットすると、このポイントに到達したと見なされます）}によって記述されます。 移動が終了すると、ポイントが逆になり、ルートが保存されます。

出発点に戻る

停止ポイントで、オペレーターがマークを削除し、ロボットが停止します。 問題は、彼が何らかの形で向きを変えなければならないことです。 ロボットの向きを変える方法に関する競争の規則には制限がなかったので、手動の方法を選択しました-オペレーターが車を回すとき。 軌道計画アルゴリズムは、仮想的にUターンを計画できたかもしれませんが、その時点でより多くの必要な機能のデバッグに時間を費やすことにしました。
「バレルが左にある場合、ホイールが右にある、ターゲットが右にある場合、ホイールが右にある」などの「単純なアルゴリズム」をすぐに放棄しました。 私はそれを「牛のメソッド」と呼びます。 明らかに、2番目の樽の外観、または追加の条件では、牛の方法は実行できません。
自律移動アルゴリズムは、次の問題の順次解決策として表すことができます。

私はどこ

ロボットがどこに行くべきか、軌道をどのように修正すべきかを決定するために、ロボットはそれがどこにあるか、つまり 「どこにいるの？」という質問に答えてください この目的のために、GPSエラーは数十メートルであるため、GPS受信機からのデータのみを使用することはできません。建物やトンネル内の動きは言うまでもありません。 また、GPS受信機を使用してフィールドに立って座標を取得すると、しばらくして同じ場所に来たときに座標が大幅に異なります。 別の問題は、座標出力のレートが低いことです-1秒間に1から5回、これは5 km / hの速度でも車を制御するのに十分ではありません-システムは状況に反応する時間がなく、ロボットは酔っ払ったドライバーのように動きますオーバーシュートが発生します。

この状況から抜け出す方法は、異なる物理現象に基づいて、性質の異なる複数のセンサーを使用することです。 ロボットでは、GPSに加えて、ホイールエンコーダーを使用します。ドライブシャフトのスクロール量とステアリングホイールの向きに基づいて、車の直線速度と角速度を決定します。 ジャイロスコープ、加速度計、および磁気コンパスに基づくオリエンテーションチャネルも、追加のチャネルとして使用されます。
各センサーの情報出力速度は異なります（たとえば、エンコーダー-70 Hz、オリエンテーションボード-10 Hz）。 また、エラーの性質が異なることも特徴です。 ホイールのサイズと車のホイールベースの長さを決定するのは不正確であるため、エンコーダーのみに基づくナビゲーションでは、時間の経過に伴う誤差の蓄積が特徴的です。 ジャイロスコープは、車体の熱ドリフトと振動の影響を受けます。 コンパスは大きな金属物体（橋、アーチなど）にそれぞれ強く反応するため、各センサーを別々に使用することもできません。
さまざまなセンサーの読み取り値を組み合わせるには、さまざまな手法が使用されます。さまざまな非線形カルマンフィルター-無香料カルマンフィルターの使用を選択しました。 指では、操作の原理は次のように説明できます-車の動きのモデルに基づいて（テレポートまたは横に移動することはできません）、各センサーの測定値が予測されます。 次に、予測値が実際の（測定された）センサーおよび各センサーと比較され、真実を示す確率に従って、その重みが付けられます（予測に近づくほど、信頼度が高くなります）。 受信した重量に基づいて、車両の現在の位置と方向の評価が形成されます。

もちろん、D-GPSを使用するとタスクが簡単になりますが、月額料金が必要です。購入して忘れることはできません（消耗品の支払いは非常に問題があります）。
それでも、得られた位置推定値は制御に受け入れられます-座標に顕著なジャンプはないため、軌道に沿ったモーションコントローラーは予測どおりに動作します。

どこへ行く？

ロボットの位置がわかっている場合、ターゲットポイントがロボットに対してどこにあるかを判断できます。 この段階での問題は、前述のように、GPSが遅いドリフトの影響を受けやすいことです。日中は座標が「浮動」します。 これは、大気、雲、雲の不均一性によって説明できます。これらはすべて、信号の通過時間に影響します。
次のように表示されます。

GPSドリフト

ロボットがピボットポイントで待機している間、その現在の位置は横に「浮き」始めます。 つまり GPSだけで田舎道を移動するように開始すると、元の軌道に対して特定のオフセットで移動しますが、センサーは通常の移動を示します-すべての座標がシフトしたことはわかりません。 これは、ロボットが道路の脇に沿って（まあ、クリスマスツリーまたはコンクリートブロックに沿って）運転するという事実につながります。 だから、もちろん、ダメです。

この問題の解決策は、軌道を計画するときに道路位置データを使用することです。 このデータを2次元画像（クロスカントリーマップ）の形式で提示すると便利です。 実際、これは写真です-車が中央にあり、通行可能エリアが1つの色（緑）でマークされ、別の色（白）で通行できない平面図です。

図-スタジアムでのテストレース中の開通性の実際のマップ。

競争条件には、コンクリートブロックと高い植生で囲まれた道路-茂みや木が含まれます。 そのため、障害物に関する情報を取得するためにリニアレーザースキャナーのみを使用することが決定されました。これを車のバンパーに固定しました（最初の写真を参照）。

レーザースキャナーの動作原理はレーザーレンジファインダーに似ています。より複雑な光学システムのみが連続的に回転し、0.5度の角度分解能で180度の視野角を提供し、2 cmの測定精度で最大範囲80メートルを提供します。 これらのパラメーターはこれらの競技会に十分であり、特定の高さに設置することで、トラック上のすべての障害物と道路の輪郭を見ることができました。
スキャナーは一連の範囲を返し、その後、単一の攻撃（草またはノイズのみ）からフィルター処理され、角度幅が少なくとも2度の障害物が残ります。 次に、配列は、中心を基準とした極座標で開通性マップ上に描画されます。 各更新の前に、開通性マップは通過できない色で塗りつぶされ、通過可能なセクションのみが描画されます。 これにより、（コンクリートブロックまたはフェンスの影の）スキャナーの範囲外のポイントを選択する誘惑からターゲットポイントを選択する誘惑がなくなります。 これが発生した場合、目標点に到達できないため、軌道計画アルゴリズムはそれを構築できません。
また、レーザースキャナーが体にしっかりと取り付けられていることも重要です。 その結果、透磁率マップはローカル座標で構築されます。 空間内の道路の位置を間違えることはありません。

したがって、開通性のマップ、ロボットの現在の位置、取得する必要のあるルートの現在のポイントがあります。 ここで、ターゲットポイント選択アルゴリズムが役立ちます。 このデータを組み合わせて、車の到達が保証される有効な（正しい）ターゲットポイントを取得します。
その動作の原理は非常に単純です-クロスカントリーマップ上の理想的なターゲットの横にある多くのポイントのランダムな選択。 次に、ターゲットに最も近いポイントが選択されます。 車の幾何学的な寸法も考慮されます-選択されたエリアでの動きが安全になるように、ポイントの周りに空きスペースが必要です。 元のターゲットがクロスカントリーマップの次元を超える場合、半径に沿ったポイントは距離Rmax（この場合、マップの次元は40 * 40メートル、Rmax = 15m）だけシフトするため、マップ上に存在し、その後のみ検索が実行されます。

マップの開通性の概略図。 白い四角は通行不可能なエリアを象徴しています

どうやって行くの？

現時点では、制御タスクは、開通性マップの中心からターゲットポイントに到達する必要があるという事実に帰着します。 繰り返しますが、問題は、従来の最短パス検索アルゴリズム（A *など）がここでは機能しないことです。 なんで？

第一に、ロボットカーが移動する空間は連続的です。 座標（x、y）は実数です。 古典的なアルゴリズムは、離散状態空間用に設計されています。 ここでは、一連の遷移は無限であり、それらをソートすることは不可能です。

第二に、車は非ホロノミックシステムです。 これは、車が空間内でその位置または向きを即座に変更できないことを意味します。 さらに、彼の次の位置は、前の位置と非常に「厳密に」結びついています。速度の微分係数の制限、即座に停止したり方向を変えられないことです。 そのため、離散アルゴリズムを使用して最短パスを構築した場合（たとえば、座標を整数に丸める）でも、そのような軌道に沿って通過することはできません。

このすべてから、ブルートフォースによって最短パスを取得することは不可能です。 この場合、「最適に近い」軌道についてのみ話すことができます。 そのような軌道は最短ではありません。 軌道の終点にあるロボットが必要な向きを持っていること（ロボットが道路に垂直な中間の頂点に到達した場合、ロボットがうまく終了しないことが重要です）。 （バックグラウンドでは、ロボットができるだけループしないことが重要です）。

異なる方法で同じポイントに到着できます。

連続状態空間でパスを検索するには、さまざまなアルゴリズムが使用されます。 最も人気のあるもののいくつかは、Rapidly Exploring Random Tree（RRT）の種類です。 RRTが実行されている場合、考えられるすべての状態は列挙されません。 代わりに、状態の（一般的な場合）空間全体が均一に分布した頂点で覆われ、その後、決定木を構築するための参照頂点として使用されます。
しかし、RRTは純粋な形では、運動制限を考慮していないため、自動車の軌道の計画には適していません。 そのため、私たちの研究では、桑田、Y、その他によって提案されたアルゴリズムを使用しました[1]。
一般的な考え方は、RRTと同じです。 車両のルート上で、N個の中間状態がランダムに選択されます。

黒丸は中間状態を示します。 赤い丸-その中の車の目的と方向

次に、初期頂点から軌跡の木が構築されます。 車の動きのモデルを考慮して、隣接ポイントの到達可能性をチェックするプロセスが変更されます。


軌道計画アルゴリズムのデモ。 ターゲットの向きに応じて、結果の軌道は異なります。

反復の制限を使い果たした場合（アルゴリズムはリアルタイムで動作する時間が必要です-マシンが動いています！）、または目標に到達したブランチの数がしきい値Mを超える場合、利用可能なもののセットから最短パスが選択されます。
結果として得られる軌道は、一連のDubinsパス-車の特定の最小旋回半径のセグメントと円弧のセットです。 このタイプの軌道は、特に車の動きを表すために開発されたものであり、初期および最終の方向を考慮して、ポイント（x、y、theta）から（x '、y'、theta '）への移動の最短経路です。

Dyubinsパスの例

このアルゴリズムの実装の難しさは、メソッド自体が計算コストがかかるという事実にあります（実際、それはバストです）。 作業を真剣に最適化する必要がありました。 変化する交通状況に対応するために、軌道を定期的に更新する必要があります。 中間のピークが存在するため、車の操作は非常に複雑でした（良い意味で）。
軌道は、実行用にモーションコントローラーに送信されます。モーションコントローラーは、ステアリングホイールと速度を制御します。 コントローラーアルゴリズムは、[1]で提案されているものと同様に採用されます。

また、このアルゴリズムは「一般的な場合の計画アルゴリズム」であることに注意してください。 つまり 道路や障害物の形状に関する先験的な情報がわからない場合（駐車場、ガレージ、交通渋滞の動き） 計算は複雑ですが、複雑な軌道を生成できます。 高速道路で運転する場合、複雑な操縦は望ましくなく、最適ではなく、危険ですらあります。 したがって、道路の流れでのみ運転する場合の計画に焦点を当てた「軽量」交通計画者がいます（まだ実装していません）。

高速道路交通計画

プログラムモードの切り替え

プログラムモードを切り替える方法については、事前に考えていませんでした。 私は急いでGozelに数字の入った小さなキーボードブロックを固定する必要がありました（私たちはロボットと呼びます）-数字の正しい組み合わせがロボットが次に何をするかを決定しました：

プログラムモードを切り替えるキーボード（jar内）。 オペレーターへのメモの近く-忘れないように

一般に、モードを選択すると、あまり便利ではないことがわかりました。 Gozelを展開するには、ペダルをリリースする必要があったため、このために、プログラムは「放す」必要があります。 その結果、キーボードで多くの中間コマンドを入力する必要がありました。 神経質な環境では、それらは簡単に混同されます。 また、両方向の自律走行よりも車の反転に時間がかかったことにも興味があります。

一般的なアーキテクチャ

上記のアルゴリズムに基づいて、プログラムコンポーネントの次の相互作用スキームをコンパイルできます。

デバッグ

デバッグは、特にロボットカーを制御するソフトウェアに関しては、あらゆるソフトウェア製品の開発において最も重要な段階です。 しかし、ここにはいくつかの困難があります。
エラーの代償は、損傷した車またはインフラです。 チームメンバーへの危険は言うまでもありません。 バグはここでは高価です。
また、テストのコストも重要な問題です。 何かがうまくいかない場合に破損する可能性のあるオブジェクトから離れた、人里離れた場所でシステム全体の動作をデバッグすることが望ましいです。 これを行うには、そこに車を届ける必要があります。 けん引サービスの支払いは何によっても補償されません。

そのため、アルゴリズムの全体的な動作とタスクのロジックを確認できるシミュレータを作成しました。 グラフィックエンジンとしてIrrlichtを使用し、物理的に-BulletPhysics。 ロボットのソフトウェアはクライアントとサーバーの相互作用であり、サーバーはアルゴリズム（クライアント）とロボットのハードウェア（センサー、アクチュエータ）間のソフトウェアインターフェイスです。 シミュレーターから実際のロボットに切り替えるには、クライアントで異なるIPアドレスを指定する必要があることが判明しました-非常に便利です-コードの変更はありません。

シミュレーター

シミュレーターにより、すべてのセンサー（エンコーダー、GPS、SICK）の信号をシミュレートできるようになったため、ほとんどの場合、デバッグはシミュレーターで行われました。
しかし、シミュレーターはシミュレーターであり、ロボットは現実の世界に乗る必要があり、原則としてモデルとは異なります。したがって、実際にはすべてを確認する必要があります。
競技が文字通り実行される前の最初の（そして唯一の）フィールドテスト-フィールドで。

モーターの過熱

アルゴリズムの最も「上」の部分はうまく機能しましたが、「低」レベルはあまり良くありませんでした-ステアリングホイールとペダルコントロール（論理的）の係数を再構成する必要がありました。一日の終わりには、許容できる結果を達成しました。すべてうまくいったようです。


競技と最終レースの小さなプレビュー

結論と結論

Robocross 2013大会で、私たちのチームが1位になりました。私たちはすべての樽を回り、安全にスタートエリアに戻りました。
それ自体を示唆する結論-ロボットカー-は複雑なシステムです。各コンポーネントの作成は、特にわが国では開発者が受け入れ、克服しなければならない課題です。当然のことながら、このようなデバイスの作成は単独では不可能なので、チームに感謝の意を表したいと思います。
私は電子機器の開発における問題を詳細に説明しませんでしたが、ソフトウェアよりもさらに多くの問題がありました。

問題は、次は何ですか？進化する。システムはかなり全体的なビューです。各コンポーネントを改善すると、ロボット全体の作業の品質が向上します。トラフィックルールロジックの追加は、ローカルターゲット選択アルゴリズムにのみ影響します。世界の自動運転車業界のもう1つの傾向は、使用するセンサーのコストを最小限に抑えることです。高価なレーザースキャナーを使用せず、より安価なテクニカルビジョンシステムに焦点を当てています。この方向に移動する必要があります。

クラシックカーには、前輪にスイベルホイールが付いているため、人が運転しやすいです。そして、すべての車輪を回転式にするとどうなりますか？これにより、速度を落とすことなく、並列駐車から列ごとの再配置まで、より複雑な操作を実行できます。そのような制御を持つ人が対処する可能性は低いですが、ロボットはできる：

ロボット「マラカイカ」。開発中 ここで

は、他のプロジェクトとラボロボットを表示できます。

psこの資料の目的は、志を同じくする人々を検索することでもあります。私たちは、ロボット車両用のオープンソースソフトウェアプロジェクトを開始しています。このトピックに興味がある場合は、開発の経験がある（または他のチームのメンバーである）私に手紙を書いてください- 。

ソース

1.桑田佳明、ガストンA.フィロレら、「RRTを使用した都市運転の運動計画」、2008 IEEE RSJインテリジェントロボットとシステムに関する国際会議、2008年9月。