初のTier IV Meetupを開催しました

こんにちは、ティアフォーでWebプラットフォーム開発を行っている関谷です。

8/18・8/19の2夜連続して、技術的な取り組みを紹介するティアフォー初のTech Meetupを実施しました。こちらはイベント直前の募集になったにも関わらず、200名を超える多くの方々にご視聴いただき、大盛況のうちに幕を閉じることができました。

また9/2にはティアフォーでの業務についてもっと皆さまに知っていただくために、Career Meetupを実施しました。

ご参加いただいた皆さま、Meetupの機会を提供いただいたTech Playの皆さま、どうもありがとうございました。

Day 1 - 世界初オープンソースの自動運転ソフトウェア「Autoware」ができること ＆ 開発秘話 -

1日目は、弊社の起源でもあり、一番力を入れて開発している「Autoware」のアーキテクチャについてご紹介しました。

開発のリードをしている斉藤・堀部から、公開しているArchitecture Proposalの内容を中心に、全体の設計、PerceptionやPlanningといった各コンポーネントの内容についてそれぞれ説明いたしました。

Tier Ⅳ Tech Meetup #1 - 世界初オープンソースの自動運転ソフトウェア「Autoware」ができること ＆ 開発秘話 - from Tier_IV

質疑応答では、

• 一番最初のデモ動画で出てきたような店舗内での自動化カートのようなものもAutowareで実現可能なのですか？
• LiDARの干渉問題はどのように対処しているんですか？
• MPCは最適化手法によって精度や処理速度が変わると思いますが、Autowareではどんな最適化手法を使っていますか？
• ジャーク制約の中には、前後方向だけでなく横方向のジャークも含まれますか？

などなど、たくさんの方から様々なご質問を頂きました。

Day 2 - 自動運転を作るのはCloudシステムの集合体?? 活用技術を大解剖 - 

2日目は、Autowareの開発やAutowareを搭載した車両の運行を支える技術として、弊社で開発を進めているクラウドシステムWeb.Autoについてご紹介しました。

わたくし関谷と飯田から、Simulatorを含むAutowareのCI/CD基盤やMaaSアプリケーションと繋がる運行管理システムで使用している技術について説明いたしました。 

Tier Ⅳ Tech Meetup #2 - 自動運転を作るのはCloudシステムの集合体?? 活用技術を大解剖 - from Tier_IV

質疑応答では、

• クラウドサービスの中から、AWSを選定した理由ってなんでしょうか？
• CI/CDを1回走らせるのにかかる時間はどのくらいですか？
• 緊急時に遠隔から車両の操縦を行うとのことでしたが、遠隔操縦特有の問題点としてはどのような点があるとお考えですか？
• FMSはとてもサービス志向の機能に感じました。そうした機能の開発において、利用者側の嬉しさをビジネスモデルまで含めて提案するような活動もされているのでしょうか？

など、参加いただいた皆さまから色々なご質問を頂きました。

Day 3 - 自動運転の民主化を一緒に実現してくれるエンジニアを募集しています -

Career Meetupでは、ティアフォーの仕事内容や求人にある方々に参加登録いただき、質疑応答を中心に座談会のような形式で実施しました。

長丁場だったにも関わらず、皆さんからたくさんの質問をいただき、エンジニアの仕事内容・取り組み方や事業の内容、カルチャーについて知っていただく良い機会となりました。

まとめ

Tech Meetupの2日間でご紹介できた内容は弊社で取り組んでいる開発の一部に過ぎません。ティアフォーでは、研究からプロダクト開発といった様々なフェーズの研究開発を行なっており、各研究・開発で色々な試行錯誤を行なっております。

そういった取り組みをこれからもご紹介できるように、今後もTier IV Meetupを開催することを計画しています。次回開催が決まり次第、Twitterなどでご案内してまいりますので、ご興味がある方は是非弊社のTwitterをフォローしていただければと思います。

また、世界と戦える自動運転技術・サービス開発を進めていく仲間を引き続き募集しております。今回開催したMeetupやこのTech Blogで弊社での研究開発にご興味が湧いた方がいらっしゃいましたら、カジュアル面談も可能ですので以下のページからコンタクトいただければと思います。

tier4.jp

オフィス移転 品川オフィス

こんにちは、ティアフォーエンジニア兼引っ越し委員の伊勢です。

今回は技術情報ではなく、新オフィスの情報を皆さんにお届けします。

株式会社ティアフォーのオフィスは本郷３丁目から品川へ

国内・海外どちらからもアクセスしやすい品川です。 新幹線に乗りやすくなりました。

オフィス移転の背景には、社員数の増加、複数拠点オフィスの統合によるコミュニケーションの効率化、そして開発スピードの向上があります。

それでは、より便利に、より働きやすくなった新オフィスを紹介します。

新オフィス

エントランス

新オフィスはJR品川駅港南口から徒歩10分程度、品川インターシティの近くに位置しています。京急北品川駅からも近く、また天王州アイルからも徒歩圏内です！ 1Fのビル受付を抜け、2Fのエントランスに入るとティアフォーロゴがお迎えしてくれます。

エントランスはグレーと黒を基調としたシンプルかつクールなデザインとなっています。また、エントランス正面のカウンターはレセプションとしての機能だけではなく、イベント開催時にバーカウンターとしておもてなしにも使えるようになっています。

執務エリア

次に執務エリアを紹介します。

当初構想では天井を抜いて開放感を出すことも検討したのですが、限りある予算をできるだけ従業員の使うものに積極的に投資することにしました。

そのため外観は普通のオフィスですが、長時間座っても疲れにくいヘッドレスト付きの椅子やダブルモニターでもスペースに余裕がある広い机、スタンディング会議室など、生産性向上への配慮が所々に細かくされています。また通路幅についても、移動しやすいようにそして移動時に他のエンジニアの集中力を妨げないように広めにとっています。

会議室

旧オフィスと比較すると会議室の数がかなり増えました！

集中して物事を検討する時は壁に囲まれた会議室を、アイディア出しなどは開放感のあるガラス張りの会議室を使うなど、用途によって使い分けられるようになってます。私はスタンディングデスクのある小さい会議室が好きです。

大型の会議室では今後、「Tier IV X Research Seminar」や「Tier IV Academy」などの各種イベントを開催予定です。機会があれば是非いらしてください。

ガレージ

新オフィスの目玉は1Fにあるガレージです。

以前は車両の整備などはオフィスから離れた別拠点で行っていましたが、車両とソフトウェアの開発を同一拠点で行えるようにすることで開発をよりスピードアップしています。

広い作業スペースでは車両の保管、メンテナンスだけでなくセンサーキャリブレーションの作業なども行えるようになっています。ガレージには、ティアフォーで開発している完全自動運転EV「Milee（マイリー）」や物流用ロボット「Logiee（ロージー）」、Autowareを搭載したJPN TAXI車両、遠隔操作用コンソールなどがあります。

リフレッシュスペース

続いてリフレッシュスペースです。 2Fはエントランスと会議室、リフレッシュスペースが割り当てられていますが、フロアの半分以上をリフレッシュスペースが占めています。広い空間で仕事を離れてゆっくり休憩できそうですね。

エントランスのシンプル、クールな洗練されたデザインとは対象的に、こちらは温かくリラックスできる雰囲気となってます。

個人的には隅っこの横になれるところがお気に入りです。昼寝やストレッチにも使えます。

時々Logieeが走り周って衛生用品を届けてくれることも・・・。

こちらはティアフォー社内で開発された、モノを運ぶための小型自動車両Loggieです！
現在開発を進めているAutowareの新アーキテクチャを搭載した自律移動のデモを、社内のリフレッシュエリアで行いました。#TierIV #自動運転 #物流 #Autoware pic.twitter.com/HTUdPsWjec

— Tier IV (@tier_iv_japan) September 16, 2020

もちろん今は難しいですが、MeetUpやHappyHourなどの社内外イベントの開催も想定しています。楽しみですね！

新オフィスでお待ちしております！

以上、新オフィス紹介でした。機会があれば是非見学に来てください！

またティアフォーでは、この快適かつ広いオフィスで一緒に「自動運転の民主化」を目指す仲間を絶賛募集しています。もしご興味があれば是非エントリーをご検討ください。

いつかこのオフィスで皆さんに会うのを楽しみにしています！！

www.youtube.com

自動運転における３次元での物体検出に画像データを活用する論文紹介

はじめまして、ティアフォーでパートタイムエンジニアをしている村松です。 

今回は、AutowareのPerceptionモジュールにおけるObject Recognitionを改善するために調査した内容について紹介します。 Autowareのアーキテクチャの詳細については過去の記事をご覧ください。

tech.tier4.jp

論文紹介

今回は、カメラ画像のみまたはカメラ画像とLiDAR点群の両方を活用した３次元での物体検出の論文を４つ紹介します。

Pseudo-LiDAR

まず最初に紹介するのは、カメラ画像のみを使って３次元物体検出をする手法です。この手法は、CVPR2019で採択された論文*1で、現在Teslaでも使われています。Teslaの取り組みについてはScaledML 2020でも発表されていますので適宜参照いただければと思います*2。

一般的に、カメラ画像のみを使った３次元物体検出の手法はLiDAR点群を使った手法と比較してパフォーマンスが劣っています。この論文中では、その原因は画像から得られる深度推定の精度ではなくデータ表現の方法に問題があるとしています。一般的に用いられている深度マップ（Depth Map）による表現では、

1. 物体の大きさが距離に依存する（例えば、遠くにあるものは小さく見える）
2. ２次元空間上で隣接するピクセルが３次元空間上でも隣接しているとは限らない

という二つの問題点があることを挙げています。そこで、この論文では深度マップを点群と同様の３次元空間（xyz）で表現されるデータ形式に変換することを提案しています。

本手法の流れは次のようになります。

1. 既存手法を用いて画像から深度推定を行う
2. 深度マップをカメラキャリブレーションのパラメータを用いて３次元空間に投影することでxyzの点群データ（Pseudo-LiDAR）に変換する
3. 得られた点群データ（Pseudo-LiDAR）について点群を入力データとする既存手法（PointPillarsなど）に与えることで３次元物体検出を行う

この手法の利点は、１ポツの深度推定と３ポツの３次元物体検出の手法を自由に変更できるというものです。そのため、既存の他の手法や将来のSotA(State of the Art)の手法に組み替えることが可能です。しかし欠点として、画像に対して深度推定と３次元物体検出の２つの手法を適用する必要があるため計算コストが大きくなること、そして点群を活用した３次元物体検出手法と比較した場合にパフォーマンスが劣っていることが挙げられます。

PointFusion

次に紹介するのは、カメラ画像とLiDAR点群の両方を活用した手法です。Zooxが公開した手法でCVPR2018で採択された論文*3で提案されています。なお、今年の１月には同社が本手法に関する米国特許を取得しています*4。

画像と点群の両方をモデルの入力とする場合、この２つのデータ形式が異なるという問題があります。そのため従来の手法では、点群の画像への射影や点群のVoxel化によりCNNを適用できるデータ形式へと変換してデータ形式を揃え、画像と点群の両方の特徴量を活用していました。しかし、このデータ変換によりデータの質が落ちてしまうという欠点がありました。そこで本手法では、点群のデータ変換を行わずに特徴量を抽出して画像と組み合わせるネットワークを提案しています。

本手法の流れは次のようになります。

1. 既存手法（YOLOなど）を用いて画像から物体検出を行い、検出領域（2D Bounding Box）に対応する点群・画像領域を抽出（クロップ）する（図のA, Bの入力）
2. クロップ点群・画像に対してそれぞれのネットワークを適用し特徴量を得る（図のA, B）
3. 得られた特徴量を用いて、3D Bounding Boxの８つの頂点位置を推定する（図のC, D）

この手法は点群・画像に対し、一般的に使われているPointNetやResNetといったネットワークを適用して特徴量を得ています。そのうち点群から得られる特徴量に関し、点ごとの特徴量(point-wise feature)を用いるかどうかで２つのモデルを提案しています。

点ごとの特徴量を使う場合（図のC）には、図中のpoint-wise feature、global featureとblock-4の３つの特徴量を結合してMLP（Multi-Layer Perceptron）を適用することで８つの頂点位置とスコアを推定しています。その中で、一番スコアの高い点に対応する結果を最終的な出力として採用しています。また、ここでスコアの学習の仕方については２つの方法を提案しています。１つ目はsupervised scoringとして各点が３次元領域内に含まれるかのバイナリ分類によって学習を行う方法です。２つ目はunsupervised scoringとして各点が３次元領域に含まれるかに関わらず良い位置推定となるものがスコアが高くなるように学習を行う方法です。

なお、点ごとの特徴量を使わない場合（図のD）には、図中のglobal featureとblock-4という２つの特徴量を結合してMLPを適用し８つの頂点位置を推定するというシンプルなモデルになっています。

本手法は、画像から検出された個々の物体それぞれに対してモデルを適用します。そのため欠点として、検出対象の物体数が増えると全体の実行時間が長くなってしまうこと、そして各物体間の位置や向きの関係を考慮できないということがあります。

Frustum PointNets

次に紹介するものも、カメラ画像とLiDAR点群の両方を活用した手法です。CVPR2019で採択された論文*5で、現在Lyftで使われている手法のベースになっていると思われるものです*6。

点群を扱う手法として2016年にPointNetが提案されたことにより、点群のクラス分類とセマンティックセグメンテーションのパフォーマンスは大きく向上しました。しかし、この手法を点群全体に適用すると計算コストが高くついてしまいます。そこで、この論文では画像を活用することで点群を効率よく処理する手法を提案しています。

提案手法の処理の流れとしては、

1. 既存手法（YOLOなど）を用いて画像から物体検出を行い、検出領域（2D Bounding Box）に対応する点群を抽出（クロップ）する（図のFrustum Proposal）
2. クロップ点群にセグメンテーションを行うことで、物体に対応する点群を得る（図の3D Instance Segmentation）
3. 得られた点群から3D Bounding Boxを推定する（図のAmodal 3D Box Estimation）

となります。また本手法では、点群の処理をよりロバストに行うために各処理の間で座標変換を行なっています。その中でも大きなポイントとして、T-Netにより点群の重心が原点となる座標系（下図のc）から物体の中心が原点となる座標系（下図のd）へと変換しています。

本手法についても、一つ前で紹介したPointFusionと同様に画像から検出された個々の物体に対してモデルを適用するため、物体の数に応じて実行時間が増えるという欠点があります。

PointPainting

最後に紹介するものも、カメラ画像とLiDAR点群を活用した手法です。nuTonomyが公開し、CVPR2020で採択された論文*7です。

本手法の処理の流れとしては、

1. 既存手法を用いて画像のセマンティックセグメンテーションを行う（図の①）
2. カメラキャリブレーションのパラメータを用いてセマンティックセグメンテーションの結果を点群に投影しクラス情報を付加する（図の②）
3. クラス情報が付加された点群を用い、既存手法による３次元物体検出を行う（図の③）

となります。

この手法は、画像から得た物体のクラス情報を点群に付与するため、PointFusion等の画像と点群の特徴量をネットワークの中間層で結合するような手法と比較し、センサーデバイスを変更した場合に生じるセンサー固有のパラメータ変化の影響を受けにくいと考えられます。 

また、CVPR 2020で開催された"Waymo Open Dataset Challenge"*8 で一位を取ったチームがPointPaintingを活用しています。解法のプレゼンはYoutubeで視聴できます*9。このチームは、PointPaintingの応用としてセマンティックセグメンテーションだけでなく2D Bounding Boxを用いた手法を考案しています。このチームによると、2D Bounding Boxを用いた場合でもセマンティックセグメンテーションとほぼ同様のパフォーマンスを出すことができています。

さいごに

今回は、カメラ画像のみまたはカメラ画像とLiDAR点群の両方を活用した３次元での物体検出の論文を４つ紹介しました。最新のアカデミックの論文においては、点群のみの手法の方が画像のみの手法や画像と点群を用いた手法より性能が優れています。しかし、より安心・安全な自動運転の実現に必要となる様々な環境でよりロバストな物体検出を可能とするためには、点群と画像の両方を活用する必要があると考えています。

ティアフォーではAutowareのPerceptionモジュールを更に改善するために、引き続き調査および研究開発を行なっており、Perception Algorithms Researcherやパートタイムエンジニアなどを絶賛募集していますので、もしご興味があれば是非エントリーをご検討ください。

tier4.jp

*1:Wang, Yan, et al. "Pseudo-lidar from visual depth estimation: Bridging the gap in 3d object detection for autonomous driving." Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition. 2019.

*2:https://youtu.be/hx7BXih7zx8

*3:Xu, Danfei, Dragomir Anguelov, and Ashesh Jain. "Pointfusion: Deep sensor fusion for 3d bounding box estimation." Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition. 2018.

*4:http://appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220200005485%22.PGNR.&OS=DN/20200005485&RS=DN/20200005485

*5:Qi, Charles R., et al. "Frustum pointnets for 3d object detection from rgb-d data." Proceedings of the IEEE conference on computer vision and pattern recognition. 2018.

*6:https://medium.com/lyftlevel5/leveraging-early-sensor-fusion-for-safer-autonomous-vehicles-36c9f58ddd75

*7:Vora, Sourabh, et al. "Pointpainting: Sequential fusion for 3d object detection." Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition. 2020.

*8:https://waymo.com/open/challenges

*9:https://youtu.be/9g9GsI33ol8

ティアフォーにおけるシミュレーションを用いたCIの取り組み

こんにちは、ティアフォーでWebプラットフォーム開発を行っている徳永です。

今回は、自動運転システムの開発にWebの技術がどのように使われているかの一例として、現在弊社で開発しているシミュレーションを用いたContinuous Integration（CI）システムの概要を紹介したいと思います｡

はじめに

警察庁の統計によると、2020年7月には24,951件の交通事故が発生しており、そのうち死亡事故が185件発生しています。

事故とまではいかなくとも、一歩間違えていれば事故になっていたヒヤリハットも発生しているでしょう。

自動運転車の走行においてはこういった事象が発生することは当然防がねばならず、人間が運転するよりもむしろ安全だという世界を作り出すことが一つのミッションであると言えます。

このミッションを達成するためには、事前に十分なテストを行い､ あらゆる状況に対応できるよう自動運転システムが進化していく必要があります。 

自動運転のテスト

自動運転においても、実車を用いたテストは重要です。実験場所に赴き、テストしたい状況を作り出し、自動運転車が意図通りに動作することを確認します。

しかしながら、雨や雪が降っている状況や、事故一歩手前のギリギリの状況など、全ての状況について実車を用いたテストを行うことは現実的ではありません。

一方、シミュレーションされた空間で車を走行させることができればこういった特殊なケースのテストも可能になりますし、もっとありきたりな状況であったとしても、実車を用いるより素早く多くの状況をテストすることが可能になります。

そのため、自動運転システムの開発ではシミュレータを用いたテストを行うことがとても重要となってきます。 

自動運転の仕組みとシミュレーションの分担

先日の記事でも紹介がありましたが、Autowareはいくつかのモジュールで構成されており、それぞれが役割・責務を負っています。

シミュレーションを用いてAutowareのテストを行う際、１種類のシミュレータで全ての機能をテストするよりも、それぞれのモジュールに対して最適なシミュレータを用いたテストを行うことで、より効率的にテストを実施することが可能です。

ティアフォーでは、以下のような分担でのシミュレーションの活用を考えています。

• Log Simulator － Perceptionモジュールのテスト
• 実際に計測したセンサやカメラなどのログデータを入力とし、それらの情報を基に周辺物体の検知・追跡・予測などを行うPerceptionモジュールに関するテストを行う。

• Planning Simulator － Planningモジュールのテスト
• 物体検知などのPerceptionに関する情報は理想的な情報をダミーで与え、車両のPlanningに関するテストを行う。

• E2E Simulator － 結合テスト 
• Game Engineを用いた仮想的な3Dマップ内で仮想車両を走行させることで、現実を模した状況において、Sensing, Perception, Planningなど全てを対象としたテストを行う。また、ランダムな状況で長時間走行させることで、事前に想定することが難しいエッジケースの探索も行う。

これらのシミュレーションは、Autoware開発者がローカル開発環境での動作確認などで用いたり、あるいは各機能の実装時にProduct Ownerが受け入れ確認用として用いることなどが考えられます。

シミュレーションとContinuous Integration（CI）

自動運転ソフトウェアの開発で重要なことの一つに、日々の開発によって変化するソフトウェアの安全性をどう担保するかが挙げられます｡ソフトウェアが日々変化していく際には、その過程で今まで対応できていたことに対応できなくなるなどのデグレード（デグレ）が発生することも考えられます。

新しくリリースされたソフトウェアが実際の車両に適用されるまでにこれらを検知して着実に修正するためには、継続的にテストを実施し、常に既存のテストに合格している状態を保ちながら開発を行うことが必要となってきます。

こういった継続的なテストを一般的にContinuous Integration（CI）と呼びます。

CIによる安全性担保

Autowareは様々なノードから構成されているため、何かの拍子にデグレが入るという可能性もあります。もし、想定している機能が正しく動いていない状態で実車試験を行うと、想定外の挙動で事故に繋がることも考えられます。

こういったことをなくすため、ティアフォーではシミュレーションによるCIパイプラインを構築し、Autowareの開発を進めていく際に、前章のPlanning Simulatorによるリグレッションテストを回しています。

シミュレーションにおいて、他の車両の動きやAutowareによる自動運転車がどのような動きを行えばよいかを定義したものをシナリオと呼びます。シミュレーションによるAutowareの動作テストはこのシナリオを基に行っています｡

テスト対象となるシナリオは、概ね以下のような流れにより登録されます。

1. 自動運転車の走行環境(ODD)を定める
2. ODDに準じたテスト要件を整理
3. テスト要件から、使用する地図を定め、シミュレーションを行うシナリオを作成
4. シナリオをシミュレータが読み込めるフォーマットで記述
5. 作成したシナリオをシミュレータで実行し､シナリオが意図通り動作しているか確認
6. CIとして登録し、以後リグレッションテストの対象シナリオとなる

現在、社内のCIシステムの中には、多くのシナリオが登録され、AutowareにPRが発行されたタイミングやリリースのタイミングで、自動的にリグレッションテストが回るようになっています｡ Autoware開発者は自身がコードの変更を行った際にリグレッションテストの結果を参照し、自身のコードがデグレを発生させてないか確認することができます｡

このように、CIを開発の軸に置くことによって、安全性を担保しつつもAutowareの開発スピードを落とさないような仕組みを日々試行錯誤しながら構築しています｡

CIのテスト結果を確認するWeb画面｡ CIのWebシステムも日々更新されています｡

シミュレーションの課題と技術的チャレンジ

シミュレーションを行うにあたり、解決すべき課題はたくさん存在します。

例えば、以下のような課題が存在します。

• シナリオの記述そのものに時間がかかる
• 特徴的なシナリオを事前に考えることに限界がある
• GameEngineのシミュレーションを行う場合、3Dマップ生成に関するコストが高い

こうした課題を解決するために、Ontologyを用いたシナリオ自動生成（Ontology based Scene Creation for the Development of Automated Vehicles）や、HD Map（Paracosm: A Language and Tool for Testing Autonomous Driving Systems）またはログデータからシナリオ自動生成する手法などの活用により、シナリオをシステム的に網羅的かつ低コストに生成できないかを現在検討しています。また、3DマップについてもODDなどの要件から自動生成ができないかといったことを検討しています｡

ティアフォーではCIとしてシミュレータを動作させるための基本的な部分の開発のみでなく、このような研究分野も調査し、より先進的で安全な自動運転の実現に向けた開発を日々行っています。

まとめ

ティアフォーでは、安全な自動運転社会の実現に向けて様々な取り組みを行なっています。本記事では幅広く紹介しましたが、それぞれの詳細な内容に関しては別の記事で紹介することができればと思います。

現在ティアフォーでは、自動運転システムはもちろん、それを支えるWebシステムを一緒に開発していく仲間も募集しています。もしご興味があれば是非エントリーをご検討ください！！

tier4.jp

プラットフォームOSの選び方

こんにちは、ティアフォーの伊藤です。

コロナで自粛中、テレワークに励んでいますが、つい時間を忘れて稼働時間が長くなってしまう今日この頃です。

私はAutowareのプラットフォーム開発を担当していまして、OSやROSといった低レイヤーの部分を中心に見ています。今回はそのOSの部分についてお話したいと思います。

さて、現在Autowareが公式にサポートしているOSはUbuntuになります。

Ubuntuはフリーで使用できる、とても有名なLinuxディストリビューションです。Autowareが研究段階の時から使用されています。

しかしながらAutowareを実用化するにあたり、今までなんとなく使ってきたUbuntuをこのまま使用し続けてよいのか、という議論がありました。

Linuxのディストリビューションには3つの流派があります。

• Red Hat系(Red Hat, CentOS, Fedoraなど)
• Debian系(Debian, Ubuntuなど)
• Slackware系(Slackwareなど)

AutowareではDebian系のUbuntuを使っていますので、まずはDebian系の中でDebian対Ubuntuを比較してどちらを採用すべきなのかを検討していきました。 

Debian vs Ubuntu

検討では様々な側面について比較しましたが、その代表的なものを紹介したいと思います。

1. ソフトウェアの安定性
   
   • Basic Foundation
     

     Debian	Ubuntu
     オリジナルのLinuxディストリビューション。 unstableブランチから開発開始→ ReleaseCriticalバグなし → testingブランチに昇格 → フリーズ/チェック/細かいバグ修正 → stableとしてリリース。 ReleaseCriticalバグがなくなるまでリリースはされない。 ボランティアが活動の主体。	Debianをフォークしたもの(testingブランチをベースに開発)。 ユーザ指向、最新のハードウェアに対応、安定性に不安？ Ubuntu独自の修正もあり安定性に不安？ Canonical社が活動の主体(ボランティアも協業)。

     Ubuntuは安定性の面で不安視されていますが、別にテストされていないわけではありません。テストはCanonical社が行っていますので、この点については同等と言えるかもしれません。
     
     
   • Linux kernel
     

     Debian	Ubuntu
     安定したkernelを導入する傾向。 ポイントリリースでkernelのバージョンを上げない。	新しめのkernelを導入する傾向。 ポイントリリースでkernelのバージョンを上げてくる(メジャーバージョンを上げてくることもある)。

     Ubuntuはポイントリリースでkernelのバージョンを上げてきますが、その際にドライバも更新されてしまい、今まで動いていたものが動かなくなる可能性があります。もっとも自動更新をオフにしておけばよいですが、うっかり設定し忘れすることがあり、これは十分なリスクになり得ます。この点についてはDebianのほうが優勢と言えるでしょう。
     
     【補足資料：Software release timeline】
     各ソフトウェアのリリース日の関連性を以下にまとめました。
     UbuntuはDebianに比べて新しいkernelを導入する傾向にあると思われます。
     

     

     
     【補足：CIPについて】
     なんとDebianには、CIP(Civil Infrastructure Platform)というDebianベースのSLTS(Super Long Term Support)があります。
     

     www.cip-project.org

     サポート期間が10年以上ありますが、対象はKernelとbusybox+αのみになります。そのため、このままでは対象が限定的ですので、他のパッケージもサポートを受ける場合、cybertrust社のEM Linux(有償)を導入する必要があります。または、自前でメンテナンスをしていく(セキュリティパッチをあてていく)ことになります。
     
     また10年以上も同じプラットフォームを使い続けるのか、という問題もありますが、工場等の設備には非常に適しているディストリビューションと言えるでしょう。
     
     なお、CIPとコラボレーションする予定のプロジェクトに、ELISA(Enabling Linux In Safety Application)というものがあり、こちらはセーフティ分野においてシステム構築や認証を支援するツールやプロセスを作成するオープンソースプロジェクトです。CIPを使うならばELISAに参画したり何らかの形でコラボレーションすると、機能安全に優れたアプリケーションを開発できるかもしれません。
     以上、少し話がそれてしまいました。
     

     elisa.tech

2. プロダクト計画との親和性
   
   • Release cycle

     Debian	Ubuntu
     リリースはあらかじめ計画されておらず、プロダクトのリリース計画が立てづらい、と言われている。 歴史的には2年おきのリリース。 ポイントリリースは不定期(ミスが判明してすぐ再リリースすることもある)。	リリースはあらかじめ計画されており、プロダクトのリリース計画が立てやすい。 ポイントリリースもあらかじめ計画されている。

     バグがなくなるまでなかなかリリースされないことが、かつてのDebianのデメリットでした。Ubuntuはそれを解消するために計画重視のリリースになっています。どちらかというと、ディストリビューションのリリース計画があらかじめ決まっていたほうが、プロダクトへの導入計画も立てやすいですね。
     
3. サポートおよびサポート体制
   
   • Support period
     

     Debian	Ubuntu
     フルサポート3年。 無償セキュリティアップデート2年。 対応はボランティア次第のところもある。 対応に関心のある企業がお金を出してサポートさせる場合もある。 プロプライエタリ系の対応は遅れる。	無償セキュリティアップデート5年。 追加で5年間の有償セキュリティアップデートを受けることが可能。 バックにCanonicalの強み。 プロプライエタリ系もCanonicalが手を回して対応させる場合もある。 NVIDIAのデフォルトOSがUbuntu。 Tensor FlowもUbuntuをサポート。

     サポートの面からするとバックにCanonicalがいるUbuntuのほうがサポートが厚そうに見えますね。
     
     
4. ROSとの親和性
   
   • Target platform

     Debian	Ubuntu
     ROSのサポート期間が2つのDebianサポート期間にまたがった場合は、最初のDebianのみをサポート。	ROS2の主要なプラットフォームはCanonicalのUbuntuリリース。

     ROS2のプライマリプラットフォームは、Ubuntuと定められています。Autoware AutoはROS2を使用していますので、自然にそれに習うという感じになるでしょうか。
     
     
   • Buildfarm

     Debian	Ubuntu
     自らCI環境を構築する必要性がある。 CIでエラーが発生した場合の対処とOSRFへの働きかけが必要。	Ubuntuの最新リリースバージョンでのみ、ROSディストリビューションで定期的にパッケージをビルドする。

     OSRF側でUbuntuを使用してCIを回しているので安心ですね。ただ、DebianでもCI環境を構築できますし、OSRF(Open Source Robotics Foundation)とCIに関するノウハウを共有できたりと、OSRFに貢献をしていきたい場合はDebianもよいかもしれません。
     
     
5. OTAとの親和性
   
   • Snap

     Debian	Ubuntu
     Snapは使用可能だが、OTA用のシステムは自ら構築する必要がある。	有償サポートでPrivate StoreやCIを使用可能。 Public Storeで問題なければ無料で使用可能。

     OTAでSnapを使用する場合、自前でソフトウェアのアップデートシステムを構築するパワーがあればDebianでもよいと思います。それに対し、Public Storeで一般公開しても問題がないとか、Private StoreやCIを手っ取り早く使いたい場合はUbuntuでもよいと思います。こちらは製品の開発方針に拠るところがありまして、優劣はつけ難いです。
     
     
6. 使用しているユーザー数
   
   • Enterprise(2020年8月現在)

     Debian	Ubuntu
     17.7%	45.3%

     Webサーバで採用されているLinuxのシェアになりますが、世間ではUbuntuが流行っているようです。
     
     【補足資料：Historical trends in the usage statistics of Linux subcategories for websites】
     

     
     ※引用：https://w3techs.com/technologies/history_details/os-linux

   • ROS1 2018 Version Survey
     

     Debian	Ubuntu
     約5%	約90%

     ROSを使用している開発者は、ほとんどがUbuntuユーザーです。圧倒的なシェアですが、オープンソースとして使ってもらいやすくするならUbuntuのほうがよさそうですね。
     
     【補足資料：ROS1 2018 Version Survey】
     Which operating system(s) do you actively use on your ROS1 development workstation?
     

     

     Which operating system(s) do you actively use on your ROS1 robots?
     

     

     ※情報元：https://discourse.ros.org/t/ros1-2018-version-survey-the-results-are-in/4547
     
     
7. プラットフォーム移行にかかるコスト
   
   • コスト

     Debian	Ubuntu
     かかる。 開発者全員に波及する問題。	ほぼゼロ。

     実はティアフォーの開発者は皆Ubuntuを使用しておりまして、Debianへ移行する場合は、大きなコスト(時間)がかかってしまいます。したがって、Ubuntuの場合は現状のまま使い続けていればよいのでコストはかかりませんね。

まとめ

以上、いろいろな側面からDebianとUbuntuを比較していきましたが、オープンソースとしてまずAutowareを普及させたいことを重視して、

• ROS2の主要なプラットフォームはUbuntuなので、まずはAutowareもUbuntu上で動作させるべき。
• Ubuntuは利用者数が多くCommunityも大きいので、Autowareの普及をより最大化できる。
• 途中でkernelが更新されるなどUbuntuにもデメリットはあるが、なんとか運用でカバーする。

という理由から現状はUbuntuを選択しています。

ただ、Ubuntuに替わるOSが台頭してくるようになれば、Autowareエコシステムの基盤になる可能性も十分にありますし、積極的に検討していきたいと考えています。今後とも様々なOSの動向を注視していきたいと思います。

最後に

ティアフォーではオープンソースの自動運転ソフトウェア「Autoware」だけではなく、Autowareを下支えするROSやプラットフォームOSの開発や性能改善等も行っております。今回はLinuxについて触れましたが、RTOSの研究や採用検討も進めております。

ティアフォーではAutowareを下支えすることができる優秀なプラットフォームエンジニアも募集していますので、もしご興味があれば是非エントリーをご検討ください。

tier4.jp

※本記事に記載されている会社名、製品名、サービス名は、当社または各社、各団体の商標もしくは登録商標です。

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

こんにちは。ティアフォーで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の活動に参加していただければと思います。

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