Testeur d'orientation

Les problèmes d'orientation sont subtils : un téléphone avec un pipeline d'orientation-fusionnée dégradé s'affiche encore correctement dans les applications qui n'ont besoin que de la rotation de l'écran, mais échoue en AR, vidéo 360° et contextes de navigation qui dépendent d'un cap précis. Le test révèle si les trois angles se mettent à jour en douceur lorsque vous faites pivoter l'appareil, s'ils convergent correctement lorsqu'ils sont maintenus immobiles, et si le cap de boussole (alpha) est ancré au nord vrai ou au nord magnétique. Le test expose également le verrouillage de cardan (beta près de ±90°), un magnétomètre non calibré (cap décalé de 10°+), et une dérive de gyro excessive (orientation errant lentement au repos). Les développeurs construisant des jeux d'inclinaison, des photos défilantes ou des superpositions AR utilisent cela pour valider leur matériel cible avant l'expédition.

La spécification W3C DeviceOrientation définit alpha comme rotation autour de l'axe Z (vertical, allant de 0–360° dans le sens horaire à partir du nord), beta comme rotation autour de l'axe X (inclinaison avant-arrière, allant de −180 à 180°, avec +90° signifiant que le téléphone pointe verticalement vers le haut), et gamma comme rotation autour de l'axe Y (inclinaison gauche-droite, allant de −90 à 90°). En termes aérospatiaux, alpha est yaw (cap), beta est pitch, et gamma est roll — mais attention : les conventions aérospatiales utilisent l'ordre de rotation ZYX avec des signes différents, tandis que W3C utilise ZXY. Les deux ordres donnent des valeurs d'angles différentes pour la même orientation physique. Pour le travail de rotation continue, les quaternions évitent ces ambiguïtés en représentant la rotation comme un vecteur à 4 composants sans conventions d'angle à confondre.

C'est le verrouillage de cardan, une limitation mathématique de la représentation de la rotation 3D sous forme de trois angles d'Euler. Dans l'ordre ZXY de W3C, lorsque beta traverse ±90° (téléphone pointant directement vers le haut ou directement vers le bas), les axes alpha et gamma s'alignent, faisant s'effondrer les trois degrés de liberté en deux. De petites inclinaisons d'appareil provoquent alors d'énormes sauts en alpha ou gamma pour compenser. Le phénomène n'est pas un bug de capteur — il se produit dans tout système d'angles d'Euler indépendamment du matériel. La solution robuste est d'utiliser des quaternions ou des matrices de rotation en interne et de ne convertir en angles d'Euler que pour l'affichage. Les frameworks AR (ARKit, ARCore, WebXR) utilisent tous des quaternions pour éviter cela. Si vous avez seulement besoin de yaw pour les applications de boussole, le verrouillage de cardan à beta=90° est acceptable; pour une orientation libre, passez aux quaternions.

Trois coupables expliquent les mauvaises lectures de boussole. Premièrement, magnétomètre non calibré : les offsets de fer dur des coques de téléphone avec aimants ou la proximité du métal peuvent décaler le cap de dizaines de degrés. Réparez en faisant tourner le téléphone en motif de huit pendant qu'une application de calibration capture des échantillons — la plupart des systèmes d'exploitation font cela en arrière-plan mais peuvent avoir besoin d'une nouvelle calibration après des changements d'environnement. Deuxièmement, déclinaison : les téléphones par défaut au nord magnétique à moins d'être explicitement convertis au nord vrai en utilisant le World Magnetic Model (WMM2025). Le nord magnétique diffère du nord vrai jusqu'à 30° selon votre emplacement. Troisièmement, les structures en acier intérieures distordent le champ magnétique local de 100–500 μT, décalant le cap de toute quantité. Testez toujours en extérieur pour un cap vrai.

L'orientation est une position dans l'espace de rotation 3D — vous indiquant 'le téléphone est actuellement incliné de 30° vers le bas et pointant vers le nord-est.' La vitesse de rotation (vitesse angulaire) est une dérivée — vous indiquant 'le téléphone tourne actuellement à 90°/seconde autour de l'axe Z.' Le capteur gyroscope mesure directement la vitesse de rotation; l'orientation est calculée en intégrant la vitesse de rotation dans le temps et en corrigeant la dérive avec des ancres d'accéléromètre (gravité) et de magnétomètre (nord). Si vous n'avez besoin que de détecter un virage soudain (comme un geste de mouvement vif), utilisez la vitesse de rotation de DeviceMotionEvent. Si vous avez besoin de savoir dans quelle direction l'appareil pointe actuellement pour les applications AR ou de boussole, utilisez l'orientation de DeviceOrientationEvent. Les deux peuvent être actifs simultanément.

L'API W3C DeviceOrientationEvent fournit alpha/beta/gamma à ~60 Hz, fusionnés à partir du gyroscope + accéléromètre + magnétomètre. Depuis iOS 13, appeler DeviceOrientationEvent.requestPermission() depuis un geste utilisateur est requis; sans cela, Safari émet des zéros. Android Chromium accorde l'accès automatiquement sur les pages HTTPS. La plus récente Generic Sensor API offre les classes AbsoluteOrientationSensor (cap ancré au nord vrai) et RelativeOrientationSensor (cap dérivant librement) avec sortie quaternion — préférées pour le travail AR mais uniquement prises en charge sur les navigateurs Chromium derrière la permission Sensors. Safari iOS expose webkitCompassHeading sur l'événement d'orientation pour un cap nord vrai sans nécessiter de mathématiques WMM. Détectez toujours les fonctionnalités et retombez gracieusement.

La spécification d'événement DeviceOrientation du W3C définit les conventions alpha/beta/gamma, l'ordre des axes (Tait-Bryan intrinsèque ZXY), et la cible de taux de mise à jour (60 Hz). Les spécifications plus récentes W3C Generic Sensor API pour AbsoluteOrientationSensor et RelativeOrientationSensor utilisent des quaternions pour éviter l'ambiguïté d'Euler. La spécification runtime OpenXR régit le rapport d'orientation du suivi de tête AR/VR. La référence du magnétomètre provient du World Magnetic Model (WMM2025, NOAA/BGS), mis à jour tous les cinq ans. Les performances du gyroscope et de l'IMU sont caractérisées via IEEE 1554 et IEEE 952 (instabilité de biais par variance d'Allan, marche aléatoire angulaire). Les téléphones modernes répondent à la spécification supplémentaire d'aviation IATA de précision ±1° pitch/roll et ±5° de cap — plus que suffisant pour la navigation, les jeux et la plupart des applications AR.