粗い再局在化
粗い再局在化とは、次のような質問に対しておおまかで簡単な答えを得ることで、大規模な局在化を可能にする機能です。
- 私のデバイスは今どこにありますか。
- どのようなコンテンツを観察する必要がありますか。
応答が正確ではありません。 次の形式で表されます。これらのアンカーに近づいています。いずれかを検索してみてください。
後で高速クエリに使用される、さまざまなデバイス上のセンサー読み取り値を使用したタグをアンカーに付けることで、粗い再局在化は機能します。 屋外のシナリオでは、センサー データは通常、デバイスの GPS (Global Positioning System) 位置です。 GPS が使用できないか、信頼性が低い (屋内など) 場合、センサー データは範囲内の Wi-Fi アクセス ポイントと Bluetooth ビーコンで構成されます。 収集されたセンサー データは、Azure Spatial Anchors に使用される空間インデックスを維持し、デバイスの近くにあるアンカーをすばやく特定するために役立ちます。
粗い再局在化を使用する場合
テニス コートよりも広い空間でアンカーを処理する予定の場合は、粗い再局在化空間インデックスの作成によってメリットが得られる可能性があります。
粗い再局在化によって可能になるアンカーの高速ルックアップは、世界規模の (たとえば、数百万個の地理的に分散された) アンカーのコレクションを利用するアプリケーションを簡単に開発できるように設計されています。 空間インデックスの複雑さはすべて隠されているため、自分のアプリケーション ロジックに集中できます。 すべての困難な作業は、Azure Spatial Anchors によってバックグラウンドで行われます。
粗い再局在化の使用
粗い再局在化を使用して Azure Spatial Anchors を作成およびクエリする一般的なワークフローは次のとおりです。
- センサーのフィンガープリント プロバイダーを作成し、目的のセンサー データを収集するように構成します。
- Azure Spatial Anchors セッションを開始し、アンカーを作成します。 センサーのフィンガープリントが有効なため、アンカーには粗い再局在化によって空間的にインデックスが付けられます。
- Spatial Anchors セッションの専用の検索条件を使用し、粗い再局在化を使用して周囲のアンカーのクエリを実行します。
これらのいずれかのチュートリアルを参照して、アプリケーションで粗い再局在化を設定できます。
- Unity での粗い再局在化
- Objective-C での粗い再局在化
- Swift での粗い再局在化
- Java での粗い再局在化
- C++/NDK での粗い再局在化
- C++ と WinRT での粗い再局在化
センサーとプラットフォーム
プラットフォームの可用性
粗い再局在化と組み合わせて、次の種類のセンサーを使用できます (下の表の詳細を参照)。
- GPS の位置: 緯度、経度、高度
- 範囲内の Wi-Fi アクセス ポイントの信号強度
- 範囲内の Bluetooth ビーコンの信号強度
次の表に、サポートされているプラットフォームでのセンサー データの可用性と、注意が必要な点に関する情報を示します。
HoloLens | Android | iOS | |
---|---|---|---|
GPS | 不可1 | はい4 | はい6、7 |
Wi-Fi | はい2 | ○5 | はい7 |
BLE ビーコン | ○3 | ○3 | はい3、7 |
1 外部 GPS デバイスを HoloLens に関連付けることができます。 外部 GPS トラッカーで HoloLens を使用している場合は、UpdatedSensorFingerprintRequired イベントを処理して GeoLocation の読み取りを送信します。
2 3 秒ごとに約 1 回のスキャンの割合でサポートされます。
3 Eddystone と iBeacon に制限されています。
4 LocationManager API (GPS とネットワークの両方) でサポートされます。
5 API レベル 28 以降では、Wi-Fi スキャンは 2 分ごとに 4 回の呼び出しに調整されます。 Android 10 以降では、[開発者向け設定] メニューからこの調整を無効にすることができます。 詳細については、Android のドキュメントを参照してください。
6 iOS によって直接サポートされます。
7 CLLocationManager API によって間接的にサポートされます。
有効にするセンサー
センサーの選択は、開発しているアプリケーションとプラットフォームによって異なります。 局在化のシナリオに応じて使用できる、センサーの組み合わせ判断の始点として、この図を参考することができます。
次のセクションでは、各センサーの種類の利点と制限事項について詳しく説明します。
GPS
GPS は、屋外シナリオで利用できるオプションです。 アプリケーションで GPS を使用する場合、ハードウェアによって提供される測定値は、一般的に次のものになることに注意してください。
- 非同期で低周波数 (1 Hz 未満)。
- 信頼性が低いまたはノイズが多い (平均 7 m の標準偏差)。
一般に、デバイス OS と Spatial Anchors ではどちらも、これらの問題を軽減するために、未加工の GPS 信号で何らかのフィルター処理と外挿が実行されます。 この追加処理は収束に時間がかかるため、最適な結果を得るには、次のことを試してみる必要があります。
- アプリケーションでできるだけ早くセンサー フィンガープリント プロバイダーを 1 つ作成します。
- そのセンサー フィンガープリント プロバイダーを複数のセッション間でキープ アライブします。
- そのセンサー フィンガープリント プロバイダーを複数のセッション間で共有します。
一般に、コンシューマー グレードの GPS デバイスは不正確です。 Zandenbergen と Barbeau (2011) による研究では、支援付き GPS (A-GPS) を搭載した携帯電話の精度の中央値が約 7 メートルであることが報告されています。 これは無視できない非常に大きな値です。 これらの測定エラーを考慮するため、このサービスではアンカーが GPS 空間での確率分布として扱われます。 そのため、アンカーは、実際の不明な GPS 位置を含む可能性が最も高い (95% を超える信頼度) 空間の領域です。
GPS を使用して問い合わせる場合も、同じ理由が適用されます。 デバイスは、実際の不明な GPS 位置を中心とする別の空間信頼領域として表されます。 近くのアンカーの検出は、次の図に示すように、デバイスの信頼領域に十分近い信頼領域のアンカーを単純に見つけることと解釈されます。
Wi-Fi
HoloLens と Android の場合、Wi-Fi 信号強度は、屋内で粗い再局在化を可能にするために適した方法です。 その利点は、追加の設定が不要であり、Wi-Fi アクセス ポイント (オフィス空間やショッピング モールなどで一般的) をすぐに使用できる可能性があることです。
Note
iOS には Wi-Fi 信号強度を読み取るための API が用意されていないため、Wi-Fi を介して有効な粗い再局在化では使用できません。
アプリケーションで Wi-Fi を使用する場合、ハードウェアによって提供される測定値は、一般的に次のものになることに注意してください。
- 非同期で低周波数 (0.1 Hz 未満)。
- OS レベルで調整される可能性がある。
- 信頼性が低いまたはノイズが多い (平均 3 dBm の標準偏差)。
Azure Spatial Anchors では、このような問題を軽減するために、セッション中にフィルター処理された Wi-Fi 信号強度のマップの作成が試行されます。 最適な結果を得るには、次のことを試してください。
- 最初のアンカーを配置する前に、セッションを適切に作成します。
- 可能な限り、セッションを有効な状態に保ちます。 つまり、1 つのセッションですべてのアンカーとクエリを作成します。
Bluetooth ビーコン
Bluetooth ビーコンを慎重にデプロイすることは、GPS が存在しないか不正確である大規模な屋内の粗い再局在化シナリオに適したソリューションです。 これは、3 つのプラットフォームすべてでサポートされている唯一の屋内方式でもあります。
ビーコンは通常、UUID や MAC アドレスを含む、すべてのものを構成できる多用途デバイスです。 Azure Spatial Anchors では、ビーコンが UUID によって一意に識別されることが想定されています。 この一意性が保証されない場合は、正しくない結果になる可能性があります。 最良の結果を得るには:
- ビーコンに一意の UUID を割り当てます。
- ビーコンを空間を一様にカバーするように配置し、空間のどのポイントからでも少なくとも 3 つのビーコンに到達できるようにします。
- 一意のビーコン UUID の一覧をセンサー フィンガープリント プロバイダーに渡します。
Bluetooth などの無線信号は障害物の影響を受けます。また、他の無線信号に干渉する可能性があります。 そのため、空間が一様にカバーされているかどうかを推測するのが難しい場合があります。 カスタマー エクスペリエンスを向上させるために、ビーコンのカバレッジを手動でテストすることをお勧めします。 候補となるデバイスと、範囲内の Bluetooth を表示するアプリケーションを使用して周辺を歩き回ることによって、テストを実施できます。 対象範囲をテストするときは、空間内の任意の戦略的な位置から少なくとも 3 つのビーコンに到達できることを確認します。 ビーコンが多すぎると、ビーコン間の干渉が増える可能性があるため、粗い再局在化の精度が向上するとは限りません。
空間内に障害物がない場合、Bluetooth ビーコンの対象範囲は通常 80 メートルです。 そのように、大きな障害物がない空間の場合、40 メートルごとのグリッド パターンにビーコンを配置することができます。
ビーコンの電池残量が少ないと、結果に影響があります。そのため、デプロイを定期的に監視し、残量が少ない、または充電していない電池がないことを確認してください。
Azure Spatial Anchors では、既知のビーコン近接 UUID の一覧にある Bluetooth ビーコンのみが追跡されます。 しかし、許可リストに登録された UUID を取得するようにプログラミングされた悪意のあるビーコンは、サービスの品質に悪影響を及ぼす可能性があります。 そのため、ビーコンのデプロイを制御できるキュレーション スペースで最適な結果を得ることができます。
センサーの精度
GPS 信号の精度は、アンカーの作成時とクエリ実行時の両方において、返されたアンカーのセットに大きな影響を及ぼします。 これに対し、Wi-Fi またはビーコンに基づくクエリでは、クエリと共通するアクセス ポイントまたはビーコンが少なくとも 1 つあるすべてのアンカーが考慮されます。 この意味では、Wi-Fi またはビーコンに基づくクエリの結果は、ほとんどの場合、アクセス ポイントまたはビーコンの物理的な範囲、および環境障害物によって決まります。 この表は、センサーの種類ごとに予想される検索空間を推定したものです。
Sensor | 検索空間の半径 (概算) | 詳細 |
---|---|---|
GPS | 20 m から 30 m | いくつか要因の中でも、特に GPS の不確実性によって決まります。 報告された数値は、A-GPS を使用した携帯電話の GPS 精度の中央値 (7 メートル) に対して推定されたものです。 |
Wi-Fi | 50 m から 100 m | ワイヤレス アクセス ポイントの範囲によって決まります。 周波数、伝送器の強さ、物理的な障害物、干渉などによって異なります。 |
BLE ビーコン | 70 m | ビーコンの範囲によって決まります。 周波数、伝送の強さ、物理的な障害物、干渉などによって異なります。 |