Testeur de gyroscope

Les pannes de gyroscope sont fréquentes après des chutes, une exposition à l'eau ou une fatigue de soudure sur les pastilles BGA du capteur, et se manifestent souvent d'abord par des applications AR boguées, des cartes qui dérivent ou une rotation automatique qui ne réagit plus. Le test confirme si les trois axes répondent, si les valeurs sont bruyantes ou bloquées, et si le biais (sortie à vitesse zéro) est conforme aux spécifications. Pour les casques VR et les IMU de drones, la santé du gyroscope affecte directement la latence mouvement-photon et la stabilité de vol. Pour les téléphones, un gyroscope dégradé peut ruiner l'OIS (stabilisation optique), la stabilisation vidéo et la précision du podomètre. Exécuter ce testeur avant d'acheter un appareil d'occasion prend 30 secondes.

Le DeviceOrientationEvent du navigateur renvoie les angles d'orientation en degrés (alpha 0–360°, beta −180 à 180°, gamma −90 à 90°), tandis que DeviceMotionEvent.rotationRate donne la vitesse angulaire en degrés par seconde dans la plupart des navigateurs (rad/s sur certaines anciennes versions de Safari — toujours vérifier). Pour un téléphone immobile sur le bureau, rotationRate devrait osciller près de 0 ±0,5 dps; toute valeur plus grande signifie une dérive de biais. Lorsque vous secouez le téléphone rapidement, des pics de 500–1500 dps sont typiques. Les gyroscopes de grade industriel sont spécifiés en millièmes de degrés par seconde (mdps) pour le biais et le bruit, tandis que les MEMS grand public sont généralement donnés en dps.

La dérive provient de deux sources. Premièrement, l'instabilité de biais : la sortie à vitesse zéro de chaque gyroscope MEMS erre lentement à cause des changements de température, du stress mécanique et du bruit électronique — les pièces grand public typiques dérivent de 10–50 dps par heure sans correction. Deuxièmement, l'erreur d'intégration : si vous intégrez la vitesse angulaire pour obtenir un angle, même un petit biais constant s'accumule linéairement en grande erreur d'angle en quelques minutes. C'est pourquoi les téléphones fusionnent les données du gyroscope avec les lectures de l'accéléromètre et du magnétomètre (fusion de capteurs via filtre complémentaire ou Kalman) pour ancrer l'estimation d'orientation. Si vous voyez des lectures constantes non nulles lorsque l'appareil est immobile, c'est le biais brut — les applications soustraient généralement un offset de calibration capturé au démarrage.

La spécification W3C DeviceOrientation définit alpha comme rotation autour de l'axe Z (cap de boussole, 0° = nord), beta comme rotation autour de l'axe X (inclinaison avant-arrière, +90° = écran vers le haut verticalement), et gamma comme rotation autour de l'axe Y (inclinaison gauche-droite, ±90° = posé sur le côté). Les conventions aérospatiales appellent ces derniers yaw, pitch et roll respectivement — mais attention au signe et à l'ordre des axes, ils diffèrent entre les standards. Pour Tait-Bryan ZXY (ordre W3C), le verrouillage de cardan se produit à beta = ±90°, faisant que alpha et gamma deviennent couplés. Pour le suivi de rotation continue, les quaternions sont préférés aux angles d'Euler exactement pour cette raison.

Le verrouillage de cardan se produit lorsque deux des trois axes de rotation s'alignent, faisant s'effondrer votre orientation tridimensionnelle à deux degrés de liberté. Dans l'ordre ZXY Tait-Bryan du W3C, cela se produit quand beta s'approche de ±90° — les rotations alpha et gamma deviennent indiscernables, et de petites inclinaisons d'appareil provoquent d'énormes sauts en alpha ou gamma. Vous le voyez en inclinant le téléphone complètement vertical (mode portrait pointant vers le haut) : le cap de boussole devient fou. Ce n'est pas un bug dans votre capteur; c'est un artefact mathématique des angles d'Euler. Les applications robustes détectent la proximité de ±90° beta et basculent vers les mathématiques quaternioniques, ou verrouillent simplement la valeur alpha lorsque beta est extrême. Les frameworks AR comme ARKit et ARCore utilisent les quaternions en interne exactement pour cette raison.

Deux APIs web sont utilisées. DeviceOrientationEvent fournit une orientation absolue (alpha/beta/gamma en degrés) via des données fusionnées gyroscope + accéléromètre + magnétomètre, déclenchées à ~60 Hz. DeviceMotionEvent fournit la vitesse angulaire brute (rotationRate.alpha/beta/gamma en dps) et l'accélération linéaire. Depuis iOS 13, les deux APIs nécessitent une permission explicite via DeviceOrientationEvent.requestPermission() appelée depuis un geste utilisateur — sans cela, Safari émet silencieusement des zéros. Android Chrome accorde l'accès automatiquement sur les pages HTTPS. La plus récente Generic Sensor API (Gyroscope, AbsoluteOrientationSensor) offre une plus grande précision mais n'est pas encore prise en charge sur Safari iOS. Cet outil retombe gracieusement lorsque l'API est manquante.

Les gyroscopes MEMS grand public sont caractérisés par quatre spécifications clés : plage pleine échelle (typiquement ±125 à ±2000 dps), sensibilité (LSB/dps), densité de bruit en mdps/√Hz (plus bas est meilleur, 4–10 est grade grand public, 0,01 est grade tactique), et instabilité de biais par variance d'Allan (le plancher de la dérive à long terme, typiquement 10–50 dph pour les pièces grand public, 0,01 dph pour le grade navigation). IEEE 1554 et IEEE 952 définissent les procédures de test standard. Le graphique de déviation d'Allan montre la marche aléatoire angulaire (ARW) à tau court et l'instabilité de biais à tau plus long — c'est ainsi qu'un amateur peut classer deux puces IMU. À titre de comparaison, le gyroscope de l'iPhone 15 a environ 0,005 dps/√Hz de bruit et ~10 dph d'instabilité de biais.