x 軸と y 軸での電話の現在の回転角度が必要な Windows Phone 7.1 でアプリケーションを開発しています。モーション API を使用して、それが提供するヨー ピッチとロールから適切な値を使用してみました。しかし、それが提供する値は、電話をあまりにも速く動かして 90 度回転させると、対応する値がそこに到達するまでに少し時間がかかるという意味で遅延します。これは私の目的を無効にします。
私は Android でも同じことを行いました。そこでは、電話の即時回転を計算するために同様のものを使用できます。
これは wp7 でジャイロスコープを使用して行うことができますが、より多くのデバイスに対応できるように加速度計を使用したいと考えています。
目標を達成する方法についての助けをいただければ幸いです
WP8 Motion API にも同様の問題があります。問題は遅延だけではない。Motion API は、あらゆる種類のコンパス (または磁力計) のエラーにも非常に敏感であるようです。さらに悪いことに、これらはヨーだけには影響しません。モーション クラスの AHRS アルゴリズムは、ピッチとロールをヨーと結合しているようです。その結果、コンパスが遅れたり、他の方法で狂ったりすると、ピッチとロールも狂います。
ジャイロスコープなしでできるとは思えません。理論的には、加速度計からのみオイラー角 (ヨー、ピッチ、ロール) を取得できますが、それは電話が静止している場合に限られます。わずかな動きでも直線/求心加速度が発生し、向きの計算が台無しになります。電話などのハンドヘルド デバイスでそれを行う試みは失敗する運命にあると思います。さらに、Motion API 自体には、加速度計に加えて、コンパスとジャイロの両方のハードウェアが必要です。
とにかく、すべてが失われるわけではありません。Motion クラスをまとめて取り除き、Sebastian Madgwick の IMU アルゴリズムに似た「独自の」IMU を実装しました。ここにCコードを含むIMU / AHRSレポート：
http://www.x-io.co.uk/res/doc/madgwick_internal_report.pdf
C ソース コードは次の場所にあります。
http://www.x-io.co.uk/open-source-imu-and-ahrs-algorithms/
適切なベータ ゲインにより、Madgwick の IMU は Windows Phone で魅力的に機能します。IMU はヨーを提供せず、ピッチとロールのみを提供します。また、ジャイロと加速度計のハードウェアのみを使用します。ヨーも必要な場合は、上記の両方のソースに含まれる完全な AHRS アルゴリズムを実装できます。もちろんコンパスも必要です。
Madgwick アルゴリズムにはオイラー角の計算 (地球とセンサー フレーム間の回転を表す四元数) は含まれませんが、Madgwick のレポートから方程式を見つけることができます。
完全な AHRS (Madgwick が言うところの MARG) の経験はありません。ただし、このアルゴリズムはピッチとロールの計算からコンパスのヨーを分離するため、磁気障害があっても正しいピッチ/ロールの読み取り値が期待できます。
座標系が異なることに注意してください。WP では、X = ピッチ軸、Y = ロール軸、Z = ヨー軸です。上記のアルゴリズムでは、Y=ピッチ、X=ロール、Z=ヨーです。したがって、X と Y を交換し、Z 加速度の方向を反転する必要があります。ジャイロスコープのレートも逆にする必要があります (そして X と Y のレートを交換します)。
お役に立てれば ：）