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

はじめまして、ティアフォー 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

AutowareにおけるLGSVL Simulatorの活用事例の紹介

はじめまして。株式会社ティアフォーで自動運転システムおよびそのシミュレーションソフトウェア開発をしている片岡です。今回のエントリではAutoware対応自動運転シミュレータであるLGSVL Simulatorについて、その仕組みとティアフォーでそれをどう活用しているかについて解説していきたいと思います。

 LGSVL SimiulatorはAutowareと同様にオープンソースで提供されている自動運転向けマルチロボットシミュレータです。街一つをまるごとシミュレーションした巨大なマップに数百台のNPC車両を動かし、その環境の中で自分の自動運転アルゴリズムを検証することが可能です。

github.com

バイナリリリースもひと月に一度のペースで行われており、そのたびに多くの新要素が追加されています。

自動運転システム開発におけるシミュレータの役割

自動運転システム開発におけるシミュレータの最大の役割は、実験コストおよび事故リスクの低減にあります。自動運転システムの開発をすべて実車で行った場合、車両のセットアップだけで数時間は必要です。公道実験ともなると実施場所の許可申請等それ以外の準備も必要になってきます。そして何より、実験時に事故を起こしてしまった場合、人命に関わるような取り返しのつかない事態も招きかねません。

そこで、そうした実車では危険な実験（制御アルゴリズムの動作テスト、未完成のパーセプションモジュールの動作テスト等）を行う際に活用されるのがシミュレータです。

自動運転シミュレータとしてROSと接続して使用できるシミュレータには以下のようなものがあります。

自動運転シミュレーションに使用可能なROS連携機能のあるシミュレータ一覧

ティアフォーではこの中からAutoware向けAPIが存在し、街一つをシミュレーション可能なLGSVL Simulatorを使用して自動運転システムの開発を行っています。

Unityをベースにしているため、ドキュメントが豊富で拡張性も高く、アセットストアのソフトウェア資産を活用することできわめて高速な開発が可能です。

ティアフォーではゼンリン様がUnity Asset StoreにてMITライセンスで公開中の秋葉原の3Dモデルを用いて数時間の作業で秋葉原での自動運転シミュレーションに成功しました。

www.zenrin.co.jp

www.youtube.com

www.youtube.com

LGシミュレータとAutowareの連携機能

LGSVL Simulatorの仕組み

ティアフォーではLGSVL Simulator Launcherというシミュレータリモート起動ツールを開発し、シミュレーターを遠隔起動できるようにしています。

github.com

このツールはFlaskというPythonのフレームワークを用いて開発されています。シミュレータマシンのポートにHTTPで以下のようなjsonをPOSTするとシミュレータに設定ファイルを引き渡し、起動してくれます。

{
  "bin_type" : "tier4-develop",
  "initial_configuration" : {
    "map" : "SanFrancisco",
    "time_of_day" : 12.0,
    "freeze_time_of_day" : true,
    "fog_intensity" : 0.0,
    "rain_intensity" : 0.0,
    "road_wetness" : 0.0,
    "enable_traffic" : true,
    "enable_pedestrian" : true,
    "traffic_density" : 300
  },
  "vehicles" : 
  [
    {
      "type" : "XE_Rigged-autoware",
      "address" : "$(autoware_machine_ip)",
      "port" : 9090,
      "command_type" : "twist",
      "enable_lidar" : true,
      "enable_gps" : true,
      "enable_main_camera" : true,
      "enable_high_quality_rendering" : true,
      "position" : {"n" : 4140310.4, "e" : 590681.5, "h" : 10},
      "orientation" : {"r" : 0.0, "p" : 0.0, "y" : 269.9}
    }
  ]
}

このLGSVL Simulator Launcherにより、ティアフォーでは自分の席からいつでもシミュレーション環境を使用可能です。

LGシミュレータは、Unity上で物理計算、NPCの挙動制御、センサーシミュレーションといった様々なモジュールがシミュレータ世界の情報を更新することで動作します。

UnityとROSの接続にはros-sharpが有名ですがLGSVL SimulatorではIROS Clientというrosbridgeに対応したROSクライアントを独自実装しています。

今後、ティアフォーではLGSVL SimulatorとAutowareの連携機能を強化することで、公道走行中にセンサを止めるといった実車では極めて危険な実験をシミュレーション上で行い、Autowareの安全性を高めたり、新規アルゴリズムの開発や性能評価、CIと統合したAutowareの動作テストに用いていきたいと考えています。

現在はAutowareにLGSVL Simulatorから出力されるGround Truthデータ（深度画像、セグメンテーション画像、物体領域、Lidar点群とそのラベル等）をKITTI Datasetのデータ形式に変換するツールを追加しようと鋭意開発中です。

LGシミュレータからの正解データ

まとめ

ティアフォーではシミュレータを用いてAutowareやその周辺ツール開発の高速化、品質向上に努めています。

今後は

• ラベルデータ自動収集機能の追加
• CIと統合した自動テスト機能の実装
• アルゴリズムの自動評価機能の追加

等の開発を進め、自動運転システム開発を強力に加速させていきたいと考えています。

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

ティアフォーにおける自動運転車両の遠隔監視・操縦システムのご紹介

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

今回は、遠隔型レベル4自動運転を行う上で必須な遠隔監視・操縦システムについてご紹介します。

遠隔監視・操縦システム

 遠隔型自動運転とは

まず自動運転のレベルの枠組みから簡単にご紹介します。

国際的に自動運転のレベルは0~5の6段階に定義されています。

自動運転のレベル

基本的には、レベル4から運転者の役割がなくなり皆様が思い描くような運転から開放された乗車体験が実現されます。

しかし、運転者の役割が無くなることに伴い、全て自動運転システムが状況を判断し、走行する必要があります。

ただ、現実問題として自動運転システムが対応出来ない場面も想定されます。

自動運転システムが対応できない場面において、個人所有の車であれば搭乗者に操縦を任せることが可能ですが、タクシーやバスなどサービスとしてお客様に提供している場合は運行管理者が対応する必要があります。

そこで、遠隔地から車両を見守り、何か有事の際は操縦し自動運転可能な状態まで復帰させるために遠隔監視・操縦システムが必要となってくるのです。

遠隔型自動運転の位置付け

出典: *1

遠隔監視・操縦システムについて

本システムの機能要件として、下記の事柄が挙げられます。

• 複数のカメラ映像を低遅延で配信できる (実際の運転席と同等の情報を遠隔から把握できる必要がある)
• 車両(Autoware)の状態を監視できる
• 遠隔から低遅延で操縦できる
• 通信状況が悪い/切れた場合に、車両側で安全に停止できる
• 複数台の車両の映像を複数人で監視できる (運行管理者や保険会社など複数のプレイヤーが出てくることを想定)
• 映像を録画できる

大別すると、映像配信と制御情報(Autowareの状態情報も含む)の送受信の2つに分かれます。  

利用シーン

映像配信の仕組み 

映像配信の仕組みとして、

• HLS (HTTP Live Streaming)

• RTMP (Real-Time Messaging Protocol)

• WebRTC (Web Real-Time Communication)

などが挙げられますが、ティアフォーではWebRTCを採用しています。

主な選定理由としては、圧倒的に低遅延(200 ~ 300ms程度)、回線の太さに合わせてビットレートが可変であること、多くのプラットフォームで採用されており汎用性が高いことの3つが挙げられます。

WebRTC

しかし、WebRTCでは基本的にP2Pで通信を行うため、N対Mの通信を行うに当たりデータ転送量の増加、各セッションの管理コストの増加、録画機能の追加が困難などいくつか問題があります。

そこで、本システムではWebRTCの中でもWebRTC SFUを採用しました。

SFUでは、センター集約型であるためN対Mの映像の送受信、録画機能が容易に実現でき、非常に使い勝手が良いというメリットがあります。

上記の図を見ると、MCUは通信量が削減されて良いように見えますが、各映像を結合する処理に大きなレイテンシが乗り、本システムには不向きなため、採用には至っていません。

制御情報通信の仕組み 

制御情報通信の仕組みとして、

• HTTP (Hypertext Transfer Protocol)

• Websocket

• MQTT (Message Queuing Telemetry Transport) 

などが挙げられます。こちらに関しても映像配信同様にレイテンシの小ささと複数台の車両を扱えるスケーラビリティ、さらにはデータ量の小ささやQoSが管理できるといった理由でMQTTを利用しています。

全体の枠組み

全体構成

本システムの全体構成は、上記のようになります。

WebRTC SFUのシステムは、時雨堂様のWebRTC SFU Soraを利用しています。

OSSのJanusなどもありますが、ブラウザのアップデートへの対応や使い勝手の面でSoraの方が優れていたため、Soraを利用しています。

さらに、WebRTC Native Clinet Momo がリリースされ、ROS対応したのでブラウザを利用せずに映像配信が可能になりました。

これにより車両側の映像配信/制御情報通信共にROSプラットフォームへの共通化が実現できています。

また、遠隔監視者は、特に環境構築等を必要とせずに、ブラウザを利用すれば、自動運転の監視・操縦が可能となっております。 

操縦シーン

まとめ

ティアフォーでは、WebRTC SFU及びMQTTを利用し遠隔監視・操縦システムを実現しています。

今後は、

• 通信の安定化 (通信データ量削減及び映像配信ノードのFPGA対応など)
• スケーラビリティの考慮 (数十、数百台の自動運転車を安全に見守れる仕組み)
• 遠隔操縦のUI/UXの改善 (VR対応やより抽象度の高い操縦方法の考案など)

を行っていく予定です。

機会があれば上記新規機能の実装のお話や、得た知見なども順次ご紹介していきたいと思っております。

自動運転サービスを一緒に開発してくれるメンバーを募集しています！

*1:自動運転をめぐる最近の動向と警察庁の取組について(平成30年)    https://www.npa.go.jp/bureau/traffic/council/jidounten/2018dai1kaisiryou1.pdf