ああ、悲惨なIT専門家です。
DeviceOrientationEvent-名前が示すように、これはデバイスの向きの変更イベントです。 DeviceCompassEventではなく、DeviceGiroscopeEventではなく、つまりDeviceOrientationEventです。
DeviceOrientationEventの値は、多くのパラメーターに基づいてブラウザーによって計算されます（実際には、値はオペレーティングシステムから取得されます）。 値は、コンパス、ジャイロスコープ、および加速度計のデータに基づいて計算されます。 しかし、簡単な実験をしてください。 スマートフォン（タブレットおよび適切なセンサーを備えた同様のデバイス）をテーブルに置き、DeviceOrientationEvent操作のデモンストレーションをオンにして、デバイスに磁石を保持します。 明らかに、ジャイロスコープと加速度計はデバイスが動かないので測定値を変えませんが、磁石が動かされるとデモプログラムはこれに反応します。 これは、コンパスがDeviceOrientationEvent値の形成において主要な役割を果たしていることを証明します（他のセンサーの値が考慮されないため、おそらく例外的な役割さえ果たします）。 はい、申し訳ありませんが、OSとブラウザを開発しておらず、これらの値またはこれらの値がどのように形成されるかわかりません。 しかし、このような実験を行った後、これはコンパスからのデータであり、処理は行われていないと想定できます（compassneedscalibrationはまだこれを示唆しています）。
また、ジャイロスコープと加速度計からのデータは、DeviceMotionEventを使用して取得できます。 DeviceMotionEvent.accelerationおよびDeviceMotionEvent.accelerationIncludingGravityには加速度計データが含まれており、DeviceMotionEvent.rotationRateを使用してジャイロスコープからデータを取得できます。
残念ながら、センサーの名前とのこのような混乱は氷山の一角にすぎず、センサーを完全に使用することはできません。 氷山の水中部分は、データを取得するための正確な時間を取得することが常に可能であるとは限らないということです。 つまり、センサー自体は100ミリ秒ごとに測定を行います（条件付きで、たとえば、異なるセンサーには独自の時間があります）。 その後、APIが介入し（OS、ブラウザなど）、その間にランダムエラーが発生します。 したがって、作成したプログラムは100ミリ秒ごとではなく、100 + nミリ秒（nは乱数）のデータを受け取ります。 また、各測定のリアルタイムを確認する方法はありません。 残念ながら、この事実により、屋内ナビゲーション（GPSが機能しない建物内のナビゲーション）およびGPS受信機から受信した値の修正に関連するいくつかのアプリケーションを作成できませんでした。
問題の別の例は、取得した値に正確な時間がないことです。 GPS受信機からの値には、ランダムな遅延も伴います。 同時に、GPS受信機はNMEAメッセージで各測定の正確な時間を認識して報告しますが、いくつかのAPIを処理した後、この情報は失われます。 おそらく、これらのAPIの作成者は、単純化するために情報量を制限しましたが、同時にユーザーを無意識に制限していました。 これにより多くの問題が発生した場合の例： forum.openstreetmap.org/viewtopic.php?id=31779
また、物理センサーが存在しない場合、イベント値がゼロになり、更新されないという問題もあります。 デバイスが実際に完全に水平な表面にあり、動かない場合、またはシステムの速度が低下して必要なデータを送信する時間がなかった場合はどうなりますか？
さまざまなAPIの作成者がこのテキストを読んでいるのではないかと疑っていますが、それでも私のリクエストを書いていきます：センサーから生データ（特にGPS受信機からのnmeaメッセージ）を受信できること、または少なくとも各測定の正確な時間を取得できることを確認してください。 また、センサーの存在も何らかの方法でチェックされます。
そして、すぐにモジュラーデバイス（Project Ara、OpenBlocksなど）が（まだ期待されています）あります。 大幅に異なるセンサーが存在し、同一のセンサーの配列が表示され、センサーに関するデータを受信したりセンサーからデータを受信したりする既存の方法は実行不可能になります。 しかし、このトピックはまったく異なる記事を対象としています。