Probador de giroscopio

Las fallas del giroscopio son comunes tras caídas, exposición al agua o fatiga de soldadura en los contactos BGA del sensor, y suelen manifestarse primero como aplicaciones AR defectuosas, mapas que se desvían o auto-rotación que ya no reacciona. La prueba confirma si los tres ejes responden, si los valores tienen ruido o están atascados, y si el sesgo (salida con velocidad cero) está dentro de especificación. Para cascos VR y IMU de drones, la salud del giroscopio afecta directamente la latencia movimiento-fotón y la estabilidad de vuelo. Para teléfonos, un giroscopio degradado puede arruinar el OIS (estabilización óptica), la estabilización de video y la precisión del podómetro. Ejecutar este probador antes de comprar un dispositivo usado o tras una reparación toma 30 segundos y ahorra devoluciones costosas.

El DeviceOrientationEvent del navegador devuelve ángulos de orientación en grados (alpha 0–360°, beta −180 a 180°, gamma −90 a 90°), mientras que DeviceMotionEvent.rotationRate da velocidad angular en grados por segundo en la mayoría de navegadores (rad/s en algunas versiones antiguas de Safari — verifica siempre). Para un teléfono quieto sobre el escritorio, rotationRate debería oscilar cerca de 0 ±0,5 dps; cualquier valor mayor indica deriva del sesgo. Cuando agitas el teléfono rápido, son típicos picos de 500–1500 dps. Los giroscopios industriales se especifican en milésimas de grados por segundo (mdps) para sesgo y ruido, mientras que los MEMS de consumo suelen darse en dps.

La deriva proviene de dos fuentes. Primera, inestabilidad del sesgo: la salida con velocidad cero de cada giroscopio MEMS vaga lentamente debido a cambios de temperatura, estrés mecánico y ruido electrónico — las piezas de consumo típicas derivan 10–50 dps por hora sin corrección. Segunda, error de integración: si integras la velocidad angular para obtener un ángulo, incluso un pequeño sesgo constante se acumula linealmente como un gran error angular en minutos. Por eso los teléfonos fusionan datos del giroscopio con lecturas del acelerómetro y magnetómetro (fusión de sensores vía filtro complementario o Kalman) para anclar la estimación de orientación. Si ves lecturas no nulas constantes cuando el dispositivo está quieto, ese es el sesgo crudo — las aplicaciones suelen restar un offset de calibración capturado al inicio.

La especificación W3C DeviceOrientation define alpha como rotación alrededor del eje Z (rumbo de la brújula, 0° = norte), beta como rotación alrededor del eje X (inclinación adelante-atrás, +90° = pantalla mirando hacia arriba vertical), y gamma como rotación alrededor del eje Y (inclinación izquierda-derecha, ±90° = recostado sobre el lado). Las convenciones aeroespaciales llaman a estos yaw, pitch y roll respectivamente — pero cuidado con el signo y el orden de los ejes, difieren entre estándares. Para Tait-Bryan ZXY (orden W3C), el bloqueo de cardán ocurre con beta = ±90°, haciendo que alpha y gamma se acoplen. Para seguimiento continuo de rotación, los cuaterniones son preferibles a los ángulos de Euler precisamente por esto.

El bloqueo de cardán ocurre cuando dos de los tres ejes de rotación se alinean, colapsando tu orientación tridimensional a dos grados de libertad. En el orden ZXY Tait-Bryan del W3C, esto ocurre cuando beta se acerca a ±90° — las rotaciones alpha y gamma se vuelven indistinguibles, y pequeñas inclinaciones causan saltos enormes en alpha o gamma. Lo ves al inclinar el teléfono totalmente vertical (modo retrato apuntando hacia arriba): el rumbo de la brújula enloquece. No es un error de tu sensor; es un artefacto matemático de los ángulos de Euler. Las aplicaciones robustas detectan la proximidad a ±90° beta y cambian a matemáticas de cuaterniones, o simplemente fijan el valor alpha cuando beta es extremo. Los frameworks AR como ARKit y ARCore usan cuaterniones internamente por exactamente esta razón.

Se usan dos APIs web. DeviceOrientationEvent provee orientación absoluta (alpha/beta/gamma en grados) vía datos fusionados de giroscopio + acelerómetro + magnetómetro, disparados a ~60 Hz. DeviceMotionEvent provee velocidad angular cruda (rotationRate.alpha/beta/gamma en dps) y aceleración lineal. Desde iOS 13, ambas APIs requieren permiso explícito vía DeviceOrientationEvent.requestPermission() llamado desde un gesto del usuario — sin él, Safari emite ceros silenciosamente. Android Chrome otorga acceso automáticamente en páginas HTTPS. La más reciente Generic Sensor API (Gyroscope, AbsoluteOrientationSensor) ofrece mayor precisión pero aún no es compatible con Safari iOS. Esta herramienta cambia con gracia cuando la API falta.

Los giroscopios MEMS de consumo se caracterizan por cuatro especificaciones clave: rango de escala completa (típicamente ±125 a ±2000 dps), sensibilidad (LSB/dps), densidad de ruido en mdps/√Hz (menor es mejor, 4–10 es grado consumidor, 0,01 es grado táctico), e inestabilidad de sesgo por varianza de Allan (el piso de la deriva a largo plazo, típicamente 10–50 dph para piezas de consumo, 0,01 dph para grado de navegación). IEEE 1554 e IEEE 952 definen los procedimientos de prueba estándar. La gráfica de desviación de Allan muestra random walk angular (ARW) en tau corto e inestabilidad de sesgo en tau más largo — así un aficionado puede clasificar dos chips IMU. Como comparación, el giroscopio del iPhone 15 tiene aproximadamente 0,005 dps/√Hz de ruido y ~10 dph de inestabilidad de sesgo.

Los teléfonos y tabletas Android en Chrome, Edge o Samsung Internet funcionan automáticamente siempre que la página se sirva por HTTPS — no aparece ningún aviso y los datos fluyen en cuanto pulsas Iniciar. El iPhone y iPad en iOS/iPadOS 13 o posterior funcionan en Safari pero requieren conceder permiso explícito: tocar Iniciar dispara DeviceOrientationEvent.requestPermission() (y DeviceMotionEvent.requestPermission() para la velocidad de rotación cruda), que debes responder Permitir. Los ordenadores de escritorio y portátiles casi nunca tienen giroscopio, así que DeviceOrientationEvent existe pero solo emite valores nulos; esta herramienta lo detecta en ~1,5 segundos y muestra un honesto mensaje de 'no se recibieron datos del sensor' en lugar de un 0° falso. Los navegadores integrados en apps (Facebook, Instagram) a veces bloquean el permiso de movimiento — abre la página en la app real de Safari o Chrome si Iniciar no hace nada.

No. Cada lectura se procesa enteramente en tu navegador usando las APIs web DeviceOrientation y DeviceMotion. Nada se envía a un servidor, se registra ni se almacena — no hay cuenta, ni subida, ni analítica sobre el flujo del sensor. Cuando usas la función Grabar, las muestras con marca de tiempo viven solo en la memoria de la pestaña del navegador; los botones Descargar CSV y Descargar JSON construyen el archivo localmente con un Blob y lo entregan directamente a las descargas de tu dispositivo. Cierra la pestaña y los datos capturados desaparecen. Esto hace que el probador sea seguro para ejecutar en dispositivos de clientes en un taller de reparación sin preocupaciones de privacidad.

Un giroscopio sano responde suave e independientemente en los tres ejes. Para probar alpha (Z), mantén el móvil plano y gíralo como un volante — el valor alpha y el rumbo de brújula deben recorrer 0–360°. Para beta (X), inclina el borde superior arriba y abajo — beta debe oscilar de −90° a +90°. Para gamma (Y), inclina a izquierda y derecha — gamma debe moverse ±90°. Un APROBADO significa que cada valor sigue tu movimiento en tiempo real y vuelve cerca de su valor de reposo al detenerte. Un FALLO se ve así: un eje congelado en un número mientras giras (eje atascado/muerto), un eje saltando erráticamente con el dispositivo quieto (eje ruidoso), o una velocidad de rotación grande no nula sobre la mesa (deriva de sesgo). Pulsa Grabar mientras haces un barrido completo de giro y luego lee el Rango por eje — un rango casi cero en un eje que realmente moviste es la señal más clara de un eje muerto.

Porque la máquina no tiene giroscopio. La API DeviceOrientation está implementada en Chrome, Edge y Firefox de escritorio por compatibilidad, pero sin un sensor físico detrás el navegador solo entrega lecturas nulas. Los probadores antiguos o ingenuos convierten esos nulos en 0 y muestran un 0° confiado pero sin sentido; esta herramienta en cambio ejecuta un vigilante de 1,5 segundos y, si no llega una lectura real (no nula), se detiene y te dice claramente que no se recibieron datos del sensor. Para probar realmente un giroscopio necesitas un dispositivo que lo tenga — prácticamente cualquier móvil o tableta moderna — abierto por HTTPS. Una IMU externa USB o Bluetooth no aparecerá aquí; las APIs web solo exponen los sensores de movimiento integrados.

Pulsar Grabar mientras el sensor está activo registra una muestra con marca de tiempo en cada evento de orientación: tiempo transcurrido en milisegundos, los tres ángulos de orientación (alpha, beta, gamma en grados) y, cuando DeviceMotion está disponible, la velocidad de rotación cruda de cada eje en grados por segundo (dps). Al detener la grabación, la herramienta calcula mín, máx, promedio y rango por eje más la velocidad de rotación absoluta máxima, y habilita Descargar CSV y Descargar JSON. El CSV (una fila por muestra) entra directo en Excel, Google Sheets o un cuaderno Python/pandas para graficar ruido y sesgo; el JSON además incrusta las estadísticas calculadas y los metadatos de unidades. Los laboratorios de calidad y técnicos de reparación lo usan para adjuntar pruebas objetivas a un ticket de reparación, comparar un dispositivo antes y después de reparar, y probar lotes de unidades numéricamente en lugar de mirar una aguja.