モバイル
スマートフォンは、現存する中で最も広く展開されているSLAMプラットフォームである:最近のすべてのiPhoneと大半のAndroid端末は、システムサービスとしてビジュアル・インナーシャル追跡(ARKitとARCore)を実行している。したがって「モバイルSLAM」に取り組むことは、2つの異なるスキルを意味する:ネイティブなアプリ言語からプラットフォームの追跡スタックを利用することと、SLAMエンジニアとしては、カスタムのC++知覚コードを電話のハードウェア上でうまく動かすことである。
Android(Java/Kotlin)。 アプリケーションはKotlin(またはJava)で書かれるが、SLAM級のコードはNDK経由でC++で実行され、JNIでブリッジされる。重要なプラットフォーム要素は、フレームアクセス用のCamera2/CameraX(タイムスタンプと露出メタデータ付き)、IMUデータ用のセンサーAPI、そして自前の追跡を実装する代わりにGoogle組み込みのモーション追跡を利用したい場合のARCoreである。Android SLAM開発の実務的な現実として、カメラ-IMU間の時刻同期の品質が端末ごとに大きく異なることや、熱によるスロットリングが「リアルタイム」の意味を左右することが挙げられる。
iOS(Objective-C/Swift)。 アプリケーションはSwiftで書かれ(レガシーコードはObjective-C)、C++は直接統合される(Objective-C++やSwiftのC++相互運用)。AVFoundationがカメラフレームを、CoreMotionがIMUを提供し、ARKitはAppleの緊密に統合されたVIOを公開している — 工場で校正され良好に同期されたカメラ-IMUハードウェアのおかげで、コンシューマー向け追跡品質のベンチマークとして広く見なされている。MetalとCoreML/ANEは、学習済みコンポーネントのためのGPU計算とニューラル推論を担う。
センサー配線:モバイルVIOの生死を分けるところ
- クロックドメイン。 カメラとIMUのタイムスタンプは同じクロック上にある必要がある。Androidでは、
SENSOR_INFO_TIMESTAMP_SOURCEによって、カメラのタイムスタンプがIMUのクロックベースを共有しているか(REALTIME)、独自のもの(UNKNOWN)かがわかる — 後者の場合、オフセットを自分で、しかも端末ごとに推定する必要がある。 - ローリングシャッター。 ほぼすべてのスマートフォンカメラは行ごとに読み出しを行うため、各画像の行は微妙に異なる時刻に撮影される。速い動きの下ではこれが幾何を歪ませ、モデル化する必要がある(あるいは誤差源として受け入れる)。プラットフォームの追跡器は内部的にこれを処理している — カスタムパイプラインも同様に処理する必要がある。
- OIS/EIS。 光学式画像安定化はレンズを物理的に動かし、フレームごとに実効的な内部パラメータを密かに変える。電子式安定化は画像を歪める。両者は映像には優れているがジオメトリには敵対的である — SLAMのためにはこれらを無効化するか、その影響をモデル化する必要がある。
- 露出メタデータ。 自動露出はフレームごとに画像の明るさを変える。直接法/光度法ベースの手法には、Camera2/AVFoundationが報告する露出時間とISO値が必要である。
実務チェックリスト
SLAMエンジニアにとって、モバイル特有のチェックリストは両プラットフォームでほぼ同じである。
- センサーアクセスと同期 — カメラとIMUのハードウェアタイムスタンプ、ローリングシャッターへの配慮、露出/ISOメタデータ(上記参照)。
- 計算予算 — (アプリと共有される)数個のCPUコア、NEON SIMD、モバイルGPU、そしてNPU。電力と熱の制約により、持続的な負荷はピーク性能よりはるかに低く制限されるため、ホット状態でベンチマークすべきであり、コールド状態ではない。
- 言語のブリッジ — 共有のC++コアの上にKotlin/SwiftのUIを載せる、クロスプラットフォームSLAM製品の標準的なアーキテクチャ。
- 利用か自作か — ARKit/ARCoreは優れており無料である。電話上でカスタムSLAMを行うことが正当化されるのは、それらが公開していない機能(カスタムセンサー、自分が所有する地図、端末間の再位置特定)が必要な場合である。
永続化と共有体験
プラットフォームスタックはまた、内部的には純粋なSLAMであるマップレベルの機能も公開している:ARKitは地図をシリアライズできる(ARWorldMap)ため、アプリはセッションを保存して後で再位置特定できる。ARCoreのCloud Anchorsは複数の端末が同じアンカーを解決できるようにする — サービスとしてのクロスデバイス再位置特定である。これらが内部で何をしているか(場所認識、地図マージ、再位置特定)を知っておくことで、いつこれらに頼れるか、いつ自前のマッピング層が必要かが正確にわかる。
SLAMにおける意義
モバイルARは、ビジュアル・インナーシャルSLAMが大規模展開に出会った場所であり、電話の制約(厳しい電力予算、ローリングシャッターカメラ、コンシューマー級のIMU)がこの分野の工学的な優先事項を形作ってきた。ARKit/ARCoreの上にアプリを構築するのか、それらと競合するのかにかかわらず、モバイルスタック — センサー配線、ネイティブ/マネージド言語のブリッジ、熱に制限されたリアルタイム性 — を理解することは、現存する最大のプラットフォームにSLAMを届けるために不可欠である。