大規模非構造データ(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名程度のメンバーを集めてオンラインで行われました。

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

技術選定会後のFeedback

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

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

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

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

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

まとめ

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

今回示した仕組みは、まずは社内の限定的な用途で使用される予定ですし、今後見直され使われなくなるかもしれません。ただし、検討や技術選定会をスピード感を持って進められたこと(他の業務を行いながら1ヶ月程度でできたこと)や、技術選定のプロセスを経験できたことは良かったと思います。

技術選定の資料作成に多くの時間は取れなかったので、技術選定会のメンバーは少ない情報の中で判断をすることになりましたが、前向きに検討してくれたと思います。

また、参加メンバーは技術的な懸念や課題を示しつつも、新しい技術や技術的なチャレンジを許容する姿勢を示していたと感じました。
今後、今回のような内容をテックブログだけでなく、以下の勉強会でも発表していきますのでこちらもぜひご覧ください。

tier4.connpass.com

LinuxのSCHED_DEADLINEスケジューラについての話

こんにちは、ティアフォーでパートタイムエンジニアをしている佐々木です。

今回はLinuxに搭載されているスケジューラの一つ、SCHED_DEADLINEについて紹介していきたいと思います。自動運転には多数のクリティカルタスクがあり、自動運転の安心・安全をしっかりと確保するためにはこのスケジューラを上手に設定することでこれらのクリティカルタスクが効率的にまた互いにコンフリクトすることなくリアルタイムに処理されることを担保する必要があります。なお、この記事で紹介するコードはLinuxカーネル5.4.0 (Ubuntu 20.04 LTSのベースカーネル) を元としています。

また、ティアフォーでは「自動運転の民主化」をともに実現していく、学生パートタイムエンジニアを常時募集しています。自動運転を実現するためには、Softwareに関してはOSからMiddlewareそしてApplicationに至るまで、Hardwareに関してはSensorからECUそして車両に至るまで異なるスキルを持つ様々な人々が不可欠です。もしご興味があれば以下のページからコンタクトいただければと思います。 tier4.jp

Linuxのスケジューラについて

まず、スケジューラとはなんぞや?という話から始めると、CPU上で実行するタスク(Linuxではスレッドがスケジュール単位)が複数あるとき、どのタスクから実行するかを決めるものです。 スケジュールの仕方のことをスケジューリングポリシーと呼び、Linuxには現在6つのスケジューリングポリシーが搭載されています。

搭載されているポリシーはkernel/sched/sched.hで確認することができます。

#define SCHED_NORMAL 0
#define SCHED_FIFO 1
#define SCHED_RR 2
#define SCHED_BATCH 3
#define SCHED_IDLE 5
#define SCHED_DEADLINE 6

SCHED_NORMAL (SCHED_OTHER)は通常のタスクに使われるスケジューラで、現在LinuxだとCompletely Fair Scheduler (CFS)という赤黒木を使用するできるだけ平等にタスクに実行時間を割り当てるスケジューラです。

SCHED_FIFOとSCHED_RRは静的優先度を使うスケジューリングポリシーです。

優先度が高いタスクが低いタスクより優先的にスケジュールされ、高優先度のタスクでコアが占有されている時、低優先度のタスクは実行されません。 逆に、低優先度のタスクが実行開始後に高優先度のタスクが来たら低優先度のタスクは直ちに中断し、高優先度のタスクが実行開始します。

SCHED_FIFOとSCHED_RRは0~99の優先度を持ち、双方この優先度に従ってスケジューリングを行いますが、挙動の違いは同じ優先度を持つタスクが複数存在する時、SCHED_FIFOはFirst-In-First-Out (FIFO)キューを用いて逐次実行し、SCHED_RRはRound-Robin (RR)を用いて設定したtime slice事に実行タスクを切り替えます。

SCHED_NORMALのタスクは優先度が100以上なので、SCHED_FIFOとSCHED_RRは任意のSCHED_NORMALタスクより優先され、SCHED_NORMALのタスクと比較してSCHED_FIFO/SCHED_RR/SCHED_DEADLINEのタスクをリアルタイムタスクと呼んだりします。

また、SCHED_FIFO/SCHED_RRはPOSIX.1-2001で規程されているので、pthread_setschedparam(3)を使って設定することが可能です。

SCHED_BATCH, SCHED_IDLEについては本記事では省略します。

Earliest Deadline First (EDF)

さて、本題のSCHED_DEADLINEについて説明していきます。

SCHED_DEADLINEはLinux 3.14以降に標準搭載されたEarliest Deadline First (EDF)というスケジューリングポリシーをベースとしたスケジューラで、設定されたデッドラインが一番近いものから実行していきます。

EDFの例を見てみましょう。

f:id:twertho:20210209113837p:plain

  • まずt=0にタスク1がリリースされ、他のタスクはないのでそのままスケジュールされます。
  • 次にt=1にタスク2がリリースされますが、デッドラインがタスク1のデッドラインより後ろなのでタスク1が終わるまで待機キューに入れられます。
  • t=2になりタスク1が実行終了するので、タスク2が実行を開始します。
  • t=3ではタスク3がリリースされ、今度はタスク3のデッドラインの方が近いので、タスク2は中断(プリエンプション)されます。
  • t=4でタスク3が終了するので、中断されていたタスク2が実行を再開します。

よって実行結果は図の最下部のようになります。 例はシングルコアでのスケジューリング例ですが、マルチコアでも同様のスケジューリングポリシーが使えます。

SCHED_DEADLINEの使用方法

ここではSCHED_DEADLINEの使い方を簡単に説明していきます。 基本は公式ドキュメントDeadline Task Schedulingを参照してください。

SCHED_DEADLINEポリシーはPOSIX規格ではないのでpthread_setschedparam(3)ではなくsched_setattr(2)を使います。(sched_setscheduler(2)sched_setparam(2)の組み合わせでも同様の設定ができます)

sched_setattr(2)の引数を説明していきます。

int sched_setattr(pid_t pid, const struct sched_attr *attr, unsigned int flags);
  • pid:ポリシーを設定する対象のpid/0の時は呼び出しスレッドが設定対象になる。
  • attr:スケジューリング属性(attribute)後述
  • flags:現状では何も意味がないので0を設定(ドキュメントには将来の機能拡張のために確保となっている)

さてスケジューリング属性attrの構造体であるstruct sched_attrは以下のようになっています。

struct sched_attr {
    __u32 size;

    __u32 sched_policy;
    __u64 sched_flags;

    /* SCHED_NORMAL, SCHED_BATCH */
    __s32 sched_nice;

    /* SCHED_FIFO, SCHED_RR */
    __u32 sched_priority;

    /* SCHED_DEADLINE (nsec) */
    __u64 sched_runtime;
    __u64 sched_deadline;
    __u64 sched_period;
};

コメントにも書かれている通りsched_nicesched_priorityはSCHED_DEADLINEでは使いません。

sched_priorityは0を設定するものの、内部ではSCHED_DEADLINEタスクは優先度が-1に設定されており、任意のSCHED_FIFO,SCHED_RRタスクよりも優先されます。

SCHED_DEADLINEでは実行時間sched_runtime、デッドラインsched_deadline、周期sched_periodを使います。

実際にSCHED_DEADLINEを使って実行時間10ms/デッドライン30ms/周期40msのタスクの設定してみると以下のようになります。

sched_attr attr;
attr.size = sizeof(attr);
attr.sched_flags = 0;
attr.sched_nice = 0;
attr.sched_priority = 0;

attr.sched_policy = SCHED_DEADLINE;
attr.sched_runtime = 10 * 1000 * 1000;
attr.sched_deadline = 30 * 1000 * 1000;
attr.sched_period = 40 * 1000 * 1000;
unsigned int flags = 0;
sched_setattr(0, &attr, flags);

なお、sched_periodは必須ではなく、設定しない場合sched_deadlineが周期として使われます。

SCHED_DEADLINEを使用する際の注意点

SCHED_DEADLINEを使うにはsched.hをインクルードして前セクションの通りに設定すれば基本的に動きます。(環境によってはlinux/sched.h)

が、環境によっていくつかハマりポイントがあるので、いくつか紹介していきます。

sched.hがない/インクルードしてもsched_setattrが見つからない

環境によってsched.hが見つからない/インクルードしてもsched_setattrコンパイルされない場合があります。(Ubuntu 18.04 LTS等)

自分の環境では以下のようにシステムコールを直打ち/構造体を直接宣言することで使用できました。

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <linux/unistd.h>
#include <linux/kernel.h>
#include <linux/types.h>
#include <sys/syscall.h>
#include <pthread.h>
#define SCHED_FLAG_DL_OVERRUN       0x04
#define gettid() syscall(__NR_gettid)

#define SCHED_DEADLINE  6

#ifdef __x86_64__
#define __NR_sched_setattr      314
#endif

#ifdef __i386__
#define __NR_sched_setattr      351
#endif

#ifdef __arm__
#define __NR_sched_setattr      380
#endif

#ifdef __aarch64__
#define __NR_sched_setattr      274
#endif

struct sched_attr {
    __u32 size;

    __u32 sched_policy;
    __u64 sched_flags;

    /* SCHED_NORMAL, SCHED_BATCH */
    __s32 sched_nice;

    /* SCHED_FIFO, SCHED_RR */
    __u32 sched_priority;

    /* SCHED_DEADLINE (nsec) */
    __u64 sched_runtime;
    __u64 sched_deadline;
    __u64 sched_period;
};

int sched_setattr(pid_t pid, const struct sched_attr *attr, unsigned int flags){
    return syscall(__NR_sched_setattr, pid, attr, flags);
}

SCHED_DEADLINEが設定されない

sched_setattrを使っているのにSCHED_DEADLINEポリシーが適用されていないという場合はsched_setattrの返り値をみてみます。 正しく設定されている場合は0、失敗した場合は-1を返します。

sched_setattrにはいくつかのerrnoが設定されてますがSCHED_DEADLINEを使う場合、以下の3つがよく遭遇します。

  • EPERM:root権限で実行していない。SCHED_DEADLINEはユーザー権限では動きません。
  • EINVAL:パラメータが正しく設定されてない、または周期等の値が210~263の間にない時にこのエラーがでます。
  • EBUSY:sched_setattrでSCHED_DEADLINEを設定する際、使用率=実行時間/周期の計算が行われます。この使用率をスケジューラが受け入れるだけの余裕があるかを計算し、無理な場合EBUSYを返します。これにより最低限のデッドライン保証をチェックしています。

特に複数のタスクをSCHED_DEADLINEポリシーで動かす場合EBUSYエラーが起こり易いので、可能ならデッドラインを長めに見積もると良いでしょう。

詳しくここのvalidationを知りたい方はここに実装があります。 まだRC版である最新の5.11系ではこのvalidationが高速化されるみたいです(参照)。

tasksetでCPU制限した場合に失敗する

SCHED_DEADLINEとtasksetを併用するとエラーを起こすケースがあります。

これはSCHED_DEADLINEのCPUハンドリングがtasksetによるマスキングに対応していないためと思われます。

実行するコアを限定したい場合はcgroupcpusetで設定することで上手く動きます。

Constant Bandwidth Server (CBS) について

さて、SCHED_DEADLINEはEDFポリシーに従ってスケジューリングしてくれますが、適切なdeadlineとruntimeを設定するのはユーザーの責任となっています。

設定が適切でなければ、仮にプロセスが無限loopなどで実行し続けてdeadlineを超過したとしても、何も起こらずCPUリソースが占有され続けることになります。

これを防ぐためにLinux4.16以降ではConstant Bandwidth Server (CBS)という機能がついています。

CBSは実行時間を制限するもので、SCHED_DEADLINEでは設定されたスレッドの実行時間がsched_runtimeを超えた場合、シグナルを送るように設定することができます。

attr.sched_flags=SCHED_FLAG_DL_OVERRUNと設定することで超過時にSIGXCPUというシグナルをスレッドに送ります。 このシグナルをハンドリングすることで超過対策を行うことができます。

またCBSにはreplenishというもう一つの機能があります。

例えばタスクAの実行中にデッドラインが近いタスクBがリリースされたことによりAは中断(プリエンプション)され、Bが終了しAを再開しようとしたときにAのデッドラインを過ぎていて本来ならばAを実行できないといったケースがあります。

このような中断はユーザが関知することができない以上、Linuxの実装ではタスク自体は実行時間が設定されたruntimeを超えない限り、デッドラインを超過していても最後まで実行させるというポリシーを取っています。

この最後まで実行させるために追加の実行時間を確保する仕組みがreplenishになります。

内容としては残りの実行時間(runtime-中断するまでに実行した時間)をruntimeとし1周期後のデッドラインをデッドラインと変更し、再度スケジューリングされます。

このCBSがあるため厳密なEDF通りの実行にならないことを考慮した上でSCHED_DEADLINEを使う必要があります。

SCHED_DEADLINEの実装

最後にSCHED_DEADLINEの実装を簡単にみてみましょう。

実装は主にkernel/sched/deadline.cに記述されています。

まず、SCHED_DEADLINEのランキューをみてみます。

struct dl_rq {
    struct rb_root_cached   root;
    unsigned long       dl_nr_running;
    struct dl_bw        dl_bw;
    u64         running_bw;
    u64         this_bw;
    u64         extra_bw;
    u64         bw_ratio;
};
  • root:ランキューを管理する構造体
  • dl_nr_running:デッドラインクラスのスレッドで実行可能な数
  • *_bw:このbwはbandwidthの略で使用率とほぼ同義で、先ほどのスケジューリング可能性のチェック等で使われます。

次にデッドラインクラスをみてみます。 デッドラインクラスはRTクラス(SCHED_FIFO/SCHED_RR)より上、最上位クラスのSTOPクラスより下になっています。

const struct sched_class dl_sched_class = {
    .next           = &rt_sched_class,
    .enqueue_task       = enqueue_task_dl,
    .dequeue_task       = dequeue_task_dl,
    .yield_task     = yield_task_dl,

    .check_preempt_curr = check_preempt_curr_dl,

    .pick_next_task     = pick_next_task_dl,
    .put_prev_task      = put_prev_task_dl,
    .set_next_task      = set_next_task_dl,

    .task_tick      = task_tick_dl,
    .task_fork              = task_fork_dl,

    .prio_changed           = prio_changed_dl,
    .switched_from      = switched_from_dl,
    .switched_to        = switched_to_dl,

    .update_curr        = update_curr_dl,
};

ここで重要なメンバを3つほどみていきます。

  • enqueue_task:タスク追加時の処理
  • dequeue_task:タスク削除時の処理
  • pick_next_task:次に実行するタスクの選択処理

タスク追加時の処理

static void
enqueue_dl_entity(struct sched_dl_entity *dl_se,
          struct sched_dl_entity *pi_se, int flags)
{
    BUG_ON(on_dl_rq(dl_se));

    //省略

    __enqueue_dl_entity(dl_se);
}
static void enqueue_task_dl(struct rq *rq, struct task_struct *p, int flags)
{
    struct task_struct *pi_task = rt_mutex_get_top_task(p);
    struct sched_dl_entity *pi_se = &p->dl;

    //省略

    enqueue_dl_entity(&p->dl, pi_se, flags);

    if (!task_current(rq, p) && p->nr_cpus_allowed > 1)
        enqueue_pushable_dl_task(rq, p);
}

DEADLINEタスク追加時の処理は、優先度継承、CBSに関連する例外処理等がありますが、重要な追加時の関数は__enqueue_dl_entityであることがわかります。

static void __enqueue_dl_entity(struct sched_dl_entity *dl_se)
{
    struct dl_rq *dl_rq = dl_rq_of_se(dl_se);
    struct rb_node **link = &dl_rq->root.rb_root.rb_node;
    struct rb_node *parent = NULL;
    struct sched_dl_entity *entry;
    int leftmost = 1;

    BUG_ON(!RB_EMPTY_NODE(&dl_se->rb_node));

    while (*link) {
        parent = *link;
        entry = rb_entry(parent, struct sched_dl_entity, rb_node);
        if (dl_time_before(dl_se->deadline, entry->deadline))
            link = &parent->rb_left;
        else {
            link = &parent->rb_right;
            leftmost = 0;
        }
    }

    rb_link_node(&dl_se->rb_node, parent, link);
    rb_insert_color_cached(&dl_se->rb_node, &dl_rq->root, leftmost);

    inc_dl_tasks(dl_se, dl_rq);
}

この実装からデッドラインクラスのランキューには通常タスクのCFSでも使われている赤黒木が使われていて、タスク構造体をデッドラインを基準に挿入していることがわかります。 赤黒木は安定した二分木なので、これによりデッドラインが一番近い(最小値)のタスクを選択しスケジュールすることが可能になっています。

タスク削除時の処理

削除に関する実装も同様に__dequeue_dl_entityを見ると赤黒木から終了したタスクの削除を行っていることがわかります。

static void __dequeue_dl_entity(struct sched_dl_entity *dl_se)
{
    struct dl_rq *dl_rq = dl_rq_of_se(dl_se);

    if (RB_EMPTY_NODE(&dl_se->rb_node))
        return;

    rb_erase_cached(&dl_se->rb_node, &dl_rq->root);
    RB_CLEAR_NODE(&dl_se->rb_node);

    dec_dl_tasks(dl_se, dl_rq);
}

次に実行するタスクの選択処理

最後に次に実行するタスクの選択処理をみてみましょう。

static void set_next_task_dl(struct rq *rq, struct task_struct *p)
{
    p->se.exec_start = rq_clock_task(rq);

    dequeue_pushable_dl_task(rq, p);

    if (hrtick_enabled(rq))
        start_hrtick_dl(rq, p);

    if (rq->curr->sched_class != &dl_sched_class)
        update_dl_rq_load_avg(rq_clock_pelt(rq), rq, 0);

    deadline_queue_push_tasks(rq);
}
static struct sched_dl_entity *pick_next_dl_entity(struct rq *rq,
                           struct dl_rq *dl_rq)
{
    struct rb_node *left = rb_first_cached(&dl_rq->root);

    if (!left)
        return NULL;

    return rb_entry(left, struct sched_dl_entity, rb_node);
}

static struct task_struct *
pick_next_task_dl(struct rq *rq, struct task_struct *prev, struct rq_flags *rf)
{
    struct sched_dl_entity *dl_se;
    struct dl_rq *dl_rq = &rq->dl;
    struct task_struct *p;

    WARN_ON_ONCE(prev || rf);

    if (!sched_dl_runnable(rq))
        return NULL;

    dl_se = pick_next_dl_entity(rq, dl_rq);
    BUG_ON(!dl_se);
    p = dl_task_of(dl_se);
    set_next_task_dl(rq, p);
    return p;
}

実装によると選択処理は5ステップから構成されています。

  • sched_dl_runnableでランキューを確認し、タスクが実行する可能か確認
  • pick_next_dl_entityで赤黒木からデッドラインが一番近いものを選択
  • dl_task_ofで選択したスケジュールから実行するタスク構造体ポインタを抽出
  • set_next_task_dlで実行開始時間を記録
  • 次に実行するタスク構造体ポインタを返す

CBSの処理が絡むとややこしいですが、それ以外の基本的な処理は赤黒木を使ったわかりやすい実装になっていることがわかります。

まとめ

今回はLinuxに搭載されているEDFスケジューラのSCHED_DEADLINEを簡単にみてみました。 なお今回は簡単にまとめる関係上Symmetric Multi-Processing(SMP)の処理部分は省いています。

リアルタイムに対応するためにRT_PREEMPT_PATCHを導入する手法も知られてはいますが、SCHED_DEADLINEを使う分には何も変更することなく値を設定するだけで簡単にEDFスケジューラがLinuxで使えるので、是非興味ある方はいじって見ると面白いと思います。

参照

www.kernel.org

linuxjm.osdn.jp

linuxjm.osdn.jp

西新宿における自動運転実証実験の振り返り

こんにちは、ティアフォーで自動運転システムを開発している木村と斉藤です。今回は2020年11月から12月にかけて行った西新宿における自動運転の実証実験の概要と振り返りをご紹介します。

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

tier4.jp

ティアフォーにおける自動運転の実証実験について

私たちが行う実証実験の目的は、お客様へのデモンストレーションから、新しい自動運転技術への挑戦、新たなオペレーション手法の検証などなど多岐にわたりますが、いずれも実証実験毎にそれぞれ具体的な目的を定めています。

今回の実証実験はビジネス視点ではサービスとしての成り立ちを見るための観点から行われましたが、私たち自動運転エンジニアとしての視点では3つの目的を持って取り組みました。1つ目は都心での実運用されている5Gを活用した遠隔自動運転の性能評価、2つ目はMobility Technologies様のアプリケーションと弊社運行管理システムとの連携、3つ目は新しいアーキテクチャとなったAutowareの公道検証となります。今回は、私たちが主に担当していた新しいアーキテクチャのAutowareを扱った自動運転システムを中心に振り返っていきたいと思います。ここでの新しいアーキテクチャのAutowareというものはAutoware Architecture Proposalとして私たちがAutoware Foundationに提案しているもので、このAutowareを用いた自動運転システムによって走行する車両を社外の方に公道でお見せするのは今回行われた西新宿における実証が初めてとなります。 

f:id:tkimura4:20210128143949p:plain

西新宿における実証実験について

①11月の実証実験

11月に西新宿での自動運転実証実験を行いました。実験は2020年11月5日(木)から2020年11月8日(日)までの計4日間行われました。11月5日(木)は関係者試乗、他3日間は一般の試乗者を募集して乗車していただきました。

11月の実証実験ではジャパンタクシー車両をベースにした自動運転車両を1台用いました。初日以外の3日間は京王プラザホテルから新宿中央公園までの1km程度のコースを走行しましたが、初日は京王プラザホテルからKDDI新宿ビル内を経由し、新宿中央公園の前を通って京王プラザホテルに戻る2km程度のコースを走行しました。

f:id:tkimura4:20210128143952p:plain

11月の実証実験で使用した走行ルート

実験中は安全のためドライバーとオペレーター(助手席)*1が乗り込んで非遠隔監視での自動運転走行を実施しました。それに加え、初日には運転席は無人で遠隔のドライバーが映像を通して監視しながら走行を行う遠隔型自動走行も行いました。

実証実験では東京都の宮坂副都知事にもご乗車いただき、「違和感のない乗り心地だった」という大変ありがたいコメントもいただきました。多くの関係者・一般試乗者の方に乗車いただきながら、西新宿という交通量の多い環境の中での実証実験を無事終えることが出来ました。

なお、11月の実証実験に関するより詳しい情報はこちらのプレスリリースをご覧ください。

tier4.jp

また、実証実験の様子は以下の動画をご覧ください。

www.youtube.com

www.youtube.com

②12月の実証実験

こちらの実証実験は西新宿にて2020年12月8日(火)から2020年12月23日(水)までの平日計12日間で行われ、そのうち7日間は関係者試乗、5日間は一般者試乗という形で試乗を乗せての自動運行を行いました。

11月の実証実験と同様に西新宿で実施しましたが、12月の実証実験では最大3台のジャパンタクシー車両を同時稼働させ、試乗者が京王プラザホテル/東京都庁第二庁舎ロータリー/新宿中央公園の3か所から出発地・目的地を選択可能という形での運行を行いました。そのため11月に行った実証実験と比較して、多数台の稼働や複数ルートの走行などの要素が加わり、更に難易度を上げての実施となりました。

f:id:tkimura4:20210128144000p:plain

12月の実証実験で使用した走行ルート

f:id:tkimura4:20210128143955p:plain

三台のジャパンタクシー

本実証実験には12日間で計100名を超える試乗者の方に参加いただき、多くの方に自動運転を体験していただく機会となりました。西新宿という難しい環境かつ難しい条件での実験を通し、ありがたい事に多くの課題も見つかりました。そうしたことを踏まえながら実証実験の振り返りをしていきたいと思います。

なお、12月の実証実験に関するより詳しい情報はこちらのプレスリリースをご覧ください。

tier4.jp

また、実証実験の様子は以下の動画をご覧ください。 

www.youtube.com

振り返り

実証実験では、西新宿という交通量も多く難しい環境の中で、多くの右左折を含むコースの走行、遠隔監視型自動走行、同時の複数台運行などの難しい条件が複合した実験となり、私たち開発者としても不安の尽きない日々でした。そのような中でも、自動運転をする上で特に難しかった/大変だったケースをいくつか紹介いたします。

障害物の誤検知

今回の実証実験でかなり悩まされたのが障害物を適切に検知することです。その中でも特に悩まされたのが歩道の段差や落ち葉です。

Autowareは、センサ情報から自動車・歩行者といった検出したいものを認識して結果を出力する「ホワイトリスト形式」、地面や雨・落ち葉といった検出したくないものを検出対象から除いて結果を出力する「ブラックリスト形式」の両方のアプローチで動作しています。この様に「ホワイトリスト形式」と「ブラックリスト形式」の両方を採用している理由は、例えば前方のトラックから急に荷物が落ちてくる、といったイレギュラーな事象にも対応するためです。

例えば今回の実証実験では、車道から新宿公園に入る際には20~30cmほどの段差がある歩道を通過する必要がありますが、その様な大きい段差がある場所では適切に地面除去できず、段差を障害物として認識してしまうことが起きていました。また、今回は秋の実験ということもあり落ち葉が非常に落ちやすい環境だったので、大量の落ち葉がまとまって落ちて来たり落ち葉が舞い上がったりすると大きな障害物としてみなされ、適切に除去出来ず障害物として認識されてしまうことが起きていました。今回の実証実験で明らかとなったこれらの課題を踏まえ、認識技術をより高精度な手法へと発展させていく取組を現在行っています。

交差点での素早い判断とスピーディな加速

西新宿で自動運転を行う上で、最も難しいことと言えばやはり交通量の多さが挙げられると思います。このような交通量が多い環境の中、今回の実証実験のコースには多くの右折が含まれていました。右折の中でも、特に難しい場所は右折信号のない交差点での右折です。右折信号がある場所では対向車両の流れが完全に途切れてから右折をすることが可能ですが、そうでない場所ではかなりシビアなタイミング判断が求められます。

ティアフォーの自動運転システムでは、安全のために前方車との衝突余裕時間(Time to Collision)を計算し、前方車との衝突がまず起きないコンサバティブな見積もりをして右折をします。これに加え今回の実証実験では、快適な乗り心地を実現するため車両の発進時には紳士的な加速を行う様に設定していました。しかしながら、このコンサバティブな見積もりに加えてこのような紳士的な加速を意識していては、交通量の多い西新宿の一部の交差点で時間帯によっては曲がるタイミングがなかなか得られないことがあり、信号の変わり目では乗り心地よりも素早い加速が求められるシーンがありました。このことから、西新宿のような交通量の多い交差点でもより自動運転サービスの可用性を高めることができるよう、人間の様にシーンに応じてコンサバティブさやアグレッシブさの加減を切り替えられるように今後取り組んでいきます。

複数の走行経路

ティアフォーが行ったこれまでの実験では走行経路が固定された1つに限られていましたしかし、今回の12月の実証実験ではより実サービスに近い設計となっており、3か所から出発地・目的地を選択可能となっていたことから、当日選ばれた組み合わせに応じて計6つの経路を走るという大変チャレンジングな取組を行いました。

Autowareでは信号や交差点、横断歩道、道路の優先関係などが紐付いた地図情報を用いて交通ルールを認識・判断しているため、実験で使用するコースを実際に走行してみて、問題なく走れるかどうか、地図情報が正しく現実と合っているかどうかなど様々なことを確認する必要があります。そのため、これまでの実証実験と同様の手法で全てを確認していたら、単純計算で6倍の時間がかかってしまいます。

そこで、今回は今まで以上にシミュレータをフルに活用することで、可能な限り現地に行かずに地図の検証等を行うことで時間を短縮し実証実験を乗り切りました。今後シミュレータの活用範囲をさらに広げていき、開発スピードもより効率化していきます。

車両個体差

最後に、大きな技術課題とまでは言えないものの地味に悩まされたのが車両個体差です。同じ種類の車両とはいえ、同じアクセルペダル、ブレーキペダルを踏んでも個体によって加減速の具合は全然異なりますし、同じハンドル操作をしても個体によってカーブの具合も全く異なります。また、タイヤ空気圧やブレーキパッドの経年劣化といった事象によっても車両の制御性は変わります。そういった個体差を吸収するためにそれぞれパラメタチューニングする必要があるのですが、どうしても実際に車両を動かす必要があるため、必要以上に時間が取られます。少し加減速の具合が違うだけでも思った以上に運転の滑らかさに影響するため、精細なチューニングが求められるのも中々難しいところでした。

今回の実証実験では台数も少なかったのでマンパワーで乗り切ることが出来ましたが、これが100台、1000台となってくると流石にワークしません。こちらの実証実験を通して、走っているうちに段々走行具合が滑らかになっていく様な自動チューニングの必要性を実感し、ティアフォーでも自動チューニングの仕組みを取り入れ始めています。

まとめ 

今回は西新宿の実証実験の概要と振り返りをご紹介しました。今回ご紹介したように、私たちの開発している自動運転ソフトウェアにはまだまだ課題が多くあります。これからも引き続きより良い自動運転のために精進していこうと思います。

謝辞

今回の自動運転実証実験は株式会社Mobility Technologies、株式会社ティアフォー、損害保険ジャパン株式会社、KDDI株式会社アイサンテクノロジー株式会社の5社の協業体制にて行いました。私たちが自動運転システムの開発に集中して取り組めたのも上記企業様の多大なご協力があってこそのことです。また、11月の実証実験は一般社団法人新宿副都心エリア環境改善委員会、12月の実証実験は東京都がそれぞれの実証実験の主催者として舞台を提供いただき実現しました。この場をお借りして深く感謝いたします。

*1:オペレーターというのは、自動運転システムで対応が困難かつ緊急性が求められる際に、自動運転システムに対する緊急停止などのソフトウェア的な介入や、ドライバーに対するオーバーライド指示を出す役割を指します

Visual SLAMの可能性と技術的チャレンジ

こんにちは、ティアフォーでVisual SLAMの研究をしている石田です。今回は、自動運転における自己位置推定に関してVisual SLAMの重要性と課題についてお話ししたいと思います。

www.youtube.com

Visual SLAMの要素技術であるVisual Odometryの例

Reference: Alismail et al., 2016
Dataset: Computer Vision Group - Dataset Download

自動運転における自己位置推定

車両が地図上のどこを走っているかを推定する技術(自己位置推定)は自動運転において欠かせない要素のひとつです。自分がどこを走っているかを把握できなければ迷子になってしまいますし、自分が走っている場所の先に何があるかを把握することも難しくなってしまいます。

現状のAutowareではレーザー光を用いたLiDARという巨大なセンサーを車両に搭載して自己位置推定を行っています。あらかじめ作っておいた地図の構造と、LiDARで得られた車両周囲の3次元構造を照らし合わせて自分がどこにいるのかを把握するというわけです。ジグソーパズルをはめ込むようにして位置推定をしていると考えるとイメージが湧きやすいかもしれません。

しかしながらLiDARベースの位置推定手法には大きく2つの欠点があります。

ひとつはLiDARそのものが非常に高価であることです。性能のいいものでは数千万円もするものがあります。これを世の中のクルマひとつひとつに取り付けて走らせることは現実的ではないため、なんらかの方法でコストを下げる必要があります。

もうひとつは構造特徴に乏しい場所では性能を発揮できないことです。絵柄のないジグソーパズルをイメージしてみてください。ピースひとつひとつが異なる形をしていたら、それぞれのピースは特定の場所にはまります。しかし、もし全てのピースが正方形だったら... これはもはやジグソーパズルの意味を成しませんよね。全てのピースがどこにでもはまってしまいます。同じように、構造的な特徴に乏しい場所(平原やトンネルなど)では、LiDARはどこにでも”はまって”しまうため、位置を一意に定めることができません。

これらの問題を解決するために現在私が取り組んでいるのがVisual SLAMという技術です。

Visual SLAMとは、視覚情報を用いて地図を作成し、同時に地図内での自己位置を推定する技術です。 また、あらかじめ作成しておいた地図に対して、その地図内でどこにいるのかを推定する relocalization という技術も活発に研究されています。

Visual SLAMの最大の利点は設備の安さです。Visual SLAMは基本的にカメラやIMU(物体の加速度や回転速度を測るセンサー)からの入力に基づいて動作します。これらのセンサーは安価に手に入るため、数万円で位置推定を始めることができます。また、Visual SLAMは視覚情報をもとに動作するため、構造特徴に乏しい場所であっても車の位置を推定することができます。さらに、カメラやIMUだけでなく、LiDARなどの他のセンサーと組み合わせることによってロバスト性を向上させ、さまざまな場所を走ることができるようになります。

自動運転ではあらかじめ作成しておいた地図との照合による位置推定が基本となるため、通常走行の範囲では relocalization が主体となります。しかし、LiDARがうまく動かない場所ではLiDARで地図を作ることが難しいため、Visual SLAMによって車両の位置推定をしつつLiDARによって地図を作ることも想定されています。

 

Visual SLAMの技術的チャレンジ

自動運転におけるVisual SLAMの最大の課題は、なんといってもそのロバスト性です。自動車はあらゆる環境のあらゆる場所を走ります。街中、ハイウェイ、峠、住宅街、晴れ、雨、雪、夜…

現在はODD(運行設計領域)対象外の環境もあるとはいえ、トンネルや逆光など、日常生活でよく目にするシーンの中にもVisual SLAMにとっては難しいものがあります。こういった場所で安定して動作する手法を設計し実装するのは至難の業ですが、技術者の腕の見せどころでもあります。

Visual SLAMにとって難しい環境は大きく分けて2つあります。ひとつは暗い場所、もうひとつは動く物体が多い場所です。

Visual SLAMは画像の情報から地図の3次元構造を計算し、その地図に対して自分がどの程度動いたかを推定することによって位置を把握します。画像からどのような情報を抽出するのかは手法によって大きく異なりますが、画像の特徴がよく現れている点(特徴点)を用いるものが一般的です。カメラから得られた画像1枚1枚から特徴点を抽出し、それらの幾何関係を利用して3次元地図を作ったり、位置推定を行ったりします。しかし、暗い場所ではそもそも画像から得られる情報が大きく減ってしまいますし、画像から有用な特徴点を抽出することも難しくなります。露光時間が長くなってブレが大きくなってしまいますし、カメラの感度が高くなって明るいものは極端に明るく映ってしまうためです。暗い場所でVisual SLAMを安定して動作させるためにはカメラ本体も含めた包括的な設計が必要になるため、これは非常にチャレンジングな問題だと言えます。

動く物体の扱いも大きな課題です。既存のVisual SLAMのほとんどは周囲の環境が動かないことを仮定しており、動く物体の扱いをあまり考慮できていません。このため、周囲に移動物体がたくさんあると、自分が動いているのか、それとも環境が動いているのかを判別できなくなってしまいます。自動車は周囲に動く物体がたくさんある場所をよく走るため、Visual SLAM単体で位置推定を行うことはせず、他のセンサーと組み合わせることが必須となります。

 

トンネル内で得られた画像の例
カメラの感度が上がっている一方で対向車のライトは非常に明るいため
カメラが扱える明るさを大きく超えてしまっている

自動運転車にとって最も難しい環境のひとつがトンネルです。トンネル内部にはGNSS(GPSなどの衛星測位システム)の信号が届きませんし、構造的な特徴に乏しいためLiDARの信頼性も低くなります。また、トンネルはVisual SLAMにとってもやはり課題のひとつです。

トンネルの内部は暗いため有用な視覚情報を得ることが難しいですし、全体が暗いのに対して周囲の車のライトは明るいため、ひとつの環境の中で非常に激しい光量変化が起きてしまいます。また、トンネル出入口では視野全体の明るさが一気に変わるため、やはり極端な光量変化に対応できる機材およびアルゴリズムが求められます。それに加えて、周囲の全ての車が移動物体なので、これらもうまく扱わなければなりません。

こういった難しい環境でも安心して走れるよう、我々はハードウェアからソフトウェア、さらにはインフラまでも対象として、日々研究開発を行っています。

 

Visual SLAMの面白さ

Visual SLAMはコンピュータビジョンの総合格闘技です。画像処理に対する基礎的な知識はもちろんとして、エピポーラ幾何や数理最適化に対する深い理解が要求されますし、IMUなど他のセンサと組み合わせる場合はカルマンフィルタや制御理論の知識も必要になります。また、Visual SLAMはやや大規模なシステムになることが多いため、コードをきれいに管理したり、綿密にテストしたりする能力も求められます。特に自動運転では非常に高い安全性が求められるため、他のVisual SLAMのアプリケーションと比べると徹底したテストが必要となります。

自動運転では、Visual SLAMは省電力デバイス上で高速に動作することが要求されるため、コンピュータの能力をフルに発揮するための実装力も必要になります。車に数千ワットの巨大なコンピュータを載せるわけにはいきませんし、かといってゆっくり動作すると車の運行性能や安全性が犠牲になってしまいます。先ほども述べたように、Visual SLAMの多くは画像から特徴点を抽出し、それらの幾何関係を利用して地図作成と位置推定を行います。カメラは1秒間に何十枚もの画像を出力しますし、1画像から得られる特徴点の数は数百から数千にもなります。自動運転では、省電力デバイスの上で、大量の特徴点から信頼できるものを選び出し、地図作成と位置推定をできるだけ高速に行う必要があるというわけです。また、地図を作っていくと誤差が蓄積してどんどん歪んでいってしまうため、この歪みを補正する処理も必要になります。小さなコンピュータで大量の情報を正確かつ高速に処理することがVisual SLAMの最大のチャレンジであり、これを徹底した安全管理と品質管理に基づいて自動車に載せていくことが私にとっての自動運転の面白さです。

Visual SLAMを自動運転に活用するためには、情報工学の理論から実装までありとあらゆる知識が必要とされます。自分がいままで学んできたことを全てつぎ込んでものをつくることが、この仕事の最大の面白さです。

もしあなたが自動運転車に乗る日が来たら、車のまわりを細かくチェックしてみてください。もしかしたらカメラがたくさんついていて、そのうしろでは私が作ったシステムが動いているかもしれません。

ティアフォーでは、自己位置推定に関するリサーチャーとエンジニアを絶賛募集しています!もしご興味ある方がいましたら、以下のURLからご応募ください!!

tier4.jp

自動運転を支えるWeb技術 - 信頼性への取り組み (SRE編)

こんにちは、ティアフォーでSREを担当している宇津井です。

2019年9月にSite Reliability Engineering(SRE)として入社して以来行ってきたことをざっと振り返った上で、自動運転の社会実装においてWeb系のエンジニアには何が求められるのかという答えを探っていきたいと思います。スタートアップ企業でどのようにSREの文化を作っていくのかという面でも何かの参考になるのではないかと考え筆を取っています。

と言いつつも重要なことなので最初に書いておきますが、ティアフォーのSREは私が一人目で入社して以来専任としてはずーっと一人でその役割を担ってきました。ようやく一緒に働く方を募集できる状態になりました。そのような背景もあってこのエントリーを書いています。もしご興味がある方は以下のCareersページからご連絡をお待ちしております。

tier4.jp

※SRE編とタイトルに書きましたが続編が出てくるかは分かりません。

まず、ティアフォーの場合はオープンソースの自動運転OS「Autoware」を開発する部門とそのAutowareを用いた自動運転エコシステムの導入・運用・開発をサポートするWeb.Auto(MaaS, CI/CD)を開発する部門が存在します。私はWeb.Autoの開発・運用に従事しています。

Web.Autoについてはサービスページ及び昨年行ったミートアップの発表資料をご覧ください。ミートアップ資料では組織・体制・採用している技術スタック等も垣間見えるようになっています。

web.auto

www.slideshare.net

入社当時の状況

当時のWeb.AutoはFMS「Fleet Management System / 配車管理プラットフォーム」、Maps「地図プラットフォーム」、Drive「遠隔監視・操作プラットフォーム」で構成されており、今考えると自動運転車両を走らせて遠隔監視ができるだけという非常にシンプルな構成でした。ざっくり表現するとパブリッククラウド(主にAWS)上にいくつかのマイクロサービスが展開されていました。

システム構成・アーキテクチャ等についてはAWS Summit 2019 (Tokyo) で発表された資料が参考になります*1。発表されたのは2019年6月の事で私は入社前でしたが、9月に入社したら資料の最後に記載されている今後に向けてというページの内容が全て完了していました。そのスピード感にとても関心したのを今でも覚えています。

また、私が入社した当時は実証実験を日本あるいは世界各地で行いつつもSREは不在で少数の開発部隊で運用・サービス実証を行なっていました。AutowareはStand-Aloneでも走行ができるのでWeb.Autoの主要機能のひとつであるFMS(Fleet Management System)が必要とされない実証実験さえ存在しました。

f:id:utsudai:20210119175407j:plain

実証実験の風景 〜 某キャラクターに似ているというmilee

システム監視だけを切り取って見てもAmazon CloudWatchでいくつかのMetrics Alertが設定されているだけでした。

要はシステムを安定的に動かすとか、高い品質を維持し続ける事、堅牢である事、パフォーマンス、キャパシティプランニング、拡張性といった信頼性に対する取り組みよりも開発スピードが優先されている状況だったということです(組織がシステムの信頼性を重要視していないというわけではなく、何を優先しているかという話です。重要なフェーズに差し掛かったから私がジョインしたわけです)。

SREとして整備した内容

システム把握

そのような中で入社してまず取り掛かったのはAWS Well-Architected Frameworkを参考に「運用の優秀性」、「セキュリティ」、「可用性」、「パフォーマンス効率」、「コスト最適化」の観点について現状どういった状態なのかを自己評価しそこからリスク分析を行いました。自分自身がどの様な状態でシステムが動いているのか知る良い機会になりましたし、上長にどのような順序で何を整備していくのかを説明するのにも客観的な視点が得られて大変役立ちました。

セキュリティ

まず手を付けたのがセキュリティです。弊社は今も昔もAWSをマルチアカウントで運用しています。アカウント数は入社当時で20個ほどあったと思います。スタートアップあるあるですがアクセス権は開発者が皆平等に強めの権限を持っていたりします。流石にrootアカウントは上長のみが保有していましたが、誰かが入社するとそれぞれのAWSアカウントにIAM Userを手作りしているような状況でした(他のAWSリソースは積極的にCloudFormationで作られていたけどなぜかここは手作業で微笑ましかったと記憶しています)。

アクセス権の管理は重要です。 然るべき権限が然るべき人に割り当てられているべきですし、アクセス状況は監査できる必要があります。権限付与も低いコストで行える必要があるし、与えられた権限の利用状況が監査できる必要もあります。別途ICTセクションでSingle Sign-On(SSO)環境を検討していた時期でID Providerが決め打ちできなかったので、AWS OrganizationsをベースにしてIAMロールによるクロスアカウントアクセス環境を構築しました。少し古い資料ですが、2017年のAWS Summitで発表された内容*2に近いものが書かれています。

監査・運用についてはAWS CloudTrail / AWS Config / Amazon GuardDutyがその役割をになっています。

AWS OrganizationsのService Control Policy(SCP)で全AWSアカウント共通の制限(上述のセキュリティ系設定を弄れないようにしたり)も実施しています。

開発者の中に元々セキュリティエンジニアとして活躍されていた方がいたこともあり、互いに協力しあって抱えているセキュリティリスクを洗い出したりもしました。この方はペネトレーションテストも実施していました、専門でやられている方が居たのは心強かったです。

モニタリングとログの統合管理 

セキュリティと並行して手を付けたのはモニタリングです。Amazon CloudWatchが悪いわけではないですが、Amazon CloudWatchだけでモニタリング体制を敷くのは結構面倒です。何かのマイクロサービスを追加する度にCloudWatchの設定をチェックして回るのはマンパワー的に無理があります。何かリソースが追加された時でもAuto Discoveryされ、手間なくモニタリングされる世界を作りたかったためDatadogを導入しました。

f:id:utsudai:20210119153839p:plain

また、ログ解析にも手間がかかる状態でした。ログは全てAmazon CloudWatch Logsに出力されているまでは良かったのですが、マイクロサービス故にユーザーからは一つのAPIをキックしているだけだったとしても、内部的にマイクロサービスがマイクロサービスを呼び出していたりしてログが分散してしまいます。何か問題が発生した時にこれらのログを見るのにも一苦労でしたし、AWS CLI v2の様にロググループをtailする機能もありませんでした。

そこでDatadogをログの統合管理基盤としても用いることにしました。既にシステムモニタリングとしてDatadogを採用していたこともあり、ツールを新たに増やさす要件を満たしにいった形です。

これで複数のマイクロサービスに跨がる処理もDatadogのFilterを駆使すれば処理の流れをリアルタイムに近い状態で追いかけれる状態になりました。

f:id:utsudai:20210119154032p:plain

ここまで出来るとAPM「Application Performance Management / Application Performance Monitoring」やマイクロサービス間の処理をTraceしたくなります。これもDatadogとAWS X-Rayを組み合わせることである程度実現できました。

更には手取り早くE2Eテストを自動化したかったのでDatadogのSynthetics Testも導入しました。E2EテストはDatadogで行うよりもフロントエンドエンジニアがJavaScriptでアプリケーションコードと同じコードベースで記述した方が良いという話が当初からあり、限定的な利用に止まっています。

ブラウザ上で発生したエラーのトラッキングも重要です。いくつか候補が上がりましたが弊社ではSentryを採用しました。これで実証実験の場でエラーが発生したとしても開発者側でトラッキングできる様になりました。

テンプレート・命名規則作り

何のテンプレートだよ、という声が聞こえてきそうですが様々なテンプレートを作成しました。

テンプレートの例としては以下の様な物です。

  • AWSリソースのタグ設計
  • 利用できるIP Subnet(CIDR)
  • 踏み台アカウントの作成方法をCFn化
  • AWS Transit Gatewayの作成基準
  • 各種Access TokenをAWS Secret Managerから取得する方法
  • モニタリングツール導入のコードサンプル
  • ログ管理のコードサンプル
  • AWSリソースの命名規則
  • 技術選定の基準
  • etc

一人で全てのマイクロサービスにルールを適用していくのは無理があるので何かルールを決めた際はどこかのサービスへ実装して、他のサービスは基本的にはそのコード化された方法を模倣してもらう作戦で凌いでいます。

将来的にはSREが基盤を作って各マイクロサービスへ自動的に反映される様な仕組みにしていきたいです。

技術選定は大きなトピックなのでこの記事では取り扱いません。

マルチテナンシーへの取り組み

AWSがマルチアカウントで運用されていることは上述しましたが、弊社では実証実験の拠点ごとにAWSアカウントを用意していました。この利点は拠点ごとに異なる要求・仕様に答えやすいし、とある拠点でのデプロイが他の拠点には影響しないという安全性がありました。自動運転業界の特色かもしれませんが、人・物を載せて運行することになるので多少コストがかかっても安全に倒すという傾向があります(ようやく自動運転が出てきた)。

ですが、全国で行われている実証実験は拠点ごとに捉えると1ヶ月のうち毎日行われる物でもありません。拠点ごとにAWSアカウントを作成して各々環境を作っていくとシステムリソースとコストの効率が非常に悪いのです。

大規模に展開していくことを見据えて早いうちに移行した方が良かろうという意思決定をして現在はマルチテナンシーで稼働しています。単純に統合すれば動くというわけでもなく、主に権限管理の仕組みだったりが必要でAWS側の基板だけではなく、APIからWeb画面まで色々な対応が必要でした(これは開発陣が尽力してくれました)。

法律・法令・ガイドライン・基準への準拠

自動運転という領域の特徴の一つとして日本国内だけで考えても道路交通法道路運送車両法道路法道路運送法といった国内法規に準拠する必要があります。法令だけでなく各省庁からガイドラインも発行されます。

また国際規格も目白押しで様々な規格を参照する必要があるのですが、この分野をSREが全て抑えるのは厳しいです。ティアフォーにはSafety Engineerが在籍しているので、彼らから必要とされた物を粛々と対応していくスタイルです(今後はもっと前のめりに対応する必要があります)。

ティアフォーとしては2020年8月に「Tier IV Safety Report 2020」を公開しましたので興味のある方は参照していただければと。

tier4.jp

テックブログにも安全への取り組みが連載されていますので合わせて紹介させていただきます。

tech.tier4.jp

tech.tier4.jp

信頼性に対する取り組み

上記以外にも取り組みは色々ありましたがシステムの稼働状況は大部分が自動計測できている状態になってきたので、いよいよ信頼性自体を定義する運びとなりました。

SLI / SLO / SLA

最終的には高いService Level Agreement(SLA)を定義してお客様に向けてシステムの稼働目標を提示できる様にしたいです。

SLAは近日中に掲げる見込みですが、これに先立って自動運転車両が安全に運行している事を担保するためにもまずはService Level Indicator(SLI) / Service Level Objective(SLO)の設定を行いました。

各マイクロサービスの開発者にヒアリングを行いつつ、開始当初は全社統一の基準を定めてスタートしました。最終プロダクトという状態ではないので自動運転で人命がかかっているとはいえ、99.999%の様なあまりにも高すぎる目標を掲げるのは理にかなっていません。自動運転の安全性は色々な側面で総当たり的に担保しています。この辺りは4半期毎にSLI / SLOの設定内容をレビューし、月毎に結果を取り纏め共有しあっています。

DatadogのSLO機能はリアルタイムでエラーバジェットの残り時間まで表示してくれるので重宝しています。

f:id:utsudai:20210119153300p:plain

DevOps文化の醸成

自動運転の実証実験にはアカデミックな側面も見え隠れします。開発者の中には大学からティアフォーに入社して活躍されている方もいます。そうなるとResearch&Developmentはやってきたけど企業でのOperations経験に乏しいみたいな方も在籍しています。

入社して2ヶ月後程度経過した時に「皆んなSREになろう」というサブタイトルでDevOpsとは何か、SLI / SLO / SLAの各指標の説明、モニタリングツールの説明等を行いました。SREを増員する時期ではなかったため開発者を全員巻き込むスタイルを敢行したわけです。

それ以外にも所属する全てのメンバーが共通認識を持つために社内勉強会、会議、実際の業務を通じて、トラブルシューティング、キャパシティプランニング等を行ってきています。

私自身の取り組みではないですがWeb.Autoに閉じず全社一丸となってDevOpsに取り組もうというムーブメントを上長がぶち上げたりもしています。自動運転の走行車両、各地で行われる実証実験までターゲットを拡げているので一筋縄ではいかない面もあると思います。Web.Autoは自動運転システムの導入・運用・開発の全てをサポートするサービスで、DevOpsを推進するサービスという側面を持っているのです。この活動には大きく期待しています。

Incident Management

各地で行われている実証実験ですがその目的は様々です。自動運転業界においては一昨年、昨年まではまだPoCの域に収まった実験が多かったと感じます。ですが、最近ではPoC「Proof of Concept」はある程度こなしてきたから今度はPoB「Proof of Business」だよというシーンが増えてきました。

そうなると自動運転のシステムでクリティカルな問題が発生した場合に組織として対処できる状態が求められます。これまではSlackに飛んできたアラートを緩く心地の良い温度感でSREと開発者が取り扱ってきました。これだとアラートに対してお見合いが発生してしまう事もあります。また、アラートへの対処方法が属人的になってしまったり、そもそもアラートに対応する人に偏りが出てきてしまう側面もあります。

そこでOn-Call、アラート発生後の対応・連絡フロー、ポストモーテムまで一気通貫した管理プロセスを構築しました。

ツールとしてはOpsGenieを導入しました。単位時間を区切ってSREと開発者全員が均等にOn-Callに対処する体制へ移行しています。OSSのグローバル企業という特色を活かし、いずれは24x365のOn-Call体制をFollow the Sunで実現したいと考えています。夜中の対応とかきついですからね。

f:id:utsudai:20210119152730p:plain

まとめ

OSSによって「自動運転の民主化」実現を目論むスタートアップにSREが入社してSREとして整備してきた事を振り返ってみました。スタートアップでは個人の業務範囲が広くなりがちなので、それこそエンジニアの仕事ではない様な事も取り組んだ気がします。ここに書いた事以外の事にも多くの時間を使ってきたと思いますがそれはそれで楽しい時間でした。

SREとして信頼性を武器に自動運転の社会実装を行いたいという方がいれば是非ともそのお力をお貸しください。業界自体が謎めいていると思うのでMeetup等を活用していただけると幸いです。

直近では1/29(金)19:00より「Tier IV 自動運転Web&Dataミートアップ」というタイトルで開催予定です!

tier4.connpass.com

 

自動運転システムの性能限界検知と環境センシングに関する取組み

こんにちは、ティアフォーで自動運転システムを開発している川端です。
今回はシステムの性能限界検知と環境センシングに関する取り組みの一部をご紹介します。

1、自動運転レベルとODDによる走行条件定義

【自動運転レベル】

自動運転のレベルはSAEの定義に沿う形で0から5までの6段階に分けられることが主流となっています*1。そのうち、レベル3以上の定義は以下のようになっています。

 

レベル3(条件付運転自動化)

運転自動化システムが全ての動的運転タスクを限定領域において持続的に実行。この際、作動継続が困難な場合への応答準備ができている利用者は、他の車両のシステムにおける動的運転タスクの実行システムに関連するシステム故障だけでなく、自動運転システムが出した介入の要求を受け容れ、適切に応答することが期待される

 

レベル4(高度運転自動化)

運転自動化システムが全ての動的運転タスク及び作動継続が困難な場合への応答を限定領域において持続的に実行。作動継続が困難な場合、利用者が介入の要求に応答することは期待されない

 

レベル5(完全運転自動化)

運転自動化システムが全ての動的運転タスク及び作動継続が困難な場合への応答を持続的かつ無制限に(すなわち、限定領域内ではない)実行作動継続が困難な場合、利用者が介入の要求に応答することは期待されない

 

すなわち、レベル4以上の自動運転の実現には、作動継続が困難な場合でも利用者による介入を求めず、自動運転システムが周囲環境やシステムの状態を検知し安全に運行停止措置へ移行する、等の応答が求められます。

では「作動継続が困難な場合」とはどのような場合でしょうか?ここでODDという概念が登場します。

 

【ODDによる走行条件定義】

ODD*2とは、自動運転システムが作動する前提となる走行環境条件のことで、以下のようにいくつかのカテゴリに分けて考えることができます(参考:Tier IV Safety Report 2020自動運転LAB

  1. 道路条件:高速/一般道路、車線数、車線や歩道の有無など走行する道路に関わる条件
  2. 地理条件:都市部/山間部/ジオフェンス内など周辺環境も含んで設定する条件
  3. 環境条件:天候/日照/昼夜/温度など環境に関わる条件
  4. その他:速度制限/インフラ協調の有無/オペレータの乗車要否/連続運行時間などの運行に関わる1〜3以外の条件 

ODDは全ての条件を満たす場合に自動運転システムが正常に作動するように定義されます。例として、先日国土交通省からリリースされた自動運転車(レベル3)に関する発表資料の主な走行環境条件で以下のような記載がありました。

環境条件(気象状況)

強い雨や降雪による悪天候、視界が著しく悪い濃霧又は日差しの強い日の逆光等により自動運行装置が周辺の車両や走路を認識できない状況でないこと

すなわち、上で登場した「作動継続が困難な場合」とは「走行環境が事前に定義されたODDの条件を満たさなくなった場合」と解釈することができます。このようにODDを事前に定義し、その条件の中でシステムを作動させることで、走行時の安全性を担保することが可能となります。

一方で、ODDの極端な例として悪天候(雨、雪)や霧、逆光を含まない明るい環境」と定義することもできますが、そのような場合には少しでも雨が降ったり、日が傾いて逆光になると(走行条件から外れて)システムが作動できなくなり、自動運転による本来のメリットを得ることが難しくなってしまいます。そのため自動運転システムの設計には、安全性を確保しつつ、同時にシステムの可用性(Availability)も高めていくことが求められています

 

以上を簡単にまとめますと、レベル4以上の自動運転を多くの環境で使えるものとしていくためには、システムに対して、

  • 時々刻々と変化する走行環境に対してODD条件の評価を行い、外れた場合には縮退運転やMRM*3などの応答を安全に実施できること
  • 雨、霧、逆光などを含む様々な走行環境で安全に走行できること

といった要素が求められます。

 

2、悪天候環境下で生じる課題と環境センシング 

日々の実証実験の中で様々な環境や気象条件に遭遇し課題が発生します。
特に日本の平均年間降水量は世界平均の約2倍と言われており、雨や霧に関連した課題に遭遇するケースが少なくありません。

例として、図1は急な降雨による気温低下と湿度上昇によってカメラのレンズ付近に水滴(結露)が付着し、光が回折することでカメラの画像にゴーストが生じている例です。

f:id:Kaz0227:20201224090759p:plain

図1:水滴(結露)により生じたゴースト

図2はLiDARが発する赤外線が空気中の水滴によって反射されることで、あたかも障害物が存在するように見えている例です。

f:id:Kaz0227:20201224094021p:plain

図2:空気中の水滴により生じたゴースト(点群の色は地面からの高さに相当)

これらの課題は日中の晴れた環境において生じることはほとんど無く、自然の環境変化によって偶発的に生じるため、対策の効果や再現性の確認、また体系的な評価を行うことが難しい領域となっています。

そのような状況を解決するための一つのアプローチとして、防災科学技術研究所茨城県つくば市)との共同研究を通して、制御された悪天候環境下での技術開発を進めています。 

本共同研究では図3に示すような車両を用いて、降雨強度、視程、照度といった環境パラメタのセンシング技術の開発と、環境パラメタとシステム性能の関係のモデル化にトライしています。 

f:id:Kaz0227:20201224100525p:plain

図3:R&D車両(通常の自動走行用のセンサに加えて、環境センシング用に照度計やディスドロメータ、降雨強度計などを搭載)

 

3、防災科学技術研究所との共同研究における実験内容の紹介 

防災科学技術研究所大型降雨実験施設は、天井に配置された直径の異なる4種類のノズルからの流量を個別に制御することで、雨粒の分布を制御しながら、降雨強度15(mm/h)から最大約300(mm/h)までの範囲 *4 で人工的に雨を降らせたり、霧を発生させることができます。また、地面からノズルまで約20(m)の高さがあるため、ノズルから吐出された水滴が落下に伴って拡散し、局在の少ないより自然の雨に近い環境を再現できるように設計されています。図4に降雨実験の様子を示しました。

f:id:Kaz0227:20201224102344j:plain

図4:降雨実験の様子(細かい雨粒で降雨強度50mm/hを再現)

図5に降雨強度を変更しながら取得したLiDAR点群(最上段、上面図)とカメラ画像の例を示します。今回実験に用いたLiDARは波長903nmの赤外線を周囲に向けて発し、物体からの反射光の位置と強度の情報をマッピングすることで3次元の情報を得ています。今回の例では降雨強度の値が大きい50(mm/h)よりも、細かい雨粒をより多く発生させた30(mm/h)の方がLiDARでの周囲認識の性能やカメラの視界が悪化する傾向が定性的に確認できました。また、図3に示した車両に搭載された計測機器で雨粒の落下速度や大きさの分布等も計測することができているため、上記の傾向を定量的に把握してモデル化するためのデータを蓄積することができています。

f:id:Kaz0227:20201224115459p:plain

図5:降雨強度によるLiDAR点群分布・カメラ画像の変化(点群の色は反射光強度に対応)

 

4、LiDAR点群による降雨強度推定

環境センシングの応用例として、自動運転車両で一般に使用されているLiDARの点群情報を用いて降雨強度を推定するモデルの開発事例を紹介します。雨粒の大きさや分布と赤外線の吸収や散乱強度の間には相関があることが知られており(参考文献1)、その相関を利用してBayesianモデリングの手法(参考文献2)に基づいてLiDAR点群(雨粒や周囲物体からの反射光の強度分布)と実測した降雨強度との関係をあらわす確率モデルを開発しています。Bayesianベースのモデルを用いることで推論結果の不確かさも同時に見積もることができるようになっています。 

f:id:Kaz0227:20201224160548p:plain

図6:開発中のモデルによる推論結果の例(プロットの色は真値が予め定めた±5%のエラー範囲の外に存在する可能性の大きさを示しています)

このように、制御された悪天候環境での系統的な評価やデータ収集を行うことで、自動運転で一般的に利用されているセンサを用いて環境パラメタの推定が行える例を示しました。このようにして得られる情報を用いて、自動運転システムを安全に運行させるために必須となる自己位置推定や物体認識といった機能の性能との対応を確認しながら、システム性能のモデル化を進めております。

今後は降雨強度だけでなく視程(MOR)、環境照度、路面の摩擦係数などODDを定義する上で重要な様々な環境パラメタに関して研究開発を進めていきます。 

 

5、まとめ

以上、性能限界検知に関する環境センシングの開発事例をご説明させて頂きました。
ここまでで述べましたように、自動運転の技術開発はソフトウェアに関する部分だけではなく、自然現象に関するセンシング技術や物理解析といった分野でも多くの知見が必要となりますし、不確かさを定量的に扱うための数理的な素養なども必要になります(確率的な推論モデルの構築に関してはティアフォーのリサーチャーと共同で実施しています)。ロボットやソフトウェア開発がご専門でない方でも、我々と一緒に新しい技術開発にチャレンジしたいというパッションをお持ちの方は下のリンクより是非ご連絡頂ければ幸いです。カジュアル面談も随時受け付けております。

tier4.jp

 

6.謝辞

この報告は、国立研究開発法人防災科学技術研究所との共同研究「悪天候環境における自立移動体の外界センシング性能の検証および向上等に関する研究」(令和2年度)の成果の一部です。特に、酒井直樹主任研究員、小林政美専門員には、降雨や実験に関する多くのご知見を共有頂きました。この場をお借りして深く感謝致します。 

以上

 

(参考文献)

1: A First course in Atmospheric Radiation, Grant W.Petty, Sundog Publishing,p.346-, 2006

2: Pattern recognition and machine learning, Christpher M. Bishop, Springer, 2006

*1:日本では公益社団法人 自動車技術会発行の資料において日本語で定義されています。

*2:Operational design domain、運行設計領域

*3:Minimal Risk Maneuver

*4:300(mm/h)は日本の過去のゲリラ豪雨でも最も強いクラスに相当

Unity for Industryでお話した事と紹介しきれなかった事

皆さんこんにちは、ティアフォーでSimulationチームに所属している織田です。

先日、「Unity for Industry」と言うウェビナーで、人生初の大勢の前(?)で話す実績を解除しました。

今回のTech Blogでは、その際にお話した事と紹介しきれなかった部分を書こうかと思います。

 

Unityだから出来た自動運転車両の設計を加速させた話

Unity for Industryではこのタイトルでお話をしました。

お話をかいつまみますと

  • 自動運転で使用するセンサの構成の検証が大変。
  • 検証が可能な場所の用意や、取れるデータを推測しながら構成しなければならなかった。
  • 上記の点を調整して、目的のデータが取れなければ再度構成の見直しを行う。
  • Unity/LGSVL-Simulatorを使用すれば、場所もデータ取りもシミュレーション可能になる。
  • 作ってみた。Unityだったので割と早めに実現できた。
  • センサ構成を検討する際に、このシミュレータを使用する事で事前に構成の検証が出来る様になった。
  • 良かったね。

上の様なお話をいたしました。

 

ウェビナーで紹介しきれなかった部分

下記の様な環境をシミュレーターで検証しました。

10m/30m/50m/100m先に人が立っていている場合、LiDARはどの様に人が立っているのを検知出来るか?

100m先まで人がいる状態

f:id:odaka_tier4:20201221135021p:plain

100m先まで人が並んでます

この時の50m地点の人のLiDARの当たり具合

f:id:odaka_tier4:20201221135148p:plain

50m先だと2lineくらい当たってますね

同様に、この時の30m地点の人々

f:id:odaka_tier4:20201221135317p:plain

30m先では6lineくらい当たってますね

やはり100m先を見通せる広くて平らな環境と言うのは現実環境ではすぐに用意できないのでこの環境の様な検証はシミュレーターが向いていますね。

30m先の人々と50m先の人々を比較してみると、50m先の人々の方がLiDARのスキャンの間隔が開いてしまい、検知可能な点が少なくなってしまう事が判別できます。

 

10%の勾配で30〜35m先の坂の上に立っている人はLiDARでどの様に検知されるか?

f:id:odaka_tier4:20201221135757p:plain

10%勾配で30〜34mに人々が立っています

30〜34m付近にいる人々

f:id:odaka_tier4:20201221140122p:plain

30mから1m毎、34mまで並んで立っています

こちらのケースも、実世界では10%勾配に見事にマッチする環境を探すのは難しいですが、シミュレーターでは勾配を変更した場合のケースも値を変更することですぐに用意できます。

30〜34m先の人々には勾配の先にいると言う事もあってか、先の平地での30m先の人に比べると全くと言って良い程LiDARのスキャンが届かない様に見えます。

 

LiDARを車両のどの位置に、どの様な角度で設置するとどの範囲を測定できるのか?

f:id:odaka_tier4:20201221140459p:plain

計測範囲を可視化した図

ここでは、追加で作成したLiDARが測位する範囲を可視化させた物を設定する事で測定範囲を可視化しています。緑、黄、青の範囲の外側だと、車両が停止している場合に計測できない領域となる箇所が一目瞭然ですね。

 

課題

ゲームエンジン/センサシミュレーションでもまだ解決出来ない問題はあるのです。

悪天候

雨/霧等、ゲームエンジンでは画面上のビジュアルに向けた実装は多いですが、センサで取れるデータと言うものに関しての考慮はやはりされていないので、どの様に実装するのかは現状の課題になっています。


とは言え、何も手が無い訳ではなくて例えばUber Advanced Technology GroupがLiDARsimと言う形で、現実的なセンサのデータに近付けるといった研究をされていたりします*1

こちらを応用したりすれば、解決していける課題になっていくのではないかと今は考えてます。

 

データを効率良く捌く

センサシミュレーションで取るデータは現状

  • LiDARによる点群計測

が主なのですが、計測する為の点群のデータ量はかなり膨大で、且つ高頻度で効率良く処理する方法も課題となっています。

 

まとめ

現実では用意が難しい環境でもシミュレータによって検証出来るようになり、事前にどの様なデータが取れそうか?等が容易に検証できる様になりました。

この辺はゲームエンジンの面目躍如です。

又、新たなセンサの構成を検証する際にもリアルタイム且つ柔軟にセンサの確認が出来るのもゲームエンジンだから可能になったと言えるでしょう。

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

 

tier4.jp

 

又、2020年1月29日(金)の夕方にはTech Meetupを開催する予定ですので、もしお時間が合う方はご参加下さい。

tier4.connpass.com