こんにちは、ティアフォーでオープンソースの自動運転システム「Autoware」の開発をしている斉藤です。現在は主にAutowareのアーキテクチャ・設計を担当しています。
ブログ「スケーラブルな自動運転システム開発プラットフォームのためのリポジトリ構成」で、スケーラブルな自動運転システム開発プラットフォームのためのリポジトリ構成について説明がありました。
Autowareではスケーラブルなプラットフォームを目指しているため以下のような様々な要求があり、これらの要求に答えられる設計を目指して日々改善を重ねています。
今回は、Autowareを実際に動かすための手順と設計や考え方についてお話します。
現在、すべての要求を満たせる自動運転アーキテクチャの決定版はなく、技術レベルやトレードオフを考慮して今後も変わっていく可能性がある点にご留意ください。
まずは、Autowareをインストールして動かしてみることが理解につながる近道だと思うので紹介していきます。Autowareのインストール方法に関してはこちらのドキュメントにて管理されています。
現在サポートされている動作環境は以下のとおりです。
Sourceビルドから利用する方法とDockerを利用する方法の2パターン有りますが、今回Sourceからビルドする方法を動画（0:00~4:40）にしてたので、ぜひこちらを参考にしてみてください。
現在のAutowareでは使う機能にもよりますが、フルの機能を使う場合は、最低でも以下のスペックが必要になります。
Autowareの起動構成として処理負荷の重い（主に機械学習ベースの認識系の技術）を使わない場合、より低スペックで動作すると思います。
私の感覚になりますが、Autowareを動作させるに支障がないスペックとしては以下のようになります。
良くあるビルド時のつまりポイントを紹介します。
最新のトラブルシューティングのドキュメントはこちらを参照してください。
ビルド時にいくつかのパッケージのメモリ消費が大きく、メモリが足りないことが有ります（CPUコアによるビルド並列度にも依存）。もしメモリが足りない場合は、swap領域を増やすか、ビルドの並列度を下げる必要が有ります。ビルドの並列度を制限したコマンドのサンプルを示しておきます。
MAKEFLAGS=-j1 colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release --parallel-workers 1 # MAKEFLAGSはパッケージ内の並列数、parallel-workersはパッケージの並列数
Autowareを開発しているとパッケージの依存のエラーが出ることが有ります。原因は様々ですが、大きくは2つです。
1つ目は、ブログ「スケーラブルな自動運転システム開発プラットフォームのためのリポジトリ構成」でも説明があったとおり、リポジトリが分割されているためリポジトリ間のバージョン・更新がズレていることが有ります。
2つ目は、新たな外部パッケージへの依存が発生し、インストールされていないことです。
いずれもこちらのHow to update a workspaceを参考にしていただければ解決すると思われます。
チュートリアルのドキュメントはこちらになります。
Autowareのチュートリアルには以下の2種類がありますが、Ad hoc simulationから利用することをおすすめします。Scenario simulationは予め定義されたパターンをテストするものであり主にCI等で使われています。
Ad hoc simulationの中にはRosbag replay simulation、Planning simulation、Digital Twin simulationの3種類があります。詳しくは次の「Autowareの各コンポーネントの説明」の章で説明をしますが、Autowareの機能は大きく以下の5つに分かれており、テストの目的や範囲に応じてよって使い分けます。
Rosbag replay simulationでは実機を使って走行した際に、取得したセンサー・車両データを再生してテストします。
センサー・車両データを一方的に流すテストになっているため、PlanningやControlを含んだClosed Loopなテストはできません。
ただし、実データを使った検証ができるため、実験中に起きた問題を解析・修正する場合に重宝します。
How to 動画（10:00~）
Planning simulationでは主にPlanningのテストにフォーカスしPlanningに必要なinputを模擬して動作させます。模擬するものとしてはPerception、Localization、Vehicle Interfaceになります。
ノートパソコン程度のスペックで動作させることができ、Planningの挙動を確かめるときに頻繁に利用します。
障害物を召喚させたり日々いろいろな機能が拡張されています。
How to 動画（4:48~）
Digital Twin simulationは現実に近い仮想環境の中でシミュレーションを行います。Rosbag replay simulationやPlanning simulationでは不可能だった「全体を結合したテスト」や「実機のコンピューティングリソースに関する解析」が可能になります。
Digital twin simulationの実装例としてはAWSIMががあり、Unityをベースとしています。
AWSIMはROSCon2022でOSS化されたばかりなので、これからドキュメントの更新が入る可能性が高く、最新の情報を見てもらう方が良いと思います。
利用しやすいようにバイナリファイルでの提供も行っているので特別な環境構築は不要です。
紹介動画
会社で使う場合はネットワークのドメインの設定をしないと、ドメインが被ってしまいトピックやサービスが同一ネットワーク内で衝突してしまいます。
こちらを参照しながら必要に応じて環境を設定してください。
AutowareにはSensing、Map、Localization、Perception、Planning、Control、Vehicle Interfaceといった計7つのコンポーネントから構成されています。
Architecture overview - Autoware Documentation
自前のコンポーネントを利用したいというときに、一部のコンポーネントを差し替えができるように、各コンポーネントのインターフェース *1 が定義されています。これらのインターフェース定義はAutowareのGitHub Discussionsで話し合われています。
各コンポーネントの役割と自動運転走行に必要なインターフェース *2 について解説していきます。
Autowareで利用する点群地図とVector地図(Lanelet2 *3)を管理し、地図の配信機能や共通処理を行う
センサーデータ・マップ情報・車両情報を統合してマップ上の位置や現在の車速といった自車両の情報を推定する
Sensingされたデータをもとに周囲の環境を認識する
与えられた目的地もしくはルートに対して自車が走るべき軌跡を生成
Planningの結果の軌跡に対して誤差を極力小さくするように操作量を決める
車両の個体差および制御インターフェースの差を吸収し、車両に対して操作指示をする
本記事では、Autowareを実際に動かすための手順と設計や考え方について紹介しました。
今後は各コンポーネントの説明についても解説をしていこうと考えています。
*1 今後、技術動向によってもインターフェースの変更が入る可能性があります。
*2 現在外部サービスと連携するためのAPIの策定が行われており、外部サービス用・安全診断・故障判断系のインターフェースについては載せていません。
*3 ティアフォーテックブログ：Lanelet2に関する過去ブログ :自動運転の地図、ベクターマップについて
*4 こちらで検討中。
*5 こちらで位置情報、速度情報、加速度情報に関しては結合・分離について検討中。
*6 Outputが満たされればよく、Input情報を全て必要としているわけではありません。
オープンソースのソフトウェアを一緒に開発していきませんか？
ティアフォーでは、「自動運転の民主化」というビジョンに共感を持ち、自らそれを実現する意欲に満ち溢れた新しい仲間を募集しています。
Media Contact
pr@tier4.jp
Share the post
LinkedIn | X | Facebook | Instagram