Azure Spatial Anchor を触って ARCloud について考察する
目的
- Azure Spatial Anchor がどんなものなのか触ってみて理解する
- 今後 ARCloud のようにクラウド上で Map やそれに紐づく情報を管理するシステムを作ろうとした時 Azure Spatial Anchor がどんな感じに使えそうなのか掴む
ドキュメント
開発環境
- HoloLens
- Windows 10 Home 1903
- Unity 2019.2.9 f1
- Visual Studio 2019+コンポーネント
- Azure 無料アカウント
事前知識
以下のリンク先の内容は開発前にざっと目を通しておくと良さそう。
- Spatial Anchors の概要
- Github の Spatial Anchors Sample
- 認証について
- アンカーのリレーションシップとウェイファインディング
- CloudSpatialAnchorSession クラス
- アンカーを効果的に作成して配置するためのガイドラインと考慮事項
- ログの記録
1. Azure Spatial Anchors を使用する Unity HoloLens アプリを作成する
↑の通りに
- Spatial Anchors リソースを作成する
- Unity のサンプル プロジェクトをダウンロードして開く
- アカウント識別子とキーを構成する
- HoloLens Visual Studio プロジェクトをエクスポートする
- HoloLens アプリケーションをデプロイする
をやれば HoloLens にサンプルアプリがデプロイされる。
ちなみに、Visual Studio のユニバーサル Windows プラットフォーム開発のオプションの[USBデバイスの接続]にチェックを入れないと、USB 経由で HoloLens にアプリがデプロイできないので注意。
Android/iOS へのデプロイも同じ Scene でビルド対象プラットフォームを PlayerSettings で切り替えれば可能なのが驚き。
次は、別デバイスや別セッション間で Anchor を共有する。
2. セッションやデバイス間での Azure Spatial Anchors の共有
これも↑の通りやればよい。何なのかサマると
- Anchor を一定期間保存して共有するための ASP.NET Core Web App を Visual Studio から発行
- Unity 側の設定で
Base Sharing Urlに Web API の url を指定 - Android や iOS, HoloLens にアプリをデプロイ
をやっている。
公式ドキュメントは何故か .NET Core 2.2 SDK 指定だが 3.0 でも問題なく動作した。
Web App(というか API) は Swagger UIで書かれている。
試しに Anchor を登録した後にブラウザから https://<appname>.azurewebsites.net/api/anchors/last GET を叩くと
6a83ce25-2604-41bc-9199-caec66b27583
という string 値が返ってきた。これが Anchor を特定する Key である。
では次に Anchor が一定期間たっても消えないよう、メモリでなく DB に保存して例えば別の日でも Anchor が共有できるようにする。
3. Azure Cosmos DB を使って Azure Spatial Anchors を共有する
Azure Cosmos DB の概要 | Microsoft Docs
↑Azure Cosmos DB について参考になったリンク
↑の手順通り進める。
先程との違いは Azure Cosmos DB のインスタンスをたてて、Anchor をインメモリではなく DB に保存するようにしてる点。Web App も API のレイヤでは全く変わらない。
試しに Android 端末にデプロイし Anchor を追加した後 Azure ポータルから Cosmos DB の中を確認すると１行追加されている。
ここにある Anchor key は、
Azure Spatial Anchors についてよく寄せられる質問 | Microsoft Docs
アンカーが作成または特定されるときは、デバイス上で環境の画像が処理されて派生形式になります。 この派生形式が転送されて、サービスに格納されます。 透明性を提供するため、環境の画像と派生されたまばらな点の集まりを以下に示します。 点の集まりは、サービスに転送されて格納される環境の幾何学的表現を示します。 まばらな点の集まりの各点について、その点の視覚的特徴のハッシュが送信されて格納されます。 ハッシュは任意のピクセル データから派生されますが、そのピクセル データは含みません。
ということらしい。この key が Anchor そのものだったということか。
ここで一つ疑問が。
Anchor の共有はこのハッシュ値があれば可能だが、Anchor に紐付いて共有されるオブジェクト（サンプルだと黄色の Cube）は誰が持ってるんだろう？と思い調べたけどよく分からなかった。
簡単なオブジェクト（Cube）の position くらいならこの key に含まれているのかもしれない？ただそれだと共有できるオブジェクト数や種類に限界があるため、いろいろ共有したりリアルタイムに更新したいなら別 DB 等用意する必要がありそう。
MixedRealityToolkit の SharingWithUNET サンプルと比較
１年ほど前に MixedRealityToolkit のサンプルにあった（今もあるかは分からないが）UNet を使い複数 HoloLens 間で P2P 接続してクライアント・サーバに分かれてオブジェクトをリアルタイムに共有する SharingWithUNET を触ったことがある。
↑参考記事
それと今回の Azure App Service 経由での Anchor 共有をざっくり比較すると、
| Pros | Cons | |
|---|---|---|
| SharingWithUNET | 同一ネットワーク内でのP2P接続なのでリアルタイムでの同期が早い | 別ネットワーク・端末間では共有できない |
| Azure Spatial Anchor | 別端末・ネットワーク間でも共有できる サーバ側に Anchor の情報が蓄積される |
レイテンシがそれなりにありそう オブジェクトをリアルタイムに共有するには別の仕組みを用意する必要がありそう |
こんな印象。
まとめ
Azure Spatial Anchor の概要は理解できた。が、まだサンプル通りにやって動かせただけなので、いろいろなオブジェクトのリアルタイム共有やクラウド側でのデータ活用もやっていきたい。
少し勘違いしていたが HoloLens が持つような（wifi をキーとした?）Map をまるまる Azure にあげてそれを複数端末間で共有することではない。Anchor も特徴点の情報+αくらいの情報しか含まれていない。ARCore/ARKit には現時点で Map の Save/Load 機能はないので当然か。
Anchor での位置合わせは少し時間がかかるな、という印象を受けた。特徴点が多い場所を使ったり、特徴点マッチングアルゴリズムを自前で用意するのもアリかも？
ARCloud への応用例
また ARCloud のようなものを実現したいと考えた時、（何をどうクラウドで管理したいかはユースケースによりつつも）仮にいくつかの公園の Map をクラウドで管理し、特定の時間に特定の場所にアイテムを出現させたい、としたら
- Map データは S3 or GCS に保存
- 公園ID、中心 GPS 座標、Mapへのリンク、ゲームアイテムのプロパティ（リスト）、Anchor
あたりは最低限クラウドのデータベースに持たせる必要がありそうな気がする。
これに加えて、池や砂場がある等それぞれの公園が持つ特有のプロパティも保持れば、その公園の特徴にあったオブジェクトを表示させたり、も出来て楽しそう。（どうプロパティを集めるかはさておき）
このように Anchor では保持できない情報を別 DB 等で管理し、端末間での位置合わせは Azure Spatial Anchor を使うように分担するのが良さげかな、とざっくりと妄想してこの記事は終わり。
