大規模非構造データ(Point Cloud)のリアルタイム通信

こんにちは、ティアフォーでフロントエンド開発を担当している田上です。

ティアフォーでは先日ご紹介したSREの信頼性への取り組みの一つとして、少人数でも信頼性が高く、効率的な開発ができるように技術選定会を実施しています。

今回は、最近技術選定会で取り上げた「Point cloud data(PCD)のように大きなサイズのデータを含んだROS TopicをAWS CloudからWebブラウザに転送する」仕組みと技術選定会の様子についてお話したいと思います。

なお、今回ご紹介するようにティアフォーには新しい技術や技術的なチャレンジを良しとする雰囲気、エンジニアの興味や好奇心を満たせる環境があります。ぜひ以下のページから募集職種のリストを見ていただき、興味を持った方は応募をしていただければと思います。

herp.careers

背景

Autowareを使った自動運転車両は車両に搭載したLiDARを用いて、周囲の物体の形状を点群データ(PCD: Point Cloud Data)の形式で取得します。PCDは、自動運転を行う上で非常に重要なデータです。例えば、自動運転車両が地図上のどこを走行しているかの推定（自己位置推定）に用いられたり、障害物の物体認識に用いられたりします。自動運転開発者は、自動運転時に発生した問題の原因を特定するために、PCDが適切に取得されたかどうか、あるいはPCDをもとに障害物が適切に認識されたかどうかを確認します。そのため、PCD自体やPCDをもとに認識した結果を可視化する仕組みは、自動運転開発においてとても重要です。

youtu.be

AutowareはROSをベースに構築されていますが、ROSにはRosbagと呼ばれるROS Topicをファイル(bagファイル）に保存する仕組みがあります。Autowareを使った自動運転車両はPCDや物体の認識結果、その他さまざまな自動運転時に用いたデータをRosbagを用いてbagファイルに保存しています。保存されたbagファイルは自動運転走行後に、クラウドにアップロードされます。自動運転開発者はクラウド上のbagファイルをダウンロードし、手元のPCでbagファイルの中身を可視化して自動運転時のセンサーのデータやAutowareの動作などを確認することができます。

通常、bagファイルの可視化にはRVizというソフトウェアが用いられます。RVizは優れた可視化ツールであり、ROSの開発者にとって一般的なソフトウェアです。ティアフォーでもRVizは当然のように使われていますが、問題点もあります。

RVizを使う上での問題点の一つは、可視化ツールとしてクラウド上の大量のデータを扱うのに適さないという点です。一台の自動運転車両は実証実験の際に一日あたり数百GByteを超えるbagデータを生成し、そのデータをクラウドに保存します。クラウド上のデータストアに存在する大量のデータのうち、どのデータが自分の興味のあるデータか探索したり、大きなサイズのファイルをダウンロードして手元のツールで表示するのは開発者にとってストレスのかかる作業です。

youtu.be

そのような問題に対処するため、現在ティアフォーではウェブブラウザ上でPCDを含んだbagファイルを可視化する仕組み（Webアプリ）を開発中です。可視化ツールをWebアプリにすることで複数のOS上でインストールレスで使用することができます。また車両の運行管理システムやbagファイルの管理システムと連携することで、開発者が可視化したいデータをより容易に見つけられるようになると期待できます。

課題

bagファイルの可視化をWebアプリで実現する際に気をつけるべき点があります。それは表示するデータ(PCDを含んだROS Topic）のサイズが大きく、クラウドからウェブブラウザに対してデータを転送する際にそれなりのネットワーク帯域を必要とすることです。1台のLiDARが取得する点群データの数は数万ポイントに及び、その点群の位置は常に変化します。そのためPCDのサイズは動画像データに匹敵する大きさになります。

ROSにはROS Bridgeと呼ばれる仕組みがあり、WebSocketを用いてROSのTopicをウェブブラウザに送信することができます。ROS Bridgeは便利な仕組みではありますが、WebSocket上でJSONフォーマット（テキスト形式）を用いてROS Topicを転送しているため、PCDのような大きなデータを転送する場合には必要以上に転送量が大きくなってしまいます。

そのため、帯域が制限された環境で使用しづらかったり、クラウドからのデータ転送量にかかる料金が増大することが懸念されます。

そこで、ROS Bridgeではない別のデータ転送方法によって、可視化に必要なデータだけをバイナリ形式でウェブブラウザに転送することを検討しました。
（また、今回は未検討ではありますが、PCDの転送には圧縮技術を適用することも求められると思います。）

実験システムの構築

ROS Bridgeに代わるデータの転送方法としてgRPC-webを使用できないか考えました。

gRPC-webを選んだ理由は

バイナリ形式でデータを転送できること
転送するデータの型定義ができること
サーバを開発する際に選択できるプログラミング言語が多いこと

などがあげられます。（またバックエンドのサービス間で使われる仕組みをフロントエンドに適用できるのは、単純に面白そうだと思ったのもあります）

実験のためAWS上に構築したシステム構成の概要が下の図です。

f:id:naokit00:20210215103453p:plain

クラウド側は構築するのが容易であるという理由でALBとECS(FARGATE)を組み合わせた構成にしました。Fargateのタスクとして二つのコンテナが動作しています。一つはEnvoyで、これはプロトコル変換（gRPC-webとgRPCの変換）を行っています。もう一つはBag serverと呼ばれるサーバで、これはbagファイルのデータをクライアントに転送するgRPCサーバです。

クライアント側はWebブラウザ上にThree.jsを使ったROS Topicの可視化アプリが動作しており、gRPC-webクライアントとしてBag serverと通信します。

実験システムの大まかな動作は次のようなものです。

Webブラウザ上の可視化アプリがgRPCのリクエストをALB/Envoyを経由してBag serverに送信する
Bag serverはクラウド上のマイクロサービス（図中のAPI Gateway）を呼び出して、S3上のbagファイルのkeyを取得する
Bag server はS3上のbagファイル中のROS Topicを読み込んで、可視化に必要なデータをgRPCのServer streaming でWebブラウザに送信する
Webブラウザ上の可視化アプリがgRPCのServer streamingのデータを受信して3次元的に可視化する

うまく動くとS3上のbagファイルのデータをWebブラウザ上で動画プレイヤーのような見せ方で表示できるというものです。

実際に試したところ構築した実験システムは期待通り動作することがわかりました。そこでこの仕組みを利用して良いかどうかを社内の技術選定会で問うことにしました。

技術選定会とその準備

ティアフォーでは技術選定会を行うことで、課題解決のためにどの技術を選ぶべきか決定しています。まず、起案者はある課題を解決するための複数の手法について次のことを準備します。

あらかじめ分類されたさまざまな観点（開発生産性、技術信頼性、コスト、セキュリティなど）の比較表を作成する
議論すべき重要なトピックをリストアップする

その上で社内の専門性の高いメンバーを集めて議論をすることで妥当な技術を選択する、といったやり方をしています。

今回はROS Bridgeの代替技術として、「gRPC-webを用いた仕組み」と「WebSocketとprotobufを用いた仕組み」の二つについて比較表を作成しました。

また重要なトピックとして次のような項目をリストアップしました。

PCDの転送効率
開発生産性
クラウド上のシステム構築の容易さ

重要なトピックとして挙げた項目について、gRPC-webは比較対象の技術と比べて概ね同等か、あるいは優位なものもあると私は考えました。

会議はバックエンドエンジニア、フロントエンドエンジニア、SREエンジニアを含む6名程度のメンバーを集めてオンラインで行われました。

１時間に満たない会議ではありましたが参加したメンバーから技術的な懸念や課題が示されて、追加で検討すべき項目がリストアップされました。

技術選定会後のFeedback

技術選定会で示された追加の検討項目は次のようなものでした。いくつかの項目は私が想定していなかったものもあり、技術的な検討を深める助けになりました。

gRPC-web自体は未成熟な技術であるから、やっぱり使えないとなる可能性は十分ある。その場合、代替技術に移行できるか？
データのアップロードに使用可能か？（Client streaming/Bi-directional streamingが可能か？）
想定される使用規模はどの程度か？ユースケースを明確にするべき
回線品質が悪い時の動作検証が必要。帯域を絞るなどして試すべき
運用コストの見積もりが必要

追加の検討項目のうち帯域制限された環境での動作検証を進めたところ、適切に動作させるためにはなんらかのフローコントロールの仕組みを導入する必要があることがわかりました。実験システムに単純なフローコントロールの仕組みを導入することで、帯域制限された環境下でも通信エラーを起こすことなく動作することが確認されました。

また、運用コスト見積もりの結果、転送量にかかる料金が支配的であることがわかりました。PCDの表示に限って言えば、点群の浮動小数点の精度を落としても問題ない（元データが単精度(4byte)であるのを半精度(2byte)に落としても表示上は問題ない）と考え、転送時にデータの精度を落とすことで転送量を削減するといった試みも行いました。

その他の追加の検討項目についても検討を進めたのち、後日再び技術選定会を開催しました。その会議においても新たに課題や懸念が示されましたが、技術選定としては承認されました。また、社内のシステムで使用されることと、３ヶ月後に技術的な振り返りをすることが決定されました。