Android加速度計の精度（慣性航法）
私はAndroid電話用の慣性航法システムの実装を検討していましたが、加速度計の精度と測定値の一定の変動を考えると難しいと思います。
まず、携帯電話を平らな面に置き、X方向とY方向（テーブルに平行なので、これらの方向に重力が作用しない）で1000個の加速度計の読み取り値をサンプリングしました。次に、これらの測定値を平均し、この値を使用して電話を較正しました（後続の各測定値からこの値を引きます）。
次に、システムを再度テーブルに配置し、X方向とY方向に5000の加速度計の読み取り値をサンプリングすることでシステムをテストしました。キャリブレーションが行われた場合、これらの加速度は各方向で（ほぼ）0になると予想されます。ただし、これは事実ではなく、5000回の反復にわたる合計加速度は0に近くなりません（各軸で平均10前後）。
私はコードを見ずにこれに答えることは難しいかもしれないが、より一般的な意味では...
これは単に、携帯電話（HTC Desire S）で加速度計の読み取り値がどの程度不正確であるかの例ですか、それともコーディングでエラーを犯した可能性が高いのでしょうか？
直線加速度を2回積分することで位置を取得できますが、エラーは恐ろしいです。実際には役に立ちません。
理由（Google Tech Talk）の説明 at 23:2 です。このビデオを強くお勧めします。
問題を引き起こすのは加速度計のノイズではなく、 ジャイロホワイトノイズ です。サブセクション6.2.3エラーの伝播を参照してください。 （ところで、ジャイロスコープも必要になります。）
屋内ポジショニングに関しては、これらが役立つことがわかりました。
RSSIベースの屋内ローカリゼーションとシグマポイントカルマンスムーザーを使用した追跡
これらのメソッドが実際のアプリケーションでどのように機能するか、またはそれらをNice Androidアプリに変える方法がわかりません。
同様の質問は this です。
UPDATE：
どうやら、上記のオリバーJ.ウッドマン「慣性航法入門」よりも新しいバージョンがあります。博士論文：
私は大声で考えているだけで、Android加速度計APIをまだ使用していません。
まず、伝統的に、加速度計からナビゲーションを取得するには、6軸の加速度計が必要です。 X、Y、およびZの加速度だけでなく、Xr、Yr、およびZrの回転も必要です。回転データがなければ、デバイスが姿勢を変えないことを想定しない限り、ベクターを確立するのに十分なデータがありません。これはかなり制限されます。とにかく誰もTOSを読みません。
ああ、そして、あなたはINSが地球の回転で漂うことを知っていますよね？それもあります。 1時間後、あなたは不思議なことに宇宙へ15°の斜面を登っています。これは、位置情報をこれほど長く維持できるINSを持っていることを前提としていますが、電話ではまだできません。
ナビゲーションに加速度計を使用するより良い方法は、3軸の加速度計を使用する場合でも、可能な場合はGPSに接続してINSを較正することです。 GPSが不十分な場合、INSはうまく補完します。 GPSを使用すると、木に近づきすぎたため、突然3ブロック離れて飛ぶことがあります。 INSは素晴らしいものではありませんが、少なくとも、流星に襲われていないことは知っています。
できることは、電話の加速度計データとその多くを記録することです。数週間の価値があります。それを良い（本当に良い）GPSデータと比較し、データマイニングを使用して、加速度計データと既知のGPSデータのトレンドの相関関係を確立します。 （プロのヒント：良いジオメトリと多くの衛星があるGPS暦を確認したい場合があります。4つの衛星しか持っていない場合もありますが、それでは十分ではありません）携帯電話をポケットに入れて歩いていると、加速度計のデータは非常に特定のパターンを記録します。データマイニングに基づいて、そのユーザーとそのデバイスのプロファイルを確立し、GPSデータがあったときにそのパターンがどのような速度を表すかを確立します。曲がり角、階段を上る、座る（速度0のキャリブレーション！）、その他のさまざまなタスクを検出できるはずです。電話の持ち方は、完全に個別のデータ入力として扱う必要があります。データマイニングを行うために使用されているニューラルネットワークのにおいがします。言い換えれば、入力が何を意味するかを知らない何か。アルゴリズムはパターンの傾向のみを検索し、INSの実際の測定値に実際に注意を払っていません。知っているのはhistorically, when this pattern occurs, the device is traveling and 2.72 m/s X, 0.17m/s Y, 0.01m/s Z, so the device must be doing that now.だけであり、それに応じてピースを前方に移動します。携帯電話をポケットに入れるだけで4つの異なる方向のいずれか、ポケットを切り替えると8方向になるため、完全にブラインドであることが重要です。また、携帯電話を保持する方法もたくさんあります。ここで多くのデータを話しています。
もちろん、まだかなりのドリフトがありますが、この方法では、デバイスは歩行を停止したことを認識し、位置ドリフトは永続的ではないため、この方法で運が良かったと思います。履歴データに基づいて、あなたがまだ立っていることを知っています。従来のINSシステムにはこの機能がありません。ドリフトは、将来のすべての測定値および化合物に対して指数関数的に持続します。信じられないほどの正確さ、または定期的な間隔でチェックするセカンダリナビゲーションを持つことは、従来のINSでは絶対に不可欠です。
各デバイスと各人は、独自のプロファイルを持っている必要があります。それは、大量のデータと大量の計算です。誰もがさまざまな速度で、さまざまなステップで歩き、携帯電話をさまざまなポケットに入れます。実際にこれを実装するには、サーバー側で処理するために数値計算が必要になります。
初期ベースラインにGPSを使用した場合、GPSの問題の一部は、時間の経過とともにGPSが独自に移行する傾向がありますが、永続的なエラーではありません。レシーバーを1つの場所に座らせ、データを記録します。 WAAS修正がない場合は、周囲100フィートのランダムな方向に漂う位置修正を簡単に取得できます。 WAASでは、6フィートまで下がる可能性があります。バックパックにサブメーターRTKシステムを配置することで、少なくともANNのアルゴリズムをダウンさせることができます。
私の方法を使用すると、INSでangularドリフトが引き続き発生します。これは問題だ。しかし、これまでにn人のユーザーに数週間分のGPSデータとINSデータを注ぎ込むためにANNを構築し、実際にこの時点で機能するようにした場合、明らかにこれまでのビッグデータは気にしません。その道を進み、より多くのデータを使用して、angularドリフトの解決に役立ててください。人々は習慣の生き物です。私たちは、歩道を歩いたり、ドアを歩いたり、階段を上がったりするのとほぼ同じことをします。フリーウェイや壁を通り抜けたり、バルコニーから歩いたりするような狂ったことはしません。
したがって、Big Brotherからページを取得して、人々がどこに行くのかに関するデータの保存を開始するとします。人々が歩くと予想される場所のマッピングを開始できます。ユーザーが階段を登り始めた場合、彼女は階段を上る前の人と同じ階段にいることは間違いありません。 1000回の反復といくつかの最小2乗調整の後、データベースは、これらの階段が非常に正確にどこにあるかをほとんど知っています。これで、人が歩き始めるときにangularドリフトと位置を修正できます。彼女がそれらの階段にぶつかったり、その廊下を曲がったり、歩道を下ったりすると、ドリフトを修正できます。データベースには、人がそこを歩く可能性、またはこのユーザーが過去に歩いた可能性によって重み付けされたセクターが含まれます。空間データベースは、divide and conquerを使用してこのために最適化され、意味のあるセクターのみを割り当てます。それは、レーザー装備ロボットが黒いイメージで開始し、すべての壁がどこにあるかを照らすことで、迷路をあらゆる角度で記憶するMITプロジェクトのようなものです。
交通量の多いエリアには高い重みが付けられ、誰もこれまでに0の重みを付けられないエリアになります。交通量の多いエリアほど解像度が高くなります。基本的には、だれもが行ったすべての場所のマップになり、予測モデルとして使用します。
この方法を使用して、ある人が劇場のどの席に着いたかを判断できても、私は驚かないでしょう。劇場に行くユーザーと解像度が十分であれば、劇場の各行と各行の幅をマッピングするデータが得られます。より多くの人がその場所を訪問するほど、その人の居場所をより正確に予測できます。
また、この種のものに関する現在の研究に興味があるなら、GPS Worldマガジンの（無料の）購読を取得することを強くお勧めします。毎月私はそれをオタクにしています。
ユニットを含めるのを忘れたため、オフセットがどれほど素晴らしいかわかりません。 （「各軸に約10個」と言ってもそれほど多くはありません。：P）それでも、ハードウェアの不正確さが原因である可能性が高いと言えます。
加速度計は、重力に対する携帯電話の向きの決定や、ジェスチャーの検出（携帯電話の揺れや衝突など）に適しています。
ただし、加速度計を使用して推測航法を実行しようとすると、多くの複合エラーが発生します。それ以外の場合、加速度計はめちゃくちゃ正確である必要があり、これは一般的なユースケースではないため、ハードウェアメーカーが最適化することを疑います。
Androidの加速度計はデジタルで、同じ数の「バケット」を使用して加速度をサンプリングします。バケットが256個あり、加速度計が-2gから+ 2gまでを検出できるとします。これは、出力がこれらの「バケット」に関して量子化され、値のセットを飛び回ることを意味します。
Android加速度計を較正するには、1000ポイント以上をサンプリングし、加速度計が変動している「モード」を見つける必要があります。次に、出力がどの程度変動するかによってデジタルポイントの数を見つけ、それをフィルタリングに使用します。
モードと+/-変動を取得したら、カルマンフィルタリングをお勧めします。
これは非常に古いことを理解していますが、当面の問題は、与えられた回答のいずれでも対処されていません。
あなたが見ているのは、重力の影響を含むデバイスの線形加速度です。電話機を平らな面に置くと、センサーは重力による加速度を報告します。これはおよそ9.80665 m/s2であるため、表示されている10となります。センサーは不正確ですが、不正確ではありません！役に立つリンクと、センサーに関する情報については、 here を参照してください。
XおよびY方向の加速度計の読み取り値（この場合は完全にハードウェアノイズ）が、平均値の周りに正規分布を形成すると仮定しています。どうやらそうではありません。
試すことができることの1つは、これらの値をグラフにプロットし、パターンが現れるかどうかを確認することです。そうでない場合、ノイズは統計的にランダムであり、少なくとも特定の電話ハードウェアについては調整できません。