ROS2 rmwを切り替えてpub/sub通信しよう

こんにちは、ティアフォーエンジニアの村上です。今回は、ROS 2の通信機能に関するお話をしたいと思います。

自動運転OSSの「Autoware」は、ROS 2の上に構築されており*1、ROS 2はその通信 (出版/購読) backendとしてDDS (Data Distribution Service) を採用しています。多くのプロセスからなるAutowareにおいて、通信は注目すべき要素です。安心・安全な自動運転の実現のためには、Autowareの機能自体はもちろんのこと、通信のようなbackendについて、各systemに対するtuningをすることは不可欠です。 今回はそのROS 2/DDSについて調査した時のreportです。

ROS 2のProtocol Stack

従来のROS (便宜上ROS 1と呼称します) においては、独自の出版/購読の仕組みを実装していましたが、ROS 2ではDDSのAPI等をinterfaceとして、具体的な出版/購読の実装をROS本体から分離しました。このlayerこそがrmw (ROS MiddleWare)です。我々は各DDS実装に対するrmwを使用することで、application側でコードを変更することなく、各DDS実装を切り替えて使用することができます。

下記の図は、ROS 2の、特に通信に着目したProtocol Stackです。

backendは様々なものを考えることが可能で、layerというものではありません。例えばPOSIXで提供されているある種のprocess間通信、RTPSのような通信protocol、RTOS (Realtime OS) でサポートされている特殊な通信API、直接Network-on-Chipなどのhardwareを扱うなんてことも考えられるでしょう。
このように、rmwやrclcによって、個別の実装は隠蔽されており、各backendに適したrmwを使いわけることで、tuningを行うことができます。

ここまでの用語を整理しておきましょう。

RMW (ROS Middleware)

各DDS実装あるいは各backendの差を吸収、あるいは最適化を施している層。rclcに対して共通のinterfaceを提供する。

DDS (Data Distribution Service)

publish/subscribe programmingを実現するAPIを規定する。同じ立ち位置のAPIとしては、例えばSocketやMPIがある。

RTPS (Real Time Publish-Subscribe)

transport-layerよりも上層に位置する通信protocolの一つ。同じ立ち位置の仲間としてはHTTPなど。protocolの位置関係は、DDS API over [RTPS/UDP/IP/Ethernet]のようになる。

共有メモリを使用するrmw

Autowareの通信を考えるとき、いかにも最適化できそうなものとして、例えば以下のような特徴があります。

• 高性能sensor群からの大きなdataの通信が存在するが、出版者と購読者が1対1で、dataを出版後に参照することはない
• GPGPUを活用している認識以外の大部分の処理は、1 hostで処理されている計算機systemである

帯域量を求めるROS node間通信と応答時間を求めるROS node間通信は、Autowareにおいて混在していますが、今回は後者の応答時間を考えたいと思います。

応答時間に対するROS 1での最適化については、nodeletを積極的に使用していました。
nodeletは1 processの中で複数のnodeを実行する仕組みであり、その通信はpointer passing、所謂参照渡しとして実装できます。ROS 2においてもこの仕組みはexecutorという、より発展した形として提供されておりますが、これらが共通して抱えている課題点はapplication levelでの変更が必要な点です。nodeletを使用しない場合、ROS 1では、たとえ1 hostの計算機で閉じていようが、socket API over [TCP or UDP]経由の通信しかできません。

対してROS 2では、先に触れたrmwより下層の切り替えのみで最適化を行うことができ、applicationへの変更は一切必要ありません。

それでは実際に、今回の条件に適しているであろう、rmw_iceoryxを使用してみたいと思います。iceoryxはshared memory上でのdata転送を効率よく行う仕組みを提供しており、今回のようなlocalhost上限定の状況では、よい選択肢となります。このような転送はiceoryxの専売特許というわけではありませんので、実際にrmwの選定を行うときには、より広い選択肢があるでしょう。
(するどい方は、DDSのAPI等と濁したことに気がついているかもしれませんが、iceoryxはDDSのAPIを提供しているわけではありません。今回はrmwをI/Fとしますので、DDSに類する機能を内包さえしてしまえば、stackは厳密に積まれる必要はないのです。)

rmw_iceoryxの応答時間評価

rmw_iceoryxのbuild

環境は、Ubuntu 18.04 ROS 2 Eloquentです。
rmw_iceoryxはgithubからcloseしてきてください。

基本的には、rwm_icoryxのreadmeのInstallationを参考にしますが、最後のcolcon buildにおいて、下記2点に注意してください。

• sys/acl.hがない場合; apt install libacl1-dev
• rosidl_runtime_cのcmake用のconfigがない場合; rmw_iceoryxがmaster(foxy用)かもしれません。eloquent用のbranchに切り替えてください。

  cd src/rmw_iceoryx; git checkout -b eloquent origin/eloquent

サンプルプログラム

今回使用するpub/sub サンプルプログラムは、2MB/100msのtopicをpublish/subscribeさせ、その間のlatencyを出力するprogramです。この2MB/100msの数字は、高性能なsensor一つの出力を模しています。

実行

1. まず、shared memory及びその上のpub/subを監督する処理を立ち上げます。
   

   ./iceoryx_ws/install/iceoryx_posh/bin/iox-roudi

2. 次に、以下のようにRMW_IMPLEMENTATIONを指定して、sample programを起動します。
   

   source /opt/ros/eloquent/setup.bash
   source iceoryx_ws/install/setup.bash
   source pubsub/install/setup.bash
   RMW_IMPLEMENTATION=rmw_iceoryx_cpp ros2 launch comm inter_process_pubsub.launch.py

環境変数RMW_IMPLEMENTATIONを特に設定しなければ、default(fastrtps)による通信が行われます。また、latencyの出力については、launcherの設定で~/.ros/log/[日時]/launch.log以下に出すようにしています。

動作比較

応答速度としては、Fast RTPS > Ice Oryx > executorが予想されます。それぞれ応答速度と引き換えに制限が発生します。それは1 hostの制限であったり、単一障害点の発生であったり、published dataを参照するnode数 etc…であったりです。 また、使用したrmwはそれぞれdefaultの設定を使用しており、tuningの余地は十分にあります。

Fast RTPS (Default DDS)

上述の通り、何も設定しない状態でのpubl/subです。

Process内 (executor)

rmw層下の話からは逸れる話ですが、先に触れたprocess内のpubsubでは、実装やコーディング制限が伴う可能性はあるものの、それに見あうだけの非常に高速な応答性があります。今回はsingle thread executorを使用しました。起動方法としてはros2 launch comm intra_process_pubsub.launch.pyで起動できます。

Ice Oryx (固定長message)

Ice Oryx (可変長messega)

上述のサンプルプログラムのvariable_messageブランチで計測ができます。固定長との違いは、message typeでstd_msgs/ByteMultiArrayを指定している点です。

最後に

今回は実験として、rmwを切り替えた時の応答速度の変化を見てみました。話を簡単にするため、Autowareではなくsample programの上で観測しましたが、Autowareにおいても十分期待ができる結果です。また、rmwの切り替えだけという、非常に簡単な方法でtuningができるということも実感できました。ただし、観測結果については通信以外の部分の考慮をしていないため、厳密な評価ではないでしょう。それでも、大雑把にこれだけの差が出ることは、大変に興味深い結果です。

ティアフォーでは、今回ご紹介したように、自動運転ソフトウェアの開発だけでなく、自動運転という最先端のApplicationに対するECU/Middlewareの設計開発も行っており、自動運転の安心・安全を確保し「自動運転の民主化」をともに実現してくため、様々なエンジニア・リサーチャーを募集しています。もしご興味があればカジュアル面談も可能ですので以下のページからコンタクトいただければ幸いです。

tier4.jp

補遺、参照

1. ROS on DDS (ROS本家tech. blog)
2. ECU; 車載向けのcontroller(計算機)の意味。完全自動運転が要求するspecは、通常の車載system、自動運転支援systemと比べても幾分か高い。性能及び組み込み的な安全性を考慮する点は、非常に挑戦的である
3. rmw-[implementationの名前]; 各DDS/RTPSに対するrmw側実装。github上に存在はしても、Full Supportか否かは別途確認が必要がある点に注意
4. ゼロコピー転送; 通信時にコピーが発生しない転送。process間のshared memory上を介した実装がIce-Oryx。process内のpointer passingによる転送もゼロコピー転送。転送先のみがそのデータを使用する場合に有効で、応答速度やメモリ消費量が改善する。そうでない一般の通信はコピーが必要だが、大きいデータを扱う時は注意が必要。以下の例では700MBほどの地図データが何重にもコピーされてしまっている
   

*1:Autoware.AIはROSで動くように設計されていたがAutoware.AutoはROS 2上で動くように設計されている

Web.Auto 全体チーム社内開発レビュー会を開催しました

こんにちは、ティアフォーでWebサービス開発を行っている桑原です。

今回はティアフォーが開発をリードしている自動運転ソフトウェア「Autoware」の開発・実証実験を支え、自動運転サービスのために必要なWebの基盤を開発しているチームの活動と開発しているWebアプリケーションの概要を紹介します。

Web.Auto 全体チーム開発レビュー会

ティアフォーが開発しているWeb.Autoは、IoT・Cloud技術を用いて、様々な組織・個人が迅速かつ簡単に自動運転テクノロジーにアクセス可能となり、自動運転サービスに関する幅広い課題を解決できる基盤となることを目指しているサービスです。自動運転サービスを導入・運用するための多くのWebアプリケーションを開発しています。

今回 Web.Autoチームではこれらのサービスが顧客に届ける価値をより高めるために、自動運転ソフトウェアの開発から実際に自動運転サービスが届けられるまでのWebアプリケーションの利用例をユーザーストーリーとして作成して、各アプリケーションが実際に使われるイメージ全体を共有するチーム横断の開発レビュー会を行いました。

この会の目的としては以下の通りです。 

• チームで閉じた開発であったり、機能ベースの開発ではなく、どのようなものが顧客に取って価値になるか考え、プロダクトを市場に届けるところまで考えれるようになる
• 自分の担当するシステムやチームの中での部分最適な開発ではなく、横断的な開発ができるようになる

自動運転技術においては専門的な知識が多く、Webアプリケーションの開発でも多角的な観点から開発するのが難しくなってしまうので、この会を通して目指しているビジョンを再認識して、開発が促進できるように開催されました。

Web.Auto サービスの全体ユーザーストーリー

実際に自動運転のサービスを提供する場合、大きく分けて以下のフローを踏んで自動走行が可能であることを確認します。実際にはもっと多くの細かい手順がありますが、ここではWebアプリケーションで補助できる部分に限った大まかなユーザーストーリーとなっています。

1. 自動運転ソフトウェアの開発とテスト
2. 自動運転サービスのための事前準備
3. 実車試験
4. 自動運転サービスの運用と監視
5. 自動運転の走行分析

次に各手順に沿ってストーリーの詳細を紹介します。

1. 自動運転ソフトウェアの開発とテスト － Testbed & CI/CD Pipeline

自動運転ソフトウェア「Autoware」の開発・評価を、安全を担保しながら信頼性高くかつ効率的に行えるようにするための開発者向けのテスト評価フローです。

自動運転ソフトウェアの開発者が機能の改良を加え、テストを実行・評価して、実車テストまで行う作業の障壁を軽減するためのユーザーストーリーです。このセッションのレビュー会の内容は以下になります。

• 自動運転車に取り付けるセンサーのシミュレーション
• 自動運転ソフトウェア「Autoware」のシミュレーションテスト

1. 車両の構成などをまとめたファイルの作成
2. テストの要件からテストシナリオを作成
3. テストの実行
4. テスト結果の確認・リプレイ
5. Web.Auto基盤から接続車両に配信可能状態なパッケージを生成

シミュレーションのリプレイ画像

Webアプリケーションでこれらを確認することで、早く安全に実車テストを行うことを可能にします。

より詳細な内容は以下の記事で紹介しています。

tech.tier4.jp

2. 自動運転サービスのための事前準備 － Setup for Self-driving Services 

自動運転車サービスには配車管理コンソールへの車両の登録と接続の設定、自動運転ソフトウェアや車両アプリケーションのインストール、地図の設定が必要です。ユーザーストーリーとしては自動運転車サービスを運用する管理者のサービスの準備となります。このセッションのレビュー会の内容は以下の通りです。

• 配車管理コンソールでプロジェクトと走行環境の設定
• 車両と配車管理コンソールが接続できるように車両の証明書を発行し、車両に設定
• 自動運転車両で使用する地図を地図ツールから配車管理コンソールにアップロード
• 配車管理コンソールから車両へ「1. 自動運転ソフトウェアの開発とテスト － Testbed & CI/CD Pipeline」の手順で生成したパッケージを配信

地図ツール画面

これらのIoT・Cloud技術で車両の管理やサービスを扱う準備を一層簡単にすることで、自動運転サービスをより早くまた安全性高く提供することができます。

3. 実車試験 － Operation for Self-driving Vehicles

自動運転車の現地試験運用を迅速かつ安全に行えることを目指した、車両オペレーターによる開発車両運用中のフローです。現在は自動運転車の車両が安全に運行できるように車両オペレーターが実際に自動運転車両が正常に動いているかどうかを監視しているので、ここでは車両オペレータが監視して実車の走行をテストするユーザーストーリーになります。

ティアフォーが行っている実証実験では、実際にオペレーターが以下の走行を監視しています。

基準緩和申請を行えば時速20キロまでなら運転席無人の自動運転タクシーを運行できるようになりました。次回は時速30キロ、複数台、広域エリアでの運行を目指します。 pic.twitter.com/1myurA3tBq

— Shinpei Kato (加藤真平) (@ShinpeiKato) November 6, 2020

オペレーターが自動運転の状態監視を行えることで安全に実車のテスト走行を実行することが可能になっています。

4. 自動運転サービスの運用と監視 － Management for Self-driving Services

自動運転車サービスの運用を迅速に、安全に、簡単に行えるようにする運用管理者・遠隔監視者・車両オペレーター・サービスユーザー向けのサービス運用中のフローです。自動運転の運行事業者が自動運転車両のサービスを提供するエリアに関して、走行の環境や地図を更新して、自動運転車両の配車サービスを運用するというユーザーストーリーになります。今回のレビュー会では実車ではなく、自動運転の走行を模擬するシミュレータを使って仮想的にサービスを確認しました。

• 運行管理コンソールから自動運転車両を配車リクエスト
• 車載タブレットから出発ボタンを押して走行
• 運行管理コンソールから自動運転の走行の状態を確認
• 運行管理コンソールから車両のカメラ映像を確認

運行管理コンソール画面

車載タブレット画面

運行管理に関しては以下の記事で紹介しています。

tech.tier4.jp

遠隔監視・運転システム画面（※画面ははめ込みです）

また遠隔からの操縦に関する取り組みは以下の記事で紹介しています。

tech.tier4.jp

5. 自動運転の走行分析 － Inspection for Self-driving Services 

自動運転車サービスの運用や開発のフィードバックのための運用管理者・開発者向けのサービス監視・評価のフローです。運行事業者や自動運転ソフトウェアの開発者が蓄積された走行データを分析して、サービス運用および開発のフィードバックを行うことができるようになります。また、実際に走行したプローブデータを収集して蓄積し、分析しやすい形で走行ごとに車両の状態を振り返ることができます。運用管理者が走行テストや自動運転サービスが終了したのちに自動走行の安全性の分析をするユーザーストーリーなります。

走行履歴画面

まとめ

Web.Auto チームでは以上の他にも様々なシステムとアプリケーションを開発しています。今回は半日かけて自動運転のサービスを提供するまでのユーザーストーリーについてレビュー会を開催しました。本レビュー会は、テックカンファレンスのようにそれぞれのアプリケーションの担当が開発背景やシステムの概要を発表し、実際動くデモを発表する形で進めました。

このレビュー会を通して、自分が担当するシステム以外の開発がどのようにユーザーまでつながっているかを一貫して全Web.Autoチームで見ることでより良い改善を進めることができています。いずれは勉強会やテックカンファレンスなどで「自動運転の民主化」に向かって、今回説明したものよりさらに改善が進んだアプリケーション・システムを紹介していきたいと思います。

ティアフォーでは、自動運転の安心・安全を確保し「自動運転の民主化」をともに実現してくため、様々なエンジニア・リサーチャーを募集しています。もしご興味があればカジュアル面談も可能ですので以下のページからコンタクトいただければと思います。

tier4.jp

安全への取り組み：②自動運転の安心・安全について

こんにちは、ティアフォーのSafety Engineerの須永です。

ティアフォーの安全への取り組みを数回にわたって紹介していくシリーズの今回は第２回目になります。第１回目については以下をご参照下さい。

tech.tier4.jp

最近、社内では機能開発に向けた実車機能テストが増えてきています。公道での実験もあることから、より一層、安全意識を持った実験を行う必要が出てきています。そこでティアフォーでは安全に関する社内の勉強会を隔週で開き、社内における安全意識と知識の醸成を図っています。

そのような取り組みの中で今一度初心に帰り、「安心・安全って何だろう？」ということの確認と自動運転の安全を確保していくための私達のアプローチを確認しました。今回の記事では、その内容をお伝えしようと思います。

そもそも安心・安全ってなに？

ティアフォーの中でも安心・安全の議論はよくされます。しかし人によって言葉の解釈が異なるので、話がかみ合っていないことが多々見られました。似たような言葉に信頼や品質という言葉もあります。この違いって何でしょう？

いろいろな観点があるのでこれが絶対的な正解だとは言うことは難しいですが、まずは安心、安全、信頼の言葉の意味を社内で定義してみました。

　安心

• 主観的心理過程であり、定性的、相対的
• 人の思い込み
• 気にかかることがなく心が落ち着いていること

　安全

• 科学的根拠があり、定量的、客観的、絶対値比較
• 人に危害を加えない
• 危害または損傷・損害を受けるおそれのないこと

　信頼

• 科学的根拠があり、定量的、客観的、絶対値比較
• 与えられた機能を続ける
• 対象を高く評価し、任せられるという気持ちを抱く意を表す

安心なものは安全なのか？

安心とは、漢字の示す通り人の心が関与していて、不安を感じていなければそれは安心していると言えます。 つまり、安全でないものでも不安を感じなければ安心していると言えます。

安全なものは安心なのか？

安全とは、人やものに危害が加わるかどうかの確率です。危害が加わる確率が非常に低くくとも、その人にとって過去の経験から不安であったことを思い出させるようなことがあれば、それは安心しているとは言えなくなります。つまり、安全なものでも安心しているとは言えないものもあると言えます。

安心はどのように生まれるのか？

安心の反対である不安を人はどんな時に感じるかというと、期待を裏切られた時や悪い経験が惹起される時などに感じるもので、つまり現在あるいは過去に信頼を裏切られた結果として不安を感じるのだと思います。つまり、安心を得るためには信頼を裏切らない、信頼を回復して任せてもらえる状態にする、心を許してもらえる状態にすることが必要になってくると言えます。

安心・安全の関係性

安心≠安全だとすると、安心・安全の関係性について考えてみる必要が出てきます。

まず、何にせよ人が使う物に関して安全は必ず必要になります。その上でどう安心を提供するのかというと、その間に信頼が必要になってきます。ティアフォーでは、安全の上に信頼があって初めて安心が芽生えていくものだと考えました。 

安心・安全・信頼の関係性

安心・信頼を得るために

これらを整理した上で、自動運転について安全を確保した上でさらに必要な安心を得るためには、信頼を得ることが必要であるとしました。信頼を得るためのアプローチとして、

• 沢山走っても事故が起きないことを示し信頼を得ること
• 実際に体験してもらい期待を裏切らないこと

が重要だと考え、ティアフォーでは信頼とその先の安心を得ていくために、自動運転を安心だと感じてもらうべく、また実際に体験してもらうべく日本各地での実証実験を日々繰り広げている状態です。

また、安全に関するティアフォーの取り組みを知ってもらい、安心を感じてもらうための取り組みとして、８月に日本語版、10月に英語版のSafety Reportを日本で初めて発行しました。この中にも記載がある通り、ティアフォーでは様々な環境下で自動運転が安全に運行できるかを細心の注意を払いつつ確認しながら、「自動運転の民主化」に重要な信頼を得るための実証実験をこれまでに約70回実施してきました。

ティアフォーが行ってきた実証実験実績

これらの実験において、ヒヤリハットはあるものの事故にいたる実験はここまでゼロとなっています。このような積み上げを行うことで、「自動運転車は定められた走行領域（業界用語でいうODD：Operational Design Domain）内であれば安全に走れるんだ！」という安心感を提供できていると考えています。

安全と安全性の違い

ここまでは、言葉遊びではないですが何となく感覚的な話をしてきました。しかし、Deep Techを目指すティアフォーでは、ここまでの内容をエンジニアリング観点で定量的に表現できるように再整理をしています。

安心は人が感じるか感じないかが判断基準になるので、アンケートなどによって評価することはできるかもしれませんが、基準が個々人の中にあるため完全に定量的であるかというと難しいところです。

安全・信頼を定量的に示したい場合には、「安全性」や「信頼性」と言った言葉で表現ができます。 この２つの言葉は国際規格であるISO、日本規格であるJISにそれぞれ定めがあり、ティアフォーではこれらを基に「安全性」について以下の通りまとめ直しました。

　安全性

• 人への危害または損傷の危険性が許容可能な水準に抑えられている状態
• 許容可能でないリスクが存在しないこと
• 人はミスをするまたモノは壊れるのでゼロリスクはない
• リスク（人への危害）をどこまで許容するか決定する

この定義では、「安全性」はリスクをどこまで許容するかを決定し、その範囲内での安全を確保することになります。一般的にALARP (As Low As Reasonably Practicable) と言われる手法で合理的に実行可能な最低の水準までリスクを低減することを目標とします。

許容できるリスクの線引きをするということは、リスク＝事故をゼロにすることを必ずしも目標にはしないということになります。「自動運転が実現すれば事故は完全にゼロにできるのでは？」と思うかもしれないのですが、不慮の事態などを考えると現実的にはこれを完全に実現するのはかなり難しいです。世の中一般に定められたルールの関係や「安全性」を高めるためのコストの問題など様々な制約があり、この制約内では100%リスクを減らすことは極めて難しいのです。そこで、この制約の中でどこまで「安全性」を高められるのかを線引きしていくことが重要となります。

ALARPの概念図

現にいまの人間が運転する自動車に関しても、どんなに安全に気を付けてても事故は起きてしまっています。そのような状況でも自動車が公道を走れているのは、法律などのルールや最新の安全装置などで社会として許容可能な安全を確保し、許容できないところに関しては、保険などといった制度側にリスクを転嫁することでリスクがコントロールされているからです。

ALARPを定量的に示すためには、許容可能なリスクの発生確率や損害程度を定量的に定めて総合的に許容可能な範囲を決めていくことになります。

この考え方に基づいた考え方がリスクアセスメントの基本となっており、自動車の機能安全規格であるISO 26262における自動車安全水準 ASIL (Automotive Safety Integrity Level) だったり、自動車のセキュリティ規格であるISO 21434のCAL (Cybersecurity Assurance Level)になります。

許容領域概念図

安全とコストとの考え方も上記でご紹介したSafety Reportの中で触れていますので、是非確認いただければと思います。

なお「信頼性」については、ISOとJISの定めを基にティアフォーでは以下の通りまとめ直しました。

　信頼性　

• アイテムが与えられた条件で規定の期間中要求された機能を果たすことができる確率
• 対象の損失コストを源流から抑えるもの
• ＝Reliability（信頼性・信頼度）＝Dependability ＝ 含 保全性（maintainability）や可用性（availability） 　

「信頼性」に関しては、主にサービスとしての可用性の部分で関係してきます。せっかく自動運転にしたのに稼働率が低く、メンテナンス工数がかかりかえってコストがかかるというような事態になってしまうと、それこそ企業としての信頼を損ねることになってしまいます。こちらについては、またの機会に詳しくご紹介したいと思います。

おわりに

今回は、安心・安全・信頼の言葉の違いやそれを定量化した時の考え方などをまとめました。ティアフォーの安全に関する考え方やこれから実現していきたいことに関してはSafety Reportにまとまっていますので、是非一読いただければと思います。

ティアフォーでは、自動運転の安心・安全を確保し「自動運転の民主化」をともに実現してくため、様々なエンジニア・リサーチャーを募集しています。もしご興味があればカジュアル面談も可能ですので以下のページからコンタクトいただければ幸いです。

tier4.jp

2020年でKubernetesクラスターを3回再構築した話

こんにちは、Tier IVでMLOpsを担当している澁井（しぶい）です。
Tier IVには2020年9月に入社して、現在社歴2ヶ月です。Tier IVでは自動運転のための機械学習システムとオペレーションを開発しています。MLOpsでは機械学習のパイプライン開発から基盤構築、運用までをエンドツーエンドに行うのですが、MLOpsエンジニアは現状私一人で、寂しく気ままに開発しています。
前職ではECの会社でMLOpsとEdge AIを担当していました。基盤の一部にAWSのKubernetesマネージドサービスであるEKS (Elastic Kubernetes Service) を使っていたのですが、退職直前の2020年7月にそのKubernetesクラスターを再構築しました。2年越しで使っていたKubernetesクラスターが2クラスターあり、Kubernetesのコンポーネントがいろいろと古くなっていてアップデートができない状態だったため、再構築した次第です。結果として前職最後の仕事がKubernetesクラスターを2個作り直すというものになりました。作り直したKubernetesクラスターが元気に動いているか気になるところです。

さよならk8s

Kubernetesクラスター再構築はもう当面やらないだろうと思っていたのですが、つい最近またKubernetesクラスター（EKS Fargateクラスター）再構築をおこないました。何故Kubernetesクラスターを作り直さなければならなかったのか、AWS EKSやKubernetesの歩みとともに、振り返ってみたいと思います。

用語

Kubernetesを差す用語について、以下のように使い分けます。

• Kubernetes：Kubernetes一般
• Kubernetesクラスター：Kubernetesのクラスター
• AWS EKS：AWSのEKSサービス
• EKSクラスター：AWS EKSのKubernetesクラスター
• EKS Fargate：AWS Fargateで作ったEKSクラスター

Kubernetesと私

私はKubernetesを2016年頃から触り始めており、もうかれこれ4年もKubernetesとともに歩んできています。その間に私は転職を3回経験しましたが、仕事を辞めてもKubernetesだけは辞めずに使い続けています。検証目的を含めれば、私が作ってきたKubernetesクラスターの数は100を下らないと思います。

k8sと私

Kubernetesはコンテナをマルチサーバやクラウド環境で効率良く運用するためのコンテナオーケストレータです。Dockerに代表されるコンテナをサーバで動かし、複数のコンテナを複数のサーバで連携させるためのインフラや管理層を抽象化したミドルウェアがKubernetesになります。KubernetesはGoogle社内のBorgというコンテナオーケストレータプロジェクトが原点となっており、ここ数年で急速に発展、浸透してきているインフラOSSになります。私がKubernetesを使い始めた頃は構築スクリプトも用意されておらず、自分でネットワーク設計含めて手動でインストールする必要があったのですが、最近ではAWS、GCP、MS Azure等の主要クラウドでマネージドサービスが提供され、簡単に使い始められるようになっています。コンテナでシステムを作る用途ではとても便利で拡張性も高いミドルウェアなので、未経験の方はぜひ一度使ってみてください。

k8sの全体像

Tier IVではメインのインフラにAWSを使っています。その一部でKubernetesをマネージドサービスのAWS EKSで稼働させています。前職ではGCP＋AWSで開発しており、私はAWS EKSの経験もあります。実は前職の最後に作り直した2クラスターはEKSクラスターでした。作り直しの際にAWS EKSの使い方をいろいろと調べていたこともあり、Tier IVでもAWS EKSを使うことができて、とても馴染みやすかったです。再構築するまでは・・・。

ここ数年でKubernetesはどう変わったか

OSSとしてKubernetesの開発が始まってから6年ほど経っていますが、その間に多くの変化がありました。構築方法としてkubeadmが導入されたり、セキュリティとしてPod Security PolicyやNetwork Policyが導入されたり、LinuxだけでなくWindows Nodeがサポートされたりしています。Kubernetesの周辺機能でも、PrometheusとGrafanaによるログ監視機能、Istioによるサービスメッシュ、Knativeによるサーバレス基盤が開発され、KubernetesがProduction Readyなシステム基盤に成長しています。
Kubernetesの機能と同じくらい重要なのは、Kubernetesの実行環境としてマネージドサービスが主流になったことだと思います。インフラの主流がクラウドになっていったことと同様に、Kubernetesの主流もクラウド上のマネージドサービスになりました。クラウド上のマネージドサービスとして具体的なものを挙げると、AWSであればEKSやEKS Fargate、GCPであればGKE (Google Kubernetes Engine)、MS AzureであればAKS (Azure Kubernetes Service) です。それぞれのクラウドベンダーが自社クラウドに適したインテグレーションを進めており、Kubernetesのうまい使い方はマネージドサービスのうまい使い方になっていってます。
特にAWSではKubernetesのマネージドサービスとしてAWS EKSとEKS Fargateという2通りを提供しており、用途に合わせた選択が可能になっています。AWS EKSはKubernetesのコントロールプレーンのみをAWSが管理する方式で、Worker NodeやPod等のリソースはユーザが操作します。対してEKS Fargateではコントロールプレーンに加えてWorker NodeまでAWSが管理し、ユーザはノードレベルを気にせず純粋にKubernetesリソースの管理だけに集中できるサービスになっています。個人的にはノードインスタンス含めて管理したいので、AWS EKSのほうが好きですが、インスタンス管理が面倒であればEKS Fargateも良い選択肢です。

AWS EKS

AWS EKSではKubernetesクラスターの構築にはeksctlというツールを使います。ノードはAWS EC2を基盤とするため、オンデマンドインスタンスとスポットインスタンスをワークロードに応じて使い分けることでコスト削減ができます。メインのノードにはオンデマンドインスタンスによるマネージドノードを使いつつ、ジョブ等の一時的なタスクにはスポットインスタンスで立ち上げるというものになります。EKSクラスターのpodからAWSの他サービス（S3やRDS等々）を参照、操作するには、AWSのIAM (Identity and Access Management) ポリシーと連携するためにOIDC (Open ID Connect) を使用します。AWSでは各サービスへのアクセス許可をIAMで管理しますが、Kubernetesクラスターではリソースへのアクセス許可をRBAC (Role-based Access Control) で管理します。AWS IAMとKubernetes RBACを連動させる仕組みがOIDCになります。
これらのツールや構成は最近1,2年で整備されていったものです。それ以前に構築されたEKSクラスターでは導入できないツールもあります。たとえばeksctlというEKSクラスターの構築、管理ツールは、最初からeksctlでEKSクラスターを構築していないと使えないツールです。eksctlの登場以前に構築したクラスターにeksctlによるクラスター管理を追加導入することはできません。eksctlはyamlのマニフェストベースでEKSクラスターの構成を管理できるため、Infrastructure as Codeでクラスターを管理しようとすると必須のツールになります。EKSクラスターのIAM設定やノード管理もeksctlで実施できるため、EKSクラスター運用には欠かせないツールと言えます。
Kubernetesクラスターにデプロイされたリソースの管理にはWeave Fluxを使います。FluxはAWS EKS のKubernetesクラスターでGitopsを実現するツールで、Kubernetesクラスターのflux namespaceでリソースとして稼働します。FluxのDaemonsetがレポジトリをウォッチして、レポジトリにKubernetesマニフェストの更新があると自動的にKubernetesリソースに反映する仕組みです。Fluxは途中導入可能ですが、マニフェストがGit管理されていない状態から追加していくには手間がかかるのが実情です。
EKSクラスターを使うにはeksctlやFluxだけでなく、EKSクラスターと連携するAWSサービスを管理することも重要です。S3やRDSにデータを格納する構成や、外部からのアクセスを制限するセキュリティグループの適用等々、クラウドでKubernetesを使うためには周辺サービスとの連携が不可欠です。Tier IVではAWSの利用サービスはCloudFormationで構成管理し、Githubにマニフェストを保管する運用にしています。マニュアルで作ったAWSリソースをCloudFormation管理に置き換えることは困難であるため、やはりリソースを作る時点からCloudFormationを使うほうが便利です。
EKS クラスターをInfrastructure as Codeで管理するためにはeksctlによるKubernetesクラスター管理、FluxによるKubernetesリソース管理、CloudFormationによる周辺機能の管理が必要になるのです。

EKSとIaC

Kubernetesクラスター再構築

前置きが長くなりましたが、AWS EKSを効率的に安定運用するためには、eksctlやFluxを導入した運用設計を行う必要があります。既存のEKSクラスターがそれらのツールに対応していない場合、クラスター自体を作り直すことになります。
Tier IVでもどうやって作ったのかドキュメンテーションされていない（＝Infrastructure as Codeになっていない）EKS Fargateのクラスターがありました。社内向けのツールが稼働していることはわかっていました。EKSクラスターを運用管理していくために、私はクラスターを作りなおすことにしました。作り直したEKSクラスターをそのまま、今後私がTier IVで作る機械学習基盤に流用してしまおうという下心もありました。
私個人としては2020年に入って3回目（全部AWS EKS）のKubernetesクラスター再構築になります。前2回までのEKSクラスター再構築によって、AWS EKSを構築するために必要なツールは認識していました。会社やシステムの違いを吸収すれば簡単に再構築できると思っていました。しかしこの認識は裏切られました。

どう動いているのかわからないソフトウェア

最初に直面した課題は、既存のEKS Fargateクラスターで動いているソフトウェアがどう動いているのかわからないというものでした。EKS Fargateクラスター自体は半年くらい前に作られたものだったのですが、運用担当者がいない状態でした。急成長するテック・スタートアップでは稀によくあることですが、まずは作ることが優先で、運用は後回しになっている状態でした。
現状のKubernetesクラスターで動いているリソースや構成を整理する必要がありました。各namespaceで kubectl get ** や kubectl describe ** を叩きまわり、Kubernetesクラスター上で動いているリソースをyamlファイルにマニフェストとして出力することからはじめました。結果として以下のような構成であることが判明しました。

謎のEKS

Kubernetesクラスターで動くWebシステムとしてはオーソドックスなアーキテクチャーです。DjangoベースのWebフロントとRDS MySQLで構成されており、Django PodからPython KubernetesクライアントでJobを起動するワークフローになっています。マニフェストさえあれば再構築したEKSクラスターでも動かすことができそうに見えます。

謎の課金

インフラ再構築の基本として、ノードインスタンスとコンテナを整理していきました。既存のEKS Fargateクラスターで稼働しているPod数は3で、resource requestもCPUで合計5gに届かないくらいでした。EC2インスタンス換算でm5.largeタイプが3台程度で済むはずで、オンデマンドインスタンスでフル稼働しても$80以内に収まるものです。しかしなぜかAWSの課金コンソールでは月間$6,000程度発生する状態になっていました。
課金原因を調査すると、EKS FargateクラスターでKubernetes Nodeが100台ほど配備されていました。kubectl describe nodes でノード内のリソースを見てもPodは配備されておらず、不要なノードが延々と稼働している状態でした。EKS Fargateでは1ノードに1Podが稼働する構成になっていますが、Kubernetes Jobを起動すると、Jobを手動で消さない限り、CompleteしたPodがノードを専有し続ける仕様のようでした。Jobを起動すればするほど課金が膨らむ状態になっていたのです。前職でも似たようなKubernetes無駄課金がありましたが、転職先でも同じものを見るとは！？
この仕様はEKS Fargateクラスター特有のもので、EKSクラスターであれば発生しないものです。今回のEKSクラスター移行で不要ノードの問題は解決しました。

でもいろいろ書き換える必要があった

ソフトウェアのコードやKubernetesマニフェストを調べていってわかったことは、EKSクラスターだけでなくシステムの構成も見直したほうが良いということでした。具体的には以下のような課題が挙げられます。

1. インターネットからHTTPでアクセスされている。
   →　Route53でドメインを取ってACMで証明書を作って、HTTPSに変更する。
2. RDSのマスターユーザパスワードがGithubのプライベートレポジトリに入っている。
   →　AWS Secret Managerに移管する。
3. 監視がない。
   →　Datadog監視を追加する。
4. default namespaceにデプロイされている。
   →　プロダクト専用のnamespaceを切る。

これらをそれぞれで作成されるリソース単位でブレークダウンし、eksctlで管理するもの、Fluxで管理するもの、CloudFormationで管理するものに分類しました。EKSクラスター自体はeksctlのyamlマニフェスト、KubernetesリソースはFlux管理するKubernetesマニフェストになります。それ以外はすべてCloudFormationマニフェストにします。eksctlもKubernetesも、部分的にホストクラウドを操作する機能が備わっています。たとえばIngress ControllerはKubernetesからAWSのALBを配備します。このALBはCloudFormationの管理外になります。しかしALBへのアクセス制御は必要なため、CloudFormationでセキュリティグループのみ追加する必要があります。
新EKS クラスターの構築は以下の手順で実行しました。

1. CloudFormationでAWS VPCとサブネットを作成する。
2. eksctlでEKSクラスターを構築する。
3. KubernetesクラスターにFluxを導入する。
4. CloudFormationでRDSをスナップショットから作成する。
5. Fluxで必要なKubernetesリソースをデプロイする。
6. CloudFormationでRoute53、ACMからドメインと証明書を作成する。
7. CloudFormationでEKSクラスター、ALB、RDSへのアクセスをセキュリティグループで制限する。

eksctl、Flux、CloudFormationで管理するリソースとコンフィグレーションが一部重複するため、ツールを行ったり来たりしました。大変でしたが、新EKSクラスターを無事本番システムとして安定運用できる状態にしました。

まとめ

長くなりましたが、AWS EKSクラスターを年間で3回作り直した経験談でした。Kubernetesはここ数年で急速に発展したインフラMWであり、マネージドサービス含めてアーキテクチャーの変更が度々発生してきました。最近では仕様も安定しており、破壊的な変更も少なってきています。そのため、Kubernetes黎明期にチャレンジ精神で作ったKubernetesクラスターは再構築のタイミングにきているものがあると思います。ちょうど私はそのタイミングに3回遭遇しました。システム移行プロジェクトは生産性がなく、好きでないエンジニアも多いと思います。しかし私としては、地図のないダンジョンを探検しながら攻略していくゲームっぽさがあり、嫌いではなかったりします。
長くなりましたが、読んでいただきありがとうございました。

---

Tier IVでは、様々なエンジニアを募集しています。もしご興味があればカジュアル面談も可能ですので以下のページからコンタクトいただければ幸いです！

初の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