ティアフォーPlanning/Controlチームの太田慧です。ティアフォーの事業拡大に伴い、私たちが開発する自動運転用オープンソースソフトウェア（OSS）である「Autoware」は様々な車種の車両にインテグレーションされ、日本各地で走行を始めています。ティアフォーでは無人自動運転移動サービスの実現および普及を目的とするプロジェクトに注力しており、Planning/Controlチームは市街地で走行する上で必要な機能の開発を行っています。
今回のブログでは、その中から障害物回避機能に焦点を当て、機能の概要や評価体制などを紹介します。
まず、「Autoware」のPlanning Componentの概要を説明します。
Planning Componentの役割は、PerceptionやLocalizationなど、他のComponentから得られた様々な情報の統合と、車両が追従すべき経路の出力になります。現状のインターフェースでは、Planning Componentの主な入力と出力は以下の通りです。
入力
出力
現在OSSで公開している「Autoware」のPlanning Componentのアーキテクチャはmission層とbehavior層、motion層の3層に分かれています。各層で処理した結果を後段の層に渡すことで、直列で動作しています。
mission層はカーナビのような役割を果たしており、現在の位置と目的地をもとに車両が走行すべきルートを決定します。「Autoware」は、目的地を外部から設定するためのAPIの提供も行っており、クラウド技術を活用し開発運用に最適化したプラットフォームである「Web.Auto」が提供するサービスの一つであるFleet Management System（FMS） から遠隔で目的地の設定も可能です。このレイヤーで扱うのは「どの車線を走行するか」や「どこで左折するか」程度の大まかな情報であり、これをもとにbehavior層でより詳細な車両の挙動を決定します。
交通規則を守り、市街地を安全に走行するために必要な役割を担うのがbehavior層です。
behavior層ではmission層で計画したルート情報をもとに、交通規則に則って走行するために必要な判断と計画を行い、以下の情報を出力します。
最もシンプルなユースケースである車線追従の場合、「車両が追従すべき経路」はルートに含まれる車線中央線に沿うように計画され、「経路上の各点における上限速度」はその車線の法定速度、「走行可能な領域」は車線の内部になります。決められた車線を走行するだけであれば、これだけで十分ですが、公道では赤信号で停止したり、右折のために車線変更をする必要があったりと、様々なユースケースに対応する必要があります。
現在の「Autoware」のアーキテクチャでは、behavior層に各ユースケースに対応するほとんどの機能が実装されており、Planning Componentの中で最も大きなレイヤーになっています。すでに20以上経路や車速を計画する機能が存在し、障害物の回避を行うモジュールもこのレイヤーに含まれます。
ℹ️ behavior層の各機能はユーザーの要求に合わせて設定ファイルから簡単にONとOFFを切り替えることができ、高性能なロボットタクシーからシンプルな搬送ロボットまで、幅広い用途に適応可能な仕組みになっています。
motion層の役割は、車両の運動学（キネマティクス）や動力学（ダイナミクス）を考慮した上で、できる限りbehavior層の指示に従う経路を計画することです。behaivor層とmotion層の出力する経路の形状がほとんど一致する場合もありますが、大型車両の経路計画では、右左折の際に車両が走行している車線からはみ出さないように少し内回りに経路を修正する処理を行います。また、behavior層の段階では経路上の各点の上限速度が与えらましたが、motion層ではその上限速度内で車両が快適かつ安全に走行できる車速プロファイル（経路上の各点の目標車速）の計画も行います。
「Autoware」がサポートする各機能の詳細については「Detailed design」を参照ください。
「Autoware」は自動運転に必要な障害物停止や前方車追従、車線変更といった機能をそれぞれ1つのモジュールとして完結する形で実装しています。そのため、ほとんどのモジュールが「判断」を行う部分とその結果に基づき「計画」を行う部分で構成されています。障害物回避を担う機能も同様の構成となっており、以下に「判断」と「計画」に分けてその概要を説明します。
障害物を回避する上で必要になるのは、「どの物体が回避すべき障害物なのか」の判断です。市街地を運転していて路駐車両に遭遇した際、ウィンカーを出しハンドルを切って路駐車両を回避しようとするでしょう。また、路駐車両でなくても、隣車線で信号待ちをしている大型車両や、道路脇の歩行者などの回避が必要な場面は多くあります。その一方で、同一車線上の前方車両が信号待ちをしている場面では、その後方で停止することが期待され、前方車両を回避することは基本的にありません。違和感の無い自動走行を実現するには、このような判断を正確に行う必要があります。
⚠️ せっかちなドライバーが信号待ちの渋滞を見て空いている車線に移動する場合がありますが、これは「追い越し」に該当すると考え、現時点では障害物回避の対象外としています。
自車が走行している車線上の駐車車両を回避したい場面
隣接車線の車両を回避したい場面
駐車車両以外を回避したい場面
一時停車中の車両を回避せず後方で停止したい場面
これらはあくまで一例ですが、Planning/Controlチームでは、人間が判断を行う際の要素を整理し、実装可能な条件に落とし込む作業を「回避したいユースケース」と「回避しなくてよいユースケース」それぞれに対して行うことで、障害物回避の「判断」を改善してきました。ここで、「Autoware」の障害物回避機能の「回避する／しない」の判断は、現状はエンジニアによって構成されたルール（=多数のif/else）をベースに動作します。
簡単な例を紹介します。まず、自車両の走行経路から遠く離れた静止物体に対しては、基本的に回避する必要は無いと考えます。そこで、経路に対して幅一定の領域を定義し、その範囲外にある静止物体は、回避しなくて良い物体と判断します。
一方で、自車両の走行経路近くの駐車車両は走行の妨げになるため、回避対象として判断されますが、信号待ちや渋滞で一時的に停車している車両も存在するため、「停止している」以外の条件に加えて駐車車両だけを抽出する必要があります。これは例えば「車両の停止位置とその車両が駐車車両である可能性の間には相関がある」という仮定を置き、駐車車両か判断する1つの基準として「車両がどの程度路肩に寄って停止しているか」を用いることができます。具体的には、車両が最大限路肩に寄った時に車線中央から横方向に移動可能な距離（=shiftable length）に対して、実際に横方向に移動した距離（=actual shift length）の比率を求め、その値が一定以上となる車両が駐車車両と判定されます。
駐車車両の判断手法
駐車車両の抽出
とてもシンプルなルールですが、これだけで市街地で遭遇する多くの駐車車両を判別可能です。このような条件をいくつも積み重ねることで、障害物回避の判断機能は改善され、安全性評価などを経てプロダクトとしてリリースされます。詳細は「Target object filtering」を参照ください。
一方で、上記のようなシンプルなルールでは対応しきれないエッジケースもあります。例えば、ティアフォーが頻繁に実験を行っているお台場では「十分に路肩に寄ることなく駐車している車両」や「車線右側の中央分離帯に寄せて駐車している車両」に遭遇することがあります。
写真左：左側に寄せることなく駐車している車両
写真右：右側の中央分離帯に寄せて駐車している車両
いずれの車両も、回避すべきか判断が難しい状況ですが、自動運転レベル4を目指す上ではこのような状況にも対応できる判断機能の検討が必要です。例えば「路肩寄っていない停止した車両」に対しては、周囲にその車両が停止する要因が見当たらないにも関わらず一定時間以上停止を継続している場合、駐車車両として判断してこれを回避するというルールが考えられます。
近くに停止する要因が無い場合
近くに停止する要因（=横断歩道）がある場合
このように、エッジケースの収集・機能改善・実験のサイクルを高い頻度で回すことで、徐々に性能向上を行ってきました。しかし、エッジケースを見つけた際に、根拠に基づき説明可能な仮定や条件を考える作業は手間が掛かり、エンジニアを悩ませた部分でした。地道な作業の結果、障害物回避機能の判断精度は市街地を十分走行できるレベルまで向上しましたが、依然として対応できていないエッジケースも存在します。
これらのエッジーケースに対応するためには、物体の位置や速度といった基本的な情報に加え、認識性能の向上や周辺車両とのインタラクションに基づく周囲のドライバーの意図推定が必要になります。また、自動運転における判断部分には、機械学習を用いるのが主流になっています。例えば、「Hierarchical Model-Based Imitation Learning for Planning in Autonomous Driving」の論文では、MGAILという模倣学習モデルを用いて熟練ドライバーのデータを大量に学習させることで、多くの場面で人間同等の自然な判断を行えるようになったと書かれています。
現在OSSとして公開されている「Autoware」は最初に述べたルールベースの判断アルゴリズムを採用していますが、これらの背景からティアフォーでは機械学習を用いたPlanningモジュールの導入を進めています。さらに、内部のアルゴリズムが異なっていたとしても、モジュールのインターフェースさえ合致していれば簡単に「Autoware」に組み込みが可能なフレームワークの検討と開発も行っており、ティアフォーは自動運転開発のプラットフォームとして大学や企業などの研究成果をいち早く取り込めるようなアーキテクチャの提供を目指しています。
ℹ️ ウィンカー検知や車両の意図推定はすでにティアフォーで開発しており、近い将来、OSSへの導入を目指しています。また、ティアフォーではオペレーターによる支援を用いた可用性の向上にも取り組んでおり、上述のエッジケースのようにシステム側が自信を持って判断を下せない場合、判断の一部をオペレーターに委ねる仕組みの実装も進めています。
経路生成には、サンプリングベースの手法や最適化を用いた手法がありますが、behavior層におけるグローバルな経路計画では、スプライン曲線を用いた経路生成手法が主に用いられます。乗り心地を損なわないためにジャークに制約を設けており、障害物回避やレーンチェンジなど、ステアを切る経路を生成する際は、下図のように元の経路に沿ったフレネ座標系における縦の移動量(s)に対する横の移動量(l)の3次微分の最大値が、指定したジャーク制約値以下になるように経路を生成します。
回避中の速度が一定と仮定した場合に、横の移動量が目標に達するまでに必要な縦距離は目標移動量（=L）と回避時の車速（=V）、縦の移動量(s)に対する横の移動量(l)の3次微分の上限値（=J）を用いて以下の数式で表されます。
s = 4.0 * V * (0.5 * L/J)^(1/3)
「Autoware」は駐車車両に対してどの程度余裕を持って横を通過するかはパラメーターで設定可能で、物体の姿勢と形状、回避モジュールのパラメーターから回避時の横の移動量が決まります。ティアフォーで開発しているロボットタクシーでは、駐車車両に対しては、急にドアが開くことを想定して最大で約1.5 mの横距離を空けて横を通過するように設定されています。また、自車両は駐車車両の横を通過する前までにシフトを終えている必要があり、シフト終了位置と駐車車両の縦の距離（以下の図におけるfront longitudinal buffer）もパラメーターで設定可能です。これによりシフト終了位置が求められ、上記の式からジャークを制約値以下に抑えるために必要な縦距離も求められることから、回避挙動（ステアを切り始める位置）の開始位置が求まります。
その後、回避挙動の開始と終了の2点を結ぶようにジャーク制約をもった曲線で補完を行い、回避経路が生成されます。シフトした状態から元の車線中央に戻る経路の生成も同様に行います。
判断部分と同様に、シンプルな手法ではありますが、シミュレーションや実車両を用いた公道での実験の結果、数台の駐車車両を同一方向に回避するユースケースであれば、この経路生成手法で対応可能であることが分かりました。ここでは回避中の車速は一定と仮定しましたが、回避中に等加速度運動をした場合でも、横の移動量の時間の3次微分（=横ジャーク）が一定以下になるように経路を生成可能です。behavior層には障害物回避以外にもレーンチェンジなど横にシフトする経路を生成する必要があるモジュールが存在するため、一連の機能はライブラリ化されており、どのモジュールからも簡単にインクルードして使えるようになっています。詳細は「Path Generation Design」のドキュメントを参照ください。
経路形状の計画における、各レイヤーの役割は以下の通りです。
behavior層とmotion層では同じ経路計画でも粒度が異なり、behavior層では大まかな経路計画、motion層では細かな経路計画を行っています。「物体回避」に関して、今まで私たちが実験を行ってきた環境では「右にシフト」→「ちょっと直進」→「左にシフト」程度の大まかな動きができるだけでも駐車車両などの障害物を回避できる場合がほとんどだったため、behavior層に組み込まれたという背景があります。一方で、左右の物体をS字状に避けながら走行したり動いている物体を回避するといった複雑な経路形状の計画や、細かな調整が必要になる場合、上で説明したスプライン曲線を用いた手法は経路形状の自由度が低いので最適な手法とは言えません。
そこで現在、Planning Componentのアーキテクチャはそのままに、behavior層の「物体回避」だけでなくmotion層の経路計画モジュールを用いることで、「Autoware」の可用性を向上させることを検討しています。
「Autowareにおける狭路走行のための走行経路計画」の記事でも紹介されていますが、「Autoware」のmotion層には、走行可能領域や車両のキネマティクスを制約として与えることで、車両が追従可能な最終的な経路形状を求めるモジュールが存在します。この機能は当初は狭路を走行する上で、キネマティクスを考慮しつつ車両のフットプリントが走行可能領域内に収まるように経路を調整することを目的に開発されたものです。内部で最適化を解いているため複雑な形状の経路計画が可能な点が強みです。
この強みを活かして複雑なシナリオでも障害物の回避を行うために、behavior層はどの物体を回避するか判断を行うことに加え、「避けるべき」と判断した障害物の近傍を走行可能領域（下図におけるdrivable area）から除外します。そうすることで、motion層で経路を走行可能領域内に収めようとする過程で物体を回避する経路を計画することが可能になります。
本機能は現在テスト段階ですが、すでにOSSとして提供されており、motion層までフル活用することで以下のような難易度が高いユースケースにも対応が可能になります。
ここまで「Autoware」の障害物回避機能について「判断」と「計画」に分けて紹介しました。内部で動いている一つ一つのロジックはシンプルですが、公道走行で必要な基本的な機能は提供しており、今後は「判断」と「計画」に機械学習や最適化などの高度な手法を取り込んで行くことで、安全性も重視しつつ可用性向上を加速させていく予定です。また、今までは主にJPN TAXIに「Autoware」をインテグレーションして評価を行っていましたが、最近ではEVバスへのインテグレーションも始まっています。プラットフォームとして様々な車種で適応可能なモジュールを開発することは、チューニングやオプションに寄って車種の差を吸収するような仕組みを整えなければならないなど、チャレンジングな課題の1つです。ティアフォーのPlanning/Controlチームでは、汎用性と性能の両面を常に意識して開発を行っています。
自動運転システムの不具合は人命に関わります。特にPlanning/Control Componentは車両の最終的な挙動を決める部分であるため、高い品質が必要になります。しかし、「Autoware」は多くのモジュールが絡み合う大規模なシステムであるため、エンジニアが細心の注意を払いながらのコーディングを行っても、バグを完全に無くすことはできません。そこで、開発した機能をどのように評価しているのかを紹介します。
システムを高品質に保ちながら、開発のサイクルをテンポよく回していくためには、自動化された評価の仕組みが必要です。良い実装案が思いついても、「Autoware」が対応している多様なユースケースでデグレーションがないかを一つ一つ確認していたら、開発を迅速に進めることはできませんし、結果的に実装に使える時間も減ってしまいます。また、ライブラリに関数を1つ追加するのであれば、単体テストを書けばよいですが、新しい機能をシステムに組み込んだ上での全体の挙動を評価したい場合は、専用の評価フレームワークが必要になります。
そこで、Planning/Control Componentに対してはscenario_simulator_v2というツールで評価を行っています。こちらのツールは、「走行環境」と「期待するシステムの振る舞い」を定義しておくことで、シミュレーションベースでシステムが想定通りの動きをしているか評価ができます。このツールはSimulatorチームが開発を主導しているので、詳細は「Autowareの開発を更に加速！Openなシナリオテストフレームワークを紹介！」の記事をご覧ください。
ティアフォーでは各ユースケースにおいて自動運転システムがどのように振る舞うべきか継続的に検討しており、シナリオという形で管理されています。シナリオの数は膨大ですが、このツールを用いて評価を行うことで今の「Autoware」がどのユースケースをサポートできているのか簡単に把握することができます。また、過去の評価結果も簡単に比較できるようになっており、デグレーションの存在にも気づくことができます。
今回紹介した障害物回避機能に関連するものとして、「自車両の車線上に1台の駐車車両が停止しており、これを回避して目的地に到達する」というユースケースがあります。「期待するシステムの振る舞い」は細かく設定することができ、このユースケースでは評価の成功条件と失敗条件を以下のように定めています。
＜成功条件＞
以下の条件すべてを満たすこと。
＜失敗条件＞
以下の条件のいずれかを満たすこと。
これは単純なユースケースですが、「走行環境」も細かく設定することができるため、路駐車両が複数台存在するケースや移動する物体が含まれるケースなど、様々なユースケースを想定した評価が可能です。シナリオは難易度や場面によって分類・管理されており、Planning Componentの機能評価シナリオだけでも2024年時点で4000以上のシナリオが存在します。障害物回避機能に関連するシナリオはその中の約1割を占めています。また、ティアフォー CI/CDチームはscenario_simualtor_v2を用いて膨大なシナリオに対する評価をクラウド上で回せる仕組みを構築しており、我々開発者は新たに機能を追加した際のリグレッション評価をブラウザ上で簡単に行うことができます。
ℹ️ ティアフォーではPerception Component向けの評価基盤も開発しており、同様にクラウド上で評価が行えるようになっています。詳しくは「driving_log_replayer」を参照ください。
上記評価基盤で入念に動作確認を行った後、実車評価に移ります。
実車評価は安全性の観点から高頻度で更新されるメインストリームのブランチ（Autoware.universeのmainブランチなど）を使用して実験を行うことはできません。これは、開発者が検証したい機能以外にも多くの変更が取り込まれているため、実験主導者が全く想定しない不具合が発生する恐れがあるためです。そこで、ティアフォーではSystem IntegrationチームとField Integrationチームが主導で評価を行ったリリース済みブランチを用いて実験を行います。このブランチは、リリース評価の過程で発見した不具合は基本的に対応済みであり、どのような不具合が発生する可能性があるかも把握しています。そのため想定外の不具合発生リスクを低減できるほか、万が一不具合が発生したとしても新たに加えた変更に起因するものか切り分けやすくなるというメリットがあるため、私たち「Autoware」開発者はリリース済みのブランチに評価したい新機能だけを追加して実車評価を行っています。
以上から分かる通り、リリース済みブランチは開発を進める上で重要な存在です。リリースは基本的にプロダクトごとに行っており、最近ではリリースプロセスの改善とリリースに携わるチームの活躍により、2週間に1度の頻度でリリースブランチを更新できるようになりました。これにより、ユーザーは新しい機能をすぐに試すことができる環境が整っただけでなく、開発者側も最終的に取り込まれるメインストリームと近い環境で評価を行えるようになりました。そして機能をメインストリームに取り込んだ後に出てくる不具合も削減することができました。このような小さな改善の積み重ねが「Autoware」の開発を支えています。
ℹ️ 最近ではリリースプロセス改善に取り組む専門のチームも立ち上がりました。ティアフォーのリリースプロセスの詳細は別の機会に改めて紹介します。
今回は「Autoware」の障害物回避機能に焦点を当てつつ、普段私たちがどのように「Autoware」の開発を行っているのかを紹介しました。「Autoware」の開発には様々なチームが関わっています。私たちPlanning/ControlチームやPerceptionチームはその中心ですが、実験をサポートするチームや「Autoware」を車両にインテグレーションして実験の環境を整えるチーム、今回紹介した評価基盤を開発するチームの存在も不可欠です。ティアフォーには様々なバックグラウンドを持った方が活躍できるポジションがあり、「自動運転の民主化」というチャレンジングなミッション実現の推進力になってくれる新しい仲間を募集中です。詳細は求人ページもご覧ください。
Satoshi Ota | 太田 慧
Planning/Controlチーム
東京大学大学院・航空宇宙工学科修士課程修了。2021年4月入社。現在はPlanning/Controlチームで、経路計画・車速計画などの機能開発をリード。
ティアフォーでは、「自動運転の民主化」というビジョンに共感を持ち、自らそれを実現する意欲に満ち溢れた新しい仲間を募集しています。
多くの職種で採用をしています。詳細は、ティアフォーの「求人ページ」をご覧ください。カジュアル面談をご希望の方は、応募する際に「カジュアル面談希望」と記載してください。
「どの職種で自分の経験を活かせるかが分からない」「希望する職種が見つからない」などの場合は、ぜひ「キャリア登録」をお願いします。
お問い合わせ先
ソーシャルメディア
X (Japan/Global) | LinkedIn | Facebook | Instagram | YouTube
関連リンク