車両の認知に対するセンサーモデルの活用
小口貴弘氏：あとはセンサーモデルですね、どのように認知するかを説明します。
こちらは測距センサー、ミリ波レーダー、ソナー、LiDARなどのセンサーを想定しているのですが、測距をする時には、いろいろな段階があると思います。理想的なセンサーは、誤差やバイアスなどエラーがまったくないセンサー。これは計算が早いのですが、模擬精度はそこまで高くはありません。逆に、有限要素法や1フレームに何時間もかけて高精度にシミュレーションをするモデルもあると思っています。
これらのトレードオフを取りながら、目的に応じて、どこを選ぶかがポイントになってくると思います。最近ゲーム業界では、リアルタイムレイトレ（リアルタイムレイトレーシング）などで、GPUを使ったレイトレーシングが流行っているので、レイトレで近似して測距センサーを模擬するというのが非常にいいのではないかなと思っています。実際、こういったところを各所でトライアルをしている状況です。
（スライドを示し）こちらは、カメラセンターですね。CGだと、原理的にパースペクティブコレクト、射影変換では180度未満までしか画角が作れないのですが、実際の車両に付いているセンサーは、画角が広いんですね。180度以上の広角なモデルが付いているので、そういったものを実装する時に、魚眼の広角なモデルを再現しないといけません。
スライド右の図ではピンホールカメラのほか、実際にひずみが入った魚眼カメラを模していますね。
スライド左側には、実写の映像と、それを模して作ったモデルの映像があります。ある程度精巧に模擬できていると思います。その過程では、3Dスキャナーを使って実際の駐車場を計測したりして、精度を上げる取り組みをしています。
全部が全部というわけではなく、物によっては「Googleマップ」から参照しながらモデルを割り当てていて、いろいろなアプローチを並行してやっている状態です。
いろいろな模擬をしていますが、スライド右側のグラフでは、横軸がいろいろなシーンが変わるフレームの番号で、縦軸が車両を認識した時の車両の認識精度、つまり車らしさを示しています。ドイツのケンプトン大学のSchneider先生が、取り組みをされているのを引用しています。
物によっては、非常に漸近して実写と仮想が近い部分もあれば、かなり離れて乖離があるところもある、というのが見て取れると思います。
いろいろな効果によって、縮まったり離れたりしているのですが、「物によって、使える部分と使えない部分が分かれる」というのがここでは言いたいことになります。
自己位置認識と駐車位置計算におけるアクチュエーター／車両運動モデルの活用
なので、事例を増やしながらやっていく必要があります。実際に、どういう事例があるのかということで、自動バレー駐車システムの事例を持ってきました。
（スライドを示しながら）駐車場にARマーカーを置いて、ランドマークを認識させて、自車位置を認識させつつ、その地図を持っています。地図で自己位置がわかるので、目的の駐車場所にどうやったら行けるかを計算して作れるということです。
こちらに、実際に仮想環境を模擬した画像があります。実際の駐車場にマーカーを置いて、それで自己位置認識をして、どういうふうにパスを作って駐車していくかを計算するうえで影響してくるのは、マーカーの位置なんですね。自己位置をどう認識するかは、マーカーの場所によって精度が変わります。トライ＆エラーして、マーカーを置く場所をいろいろ変えていくというトライアルをしたのがこちらの事例です。
スライドの左下にある画像には、黄色の文字で「推定位置」と重畳表示されていますが、自己位置推定の結果を示していますね。認識器が出した結果と、今現在自車がいる「実際の位置」との差異が見て取れるように表示しています。
マーカーの置く場所を、ここだったらきちんと取れているね、ここだったらちょっとずれているね、という感じで手戻りを削減したという事例です。このようにシステム検証の取り組みをトライアルしています。
仮想環境開発事例その2 センシングの機能開発
次に、センシングの機能開発の事例について紹介したいと思います。
「Semantic Segmentation」と呼ばれる、画像上でどのピクセルがどういったクラスになっているのかを判別する画像処理は、深層学習による認識が主流になっています。
これによりどこに何があるかはわかってきますが、これを作るためには、大量の画像データと大量の正解データが必要です。これはクルマです、道です、人ですというところは、画像とセットになって、ピクセル単位で正解データが必要になってくるのですが、ここが大量に必要になります。
実は、ゲームエンジンは中間バッファでIDを持っていて、ここでゲームエンジンを使って中間バッファを抜いてくると、正解データを容易に取れるというのが、ゲームエンジンを活用できるポイントかなと思っています。実際、NVIDIAさんは、こういったものを活用して認識率を上げたという事例を多数報告しています。
仮想環境開発事例その3 HMI機能開発
最後に、HMIの機能開発事例ですね。
HMIのシステム群には、ドライバーステータスモニターや、ナビや、TopViewなどがあります。TopViewはクルマを上から見たイメージを作って、駐車をやりやすくするという機能です。
カメラの品質がどんどん上がってくると、広い範囲が取れるのですが、オクルージョンで遮蔽されているところは見えないという問題があります。
実際も見えないので、これは仕方ないのですが、本当は見えないところも、それっぽく見えたらいいなと考えてみました。これは安全担保ではなく、安全が担保されたうえでどう見せるかという流れですね。
LiDARやSfM（Structure from Motion）等を使って、深度がわかった状態であれば、スライド右上の図にある黒い領域、オクルージョンの領域が判別できます。オクルージョンがわかったところで、GAN（Generative Adversarial Network）を使って、ここを生成します。そして、見えないところを見えるようにしてみようという取り組みになります。
GANの仕組みは、Generatorががんばって、本物と見間違うようなデータを作って、Discriminatorが本物か偽物かを見分けるトレーニングを繰り返すと、あたかも本物のようなデータが作れるという流れになります。
これを全部現実のデータでやるとすると、ドローンでぴったりクルマの上から撮影を続けなくてはいけないという神業が必要になるんですね。
実際にやるのは大変なので、仮想環境で作ってみたという事例です。先ほど話題に出たように、ここで必要になる場所、外界モデル、要素モデルの配置を組み合わせてみました。
2019年に、当時出たばかりの論文「Edge Connect」を使って推定しました。最初にエッジを再現して、その後、穴埋め問題で埋めるというアプローチです。
左側がGround Truthで、左から2番目が入力で、残り2つが出力で、1番右が最終出力ですが、1番左と1番右を比べてみると、おおむね期待した復元ができていることがわかると思います。
実際に映像で見るとちょっとモヤモヤとしているところは、入力がなかったところから再現を試みて作ったものですが、動画では、違和感はそれほどないと思います。
最後に、完全にオクルージョンになると、ヒント情報が無くなって生成が失敗している様子もあります。これは左上が入力で、右上で中間段階のバッファ、右下が最終出力、左下がGround Truthになっています。
左下と右下を見比べると、違和感がそれほどないようになっていると思います。
ということで、いくつか、うまくいっていないところはあると思いますが、実際は2週間ぐらいの非常に短いスパンで、このトライアルができました。
当時使っていたUnreal Engineのバージョンは4.16で、これだとReadPixelsが、ブロッキング関数ですごく遅かったんですが、ここを最適化して10倍ぐらいに早くしたり、中身もチューニングしたりしながら効率よくやっています。
というように、HMIのディープラーニングを使った推論の事例を紹介しました。このように、いろいろなアプローチをしながら開発を進めている状況です。
以上で発表を終わります。
