android - 振動のある悪い加速度計データ

Question

私は自転車用コンピューターアプリを使用しています。加速度計を使って斜面の傾きを計算したかったのですが、うまくいきません。

UI レートで smapeling し、約 6 秒の価値がある 128 サンプルの移動平均を維持するセンサー データを取得するテスト コードを入れました。携帯電話を手にしていると、データは良好で、キャリブレーション フラット ベクトルと比較して適切な角度を計算できます。

電話が自転車に取り付けられていると、物事はまったく良くありません。かなりのノイズが発生することを期待していますが、大きな時間枠にわたる多数のサンプルにより、振動の影響と一般的な自転車の動きが取り除かれることを期待していました。残念ながら、これは機能していません。加速度ベクトルの大きさは実際には 9.8 マーク付近にとどまっておらず、低下しています。これは、どこかで何かが正しくないことを示しています。

これは、試乗の一部からのデータのプロットです。

ご覧のとおり、開始時に静止しているときは等級は問題ありませんが、開始すると低下します。問題は振動に関連していると確信しています。最初に下降し、大きな振動があり、その後上昇しました。振動は小さくなり、マグニチュードは 9.8 に戻りましたが、悪路で急速に落下し、マグニチュードは 3 未満になりました。 .

これは、BMA250 センサーを使用する SonyErricson Xperia Active を使用したもので、データシートはセンサーが機能しているように見えます。問題の原因についての私の唯一の理論は、範囲が 2g 範囲に設定されており、振動によってデータが範囲外になり、これが問題を引き起こしているということです。

誰もこのようなものを見たことがありますか？誰かが問題の原因について何か考えを持っていますか?
見つけられなかった感度を変更する方法はありますか?

追加情報。

OK フィルタリングする前に生のセンサー データをログに記録しました。ここに示されている非常に小さな部分 長軸は緑色で平らであり、これは振動がなければ約 8.5 になるはずです。データに明らかなクランプはありませんが、8.5 を超える値よりも 8.5 を下回る値の方が多くなります。センサーが最も敏感な 2g 範囲に設定されている場合でも、振動は問題ないように見えます。ここでの最大値は 15 をわずかに上回り、最小値は -10 です。まあ、± 20 の範囲が正しく中央に配置されていません。 8.5である必要があります。

少し違うセンサーを持っているように見える私の他の電話を掘り起こし、BMA150で試してみますが、それが完璧でない限り、アイデアをあきらめなければならないと思います.

Answer 1

加速度計は、このような大きなG範囲では線形ではないと思います。もしそうなら、そして非対称性があれば、それはあなたが見ていることをします。

そのための解決策は、加速度計のマウントをもう少しパッドし、発泡ゴム、バンジーコードなど、より重いステージにマウントして振動をさらにフィルタリングすることです。

または（良い解決策ではありません）エラーをモデル化して補正してみてください。

Answer 2

私は同じハンドセットを使用し、偶然にも数年前のアプリケーションで同じ平均間隔 6 秒を使用しましたが、グラフで動作を見た記憶がありません。

問題は 6 秒間の平均が累積される方法にあるのかどうか疑問に思っています。私が抱えていた問題の 1 つは、サンプリング間隔が一定ではなく、プロセッサのビジー状態に依存することです。指定した時間にサンプルを取得しますが、イベントハンドラの呼び出しはスケジューラに依存します。プロセッサがアンロードされている場合、サンプリングは一定の周波数で行われますが、プロセッサがより激しく動作するにつれて、サンプリング周波数は遅くなり、不安定になります。サンプリング中にプロセッサの負荷を低く抑えるようにアプリを作成できます。私たちが行ったことは、6秒間サンプリングし、他に何もせず、サンプリングを停止して最後のサンプルセットを処理しましたが、同時に実行されている他のアプリを制御することはできず、スケジューラーはそれらの間でプロセッサリソースを共有しているため、これは部分的にしか成功しませんでした全て。Xperia Active では、JVM の 1 つでのガベージ コレクションが原因で、サンプル間で数秒かかることがあることがわかりました。私たちにとっての解決策は、各サンプルにタイムスタンプを付けてから、サンプルセットに対していくつかの品質チェックを実行し、品質チェックに失敗したものを破棄することでした. 何が十分かを定義することは不正確であり、ユーザーが多くのリソースを使用する別のアプリを実行すると、ほとんどのサンプル セットが破棄される可能性があるため、アプリはそれを処理するための追加のロジックが必要になるため、これは不十分なソリューションです。

Xperia Active では利用できない現在の Android API は、 https: //source.android.com/devices/sensors/hal-interface.html#batch_sensor_flags_sampling_period_maximum_report_latency で説明されているようにサンプルをバッチ処理できるため、これを排除する必要があります。

アルゴリズムがサンプルをカウントするのではなく特定の数のサンプルを想定し、バイクが速くなるにつれてプロセッサがよりハードに動作した場合、その理由はわかりませんが、最初のグラフのようなものが生成されます。下がり、坂を上ると上がります。そこには多くの憶測がありますが、このセンサーでの私の経験から、3 m/s^2 未満の大きさを与える 6 秒の平均は信じがたいように見えます。