GPSデバイスでの「動きの欠如」の検出

車両に搭載されたGPS追跡デバイスを使用しており、後でアプリケーションの動きを表示します。ただし、車両が動いていない場合には小さな問題が発生します。

静止しているにもかかわらず、GPSデバイスはさまざまな位置で情報を送信し、車両が動いていることを報告することもあります（車両が非常に速く動いていることを時々報告します）。最終結果は、アプリケーションの動きのい表現であり、さらに悪いことに、車両が移動して静止している時間に関する誤った計算です（統計分析も行われています）。

問題は新しいものではないことを知っています：Android搭載の携帯電話のGoogleナビゲーションは、交差点で時々止まるときにも問題があり、逆方向に運転していることを検出します（実際、まだ立っているとき） ）。

しかし、特に長時間にわたって、車両が動いていないことを伝える何らかの方法が本当に必要です。

この問題は、夜間に屋根の下に保管される一部の車両ではさらに悪化します。これにより、信号が弱いためにGPSが乱暴になります（ただし、位置を取得するのに十分な強度です）。

車両のエンジンがオンまたはオフになっているかどうかは検出できますが、エンジンがオフの状態で移動していないとは想定できません（破損した車両が牽引された事件がありました...もちろん、盗難の可能性もあります。報告される）。

この問題に取り組む最良の方法は何ですか？

編集：

さらに情報を追加するには：

• GPSデバイスには加速度計がありますが、それはバイナリ情報（移動/移動なし）のみを返し、TOO感度が高いか、単なるプレーンが機能していません。

• 衛星の数や品質などにはアクセスできますが、その情報をどのように利用するかはわかりません。したがって、私の質問。:)

• 問題は、車両が動いているかどうかをリアルタイムで検出することではありません。データを収集し、後で統計分析を行って表示します。車両の現在位置を示していますが、それはほとんど重要ではありません。したがって、基本的には、履歴データを見て、車両が動いているかどうかを判断できる必要があります。

質問の下のコメントは、特に衛星データの品質（衛星の数、信号強度）の解釈に関するいくつかの良い点をもたらします。この情報をモバイルデバイスまたはサーバーで使用して、「悪い」GPS値を除外できます。問題は2つの部分に分かれます。1）偽のGPS読み取り値をどのように定義するか、2）静止状態をどのように定義するか。

いくつかのパラメーターから始めましょう。

• Static_speed =モバイルユニットがこれより遅い場合、静止している
• too_fast =モバイルユニットがこれより高速になっている場合は、偽のGPS読み取り値を与えています

これらの速度を正確に計算するのは難しいです。前の測定値（t0）と現在の測定値（t1）の間の/として速度を計算するとします。時間差が大きく、ユニットが曲線を周回する場合、実際の移動距離は計算された距離より大きくなります。また、2つの誤った読み取り値が連続して取得され、それらが互いに十分近い場合、予測できない結果が得られる可能性があります。

速度がわかったら、それをパラメーターと比較して、GPSの読み取り値が誤っているか、ユニットが静止しているかを確認します。

カルマンフィルターを使用して、より洗練されたフィルター処理を行うことができますが、それはさらに複雑になる可能性があります。

モーションセンサーデータを微調整することができました。

GPSトラッカーによって報告されたモーションセンサーデータ、点火データ、および速度を使用して、車両が動いているかどうかをかなり正確に知ることができるはずです。

また、衛星の数を調べましたが、うまくいきませんでした。屋根の下の車両の場合、衛星の数は少なかったが、それでも比較的高かった。9-10はこのような車両の通常の値ですが、屋根の下では7に低下します（ただし、信号を受信して​​上昇することもあります）。言うまでもなく、衛星の数は役に立たないことが判明しました。

表示されているものではなく、最後の修正に使用したsatsの数を使用できます。例えば。ビュー= 11、修正= 5そして、最も強いsatの信号の最大DB値を使用します。適切な信号を得るには、30Db以上である必要があります。

使用するデバイスの概念は移動/不動で、センサーは加速度、振動、入力電圧、入力信号（キー接触から）、GPSデータです。開始/停止（イベントベース）や方向/距離イベントなどの位置についてレポートするには、デバイスは移動モードである必要があります（これはカウントダウンカウンターであり、構成可能です）。

センサーは組み合わせられる可能性があります。トレーサーが移動モードではないと判断している間は、方向/距離イベントやタイマーは報告されません。関係するセンサーがレポートを停止すると、タイマーはゼロまでカウントダウンし、その後停止イベントが生成され、ユニットは非可動モードになります。次回まで。この方法では、始動エンジンの加速値を移動モードで「置く」ために分離でき、移動モードで「保持」するための別個の下限しきい値は両方とも非常に明確な加速パターンであるためです。

私たちが使用するユニットは、あなたのハードウェアがそれをするかどうかわからない、悪い衛星データでポイントが取られた場合に報告します。SV_PositionまたはSV_KeepAliveまたはSV_TimeAliveがあります。キープアライブは、GPSがテーブルを更新することも、正確な修正を取得することも、悪い修正であっても取得できないため、正確な最後の値を繰り返します。TimeAliveは、トンネルを通過するとき、または誰かがガレージに駐車したときに表示されるものです。

部分的に経験に基づいた推測であり、追跡している資産の種類に依存しますが、監視する1つの方法は電圧電源です。例えば。12.30vで動作するデバイスは、エンジンが作動していない車です。14.2vを報告するものがあれば、オルタネーターが回転していることがわかります。24V車両の場合、スポットと同様のパターンがあります。

これでアイデアが得られることを願っています。それはすべて、ハードウェアの質に少し依存します。データのソースはそこから始まり、その後の残りはすべてそのままです。ただし、ユニットサイド機能を使用して、サーバーサイドですべてを行うのではなく、品質を区別することを強くお勧めします（後から）。3000台が好きになったら、すべての追跡データを絶えず分析するために強力なサーバーが必要になります。

GPSロガーを使用してスクーターを追跡するときに、同様の問題が発生しました。私がしたことは、GPSトラックを道路レイヤーにオーバーレイし、交差点や信号機の中または近くの誤った場所を手動で削除することでした。それに対処する自動化されたツール、おそらく交差点周辺のバッファー、およびそのバッファーの出入りの最小時間と最大時間の計算があると確信しています。

これのための技術用語はスパイダーです。一般的なアプローチは、修正が以前の修正から10mの場合にのみサンプリングすることです。たとえば、Garminハンドヘルドは距離に基づいて修正を記録し、フィットネスウォッチは時間に基づいて修正を記録します。ハンドヘルドはあまりクモをしませんが、時計はします。