概要
SAE AutoDriveチャレンジは、米国とカナダから4チームが参加する8年間の大学デザインコンペティションです。 このコンテストの3年目の高レベルの技術目標は、SAEレベル4で説明されているように、自動運転モードで都市の運転コースをナビゲートすることです。
MathWorksは、シミュレーションを使用するようにチームに要求します
シミュレーションは、自動運転車の開発に非常に役立つツールです。 モデルベースのテストは、アルゴリズム開発、ユニットおよびシステムレベルのテスト、およびエッジケースシナリオのテストに役立ちます。 現実の世界 センサー データを記録してシステムに再生し、融合アルゴリズムを調整することができます。 シミュレーション環境を作成して実際の環境をモデル化し、さまざまなアルゴリズムやセンサーの位置をテストするために使用できます。 チームの要件を満たす最適なアルゴリズムとセンサーの位置は、パフォーマンスの結果に基づいて選択できます。
毎年、MathWorksは、シミュレーションチャレンジを介してシミュレーションを使用するようにチームにチャレンジします。 このブログでは、1チャレンジの2位と2020位の受賞者（トロント大学とケタリング大学）、システム設計、および全体的な競争目標の達成に役立つMathWorksツールの使用方法について簡単に説明します。 チームは、ツールを使用して実行した方法に基づいて判断されました。
- 開ループ知覚テスト–開ループテスト用のデータを合成し、アルゴリズムの正当性を評価します
- 閉ループ制御テスト–閉ループシナリオの合成、制御アルゴリズムのパフォーマンスの評価
- 制御アルゴリズムのコード生成–アルゴリズムのコードを生成し、生成されたコードを車両に統合します
- MathWorks ツールを使用したイノベーション – テクニック/テクノロジー 上記の3つのカテゴリとは明らかに異なります
トロント大学
トロント大学、aUTorontoの学生チームがチャレンジで1位を獲得しました。
開ループ知覚テスト
このチームの最初のステップは、開ループ知覚テスト用のデータを合成することでした。 彼らは、センサーフュージョンアルゴリズムをテストすることを選択しました。 テスト用の合成データを合成するために、彼らは（DSD）を使用しました。 このアプリを使用すると、自動運転をテストするための合成運転シナリオを設計できます。 チームは、図3に示すように構成されたセンサー融合アルゴリズムでレーダーと1台のカメラを使用しました。
図1：チームセンサーの場所（©aUToronto）
彼らは、センサーデータを合成してセンサー融合アルゴリズムにフィードするために、DSDアプリでカメラセンサーをその位置、向き、構成とともにモデル化しました。 DSDは、チームの画像処理とコンピュータービジョンアルゴリズムの後にカメラ出力をシミュレートし、データにノイズと外れ値を追加します。
シナリオリーダーブロックは、DSDを使用して作成されたシナリオ情報を読み取るために使用されました。 アクターのポーズは、複数の検出ジェネレーターへの入力として送信されました。 次に、これらのさまざまなセンサーの検出は、可変サイズのROS（Robot Operating System）メッセージアレイとしてパッケージ化され、カスタムROSメッセージとして特定のROSトピックに送信されました（図2）。
図2：開ループテスト用のSimulinkモデル（©aUToronto）
チームは、オブジェクトトラッカーからの出力を車両のグラウンドトゥルース値と比較しました。 パフォーマンス評価には、RMSE（二乗平均平方根誤差）メトリックが使用されました。
閉ループ制御テスト
チームの主な焦点は、建設ゾーンの再ルーティングや障害物の回避などの新機能について、変更されたプランナーをテストすることでした。 プランナーは、必要に応じてオブジェクトの周囲のパスを見つけるためにエッジがマップから削除される格子構造を使用するように再設計されました（図3）。 DSDは、シナリオの作成に再び使用されました。 バリアと信号機もシナリオに追加されました。
図3：パスファインディングの格子構造（©aUToronto）
チームは、Stateflowを使用して信号機パブリッシャーをモデル化しました（図4）。 エゴビークルが信号の範囲外（> 50m）にある場合、不明な状態が公開されます。 エゴが範囲内に入ると、赤信号のメッセージが表示されます。 エゴが5秒間停止すると、メッセージが緑色に切り替わります。
図4：モデルコントローラーへのStateflow（©aUToronto）
コントローラー、プランナー、および車両モデルのROSノードが起動されました。 障害物が自我車両から50m以内にある場合、その位置はROSメッセージとしてSimulinkモデルに送信されました（図5）。
図5：位置メッセージを送信するロジック（©aUToronto）
制御アルゴリズムのコード生成
チームは一時停止標識処理アルゴリズムのコードを生成しました (図 6)。 Simulink Coder を使用して、Stateflow を C++ コードに変換しました。 スタンドアロン モジュール コードパッケージ化機能を使用して生成されました。 生成されたモジュールはチームのコードベースにマージされました。
図6：信号制御ロジックの停止Stateflow（©aUToronto）
MathWorksツールを使用したイノベーション–Lidarカメラのキャリブレーション
LIDARとカメラセンサーからの入力を使用してシーン内のオブジェクトを正確に解釈するには、センサー出力を融合する必要があります。 したがって、チームはLidarとチームカメラの間で変換を実行して、Lidarポイントを画像に投影したり、センサーフュージョンのためにその逆を行ったりしました。 チームは、投影が良好に見えるまで手動測定と回転カメラを使用する代わりに、Lidar処理ツールボックスから新しく開発されたLidarカメラキャリブレーションツールを使用しました。 このツールは、3D LIDAR平面の点と画像平面のピクセルの間の対応を確立する、剛体変換行列を推定します。
現在のキャリブレーションボードはツールには小さすぎるため、彼らはより大きなキャリブレーションボードを作成しました。 カメラキャリブレーションツールを使用して、カメラの固有マトリックスを取得しました。 チェッカーボードの角は、各画像とLidarデータで見つかりました。 Lidarとカメラの間の剛体変換行列が見つかりました。 このプロセスは、点群データを画像に投影するため、またはその逆に使用できる変換を出力します。 これらの手順を図7に示します。
図7：（a）カメラ固有のマトリックス（b）チェッカーボードのコーナー（c）LIDARからカメラへの変換マトリックス（©aUToronto）
ケタリング大学
学生チーム ケタリング大学から、チャレンジで2位を獲得しました。
開ループ知覚テスト
チームはUnrealEngineを使用してさまざまなシナリオを作成しました。 シミュレーション3Dカメラブロックを使用して、Unrealのエゴビークルにカメラが追加されました。 Simulinkモデルを使用して、非現実的な画像を使用して車線検出を実行しました（図8）。 青い四角は車線検出機能を示し、黄色は各ステップでの出力を示します。 これらの出力図を図9に示します。
図8：開ループテスト用のSimulinkモデル（©Kettering University）
図9：レーン検出出力（©Kettering University）
閉ループ制御テスト
チームのシステム設計は、縦方向と横方向の2つのステートマシンで構成されていました。 図に示すこれらのステートマシンは、センサーと意思決定データに基づいてコントローラー選択のロジックをモデル化するために使用されました。 それらは相互にリンクされ、コントローラーサブシステムを有効化および初期化するために使用されました。
図10：ステートマシン（©Kettering University）
すべてのチームコントローラーの動作を検証するために、図11のSimulinkモデルと組み合わせたコントローラーシミュレーションが実行されました。 これらのコントローラーへの入力は、スライダーとゲージを使用して提供されました。
図11：閉ループテスト用のSimulinkモデル（©Kettering University）
縦方向ステートマシンのコントローラーサブシステムには、縦方向速度コントローラーと自動緊急ブレーキ（AEB）が含まれます。 状態は、加速、巡航、減速、停止、駐車などの縦方向の車両ダイナミクスによって決定されました。
ラテラルステートマシンのコントローラーサブシステムには、レーンキープアシスト（LKA）、レーンチェンジ、ターンコントローラーが含まれます。 状態は、横方向のビークルダイナミクスに基づいて決定されました（図12）。 縦方向の速度、車線変更、およびLKAコントローラーについて以下で説明します。
図12：横方向のコントローラーの状態（©Kettering University）
縦方向コントローラー
図13は、縦方向コントローラーのモデル化に使用されるSimulinkモデルを示しています。 これは、速度に基づくPIDで構成されていました。 基準トルク率と出力トルク率は、競争の加速とジャークの制限内にとどまるように制限されていました。 システム入力はスライダーで初期化および編集され、スコープを使用してデータが表示されました。 図14は、目標および実際の縦方向速度出力を示しています。
図13：縦方向コントローラーのSimulinkモデル（©Kettering University）
図14：縦方向の速度比較（©Kettering University）
車線変更コントローラー
チームのレーンチェンジコントローラーは、アダプティブMPC（モデル予測制御）を使用しました。 参照パスは、車速や車線幅などの車線変更入力を使用して、パラメトリック関数を使用して生成されました。 コントローラへの出力は、基準横位置とヨーでした。 3DOF（Degree of Freedom）モデルを使用して、車体をシミュレートしました。 図15は、シミュレーションに使用されたSimulinkモデルを示しています。 図16は、車内テスト後に得られたパスとともに、参照パスとシミュレーションされた車線変更パスを使用したシミュレーションの出力を示しています。
図15：車線変更コントローラーのSimulinkモデル（©Kettering University）
図16：車線変更パスの比較（©Kettering University）
車両モデル
チームは、3DOFシングルおよびデュアルトラック車両モデルを開発および検証しました。 最初の検証は、線形自転車モデルを使用して実行されました。 最終検証は、物理テストデータを使用して実行されました。 図は、テストデータを使用した場合と使用しない場合の、初期検証と最終検証を使用した横加速度の比較出力を示しています。
図17：（a）横加速度の比較（b）テストデータとの比較（©Kettering University）
MathWorksツールを使用したイノベーション–非現実的な都市
チームは、すべてのコントローラーの閉ループテストにUnrealを使用しました。 彼らは、制御可能な歩行者の動きと信号機を備えた非現実的な都市を作成しました。 カスタマイズ可能なアクターが作成され、アクター名、アクタータイプ、アクターの詳細、アニメーションの詳細、タグなどの情報が保存され、すばやくアクセスできるようになりました。 図18というラベルの付いたライトの場所とともに、信号機のマップも作成されました。
図18：非現実的な信号機の地図（©Kettering University）
図19は、Simulink-Unrealシステムの通信構造を示しています。 車両の位置、歩行者の動き、信号機の状態などで構成されるUnrealシーンの意思決定は、Stateflowを使用して行われ、コントローラーへの入力として送信されました（図20）。
図19：Simulink Unrealシステムの通信構造（©Kettering University）
図20：非現実的なシーンの意思決定のためのステートフロー（©Kettering University）
結論として、トロント大学とケタリング大学の学生チームは、MATLABとSimulinkを活用して、融合、追跡、ナビゲーションアルゴリズムを設計、構築、テスト、評価し、SAEレベル4自動運転車の構築に一歩近づくことができました。シミュレーション。 彼らは、さまざまなシミュレーション環境で信号機と複数のアクターを使用して複雑なシナリオを作成し、環境をSimulinkと統合し、これらのシナリオで選択したアルゴリズムを展開してテストしました。 開ループおよび閉ループの知覚アルゴリズムは、Simulinkを使用してモデル化およびテストされ、これらのシステム用にコードが生成されました。 チームはまた、SimulinkとStateflowを使用してさまざまなコントローラーアルゴリズムを設計およびテストしました。 MathWorksツールは、これらのチャンピオンシップチームの両方で革新的かつ広範囲に使用されました。