Turing Tech Talk 第9回「自動運転車両のハードウェア＆システム完全解剖」

チューリングの最新の研究開発内容を担当するエンジニアが直接解説するオンラインイベント「Turing Tech Talk」。

2024年12月23日に開催した第9回は「自動運転車両のハードウェア＆システム完全解剖」がテーマとなりました。AIモデルを搭載した車両を動かすためのハードウェアやソフトウェアにフォーカスして、その秘密を当社CTOの山口祐、Driving Softwareチーム シニアソフトウェアエンジニアの徳弘賢人が、実際の車両を見ながら解説を行いました。当日の模様をイベントレポートとしてお届けいたします。

山口：皆さんこんにちは。第9回のTuring Tech Talkは普段とよそおいを変えて、私たちの車両開発研究の拠点である平和島ラボからお送りしています。

今、私たちの後ろに見えている車。こちらが今日ご紹介する自動運転の車両です。今回は、自動運転の車両がどんな構成になっているのか、どんな開発を行っているのか深掘りしていきたいと思います。

それでは、登壇者の紹介です。本日は、Driving Softwareチームの徳弘賢人に来てもらっています。簡単に自己紹介をお願いします。

徳弘：チューリングのDriving Softwareチームでシニアソフトウェアエンジニアをやっている徳弘といいます。2022年に新卒でチューリングに入社して以来、自動運転に関わるソフトウェアや車載のシステムの設計開発を担当しています。今日はよろしくお願いします。

自動運転車にはどんなシステムが搭載されているのか？

山口：私たちチューリングでは、End-to-End自動運転モデル「TD-1」を開発しています。今日は「自動運転車両のハードウェア＆システム徹底解剖」ということで、AI側ではなく、AIの「TD-1」モデルを搭載した車両が実際にどうやって動いているのか、またそれを動かすためのソフトウェアのアーキテクチャはどうなっているのかについて、徳弘に解説してもらおうと思います。

徳弘：よろしくお願いします。

こちらは実際に「TD-1」を搭載して動いている車の外観の写真です。外から見てわかるように、センサーがいろいろと搭載されています。

一つずつ紹介しますと、まず私たちは基本的にカメラからの映像の入力のみで自動運転をするという設計コンセプトの自動運転システムを開発しており、カメラは車の外周に8つ取り付けられています。また、位置情報を取得するための、GPS（GNSS）のアンテナ、学習用のデータセットを作るためのLiDAR（距離の情報を計測するセンサー）が取り付けられています。そして、車載ネットワークとつながって、車自身から車がどういった運動をしているのか情報を取得できるような構成になってます。

また、自動運転をするには車の動きを操る必要があるので、ソフトウェア制御ができるパワーステアリングを備えています。さらに、アクセルとブレーキも自在に操れるシステムを構成しています。

こちらの図は、実際にシステムを構成する機器がどう接続されているのかを表したブロック図です。

私たちのシステムは、NVIDIAの「Jetson AGX Orin」という計算機をメインにシステムを構成しています。車の外に組み付けられているLiDAR、カメラ、GPSのアンテナはすべてこの計算機に接続されていて、計算機自身は車内にいる開発者またはドライバーに情報を表示するためにディスプレイに出力し、タッチ操作ができるようになっています。

自動運転は安全性が重要になってくるので、車とのインターフェースとなる部分には「セーフティMCU」と呼ばれる、システムの出力や挙動を検証する機能を備えたハードウェアを車との通信の間に入れています。そのセーフティMCU中で組み込みのソフトウェアが動いて、それがメインのJetson AGX Orinで動くシステムと通信しながら車を制御する、といった構成になっています。

自動運転車のソフトウェアアーキテクチャとは

物理的な接続はいまお話ししたとおりですが、ソフトウェアアーキテクチャとして、Jetson AGX Orinのデバイスの中ではLinuxが実際に動いています。そのLinuxの中でどういったソフトウェアが構成されているのかについて説明します。

私たちの自動運転システムでは、複数のプロセスが協調して動いていて、プロセス同士が通信をしており、センサーやハードウェアごとにプロセスがそれらを制御しています。

例えば図の左から説明すると、カメラを制御するプロセスは、直接カメラ用のLinuxドライバーを経由することでカメラを制御して、その情報を他のプロセスが扱えるように配信する、という仕組みになっています。他のセンサーを制御するプロセスも同様に、それぞれが担当のセンサーを制御して、その情報を他のプロセスと共有するものになっています。

プロセス同士の通信は、パブリッシュ-サブスクライブモデル（Pub/Sub）の「シングルパブリッシャー・マルチサブスクライバーモデル」（※）の配信の仕組みを採用しています。

※シングルパブリッシャー・マルチサブスクライバーモデル……プロセスごとにある特定の情報を配信する場合、配信者は1つで、複数の他のプロセスからその情報を読み出すことができる仕組み

例えばこの図でいうと、「positioning」のプロセスが配信した情報を、「controller」で車の制御をする際の姿勢推定の計算に使用したり、「model」で車速などの情報を参考にするためにサブスクライブ受信をして出力計算に使用する、というような仕組みになってます。

いちばん右の「logger」というプロセスでは、すべてのパブリッシュ（編集）されたメッセージを受信し、それをSSDストレージに書き込んでいます。すべての動作ログはこのPub/Subされた情報にもとづいて、それがログという形で残り、AIの学習に使うデータセットを作るためのRawデータ（生データ）にもなっている、という仕組みになっています。

こちらについて、どういったツールや開発環境を使っているのかもう少し詳しく紹介したブログ（※）も先日公開したので、ぜひこちらもご覧になっていただきたいと思います。

※チューリングの自動運転システム開発環境と、それを支える開発ツールたち
https://zenn.dev/turing_motors/articles/d76005207e2b87

自動運転車両を見てみよう！①外装編

山口：ここからさらにハードウェアとソフトウェアのアーキテクチャについて深掘りしていきたいと思うのですが、せっかく平和島ラボにいるのだから、車を見たいですよね。

徳弘：見たいですね！

山口：では、さっそく自慢していきましょう（笑）。この後ろに見えている車、ちなみに車種は何でしょうか？

徳弘：これはトヨタの30系後期、「アルファード」という車種になります。

山口：このアルファード、チューリングでは何号車まで作っているんですか？

徳弘：今、18号車の製作に着手した段階ですね。

山口：もう20台近い車をデータ収集や自動運転の車両に仕立てているということで（笑）。その車がどういう構成になっているのかも、ぜひ皆さんにご紹介できたらなと考えています。

じゃあ、実際にカメラを移動しながら詳細を聞いていこうと思います。

まず正面ですが、フロントガラスの上にカメラが3つ付いていますね。計算機とつながっている8つのカメラのうち、3つが真ん中に付いているということですね？

徳弘：そのとおりです。それぞれレンズの画角が異なり、見える距離や幅が違うものを正面の方向に3つ付けています。

山口：自動運転でいうと正面からの情報がすごく重要になってくるので、フロントのカメラはリッチに構成しています。加えて、サイドにもカメラが付いてるんですよね。

徳弘：まるで元から付いていたかのような……。こういった仕上げをできる技術を持った協力会社さんがいて、非常にきれいな仕上がりになっています。

山口：サイドのカメラで斜め前と斜め後ろの2方向を見ることができるということですね。このカメラの画角は？

徳弘：サイドは120度の画角のカメラを使っています。

山口：この上も気になる人が多いかなと思います。先ほどGPSアンテナとLiDARセンサーがついてると言っていましたが、LiDARのほうから見ていきましょう。

これ、上にルーフキャリア用のアームが伸びていて、その上にLiDARセンサーが固定されていますね。私たちが自動運転をするときはカメラだけを使うので、LiDARは普通使いません。でも、この車がLiDARをつけているのはなぜですか？

徳弘：これは、AIの学習に使うデータセットを作るのに、例えばアノテーション（画像の中に何が写っているかという情報を付与する工程）を実施するうえで、カメラの映像からだけではカメラ同士の相対的な位置関係を割り出すのは難しいという問題がありました。LiDARは周囲360度、深さも距離もかなり正確な情報を取れるので、その距離の情報と他のカメラの映像をマッチングさせることで、より正確かつ効率的に学習用のデータセットを作成することができます。

山口：このパトカーの回転灯みたいなものがLiDARで、その前に張り出してる角みたいなものがGPS（GNSS）のアンテナですよね。これがあるのは自動運転でデータを取るときに、自分の位置情報がすごく重要になってきますよね。

徳弘：そうですね。自動運転のデータを取るうえで、車がどういった軌跡を辿ったかという情報が非常に重要になるので、その軌跡の情報をなるべく正確に取得できるように、衛星から得られる位置情報をデータとして記録しています。

自動運転車両を見てみよう！②車内編

山口：今度は、車の中の計算機についても紹介していこうかなと思うのですが、これがそうですね。

山口：この緑色の部分からいろいろ配線が出ているけど、これ1個がいわゆる車載コンピュータみたいな形ですよね？

徳弘：そうですね。これ1つでLinuxのシステムが動いていて、計算機として必要なものがぜんぶ揃っているコンピュータになっています。

山口：配線がいろいろ伸びていて、この下側に8つ線が伸びているけど、これがカメラの配線ですよね？

徳弘：はい、これがGMSLという通信規格で通信するカメラ専用のケーブルになります。

山口：それからいちばん左は電源ケーブルかなと思うのですが、その隣に小さい配線もありますよね。これは何ですか？

徳弘：これはコントロールエリアネットワーク（CAN）という、車の中を流れている信号を入力する端子ですね。

山口：この辺の信号端子みたいな部分と、車のシステムがダイレクトにつながっているんですよね。面白いのはファンがあって、計算機を冷やしてるんですよね。

徳弘：そうなんですよ。ファンのあるなしで冷却の度合いが変わってくるので、自分たちで付けています。

山口：それ以外だと、セーフティMCUなどもこの辺りにまとまっていて、社内のケーブリングは汚くならないように天井裏とかに這わせているのですね。

運転席も見ていいですか？

徳弘：ぜひ！

山口：モニターがいろいろ追加されていますけど、普通の車にはないモニターですよね。

徳弘：これは私たちが後からつけたモニターです。今はメーターと重なっちゃっているのですが、実際外に出るときにはかぶらない位置に調整をして、自動運転用のデータを集めるシステムが動作するのに必要な情報を表示しています。

山口：この赤いボタンは何ですか？

徳弘：これは非常に重要なものです！　この車は自動運転車として実際に動かすことを想定して作っているのですが、これが先ほどお話したCANという、車と計算機の間の接続を断ち切るための非常停止ボタンになります。

山口：万が一システムが変な挙動をした場合に、人間が介入して断ち切る指導ができるということですね。ここは今、開発もいろいろと調整をしているところで、実際に運用するときにはもう少ししっかりと固定して、場合によってはより操作しやすい場所に移行することもあると。

徳弘：今はまだテストコースであるとか、限られた場所で検証しています。

山口：以上が、私たちの自動運転車両の紹介でした。基本的にはデータ収集の車両も制御用の車両も、同じハードウェア構成・ソフトウェア構成を目指していますよね？

徳弘：そうですね。ハードウェアとしては同じ構成で、ソフトウェアとしても同じもので動かせるように開発している状況です。

搭載する計算機やカメラのスペックは？

山口：ここからは再びスライドを見ながら、よりテクニカルに、かつディープな部分を皆さまにお伝えしていきます。

このシステムブロック図、メインの計算機ではLinuxが動いているという話だったのですが、どういったタイプのLinuxですか？

徳弘：基本的にはJetson Linuxという、NVIDIAがJetsonシリーズ向けに出しているUbuntuベースのOSになります。

山口：なるほど。車用だとJetsonのほかに「DRIVE Orin」というのもあって、こちらのほうが機能・安全などがよく設計された自動車向けの計算機なのですが、私たちの試験車両としては現状Jetsonでクイックに構築していますね。ちなみに計算機のスペックも聞いておきたいなと思うのですが。メモリはどのくらいあるんですか？

徳弘：計算性能は今使っているJetson AGX Orinのモジュールにも依存するのですが、CPUでいうと2.2GHzで12コアと、あとメモリが64GBのものを備えています。計算能力でいうと、NVIDIAの公称で275TOPS（※1TOPS＝毎秒1兆回の演算性能）の計算能力です。でも、これはすべてのハードウェアの処理性能を合計した最高値で、実際にアプリケーションによってそこまで性能が出ることはないのですが、AIの推論や画像処理などに使うぶんには非常に強力なものになっています。

山口：そういったいろいろな処理ができるためのエッジ向けの計算機で、普通のデスクトップPCとは違う形になっている。車に載せるといろいろ大変なことが多いですよね。例えば振動もあるし、夏場は車内がめちゃくちゃ暑くなるし、逆に今の季節だと寒くなる。あと、車って意外と電磁波が飛んでいるんですよね。この辺の対策はどうしていますか？

徳弘：Jetson AGX Orinというモジュールを載せた計算機のボックスが、システムとして振動体制、電磁波、ノイズへの耐性といった各種試験をパスしている製品になっています。また、カメラのGMSLという規格は量産している車でも実際に使われているノイズに強い通信規格で、車という厳しい環境で使うためのいろんな対策がされている、そういう計算機になります。

山口：カメラについても聞いていきたいのですが、カメラの解像度、確かすごく高いんですよね。

徳弘：そうですね。5メガピクセル。めちゃくちゃ大きいです。2880×1860の3Kカメラです。

山口：3Kカメラ……すごいですね。しかも、それをビデオでずっと撮っていて、ぜんぶ記録しているんですよね。

徳弘：8つのカメラ、すべて30FPSで記録していて、実際に動画として保存するためのエンコーディング処理のほうが間に合わないという、それだけ非常にリッチなカメラですね。

山口：とはいえ自動運転では映像の視覚情報がすごく重要になってくるので、カメラもかなりハイスペックなものを入れていると。ただ、そのハイスペックなカメラを8つ同時に処理するには計算機をフル活用しないと間に合わないということで、そのあたりも実はエンジニアかなり頑張ってくれたところです。

ソフトウェア構築にはどんなシステムを採用している？

山口：ソフトウェアアーキテクチャについても聞きたいんだけど、自動運転やロボットではよく、ROSあるいはROS2と呼ばれるコアアーキテクチャを使うことが多いですよね。でも、私たちは実はROSは使ってないんですよね。

徳弘：ROS・ROS2は使っていませんね。

山口：社内のアプリケーションでもROSはほぼ使わずに、プログラミング言語としてはC++、それからPython、この辺りで実はすべてのシステムを実装しています。

このモジュールがPub/Subで通信している、という話がありましたが、このモジュールというか、プロセスは基本的に独立しているものになるんですか？

徳弘：そうですね。もちろんすべてのプロセスを統括・マネジメントするプロセスも、その上位の存在としてはあるのですが、プロセス自身は1個ずつ、他のプロセスから情報が入ってこなくなってもそれ単体として成立する、スタンドアローンなプロセスで構成されているシステムになります。

山口：そのように疎結合なシステムにしていくと、ソフトウェアアーキテクチャ上は開発しやすかったり、例えばこのモジュールを追加する、あるいはデバックをするときにはやりやすかったりするメリットがありますか？

徳弘：現象を再現するであるとか、デバッグをするであるとか、そういった作業が非常にしやすいメリットが大きいですね。

山口：特に車が絡んでくると、机上で全部検証できないケースもすごくたくさんありますよね。例えば、このカメラとの通信のデバイスを扱うところや、あるいはAIの推論などGPUをフル活用するところは、また違うプロセスや開発のCI/CDも別に取っていますよね。

徳弘：実際に車との界面になる部分だけ切り出して、そこは実環境で検証しないといけないので、こういうすみ分けがしやすいというのはあります。

山口：まさにここ平和島ラボで、ハードウェア開発だけでなく、実車を使ったソフトウェア開発も行っていて、私たちも大崎と平和島を行ったり来たりするような日も過ごしています。

※以降では、参加者との質疑応答が展開され、さらには「延長戦」と題して、ソフトウェア開発のさらにディープな領域へと話は及びました。本イベントの全内容は、ぜひ以下のリンクからご覧ください。

【イベント概要】
Turing TechTalk #9 自動運転車両のハードウェア＆システム完全解剖
https://www.youtube.com/live/9FNxoaogKbg