モバイルセンサ融合と姿勢推定

生センサはなぜ単体で使えないのか

スマートフォンには加速度計・ジャイロスコープ・磁気センサ（磁力計）というMEMS慣性センサが載っていますが、どれも単体では姿勢や動きを正しく表せません。それぞれが異なる物理量を、異なる誤差特性で測っているからです。

加速度計は重力を含む合力（比力）を測ります。端末が静止していれば重力ベクトルの向きから傾きを復元できますが、端末を振ればユーザーの動きによる加速度が重力に重畳し、どこまでが傾きでどこからが運動かを区別できません。逆にジャイロスコープは角速度を測るため回転そのものは高精度に追えますが、角度を得るには積分が必要で、微小なバイアス誤差が時間とともに累積し、姿勢が少しずつ漂う（ドリフトする）性質を持ちます。磁気センサは地磁気から絶対的な方位を与えてくれますが、周囲の金属やスピーカーの磁石、電流が作る磁場の外乱に極めて弱いという弱点があります。

融合の原理：相補フィルタとカルマンフィルタ

最も直感的な融合が相補フィルタです。ジャイロを積分した姿勢にハイパスフィルタを、加速度・磁気から算出した姿勢にローパスフィルタをかけ、両者を足し合わせます。擬似コードで書くと次のようになります。

# alpha は 0.98 前後（1に近いほどジャイロ寄り）
angle = alpha * (angle + gyro * dt) + (1 - alpha) * accel_angle

第1項がジャイロの短期追従（ハイパス）、第2項が加速度の長期基準（ローパス）を担い、両者のカットオフ周波数が一致するよう alpha を選びます。軽量で実装しやすい一方、センサノイズを統計的に扱わないため最適ではありません。

より原理的な手法がカルマンフィルタで、状態（姿勢とジャイロバイアス）とその不確かさを共分散として保持し、ジャイロによる予測とセンサ観測を、それぞれの分散に応じた重み（カルマンゲイン）で統合します。回転を表す状態が非線形になるため、実際にはクォータニオンを状態に持つ拡張カルマンフィルタ（EKF）が広く使われます。重要なのは、これらの融合が推定の信頼度を動的に調整する点です。端末が激しく動いて加速度が信用できない局面ではジャイロの重みを上げ、静止して加速度が信用できる局面では加速度の重みを上げる、という切り替えが確率的に行われます。

プラットフォームAPI：CoreMotionとSensorManager

こうした融合を、アプリ開発者が毎回EKFから実装する必要はありません。iOSとAndroidはOS側で融合を済ませた高レベルなAPIを提供します。

CoreMotionのCMDeviceMotionは、加速度・ジャイロ・磁気を融合したattitudeに加え、重力成分（gravity）とユーザー由来の加速度（userAcceleration）を分離して返します。この「重力とユーザー加速度の分離」こそ融合の恩恵で、生の加速度計だけでは不可能だった判定が可能になります。AndroidのTYPE_ROTATION_VECTORも同様に融合済みで、getRotationMatrixとgetOrientationを通じて方位角・傾斜角へ変換できます。TYPE_LINEAR_ACCELERATIONは重力を差し引いた運動加速度のみを返す派生（合成）センサで、内部で融合が働いています。

歩数推定と動作分類

歩数計（ペドメータ）は、融合されたモーションデータの応用例です。単純な加速度のピークカウントではなく、実際には歩行に特有の周期的パターンを認識します。歩行は上下・前後方向に約1.5〜2.5Hzの準周期的な加速度を生むため、この帯域のパターンマッチングやピーク検出で1歩を数え、走行やジョギングとは周期と振幅で区別します。iOSのCMPedometerはさらに歩数だけでなく距離・ペース・階段の昇降まで推定し、CMMotionActivityは静止・歩行・走行・自転車・自動車といった動作分類（アクティビティ認識）を確信度付きで返します。

横にスクロール

ここで実装上決定的に重要なのが、これらの処理がどこで動くかです。歩数のように常時計測したい機能を、アプリのCPUを起こし続けて実装するとバッテリが持ちません。そこで両プラットフォームとも、メインのアプリケーションプロセッサとは別の低消費電力コプロセッサ（センサハブ、iOSのMotionコプロセッサに相当）に歩数計測を委譲します。アプリが停止・サスペンド中でもコプロセッサが歩数を数え続け、アプリが起きたときにまとめて読み出せる設計です。このバックグラウンドでの継続計測は、/mobile-development/mobile-background-execution-limits/ が定める実行制限の下でも動作するよう、OS側が特別に用意した経路だと理解すると位置づけが明確になります。

センサレート・バッチング・電力のトレードオフ

センサ機能の電力を左右する最大の要素は、サンプリングレートと配信方式です。加速度計を200Hzで常時取得しコールバックのたびにCPUを起こせば、たとえ処理が軽くてもCPUがスリープに落ちきれず電力を浪費します。これは無線の間欠通信と同じ「起床回数が電力を支配する」構造で、詳しくは /mobile-development/mobile-battery-power-profiling/ の電力設計と地続きです。

ここにレート選択の原則が現れます。姿勢や方位のように人間の動きに追従すれば十分な用途では50Hz程度で足り、レートを上げても電力を食うだけで体感は変わりません。逆にARのヘッドトラッキングや素早いジェスチャ判定では、遅延1フレームが破綻を招くため高レートと即時配信が要ります。センサ融合の恩恵を活かしつつ電力を抑える設計は、「必要なレートを見極め、許される限りバッチングでCPU起床を減らし、常時計測はコプロセッサへ逃がす」という三段構えに集約されます。なお高レートのモーションデータは歩容から個人を推定しうる機微情報であり、iOS・Androidともにモーション権限の同意を要求します。この扱いは /mobile-development/mobile-app-sandbox-permissions/ の権限モデルの一部です。

まとめ

モバイルのモーション機能は、単体では使えない3種のMEMSセンサを、周波数帯での相補性に基づいて融合することで初めて実用になります。加速度・磁気が与える長期的な絶対基準と、ジャイロが与える短期的な高精度追従を、相補フィルタやクォータニオンEKFで統合し、CoreMotionのattitudeやAndroidのTYPE_ROTATION_VECTORとして提供されるのが現代の構図です。歩数のような常時計測は低消費電力コプロセッサへ委譲し、サンプリングレートとFIFOバッチングでCPUの起床頻度を制御する。この融合の原理と電力トレードオフの両輪を理解することが、ドリフトせず電池も食わないモーション機能を設計する条件になります。