Google Tangoで踊ろう！ ARアプリ開発のコツまとめ【ティーポットの独り言】
近況：早速「Lenovo Phab 2 Pro」を発売初日の11月1日に注文してみました。が、到着予定日は1ヵ月以上先の12月7日とのこと。場合によっては、日本で入手する方が早くなりそうです……。
こんにちは、あるしおうねです。
今回はタイムリーなお話として、先日いよいよ米国で一般向け製品が発売開始されたGoogle Tangoについて、簡単に紹介していきたいと思います。
一般向けに発売されたLenovo Phab 2 Pro。米国での価格は499.99ドルより。
Google Tangoは、Googleが数年に渡って開発してきた、本格的なAR体験を可能にするスマートフォン/タブレット向けのプラットホームです。通常のスマートフォンに搭載されているRGBカメラに加え、
・魚眼カメラ（画像トラッキング用）
・距離画像センサー
・高性能なIMU（加速度センサー、ジャイロ、磁気センサー）
を備えており、これらの組み合わせによって
・高度なAR向け位置トラッキング
・現実環境の三次元計測
・AR向けのCGのオクルージョン（遮蔽）表現
などが可能になっています。以下で、これらの各機能について、簡単に触れていきたいと思います。
部屋の中に、屋台風のシューティングレンジが出現するTango Targets。
AR向け位置トラッキング
ARにおける位置トラッキングは、VRとは異なり「現実環境との正しい位置関係」が求められます。しかし、Tangoは本体に搭載されたセンサーのみで位置トラッキングを行うInside-out方式のため、現実環境に設置、固定するセンサーのような、物理的な「基準点」を持つことができません。
そこで、Tangoでは位置トラッキング中に魚眼カメラで撮影した画像を複数記録しておき、これらから抽出した位置情報を「基準点」として用いることで、現実環境に対してずれ（ドリフト）のない位置トラッキングを行う「Area Learning」機能を用意しています。
Area Learningによるドリフト補正=drift correction（Google Area Learningページより）
Area Learning機能を有効（=Learning mode on）にすると、先述の基準点の記録を逐次行い、メモリー内に追加、格納していきます。なお、一周回って同じ場所に戻って来た場合にも、同じ基準点が複数個記録されるようなことはなく、過去の基準点と照合して統合しつつ、蓄積した誤差も自動補正する賢い仕組み（Loop closure）が取り入れられています。
この記録された基準点をファイルとして保存するのがADF（Area Description File）と呼ばれるファイルフォーマットです。具体的には、基準点に当たる「キーフレーム」の位置、姿勢情報と、各キーフレームに結び付けられた画像特徴点（位置トラッキング計算を行なうための画像内の手がかり）の情報が格納されており、先日の記事で紹介したSLAMにおける「特徴マップ」に相当します。
ADFファイルは、Area Learning機能が有効になっている状態で、ある程度基準点の追加を行った後にセーブすることができます。基本的には、記録された基準点が十分な数で広範囲に渡っていれば（＝記録時に現実環境内を十分に動き回っていれば）、ずれのない安定したトラッキングが可能になりますが、模様の乏しい環境や、似たような模様が繰り返される環境だと、ずれの補正に失敗することもあるため、使用環境には若干の注意が必要です。
この記録したADFファイルの品質（基準点がどの位記録されているかなど）をチェックする「ADF Inspector」というツールも公式に配布されており、記録状況の確認に便利……なはずなのですが、なぜか筆者の環境であるGoogle製Tangoタブレットと最新版のADF Inspectorでは、ADFファイル読み込み時にクラッシュする不具合を確認しています。
ADF Inspectorの画面。青い矩形がキーフレーム位置＝基準点、緑色が画像特徴点、右端が「位置トラッキング品質メーター」です（Google Tango ADF Inspectorページより）
開発者は、このArea Learningの基準点追加（とADFファイルのセーブ）を行うか否か、アプリケーション起動時にADFファイルの読み込みを行うか否かを選択した上で、アプリケーションの各モードの設計を行う必要があります（記録モード、再生モードの2モードに分けるなど）。アプリケーションにおいて、ADFファイルを読み込んで使用する場合の利点と欠点は、下記の通りです。
利点：
・現実環境に対して、蓄積していくようなずれ（ドリフト）が無くなるので、現実環境との位置関係を厳密に合わせる必要のあるARアプリケーションに向いている
欠点：
・ADFファイルのセーブ＝事前準備とロード＝再生、といった2ステップが必要となる
・変化の大きい環境や、すぐにアプリケーションを使用したい用途には向かない（ADFファイルのロード後も、キーフレームとマッチング出来るまで位置トラッキングは開始できない）
・現実環境の事前記録が必要なので、ユーザーに対して敷居が高くなる。特に複数の現実環境を記録して管理する場合は、ユーザーを訓練できる業務用途には合理的だが、一般消費者向けには負担が大きい
以上から、現実環境の変化が小さく、事前に一度計測すれば長く使える状況下ではADFファイルの使用が効果的で、現実環境との正確な位置関係が必要なアプリケーションも可能になります。
逆に、現実環境の変化が大きく（周囲の人や物が頻繁に動くなど）、事前計測が不可能な状況下では、位置トラッキング性能が低下する（現実環境との位置関係にずれが生じる）状況をアプリケーション側で考慮する必要があります（ある程度のずれを容認する作り方にするなど）。
現実環境の三次元計測
AR向けの位置トラッキングと同時に、距離画像カメラで取得した奥行きとRGBカメラの画像を使用して、現実環境の三次元計測をリアルタイムに行うことができます。この三次元計測も、リアルタイムで逐次計測結果のメッシュを追加していくか、あるいは記録モード時に計測した結果をメッシュファイル化（例えばOBJフォーマットで書き出し）して、再生モード時にファイル読み込みを行うか否か、といった各モードの設計を行う必要があります。
三次元計測の様子。色付きの頂点のメッシュとして記録されていきます*1。テクスチャではないので、色情報はかなり粗めです
事前に三次元計測を行う場合の利点と欠点は、下記の通りです。
利点：
・アプリケーション側が事前に現実環境を把握できるため、ユーザー体験の設計を行いやすい。どこに何を置くといった情報を静的に設定してセーブできる（メッシュファイルと共にアプリケーションで使用する各種オブジェクトの配置情報をファイル化してセーブ＆ロードすればよい*2）
・リアルタイムに三次元計測を行う場合は若干処理が重くなるが、事前計測を済ませている場合は省略できる分、処理が軽くなる（＝フレームレートが向上する）
欠点：
・Area Learningと同様、三次元計測結果であるメッシュの管理に対して、ユーザーへの負担が増える
・計測結果のメッシュの読み込み、管理をアプリケーション側で実装する必要がある
事前計測を行うか否かは、Area Learningと三次元計測の双方で共通の課題で、ADFファイルをアプリケーションで使用する場合は、計測結果のメッシュもADFと同時に事前計測して取得するのが自然だと思います*3。
なお、リアルタイム計測でも事前計測でも、計測した範囲に応じてメッシュの描画負荷は重くなっていきます。Unityには巨大なメッシュを複数オブジェクトに分割して読み込めるアセットもあるので、それらの利用を推奨（というよりも必須）します。いずれの場合も、各種の処理負荷をコントロールするのはアプリケーション側の責任です。
距離画像とRGB画像
距離画像カメラで取得された距離画像は、先述の三次元計測だけでなく、その他の用途にも使用することができます。また、RGBカメラの画像も、アプリケーション画面に適切な位置でオーバーレイさせてやれば、ビデオシースルー型のARアプリケーションを開発することができます。ただし、Cardboard等を用いてHMD向けのビデオシースルーARアプリケーションを開発する場合、RGBカメラはモノラルのため両眼視差を表現できず、両眼視差付きで表示されるCGに対して若干のずれが発生してしまうので注意が必要です。
距離画像をポイントクラウド表示した様子。距離によって点群の色が変わっています。計測レートはCG表示のフレームレートと比べて低いので、高速な応答が必要な用途には不向きです*4。
また、距離画像は透明なシェーダで奥行きのみ描画することで、CGと現実環境の相互の遮蔽関係＝オクルージョンを表現することが可能です。公式のUnityサンプルでは、距離画像としてZ値つきの単色の矩形ピクセルをポイントクラウドとして描画した後に、背景のRGB画像をZ値の更新なしで上書きして、距離画像のZ値のみが残った状態でCGを描画するようになっています*5。シェーダとしては簡単なものですが、Z値の更新（ZOff/ZOn）や描画順（Render Queue）の制御に注意してサンプルを読み込んで見ると非常に参考になると思います。
オクルージョンの様子。地球のCGが、手前のPSVRの箱（実物）によって遮られている様子が分かります*6。
さらには、KinectやRealSenseのように、人体トラッキングやジェスチャ検出など、距離画像を使った各種画像処理も原理的には可能ですが、現状のSDKにはそういった高度な処理を行うライブラリは付属しておらず、自前で準備もしくは実装する必要があります（NDK経由でPCLを使用する等）。Google側も今後機能拡張を行っていくと思いますが、ここは画像処理を得意にする開発者の腕の見せ所かもしれません。
まとめ
以上で紹介してきたように、Tangoはこれまでのような印刷されたマーカーを必要としない、よりリッチなAR体験を可能とする高度なシステムです。ただし、開発者は
・周囲の環境を事前計測するか否か。ユーザー体験に配慮したアプリケーションの設計
・現実環境を三次元計測したメッシュの描画負荷の制御（計測範囲によって大きく変動）
・RGB画像や距離画像の効果的な使用
を考慮する必要があり、出来ることが増えている分考えることも格段に増えていると言えます。ソフトウェア面も未だ発展途上にあり、Tangoの機能をフルに活用したARアプリケーションの開発は、VRよりも難易度が高いのが現状です。その分、腕に覚えのある開発者にとっては非常に面白い環境だと思います。これを機に本格的なARアプリケーション開発にチャレンジしてみてはいかがでしょうか？
*1 UnityサンプルのExperimentalMeshBuilderWithColorシーンを使用しています。他にもメッシュ関連のサンプルがありますが、いずれも2016/11/10現在、動作がやや不安定なので注意してください
*2 UnityサンプルのAreaLearningシーンで使用されているC#スクリプトAreaLearningGameController.cs内の_SaveMarkerToDisk()/_LoadMarkerFromDisk()の両関数が参考になると思います。
*3 UnityサンプルのExperimentalMeshOcclusionシーンで、ADFとメッシュを一対一に対応付けてセーブ、ロードできるサンプルが提供されていますが、今の所、Google製Tangoタブレットでの動作は確認できてません。今後、これらのデータの管理方法もSDK側での整備が進むと思います。
*4 Google製のTangoタブレットは構造化光投影方式、Lenovo製のPhab2ProはToF方式と呼ばれる距離画像カメラを使用しています。筆者は前者でテストしていますが、両者の特性は異なる可能性があります
*5 UnityサンプルのYUV2RGBシェーダ（背景描画用）と、PointCloud_Occlusionシェーダ（オクルージョン描画用）を参照してみてください。
*6 UnityサンプルのSimpleAugmentedRealityシーンで、Tango AR ScreenコンポーネントのEnable Occlusion設定と、Tango Point CloudコンポーネントのUpdate Points Mesh設定を有効にしてビルドすると、このようなオクルージョン表現が可能になります。
●著者紹介
あるしおうね 大学院にて、VRを専門とする研究室に所属。卒業後、国内電子機器メーカーで約9年間、Augmented Realityおよび画像処理の研究開発に従事。2015年11月に外資系電子機器メーカーに転職し、2016年6月より渡米。
●関連リンク
・Lenovo Phab 2 Pro
・Google Tango
