ドメイン駆動設計による運行管理システムのアーキテクチャの最適化

こんにちは。ティアフォーでWebサービス開発を担当している池谷です。

世の中はコロナで自粛モードが続いていますが、ティアフォーではリモートワークを活用し日々の業務に柔軟に取り組んでいます。

さて、私の所属するWebチームでは、オープンソースの自動運転OS「Autoware」を利用した多種多様なサービスを開発しています。その中でも代表的なサービスに「FMS」という運行管理サービスがあります。今回は、当サービスを開発してきた振り返りとして、主にドメイン駆動設計によるアーキテクチャの最適化に纏わるトピックについてお話したいと思います。

What's FMS?

tech.tier4.jp

過去にも一度ご紹介させていただきましたが、FMS（Fleet Management System）とは、業界的には「配車サービス」や「運行管理サービス」と呼ばれており、複数の車の走行予定・計画などを管理するサービスです。

例えば、海外ではUber社などが配車サービスを展開しています。国内にも配車サービスビジネスを展開しているプレイヤーは存在します。

ティアフォーのFMSの注目機能

弊社のFMSが運行管理サービスとして特殊な点は以下の通りです。

• 管理する車が自動運転車である
• ハイブリッドな運行モデルの走行管理が可能である

運行管理サービスというと、車両に一般的な自動車を用いる場合がありますが、弊社の場合はAutowareの自動運転技術とWeb技術をインテグレーションすることで、自動運転車を使った運行管理サービスを実現しています。

また、FMSは複数の運行モデルに対応しています。運行モデルというと聞き慣れない言葉かもしれませんが、モデルによって以下のような違いがあると認識していただければと思います。

オンデマンド配車モデル

例えば、自分が今いる場所まで車で迎えに来てほしい人がいた時に、まずその人がいる地点に車を迎車させ、その後目的地まで送り届けるといった車両スケジュールを管理します。

旅客ビジネスや配車ビジネスの場面において求められる運行モデルです。

巡回走行モデル

一方で、巡回走行モデルは決められた地点を延々と周回するような運行モデルです。

こちらは、工場などの物流ビジネスの場面で求められる運行モデルです。

ベストプラクティスを求めて

FMS開発における試行錯誤

自動運転やMaaSの分野は歴史が浅いこともあり、FMSを含めたWebサービスのデザインパターンが確立されていないのが実情です。そのような中、開発にあたっては常に自分達にとってベストな形を模索してきました。

FMSはこれまでに2度に渡る変遷を遂げています。第1の転換期は、α版からβ版への変更で、機能面の拡充やサービスとしてのスケーラビリティなどの非機能向上を目的にシステム再構築を実施した大イベントです。現在のFMSの礎はここで構築されました。

しかしその後、マイクロサービスとしての設計上の問題などが影響し、次第にバグが増加したりシステムの保守性が低下していきました。そこで、こういった課題を解決すべく実施したのがアーキテクチャの最適化です。これが第2の転換イベントです。今回はこのイベントにフィーチャーしたいと思います。

浮上していた課題

具体的には、β版は次のような課題を抱えていました。

• マイクロサービスにおけるコンポーネント間のメッセージング・I/Fが密結合してしまっていた
  コンポーネントに閉じた修正のはずが他のコンポーネントに影響しデグレが発生
• リファクタリングが不足し変更容易性が低下していた
  機能追加や機能変更時に必要以上に時間を消費
• システムとして仕様の明記や用語の整理が不十分なために全体の理解容易性が低下していた
  新しい開発者がキャッチアップに躓いたり属人化の傾向が出ていた

これらの課題を解決するために、アーキテクチャを俯瞰的に見直し、各コンポーネントのリファクタリングや再開発を実施しました。

開発手法のアプローチ

ドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

アーキテクチャ全体の見直しにあたって、開発手法としてドメイン駆動設計を取り入れました。人気度が高く話題に上がることの多いDDDですが、DDDを採用した理由は、次の利点に惹かれたところが大きいです。

• 変更容易性が高い
• 顧客やチームメンバーと共通認識を持ちやすい

FMSではモビリティやAutowareに纏わる専門用語を多く扱います。

• 例：Waypoint, Lane, LatLng, MGRS, ETA, Dispatch など

こうした専門用語のキャッチアップが、新しくジョインしたエンジニアが最初に躓くポイントになっていました。

DDDでは、ユビキタス言語というユーザーと開発者で互いに通じる用語に関する内容が登場しますが、これはユーザーのみならず、例えば他の開発メンバー達とも理解が促進されるものと思われます。これにより、上述の障壁を少しでも軽減したいと考えました。

また、FMSの開発チームでは、スクラム開発におけるフィーチャーチーム体制を導入しており、みんなで一緒に複数のコンポーネントをクロスファンクショナルに開発し合うスタイルを取っています。共通の認識を持てる言葉ができることでコミュニケーションが捗り、その結果チーム開発のアジリティ促進効果を期待できると考えました。

モデリングの実践

ではここで、車両のスケジュールを管理するSchedulerコンポーネントに対して実際に行ったモデリングについてご紹介します。

これらは、Schedulerが管理する最も基本的なドメインモデルです。スケジュールは、ステータスや走行の予実などを管理しますが、その他に別のドメインモデルであるタスクも管理していますね。こういった複数のモデルやオブジェクトを一つのまとまりとして管理することを「集約」と言います。

このように整理することで「タスクの○○の部分を☓☓に変更しておいて」「ああ、タスクね」といったコミュニケーションが可能となります。

設計・実装面のアプローチ

クリーンアーキテクチャ

Schedulerですが、以前は一般的なレイヤードアーキテクチャでしたが、DDDを具現化するために、DDDと相性が良いと言われるクリーンアーキテクチャを取り入れて再開発を行いました。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

採用根拠

DDDの実装手段としては、クリーンアーキテクチャ以外にも候補はありましたが、大きな動機としてはやはり変更容易性の高さが決め手となりました。

Schedulerは、機能開発のボリュームは実はそれほど多くはありません。ある程度機能面での補完が終わったら、その後はスケジューリングの最適化問題などに対する試行錯誤が想定されます。

例えば、オンデマンド配車のユースケースを想定すると配車依頼がかかった時に、最適な車両を配車させるニーズが生じます。本格的に対応するには、離散最適化などの高度なコンピューターサイエンスが要求されます。こうした変更開発の比重が大きくなりそうなシステムの開発においては、変更容易性の高さを享受できるクリーンアーキテクチャは合理的だと判断しました。

新しくなったFMS

新アーキテクチャ

こうして、開発手法および技術の刷新によって新しくなったFMSの姿がこちらです。それぞれのコンポーネントが独立し、それぞれの責務を果たすアーキテクチャへと変貌を遂げました。

序盤に挙げた以下3つの課題ですが、まだ完全に解決できた訳ではありませんが、着実に進歩したものと感じています。

• バグの多発
• コンポーネントの変更容易性の低下
• システム全体の理解容易性の低下

この他にもまだ課題はありますが、現在はこのアーキテクチャをベースに新機能の開発や非機能の拡充に励んでいます。

開発手法や技術の選定にあたってのご注意

今回採用したDDDやクリーンアーキテクチャですが、勿論良い面ばかりではありません。例えば、ある程度規模感のあるシステムでないと、旨味が少ない割に開発コストばかり高くついたり、変更が少なかったり寿命が短いシステムにおいて、変更容易性はあまり重要ではないという考え方もできます。

この辺りは、良い面と悪い面をしっかりと理解した上で、自分達のシステムとの相性を見極めてから採用されることをお勧めします。

最後に

今回は、マイクロサービスのアーキテクチャ最適化について、代表的なサービスをベースにご紹介させていただきました。こう見えてFMSはまだまだ開発途上なサービスです。また、FMS以外にもWebチームではバラエティに富んだサービスを鋭意開発中です。

ティアフォーでは、これらサービスの開発を加速していただける優秀なソフトウェアエンジニアを募集しています。

Careers | Tier Ⅳ, Inc.

AWFへ提案中のAutoware新アーキテクチャのご紹介

こんにちは。ティアフォーの上野です。

先日から安全への取り組みについての連載が始まったところですが、今回はティアフォーからThe Autoware Foundation (AWF)に提案しているAutowareの新アーキテクチャを紹介したいと思います。

はじめに

2015年8月25日にAutowareが公開されてから、もうすぐ5年が経とうとしています。

Autoware公開当初は、アカデミックの研究成果をもとに自動運転システムのアーキテクチャを模索しながら開発が行われていました。

その後、世の中で自動運転の機能や研究が急速に発展していく中で、それらを統合するためのより良いアーキテクチャとはどのようなものなのか、日々議論が行われてきました。しかし、そのような議論を詳細まで詰めていくためには、実際に細部まで実装してみないと分からない部分も多くあります。

ティアフォーでは、これまで積み上げてきた実証実験の経験を活かし、プロトタイプ実装を繰り返しながらアーキテクチャの議論を進めてきました。そして今回、それらの議論がある程度成熟したと判断し、今後のOSSの自動運転開発に向けた詳細な新たなアーキテクチャ提案を、そのプロトタイプ実装とあわせて公開することにしました。

プロトタイプ実装のソースコードは下記リンク先で公開していますので、是非ダウンロードして試してみてください。

https://github.com/tier4/AutowareArchitectureProposal

アーキテクチャ紹介

下の図の通り、このアーキテクチャではAutowareは7つのモジュールで構成されています。

各モジュールの役割が明確化されてインターフェースがシンプルになり、OSSとしてより継続的に開発・改善しやすい構造になっています。

各モジュールは以下のような役割を担っています。

• Sensing：センサーから取得したデータのROSメッセージ化。他のモジュールにデータを渡す前の共通の前処理。
• Localization：センサーデータを統合し、自車両の自己位置と速度を推定。
• Perception：動物体の認識、および信号機の色認識。
• Planning：ゴール地点までのルート計算から実際の走行軌跡生成までの処理。
• Control：走行軌跡に沿って走るための、車両へのコマンドの生成。
• Map：地図データの読み込み、変換。
• Vehicle：Autoware内のデータ形式と車両固有の信号フォーマットの変換。

以下、各モジュールについてもう少し詳しく説明していきます。

Sensing

Sensingモジュールでは、LiDAR・カメラ・GNSS・IMUの4種類のセンサーをサポートしています。それぞれのセンサーに対してドライバーを用意し、ROSのメッセージ型にデータを変換します。

また、Preprocessorとして、他のモジュールへデータを渡す前の前処理（例：LiDARの点群データからの外れ値除去や、自車両の運動による歪みの補正など）を行います。

Localization

Localizationモジュールでは、センシングしたデータをもとに、自車両のPose（位置と姿勢）とTwist（並進速度と角速度）を求め、mapからbase_linkへのTFとTwistを出力します。

Pose estimatorではLiDAR・カメラ・GNSSの3種類のセンサーベースの自己位置推定手法をサポートしており、Twist estimatorではIMU・車両からのTwist情報を統合して扱うことができます。

このように複数のセンサーを併用することで、より高い精度、ロバスト性を持った自己位置推定を実現することが可能になります。

Perception

Perceptionモジュールは、①Object recognitionと②Traffic light recognitionの2つのパートに分かれています。

①では車両の周りを取り巻く物体の検出・追跡・予測を行っており、②では信号の検出および識別を行います。

”はじめに”の章でご案内したプロトタイプ実装のコードでは、信号機の色（赤・黄・青）が認識できるようになっていますが、カスタマイズすることで、他の信号（矢印、国・地域特有の信号）への対応も可能です。

Planning

Planningモジュールでは、今回はシナリオ形式を採用しました。

このシナリオ形式では、走行のシチュエーション（例：通常の道路走行、駐車場での駐車など）に応じた適切なシナリオを選ぶことにより、各シチュエーションにおける適切な挙動をするようPlannerを切り替えることが可能となります。

また、開発の観点からも、個々のシナリオの独立した（並行した）開発や、シナリオに応じたパラメータチューニングが可能というメリットがあります。

Control

Controlモジュールでは、Planningで計画した走行軌跡に沿って車両を走らせるための、車両へ送るコマンド（ハンドルの角度と各速度、車両の速度と加速度など）を生成します。

また、遠隔操作のコマンド等、Autoware外部からの入力も含めた複数の制御値のうち、どのコマンドを実際に車両に送るか切り替えるGatewayとしての役割も担っています。

Map

Mapモジュールでは、①Pointcloud mapと②Vector mapの2種類のマップをサポートしています（※）。

①は3Dの点群地図の情報、②は車線や信号の位置といった地物情報を含んでおり、それぞれのマップに対するLoaderを通して、Localization・Perception・Planningといった他のモジュールで利用可能な形にデータを変換しています。

※Vector mapはLanelet2のみのサポートとなっています

Vehicle

Vehicleモジュールは、Autoware内で扱われているデータ形式と車両固有の信号フォーマットの変換を行うため、車両によってモジュール内の構造が異なります（上の図に加えて、追加の変換コンポーネントが必要な場合があります）。

Autowareから車両へ（上の図の右向き矢印）と、車両からAutowareへ（左向き矢印）の双方向の変換が行われます。

デモ動画

新アーキテクチャのプロトタイプ実装を用いてデモを行った動画を、YouTubeで公開しています。どんなことができるようになっているのか、是非動画でご覧ください。

youtu.be

この他にも、別のデモ動画やシミュレーション動画も公開しています。”autoware architecture proposal”で検索していただくか、Tier IVチャンネルからご覧ください。

おわりに

新アーキテクチャの内容、いかがでしたでしょうか？

ブログタイトルや“はじめに”に書いてある通り、この新しいアーキテクチャはAWFに対して現在絶賛提案中です（2020年6月上旬時点）。今後Autowareがどのように変わっていくのか興味を持たれた方、自分も議論に参加したいという方は、ぜひAWFの活動に参加していただければと思います。

また、今回はアーキテクチャの紹介でしたが、今後それぞれのモジュールの実装の詳細についても紹介する記事を展開する予定ですので、そちらもどうぞご期待ください！

安全への取り組み: ①自動運転関連の法律･ガイドライン

はじめまして、ティアフォー Safety Engineerの須永です。

これから数回にわたって、ティアフォーの安全への取り組みを紹介していきたいと思います。

はじめに

今年4月1日、道路運送車両法の保安基準が改定され、自動運転レベル3(※)以上の車両に搭載された「自動運行装置」も国が定める保安基準の対象に規定されました。つまり、レベル3の自動運転車の公道走行がいよいよ法的に可能となります。

当たり前のことですが、安全を確保するにはまずはルールに従うことが重要です。もちろん、ルールを守っただけで安全が十分に確保されるわけではありませんが、守らないことには何も始まりません。そこで今回、自動運転関連で遵守すべきルールについて社内の勉強会資料を整理してみました。

(※)高速道路など、一定の条件下で自動運転が可能なレベル

1. 様々なルール

まず、一般的なルールを整理します。

守らないと罰則のあるもの、罰則はないけれど守るべきもの、業界で決められたルールなど、その種類は様々です。国内外の情勢も含め、簡単に説明していきます。

2. 自動運転関係の法規

自動運転車として車両が道路を走るため、①道路交通に関する国内法規に準拠する必要があります。また、道路上で事故を起こした場合には、②交通事故の法的責任に関する法規によって責任を負うことになります。

①道路交通に関する国内法規

主に関連する法規は、道路交通法、道路運送車両法、道路法、道路運送法の4つです。  

• 道路交通法：主に、車両の運転者や歩行者が道路上において守るべきルールを定めています。自動運転では、自動運行装置が運転者としての行為を一部代替するため、関係してくる法規です。
• 道路運送車両法：主に、車両の所有権、安全性・公害防止・環境の保全、車両の整備についての技術的なルールを定めています。車両に関する技術的な基準が記載されており、自動運転の実証実験に使用する車両も、公道を走る場合にはこれをクリアしないと違法になります。
• 道路法：そのままですが、主に道路に関するルールを定めています。自動運転技術は、車両そのものだけでなく道路などのインフラに依拠する部分もあるため、道路の構造に関連するルールが定められている道路法も参照すべき法規となります。
• 道路運送法：旅客自動車運送や有料道等の自動車道路事業についてルールが定められています。自動運転車としてサービスをする場合に関連してくる法規です。

これらの法規の内容に関しては、国際協調及び相互認証を目的とし、国連内の自動車基準調和世界フォーラム（通称「WP29」）と連携が取られています。また、WP29傘下の分科会における技術的・専門的な検討では、日本は様々な分野で主体的な役割を果たしています。このあたりの詳細については、また別の機会にご紹介できればと思います。

②交通事故の法的責任に関する法規　

自動車事故を起こした場合には、運転者は刑事・民事・行政上の法的責任を負うことになります。自動運行装置が運転者を代替する場合、代替している間は同様の法的責任が認められるため、これらの法規に関しても無視することはできません。

レベル3以上の自動運行装置を搭載する場合は、責任範囲の明確化のため、作動状態記録装置を設置することが義務付けられました。そのため、メーカーには製造物責任法に基づく責任、販売店には契約不履行責任が生じる可能性もありますが、このあたりは国際的にもまだ議論中のようです。国際動向としては、日本が批准しているジュネーブ道路交通条約やヨーロッパ諸国が加盟しているウィーン道路交通条約がありますが、この改正に関しても国連内の道路交通安全作業部会でまさに議論が進められています。

3. 自動運転関係のガイドライン

2015年11月、2020年までの自動走行の実用化に向けた制度整備等に関して安倍首相が発言したことにより、国内では法令整備の準備が本格的に始まりました。また、2018年4月には「自動運転に係る制度整備大綱」が発行され、現在これに沿って制度の整備が進められています。

自動運転システム搭載車は、ある日突然公道を走り始めるわけではありません。実証実験を通して徐々に社会受容性や技術レベルを上げていくことで、自動走行の実用化を進めています。そのように実証実験が日本各地で行われる中、これまでは安全を確保するためのルールが法令しかありませんでした。そのため、法令に当てはまらない事象については、どう対処すべきか正解を模索しながら実験を行う必要がありました。そこで、各省庁はいきなり法規化するのではなく、まずはガイドラインとして大枠のルールをいくつか定めました。

実証実験を行う場合、当然ですが公道の使用許可が必要になります。その際、ガイドラインに沿って許可を取得することになりますが、ガイドラインは法令ではないので、必ずしも全てのルールを遵守する必要はありません。そのため、対応が難しいものに関しては、各省庁や自治体と個別に相談しながら実証実験を検討・実施することになります。

現在、自動運転に係るガイドラインは各省庁から5つ出ています。ティアフォーも各ガイドラインの内容を十分理解・準拠し、また関係各所と事前相談をした上で、日本各地で実証実験を行っています。

4. 自動運転の安全に関する国際規格

自動運転車は、まず通常の自動車としてのシステムの安全が確保された上で、自動運転システムについても安全である必要があります。そのため、自動車のサプライヤーが準拠すべきマネジメントシステムから、システムの安全標準規格まで、業界標準レベルでの安全を確保することが必要になってきます。

自動車業界で対応している国際規格

• ISO 9001：QMS(Quality Management System)の標準規格。品質を継続的に改善していく仕組み。
• IEC 61508：システムのリスクを軽減するために使用される電気・電子・プログラマブル電子により安全性を高めるための機能安全規格。
•  ISO 26262：安全機能を設けることにより、自動車に特化した電子システムに故障が発生した場合でも、ドライバーや乗員・交通参加者等へ危害を及ぼす危険を許容可能なレベルに低減するという機能安全規格。
• ISO/PAS 21448：Safety of the Intended Functionality。他車の動向や天候など自車で制御できない事象や、自車のシステム故障以外の誤使用や性能限界などを想定して安全性を高めるための規格。
• ISO/SAE 21434：自動車のサイバーセキュリティに対する国際規格。ハッキングされた場合には自動車の安全にも影響が出るため、体系的に取り組む必要がある。
• UL 4600：最近発行された、ULというアメリカの認証機関の規格。自動運転システムのベストプラクティス。 

その他、ISO 22737やISO 3691など、自動車以外に適用される自動運転の新しい標準規格についても、内容を確認し順次対応していくことを検討しています。

このように、自動運転に関連する標準規格はいくつもあり、ティアフォーのようなスタートアップがこれら全ての国際規格に準拠することはなかなか難しい部分もあります。とはいえ、これらの規格を無視することはもちろんできないため、まずはできる範囲での準拠を目指し、安全を最大限確保できるよう努めています。

5. 自動運転の安全に関するドキュメント

安全設計を行う上での業界調査のようなこともしています。

これも挙げればきりがないのですが、安全に近道なし、という信念を持っていろいろな先駆者のドキュメントも参照・分析しています。

• SaFAD：Safety First for Automated Driving。自動車OEMやTier1が11社集まって作成した、安全な自動運転を可能にする乗用車の開発、ならびに検証および妥当性確認に向けたフレームワーク。
• Safety Reports：世界各国の自動運転開発会社が安全に対してそれぞれどのように取り組んでいるのかをまとめた公開資料。センサー構成やアルゴリズム、安全性を高めるためにどのようなことを行っているかなど、ティアフォーの競合でもある各社のお知恵拝借ではないですが、内容を参考にしています。(e.g. Waymo、Nuro、NAVYA)
• NHTSA/ U.S.DOT：アメリカ運輸局内の自動車や運転者の安全を監視する部署が出している安全に関する様々なドキュメントも参考にしています。(e.g. USDOT Automated Vehicles Activities)
• NCAP： 新車のアセスメントプログラム。特に予防安全としてのアクティブセーフティのプロトコルを参考にしています。(e.g. Euro NCAP 2025 Roadmap)

以上、自動運転の安全に関して参照しているものを列挙してみました。論文やその他ドキュメントもあわせて参照し、安全への取り組みに役立てています。

おわりに

冒頭にも書きましたが、ルールを守ることは安全を確保するための必要条件ではありますが、十分条件ではありません。そこで次回以降、安全を確保するためにティアフォーでは実際にどのようなことを行っているのか、もう少し具体的に紹介していきたいと思います。

ティアフォーで開発に用いる車両

ティアフォーでは自動運転ソフトウェアであるAutowareの開発を行っていますが、開発したソフトウェアの検証を行うために実在する車両が必要です。今回はティアフォーで開発に用いる車両の一部をご紹介します。

LEXUS RX450h

自動運転向けに改造したLEXUS RX450hです。車両上部に「AI Pilot」という機器を用いて4つのLiDAR・2つの認識用カメラをマウントしています。公道での自動運転向け開発技術の検証によく使用しています。AI Pilotに搭載してあるカメラとは別に車両の前後左右に、遠隔監視・操縦のために用いるカメラ4台を備えています。遠隔監視・操縦システムについては下記記事にて紹介しております。

tech.tier4.jp

ラゲッジスペースに産業用のコンピュータがあり、そこにAutowareがインストールされています。

Milee（マイリー）

ティアフォーを代表する4人乗りの小型車両です。頻繁にデモなどで使用しているので、何処かで見たことが有る方もいらっしゃるかもしれません。後に紹介するゴルフカートをベースとして、天頂と前後左右下部の合計5箇所にLiDARが、天頂LiDARの下に認識用カメラが取り付けられています。LEXUS同様遠隔監視・操縦用のカメラもついています。最大時速は19 [km/h]となっており、テーマパークや施設構内などのプライベートエリアを低速で走行するシーンによく使用します。前後にサイネージディスプレイ、天頂とフロントライト付近にフルカラーLED、前方と車内にスピーカー、車内前方にタブレットを備え、搭乗者に限らず周囲の方に車両の状態を知らせることが可能です。残念ながらナンバーが無いため公道では走行できません。名称であるMileeは「ラストワンマイル」から来ており、ワンマイルモビリティを象徴するコンセプトカーです。ステアリングハンドルやアクセル・ブレーキペダル等にアクセス出来ない状態にすることができるので、まさに自動運転向けの車両と言えます。

これらLEXUS、Mileeが活躍した番組がNHK BSプレミアムにて7月13日 午後9時00分～ 午後10時30分 に放送されます。ぜひご覧ください

www4.nhk.or.jp

ゴルフカート

先のMileeのベース車両にもなっているゴルフカートです。LEXUS同様AI Pilotを用いてセンサをマウントしています。ガソリン無しで走るEV車になっているので僻地や離島で力を発揮します。こちらはナンバーの交付を受けることが可能なので公道を走ることが出来ます。ティアフォー内で所有している台数が最も多く、新しいセンサの検証などマルチに活躍しています。ほぼ同等の車両が自動運転開発向け電動小型低速車両「アカデミックパックPRO」として販売されております。

news.yamaha-motor.co.jp

www.macnica.co.jp

LogieeS-TC（ロージーS-TC）

こちらは物を運ぶことを意識した超小型車両です。前後にLiDARを搭載しており、他の車両と違って左右のタイヤを独立して制御できるので、小回りの効いた動きをさせることが出来ます。屋内、屋外共に走行可能であることも大きな特徴の1つで、車両サイズに影響が無い開発項目の検証等にも役立っています。Logieeという名称はロジスティクスから来ており、見た目の通り上に物を載せて運ぶことが出来ます。なお、Sは小型化の経緯から、末尾のTCは「つくばチャレンジ」を指し、市街地で自律走行を行う技術チャレンジであるつくばチャレンジに2018年に出場し、完走した実績があります。

まとめ

これらの車両は全てAutowareを使用して自動運転可能で、開発内容に応じて適切な車両を選択し検証をおこなっています。Autowareの普及のためには複数の車種に適用可能で有ることが大事ですので、ティアフォー自ら複数台の車両を所有し、実際に車両を動かしながら開発を進めています。

Autowareにおける三次元物体認識アルゴリズム「PointPillars」の紹介

こんにちは。

ティアフォーで自動運転ソフトウェア開発を行っている村上です。
今回はDeep Learningを使った三次元物体認識の手法を紹介していきます。

TL;DR: 12msで動作する三次元物体認識アルゴリズムの開発

自動運転におけるDeep Learning

自動運転では主に周りの環境を認識する際にDeep Learningを用いることが多いです。画像認識アルゴリズムであるSSD*1やYOLO*2が有名なものになります。

Deep Learningは認識以外の分野にも応用されています。例えば、自動運転における判断*3や車両制御*4に応用するような論文も出てきていたりします。 

点群を処理するためのDeep Learning

そんな中で今回はDeep Learningを点群処理に応用したアルゴリズムを紹介したいと思います。

そもそも、なぜ点群を処理するためにDeep Learningが必要なのでしょうか？
理由は高精度の物体認識と形状推定を実現するため、です。

ざっと従来手法

2011年にStanfordから発表された、DARPA Urban Challengeの研究成果を取りまとめた論文*5*6では以下のような点群による認識のパイプラインが提案されました。

下のグラフのように、点群に対して順番に様々な処理をしていくようなパイプラインになっています。

従来のパイプライン

しかし、このパイプラインでは自動運転で求められるような高精度の認識が難しいという問題がありました。

従来手法での問題

いくつか問題がありましたが、一つ挙げるとすれば、「クラスタリング」において、二つの物体が隣り合っている場合、区別することが難しいという問題がありました。

Euclidean Cluster結果

右側の画像でクラスタリング手法の一つである、Euclidean Clusterの結果を表示しています。前方左にバイク、前方右に自動車があるような状況ですが、二つの物体を一つの物体として認識しており（同じピンクの色で認識）、それぞれの物体を区別することができていませんでした。

形状推定の必要性

また、自動運転におけるPerceptionの難しさの一つに隠れ(オクルージョン)の問題があります。従来のパイプラインでは一部の物体形状しか得られない状態において、物体全体の形状を推定することが困難でした。

左から画像、同一視点からの点群、鳥瞰方向からの点群

上の画像は前方の車両を様々な角度から見たものです。一番右の鳥瞰方向の画像では、前方の車の形状が分かりにくいことを示しています。

実際の物体は下の画像のように存在します。
このように物体全体の形状を推定することは、TrackingやPlanningなどの自動運転における重要なプロセスの中で非常に役に立ちます。

実際の形状を緑枠で表示

Deep Learningで可能なこと

従来の手法では点群を順番に処理していましたが、DeepLearningベースの手法ではEnd to Endで最適化されたクラス分類と形状推定をすることができます。

これは従来のパイプラインにおける「地面除去」、「クラスタリング」、「クラス分類」といった処理を暗に内包していると言えます。

また、物体の形状についても事前知識を利用することによって、従来手法では成し得なかった全体形状の高精度な推定が可能となりました。

Deep Learningのパイプライン

三次元物体認識アルゴリズム「PointPillars」の紹介 

従来手法では達成できなかった「高精度の物体認識と形状推定」をするために、今回「PointPillars」*7を実装しました。

今回のパイプライン

ざっと類似手法

2016年に発表されたMV3D*8では画像と点群を使用し、Faster R-CNN*9を模した構造で特徴量抽出した後にFusionをして三次元Bounding Boxを生成しました。

2017年にAppleの研究員が発表したVoxelNet*10では、PointNet*11をベースにしたPoint単位の特徴量抽出とVoxel単位での局所的な特徴量計算を合わせて行うことで、MV3Dを上回る性能を達成しました。

2018年に発表されたSECOND*12はVoxelNetの構造を参考にしながら、一部にSparse Convolutionを適用することでモデルの軽量化と性能向上を達成しました。

なぜ「PointPillars」

SECONDとほぼ同時期に発表されたのがPointPillarsでした。VoxelNetを踏襲しながら、Voxel単位の特徴量抽出ではなくPillar（柱）単位での特徴量抽出と2D-convolution使用による軽量化された構造が特徴です。

今回、なぜ数あるアルゴリズムの中からPointPillarsを選択したかというと、処理速度と予測精度のバランスが優れているからです。

 予測精度は他のアルゴリズムと比べてトップクラスであると同時に、処理速度は類似手法と比較し最も早く動作するアルゴリズムであり、16ms（約62Hz）で動作することが論文内で述べられています。

下の画像*13ではクラス別の比較項目の中で、PP(PointPillars)が他のアルゴリズムに比べて、予測精度と処理速度の二つの点から優れていることが分かります。

PointPillarsと類似手法比較

ネットワーク構造はVoxelNetとくらべてPillar単位の特徴量抽出や2D-convolutionの使用により、軽量化されています。

PointPillarsネットワーク構造の概略図

CUDAとTensorRTによる高速化

従来手法と比べた大幅な高速化は二つの要因から達成されました。
一つはネットワーク構造のスリム化。
そして、もう一つはTensorRTと呼ばれるDeep Learningの推論を高速化するLibraryの使用です。

TensorRTは便利ですが、対応しているレイヤーの種類が限られている、という欠点があります。

実際に、PointPillarsで使用したいと考えていた"Scatter"と呼ばれるレイヤーが存在しなく、自身で実装する必要がありました。


最初はCPU側でコードを書いていたのですが、メモリ転送の時間コストが高かったため、この部分をCUDAで実装しました。

また、点群の前処理と後処理においてもCUDAによる実装をすることで、計算効率化とメモリ転送コストの削減を達成しました。

コード実装の概略図

Deep Learningによる点群処理手法の問題点のうちの一つが、その処理速度が遅いことでした。たとえば類似手法で紹介したVoxelNetでは225msかかっており、LIDARのセンサー周期が100msで動いていることを考慮すると、自動運転で扱うことが難しいアルゴリズムでした。

元論文では優れたネットワーク構造とTensorRTによって16msで動作することを発表しました。

さらに今回の実装では、前処理・後処理をCUDA化することによって全体処理時間を12msまで短縮しました*14 *15。

下の動画では、Autowareに組み込まれているPointPillarsをKITTI Raw Dataset で評価した結果になります。

PointPillars tested with KITTI data

KITTI dataset*16 is published under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0.

最後に

最後になりますが、現在ティアフォーでパートタイマーとして勤務している、
東京大学、創造情報学専攻の村松さんにはPointPillarsのネットワーク実装においてアドバイスをいただきました。
ありがとうございました。

*1:W. Liu, D. Anguelov, D. Erhan, C. Szegedy, S. Reed, C.-Y. Fu, and A. C. Berg. SSD: Single shot multibox detector. In ECCV, 2016.

*2:J. Redmon and A. Farhadi. YOLO9000: Better, Faster, Stronger. In CVPR, 2017, pp. 6517–6525.

*3:S. Shalev-Shwartz, S. Shammah, and A. Shashua. Safe, multiagent, reinforcement learning for autonomous driving. In NIPS Workshop on Learning, Inference and Control of Multi-Agent Systems, 2016.

*4:G. Williams, N. Wagener, B. Goldfain, P. Drews, J. M. Rehg, B. Boots, and E. A. Theodorou. Information theoretic MPC for model-based reinforcement learning. In ICRA, 2017.

*5:A. Teichman, J. Levinson, and S. Thrun. Towards 3D object recognition via classification of arbitrary object tracks. In ICRA, 2011, pp. 4034–4041.

*6:J. Levinson, J. Askeland, J. Becker, J. Dolson, D. Held, S. Kammel, J. Kolter, D. Langer, O. Pink, V. Pratt, M. Sokolsky, G. Stanek, D. Stavens, A. Teichman, M. Werling, and S. Thrun. Towards fully autonomous driving: Systems and algorithms. In Proc. IEEE IV, Jun. 2011, pp. 163–168.

*7:A. H. Lang, S. Vora, H. Caesar, L. Zhou, J. Yang, and O. Beijbom. PointPillars: Fast encoders for object detection from point clouds. arXiv:1812.05784, 2018.

*8:X. Chen, H. Ma, J. Wan, B. Li, and T. Xia. Multi-view 3d object detection network for autonomous driving. In CVPR, 2017.

*9:S. Ren, K. He, R. Girshick, and J. Sun. Faster R-CNN: Towards real-time object detection with region proposal networks. In NIPS, 2015.

*10:Y. Zhou and O. Tuzel. Voxelnet: End-to-end learning for point cloud based 3d object detection. In CVPR, 2018.

*11:C. R. Qi, H. Su, K. Mo, and L. J. Guibas. Pointnet: Deep learning on point sets for 3d classification and segmentation. In CVPR, 2017.

*12:Y. Yan, Y. Mao, and B. Li. SECOND: Sparsely embedded convolutional detection. Sensors, 18(10), 2018.

*13:https://youtu.be/p5AtrKqQ3Fw?t=2203

*14:https://github.com/autowarefoundation/autoware/tree/master/ros/src/computing/perception/detection/lidar_detector/packages/lidar_point_pillars

*15:CPU:Core i7 8700K, GPU:GTX-1080ti, Tested with a rosbag in the office

*16:http://www.cvlibs.net/datasets/kitti/

ティアフォーにおける自動運転車両の運行管理サービスのご紹介

はじめまして、ティアフォーで自動運転のWebプラットフォーム開発を行っている森本です。

今回は、自動運転車に対して走行ルートの指示などを行う運行管理サービスであるFMS（Fleet Management System）についての概要をご紹介します。*1

運行管理サービスとは

まず、運行管理サービスとはどんなものなのかを簡単にご説明します。

実際に車両を運転する際は、どんな経路を通り途中で何をして最終的に目的地に到着するのか、といった経路に関する要素が存在します。

また、タクシーのようなサービスの場合、迎えに来てほしいというお客様に対してどの車両が向かうべきか、という最適配置の要素も存在します。

こうした要素に対し、例えば自動運転車両の向かいたい地点を指定された際、運行すべき経路をWeb側で生成して最も運行効率の良い車両を配車するということが考えられます。

このように、車両の運行に関する情報をWeb側で管理するサービスを運行管理サービスと呼びます。

運行管理において必要な情報

運行管理を行う上では車両の情報が欠かせません。車両の現在地や、運行中なのか停止中なのかといった情報だけでなく、場合によっては運行経路中の信号などのインフラ情報が必要になることもあり得ます。

一方で、例えばタクシーのように人を迎えに行ってから目的地に送り届ける、というモデルを考えると送迎などの情報も存在することになりますが、こういったサービスに関する情報はFMSとは別枠で考えるため、FMSではなくAutowareCallsという別サービスで管理を行なっています（今回は言及しません）。

ステートマシンの作成

FMSでは運行管理を行うためにステートマシンを作成して運行管理を行います。

例えばバスのようなモデルを考えると

・車両が決まったルートを運行しており、停車後一定時間待つと次の目的地に向かって走り出す

となり、これは以下のような状態遷移が考えられます。

次にタクシーのようなモデルを考えると

・ユーザーが車両を呼び出し、車両が無人でその場に迎えに行き、ユーザーの乗車後に発進ボタンが押されることで目的地に向かって走り出す

となり、これは以下のような状態遷移が考えられます。

このように、それぞれの運行モデル毎に適切なステートマシンの作成が必要となります。

また、実際にはもう少し細かく状態を管理する必要があり、異常系のケアなども必要になってきます。

 FMS構成概要

FMSはあくまで運行管理を行うためのWebサービスなので、実際の運用では自動運転OSSであるAutowareやユーザーアプリなどと組み合わせることで一つのサービスとして稼働します。

構成例としては、以下のようなものが考えられます。

処理の流れは以下のようになります。

1. AutowareのPublishするトピックメッセージを元に車両情報を随時更新
2. ユーザーアプリからの配車依頼を受け、車両それぞれについての最適経路を探索し、経路を元に配車する車両を決定する。また、走行が完了するまでその車両に対する配車を不可とする
3. 配車対象車両のAutowareに対して走行経路をPublishする
4. Autowareが受け取った経路情報を元に走行し、走行の状態毎にノードの情報を更新
5. 走行が完了すると配車が可能な状態に戻る

このような状態遷移のためにはAutowareのPublishするトピックメッセージに含まれているステートが必要となりますが、FMSではこのステートを抽象化した上でAWS IoT側にPublishすることで極力Autowareを意識する必要がないようにしています。

動作検証の流れ

上記のような構成で実際に車両に対して経路を送信し、それに従って車両を自動走行させることが可能となりますが、いきなり実機で走行テストを行うのは様々なリスクが考えられます。そこで、Autowareのwfsimというシミュレーション機能とFMSを組み合わせることで事前にシミュレーションを行い、実機での動作検証を安全に行うことができます。

wfsimを用いたシミュレーション

以下は、タクシーのモデルについてwfsimを使ってシミュレーションした際の映像です。

最初は経路が与えられていませんが、ユーザーに呼び出されたタイミングで車両の現在地からユーザーのいる地点までの経路を生成してAutowareに送信しています。

次に、Autowareが経路を受け取ったことを確認するとFMSから発信命令を送信して自動で動作を開始します。

ユーザーの待つ地点に到着すると、そこから目的地への経路を新たに生成してAutowareに送信します。一つ目の経路では車両が無人のためFMSから自動で動作命令を送信していましたが、今度はユーザーが乗っているため（動画では判断できませんが）人が発信ボタンを押すことで発信命令が送信され、車が動き出しています。

このように、wfsimを用いると実機なしでのシミュレーションができるというだけでなく、実機では難しい連続可動試験が実施できるといったメリットも存在します。

実機を用いた検証

最後に、実際に実機を使って動作確認を行います。

Autowareの性質上、wfsimでのシミュレーションと実機での動作はほぼ差分がありません。そのため、ここで動作がおかしくなった場合はwfsimでのパラメータと実機検証でのパラメータの差分を確認しつつ問題を整理していくことになります。

以下は実際に実機を用いて試乗を行なった際の動画で、タクシーモデルで人が乗り込んだ後に発信ボタンを押すことで車が発信し、自動運転が開始される様子が映っています。

まとめ

以上がティアフォーの自動運転においてWeb側が担当している役割の一つである運行管理サービスについての概要となります。

自動運転と聞くと車両側の制御のことを想像しがちですが、実際のサービスとして車両が走行する際は、こうしたWeb側の役割も欠かせません。

実際のサービスでは複数台車両をどのように最適に捌くか、予約はどうするか、割り込みはどうするか、といった複雑な問題が様々存在しており、Web側にも多くのチャレンジングな課題が存在しています。

ティアフォーではこのような課題を解決するWebエンジニアを随時募集しておりますので、少しでもご興味をお持ちいただけましたら是非ご連絡ください

*1:運行管理サービスは要件毎に内容が異なってくるため、全ての案件で同一構成になっているわけではありません。

Autowareにおける車両制御アルゴリズムの開発

はじめまして！

株式会社ティアフォーで自動運転システムの開発を行っている堀部です。

今回は自動運転における車両制御、特に経路追従と呼ばれる部分について説明していこうと思います。

Autowareによる経路追従の様子

自動運転における車両制御

一般に自動運転において「車両制御」とは、経路追従制御およびステアリング・速度制御を合わせた領域を指します。

この２つの機能の目的は

• 経路追従制御：車両を目標経路に沿わせるための目標ステア角・車速を計算する
• ステアリング・速度制御：ステアリング角と車速を目標値に合わせる

となっており、ブロック図としては以下のように書かれます。

control block diagram

ステアリング制御は、ステアリング角度を目標角度にサーボさせる、いわゆるモーター制御に近いイメージです。しかしステアリングの運動には摩擦による地面との相互作用が存在し、車速や重量、路面状況などによって特性が大きく変化します。

通常の制御では摩擦は外乱としてフィードバックで押さえ込むことが多いのですが、ステアの場合はこの外乱が非常に大きく、この非線形特性をうまく取り扱えるかが制御の肝になります。

速度制御も同様に、車両速度を目標速度に合わせることが目的ですが、ここでもエンジン特性のような非線形を考慮する必要があります。エンジンの特性は数式で記述することが難しいため、非線形性を吸収するマップを作成して対応したりします。速度の加減速は人が感じる乗り心地に直結するため、自動運転に置いても非常に重要な役割を持ちます。

今回説明する経路追従制御は、目標経路に沿って走行するためのステア目標値、速度目標値を計算し、上記2つの制御系に渡すような構造となっています。この系はステア・速度制御をフィードバックループの内部に持つような構造になっており（ブロック図参照）、車両全体の運動特性を考慮して設計する必要があります。

軌道追従制御の歴史

開発初期（PID制御）

車両の走行制御の開発は古くから行われており、日本でも1960年代には時速100kmでの自動走行に成功しています。*1

この時代は道路に埋め込んだ磁気マーカーを検出して自己位置を求める方法が主流であり、古典制御（いわゆるPID）によって追従制御が行われていました。

PID制御では以下の図のように、車両と目標経路との横方向偏差（Lateral error）、および姿勢偏差（heading error）にPIDゲインを掛けて、ステアリング指令値を計算します。

PID control

この手法は古典制御理論を利用した解析やチューニングが容易な反面、経路形状を考慮できなかったり、偏差が生じた後にしか対応ができない（つまり必ず偏差が生じる）といった欠点があります。

DARPAグランドチャレンジ（pure-pursuit）

DARPA Ground Challenge: Carnegie Mellon University

DARPAグランドチャレンジ*2とは2004年と2005年にアメリカの国防高等研究計画局（DARPA）主催のもと開催された自動運転のレースであり、スタンフォードやカーネギーメロン、MITと言った名だたる大学のチームが参加しました。この大会で今の自動運転に必要な多くの技術が生まれたと言われています。

この大会で多くのチームが使用した経路追従アルゴリズムが、Autowareでも採用されているpure-pursuitと呼ばれる制御方法になります。*3

この制御は経路の一定距離（Lookahead distance）前方に目標点を設定し、その点に向かって円を描いて進むようにステア角を決定するアルゴリズムです。簡易な方法ではありますが、前方を見ることによって（曲率一定という仮定はあるものの）経路形状を考慮できており、設計パラメータが少なく直感的にわかりやすい、と言った利点を持ちます。

 

また、制御理論の観点から見るとpure-pursuitはPD制御とよく似た性質を持っていますが、アルゴリズムに数値微分を必要としないという特徴があります。

PID制御の"D"は微分を意味しますが、微分とは変化率を求める作業であり、D制御は「現在の変化率から将来を予測して制御する」という一面を持ちます。

一方で、pure-pursuitでは「経路の先を見て将来を予測する」という方法によってD制御の効果を実現しており、微分を必要としない、ノイズに強い制御方法となっています。

グランドチャレンジの頃からは、自己位置推定の方式が磁気センサーのように環境に手を加える方法ではなく、LiDARなどによるマップマッチングが主流となりつつありました。この方法は直接自己位置を観測できる磁気センサーと異なり、推定される自己位置に多くのノイズが生じるため、pure-pursuitのノイズ耐性は非常に有用なものであったと考えられます。

近年の開発（MPC）

近年では、より複雑な制御理論が自動運転開発に適用されるようになってきました。その一例としてMPCと呼ばれる制御方法をご紹介します。

MPCは機械分野では2000年頃から実用化され始めた制御方法であり、1950年代に完成した古典制御、60年代の現代制御と比較すると比較的新しい制御手法になります。

この手法は下図のように、目標軌道（Reference trajectory）上の複数の点に対して、それらの点に沿う最適な経路（Predicted trajectory）を毎制御周期ごとに計算します。MPCは内部に車両モデルを持っており、このモデルと実現可能な入力の組み合わせの中から最適経路を計算し、その経路を実現するステア角を目標ステア角として後段のステアリング制御系に渡します。

MPCは経路上の複数の点を利用しているため、経路形状の情報を適切に考慮した制御を行うことができます。これによって「この先は急カーブだから、早めにハンドルを切ろう」といった、賢い制御が可能になりました。

さらにMPCでは経路の計算に凸最適化と呼ばれる手法を用いており、ステアリングの最大角度や横G制限といった制約条件を考慮することができます。MPC以前の制御理論では、このような制約条件を含んだ制御設計を行うことはできず「制約条件に掛からないように全体の応答性を下げる」といった施策が必要でした。一方でMPCは「制約を考慮した最適な制御」を計算することが可能となり、限界まで機体の性能を使い切ることがでるようになりました。

このようにMPCは非常に性能の高い制御方法ですが、ほかの制御を比べて圧倒的に計算コストが高いという欠点があります（これが最近までMPCが実用化されなかった最大の理由です）。

この欠点は最近の計算機性能の向上に伴って特別に問題視されることは少なくなりましたが、それでも性能と計算コストのチューニングにはいくらかの労力を要することになります。

ティアフォーでの開発 

現在Autowareで使用しているpure-pursuitはオリジナルから一部改変が加えられており、速度に応じてlookahead distanceが線形に増加するようになっています。

これは「速度 / lookahead distance の値に応じて安定性が変化する」というpure-pursuitの解析結果*4を反映しており、速度増加に伴って振動を生じさせないような施策となっています。

しかしpure-pursuitはアルゴリズムの特性上、高速走行時や複雑な経路において追従精度が低くなってしまうという問題があります。

この問題を解決するため、現在ティアフォーではより高性能な制御系開発に取り組んでいます。

しかし、例えばMPCは上で述べたように高性能な制御の代名詞的存在ですが、pure-pursuitのようにロバスト性が特別高いというわけでもなく、ノイズの強い自己位置や、粗い経路を与えると発振や追従性の低下を引き起こしてしまいます。

また、経路予測に用いる車両の数式モデルの作成や、大量のパラメータ調整など、設計コストも高くなるため、多くの検証が必要になります。

我々は現在、車両シミュレーターを使ってこれらの制御系の開発・検証を行っています。社内メンバーに限らず、海外のチームなどともやり取りをし、Autowareの開発を加速させています！

・LGSVL シミュレータ（MPC, pure-pursuit）

youtu.be

・Gazebo（MPC, pure-pursuit）

www.youtube.com

最後に

ティアフォーでは自動運転システムを一緒に開発してくれるメンバーを募集しています！！

*1:自動運転の発展の歴史　国際交通安全学会誌 Vol. 40 No. 2 

http://www.iatss.or.jp/common/pdf/publication/iatss-review/40-2-01.pdf

*2:DARPA The Grand Challenge 

https://www.darpa.mil/about-us/timeline/-grand-challenge-for-autonomous-vehicles

*3:A Survey of Motion Planning and Control Techniques for Self-driving Urban Vehicles 

https://arxiv.org/pdf/1604.07446.pdf

*4:Stability of Autonomous Vehicle Path Tracking with Pure Delays in the Control Loop 

https://pdfs.semanticscholar.org/41f7/12a51b1490937fe494e80debeb87f09d7abe.pdf