En esta sección, se describen los ejes de los sensores, los sensores básicos y los sensores compuestos (actividad, actitud, sin calibrar y de interacción).
Ejes del sensor
Los valores de los eventos de muchos sensores se expresan en un marco específico que es estático en relación con el dispositivo.
Ejes del dispositivo móvil
La API de Sensor solo es relativa a la orientación natural de la pantalla (los ejes no se intercambian cuando cambia la orientación de la pantalla del dispositivo).
Figura 1: Sistema de coordenadas (en relación con un dispositivo móvil) que usa la API del sensor
Hachas para automóviles
En las implementaciones de Android Automotive, los ejes se definen con respecto al marco de la carrocería del vehículo. El origen del marco de referencia del vehículo es el centro del eje trasero. El marco de referencia del vehículo se orienta de modo que:
- El eje X apunta hacia la derecha y se encuentra en un plano horizontal, perpendicular al plano de simetría del vehículo.
- El eje Y apunta hacia adelante y se encuentra en un plano horizontal.
Figura 2: Sistema de coordenadas (en relación con un dispositivo automotriz) que usa la API del sensor
El marco de referencia del vehículo es un sistema de coordenadas a la derecha. Por lo tanto, el eje Z apunta hacia arriba.
El eje Z del marco de referencia está alineado con la gravedad, lo que significa que el eje X y el eje Y son horizontales. Como resultado, es posible que el eje Y no siempre atraviese el eje delantero.
Sensores de la base
Los tipos de sensores básicos se denominan según los sensores físicos que representan. Estos sensores transmiten datos de un solo sensor físico (a diferencia de los sensores compuestos que generan datos a partir de otros sensores). Estos son algunos ejemplos de tipos de sensores básicos:
SENSOR_TYPE_ACCELEROMETERSENSOR_TYPE_GYROSCOPESENSOR_TYPE_MAGNETOMETER
Sin embargo, los sensores base no son iguales a sus sensores físicos subyacentes y no deben confundirse con ellos. Los datos de un sensor base no son el resultado sin procesar del sensor físico, ya que se aplican correcciones (como la compensación de sesgo y la compensación de temperatura).
Por ejemplo, las características de un sensor base pueden ser diferentes de las de su sensor físico subyacente en los siguientes casos de uso:
- Un chip de giroscopio con un rango de sesgo de 1 deg/s.
- Después de la calibración de fábrica, se aplican la compensación de temperatura y la compensación de sesgo. El sesgo real del sensor de Android se reducirá, tal vez, hasta un punto en el que se garantice que el sesgo sea inferior a 0.01 deg/s.
- En esta situación, decimos que el sensor de Android tiene una desviación inferior a 0.01 deg/s, aunque la hoja de datos del sensor subyacente indique 1 deg/s.
- Un barómetro con un consumo de energía de 100 μW.
- Dado que los datos generados deben transportarse del chip al SoC, el costo de energía real para recopilar datos del sensor de barómetro de Android podría ser mucho mayor, por ejemplo, 1,000 uW.
- En esta situación, decimos que el sensor de Android tiene un consumo de energía de 1,000 uW, aunque el consumo de energía medido en los cables del chip del barómetro sea de 100 uW.
- Un magnetómetro que consume 100 uW cuando está calibrado, pero consume más cuando se calibra.
- Su rutina de calibración podría requerir la activación del giroscopio, lo que consume 5,000 uW, y la ejecución de algún algoritmo, lo que cuesta otros 900 uW.
- En esta situación, decimos que el consumo máximo de energía del sensor de Android (magnetómetro) es de 6,000 uW.
- En este caso, el consumo de energía promedio es la medida más útil, y es lo que se informa en las características estáticas del sensor a través del HAL.
Acelerómetro
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER)
devuelve un sensor que no es de activación
Un sensor acelerómetro informa la aceleración del dispositivo a lo largo de los tres ejes del sensor. La aceleración medida incluye tanto la aceleración física (cambio de velocidad) como la gravedad. La medición se informa en los campos x, y y z de sensors_event_t.acceleration.
Todos los valores están en unidades del SI (m/s²) y miden la aceleración del dispositivo menos la fuerza de gravedad a lo largo de los tres ejes del sensor.
Estos son algunos ejemplos:
- La norma de (x, y, z) debe ser cercana a 0 cuando el dispositivo está en caída libre.
- Cuando el dispositivo está apoyado sobre una mesa y se lo empuja desde el lado izquierdo hacia la derecha, el valor de aceleración en X es positivo.
- Cuando el dispositivo está apoyado sobre una mesa, el valor de aceleración a lo largo de Z es +9.81 alo, lo que corresponde a la aceleración del dispositivo (0 m/s²) menos la fuerza de gravedad (-9.81 m/s²).
- Cuando el dispositivo está apoyado sobre una mesa y se empuja hacia el cielo, el valor de aceleración es mayor que +9.81, lo que corresponde a la aceleración del dispositivo (+A m/s²) menos la fuerza de gravedad (-9.81 m/s²).
Las lecturas se calibran con lo siguiente:
- Compensación de temperatura
- Calibración del sesgo en línea
- Calibración de la báscula en línea
La calibración del sesgo y la escala solo se debe actualizar mientras el sensor está desactivado para evitar saltos en los valores durante la transmisión.
El acelerómetro también informa qué tan precisas espera que sean sus lecturas a través de sensors_event_t.acceleration.status. Consulta las constantes
SENSOR_STATUS_* de
SensorManager para obtener más información sobre los valores posibles de este campo.
Temperatura ambiental
Modo de informe: On-change
getDefaultSensor(SENSOR_TYPE_AMBIENT_TEMPERATURE)
devuelve un sensor que no es de activación
Este sensor proporciona la temperatura ambiente (de la habitación) en grados Celsius.
Sensor de campo magnético
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD)
devuelve un sensor que no es de activación
SENSOR_TYPE_GEOMAGNETIC_FIELD == SENSOR_TYPE_MAGNETIC_FIELD
Un sensor de campo magnético (también conocido como magnetómetro) informa el campo magnético ambiental, medido a lo largo de los tres ejes del sensor.
La medición se informa en los campos x, y y z de sensors_event_t.magnetic, y todos los valores están en microteslas (uT).
El magnetómetro también informa qué tan precisas espera que sean sus lecturas a través de sensors_event_t.magnetic.status.
Consulta las constantes
SENSOR_STATUS_* de SensorManager para obtener más información sobre los valores posibles de este campo.
Las lecturas se calibran con lo siguiente:
- Compensación de temperatura
- Calibración de hierro dulce de fábrica (o en línea)
- Calibración en línea de la influencia del hardware
Giroscopio
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_GYROSCOPE)
devuelve un sensor que no es de activación
Un sensor de giroscopio informa la velocidad de rotación del dispositivo alrededor de los tres ejes del sensor.
La rotación es positiva en el sentido contrario a las agujas del reloj (regla de la mano derecha). Es decir, un observador que mira desde alguna ubicación positiva en el eje X, Y o Z a un dispositivo ubicado en el origen informaría una rotación positiva si el dispositivo pareciera girar en sentido contrario a las agujas del reloj. Ten en cuenta que esta es la definición matemática estándar de rotación positiva y no coincide con la definición aeronáutica de alabeo.
La medición se informa en los campos x, y y z de sensors_event_t.gyro, y todos los valores están en radianes por segundo (rad/s).
Las lecturas se calibran con lo siguiente:
- Compensación de temperatura
- Compensación a escala de fábrica (o en línea)
- Calibración del sesgo en línea (para eliminar la desviación)
El giroscopio también informa qué tan precisas espera que sean sus lecturas a través de sensors_event_t.gyro.status. Consulta las constantes
SENSOR_STATUS_* de
SensorManager para obtener más información sobre los valores posibles de este campo.
El giroscopio no se puede emular en función de los magnetómetros y los acelerómetros, ya que esto haría que tuviera una menor coherencia y capacidad de respuesta locales. Debe basarse en un chip de giroscopio habitual.
Frecuencia cardíaca
Modo de informe: On-change
getDefaultSensor(SENSOR_TYPE_HEART_RATE)
devuelve un sensor que no es de activación
Un sensor de frecuencia cardíaca informa la frecuencia cardíaca actual de la persona que toca el dispositivo.
La frecuencia cardíaca actual en pulsaciones por minuto (PPM) se informa en sensors_event_t.heart_rate.bpm y el estado del sensor se informa en sensors_event_t.heart_rate.status. Consulta las constantes
SENSOR_STATUS_* de
SensorManager para obtener más información sobre los valores posibles de este campo. En particular, en la primera activación, a menos que se sepa que el dispositivo no está en el cuerpo, el campo de estado del primer evento debe establecerse en SENSOR_STATUS_UNRELIABLE. Debido a que este sensor es on-change, los eventos se generan cuando heart_rate.bpm o heart_rate.status cambiaron desde el último evento y solo en ese caso. Los eventos se generan cada sampling_period como mínimo.
El framework anula automáticamente sensor_t.requiredPermission con el permiso adecuado para mantener la compatibilidad. El framework usa el permiso SENSOR_PERMISSION_READ_HEART_RATE para Android 16 y versiones posteriores, y el permiso SENSOR_PERMISSION_BODY_SENSORS para Android 15 y versiones anteriores.
Claro
Reporting-mode: On-change
getDefaultSensor(SENSOR_TYPE_LIGHT)
devuelve un sensor que no es de activación
Un sensor de luz informa la iluminación actual en unidades lux del SI.
La medición se informa en sensors_event_t.light.
Proximidad
Reporting-mode: On-change
Por lo general, se define como un sensor de activación.
getDefaultSensor(SENSOR_TYPE_PROXIMITY)
devuelve un sensor de activación
Un sensor de proximidad informa la distancia desde el sensor hasta la superficie visible más cercana.
Hasta Android 4.4, los sensores de proximidad siempre fueron sensores de activación que activaban el SoC cuando detectaban un cambio en la proximidad. Después de Android 4.4, te recomendamos que implementes primero la versión de activación de este sensor, ya que es la que se usa para encender y apagar la pantalla mientras se realizan llamadas telefónicas.
La medición se informa en centímetros en sensors_event_t.distance. Ten en cuenta que algunos sensores de proximidad solo admiten una medición binaria de "cerca" o "lejos".
En este caso, el sensor informa su valor de sensor_t.maxRange en el estado "lejos" y un valor inferior a sensor_t.maxRange en el estado "cerca".
Presionar
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_PRESSURE)
devuelve un sensor que no es de activación
Un sensor de presión (también conocido como barómetro) informa la presión atmosférica en hectopascales (hPa).
Las lecturas se calibran con
- Compensación de temperatura
- Calibración de sesgo de fábrica
- Calibración a escala de fábrica
El barómetro se suele usar para estimar los cambios de elevación. Para estimar la elevación absoluta, se debe usar como referencia la presión a nivel del mar (que cambia según el clima).
Humedad relativa
Reporting-mode: On-change
getDefaultSensor(SENSOR_TYPE_RELATIVE_HUMIDITY)
devuelve un sensor que no es de activación
Un sensor de humedad relativa mide la humedad relativa del aire ambiente y devuelve un valor en porcentaje.
Tipos de sensores compuestos
Un sensor compuesto genera datos procesando o fusionando datos de uno o varios sensores físicos. (Cualquier sensor que no sea un sensor base se denomina sensor compuesto). Estos son algunos ejemplos de sensores compuestos:
- El detector de pasos y el movimiento significativo, que suelen basarse en un acelerómetro, pero también podrían basarse en otros sensores si el consumo de energía y la precisión fueran aceptables.
- Vector de rotación del juego, basado en un acelerómetro y un giroscopio.
- Giroscopio no calibrado, que es similar al sensor de base del giroscopio, pero con la calibración del sesgo que se informa por separado en lugar de corregirse en la medición.
Al igual que con los sensores básicos, las características de los sensores compuestos provienen de las características de sus datos finales. Por ejemplo, el consumo de energía de un vector de rotación de juego probablemente sea igual a la suma de los consumos de energía del chip del acelerómetro, el chip del giroscopio, el chip que procesa los datos y los buses que transportan los datos. Como otro ejemplo, la desviación de un vector de rotación del juego depende tanto de la calidad del algoritmo de calibración como de las características físicas del sensor.
En la siguiente tabla, se enumeran los tipos de sensores compuestos disponibles. Cada sensor compuesto se basa en los datos de uno o varios sensores físicos. Evita elegir otros sensores físicos subyacentes para aproximar los resultados, ya que proporcionan una mala experiencia del usuario.
| Tipo de sensor | Categoría | Sensores físicos subyacentes | Modo de informes |
|---|---|---|---|
Actitud |
Acelerómetro, giroscopio, NO USAR magnetómetro |
Continuo |
|
Actitud |
Acelerómetro, magnetómetro, NO USAR giroscopio |
Continuo |
|
Gesto de vistazo  |
Interacción |
Sin definir |
Un ejemplo |
Actitud |
Acelerómetro, giroscopio (si está presente) o magnetómetro (si no está presente el giroscopio) |
Continuo |
|
Sin calibrar |
Giroscopio |
Continuo |
|
Actividad |
Acelerómetro, giroscopio (si está presente) o magnetómetro (si no está presente el giroscopio) |
Continuo |
|
Sin calibrar |
Magnetómetro |
Continuo |
|
Orientation (obsoleto) |
Actitud |
Acelerómetro, magnetómetro y giroscopio (si están presentes) |
Continuo |
Interacción |
Sin definir |
Un ejemplo |
|
Actitud |
Acelerómetro, magnetómetro y giroscopio (si están presentes) |
Continuo |
|
Actividad |
Acelerómetro (o cualquier otro que consuma muy poca energía) |
Un ejemplo |
|
Actividad |
Acelerómetro |
Al cambiar |
|
Actividad |
Acelerómetro |
Especial |
|
Actividad |
Acelerómetro |
Especial |
|
Interacción |
Sin definir |
Un ejemplo |
= Sensor de bajo consumo
Sensores compuestos de actividad
Aceleración lineal
Sensores físicos subyacentes: Acelerómetro y (si está presente) giroscopio (o magnetómetro si no está presente el giroscopio)
Modo de informes: Continuo
getDefaultSensor(SENSOR_TYPE_LINEAR_ACCELERATION)
devuelve un sensor que no es de activación
Un sensor de aceleración lineal informa la aceleración lineal del dispositivo en el marco del sensor, sin incluir la gravedad.
Conceptualmente, el resultado es el resultado del acelerómetro menos el resultado del sensor de gravedad. Se informa en m/s² en los campos x, y y z de sensors_event_t.acceleration.
Las lecturas en todos los ejes deben estar cerca de 0 cuando el dispositivo está inmóvil.
Si el dispositivo tiene un giroscopio, el sensor de aceleración lineal debe usar el giroscopio y el acelerómetro como entrada.
Si el dispositivo no tiene un giroscopio, el sensor de aceleración lineal debe usar el acelerómetro y el magnetómetro como entrada.
Movimiento significativo
Sensor físico subyacente: Acelerómetro (o cualquier otro, siempre que sea de bajo consumo)
Modo de informe: One-shot
Bajo consumo
Implementa solo la versión de activación de este sensor.
getDefaultSensor(SENSOR_TYPE_SIGNIFICANT_MOTION)
devuelve un sensor de activación
Un detector de movimiento significativo se activa cuando detecta un movimiento significativo, es decir, un movimiento que podría provocar un cambio en la ubicación del usuario.
Estos son algunos ejemplos de mociones significativas:
- Caminata o paseo en bicicleta
- Sentarse en un automóvil, autobús o tren en movimiento
Ejemplos de situaciones que no activan un movimiento significativo:
- Teléfono en el bolsillo y la persona no se mueve
- El teléfono está sobre una mesa, y esta se sacude un poco debido al tráfico cercano o a la lavadora.
A un nivel superior, el detector de movimiento significativo se usa para reducir el consumo de energía de la determinación de la ubicación. Cuando los algoritmos de localización detectan que el dispositivo está estático, pueden cambiar a un modo de bajo consumo, en el que dependen de un movimiento significativo para activar el dispositivo cuando el usuario cambia de ubicación.
Este sensor debe tener un bajo consumo de energía. Se compensa el consumo de energía, lo que puede generar una pequeña cantidad de falsos negativos. Esto se hace por varios motivos:
- El objetivo de este sensor es ahorrar energía.
- Activar un evento cuando el usuario no se está moviendo (falso positivo) es costoso en términos de energía, por lo que se debe evitar.
- No activar un evento cuando el usuario se está moviendo (falso negativo) es aceptable siempre y cuando no se haga de forma repetida. Si el usuario caminó durante 10 segundos, no activar un evento en ese lapso no es aceptable.
Cada evento del sensor informa 1 en sensors_event_t.data[0].
Detector de pasos
Sensor físico subyacente: Acelerómetro (y posiblemente otros, siempre que sean de bajo consumo)
Reporting-mode: Special (un evento por paso realizado)
Bajo consumo
getDefaultSensor(SENSOR_TYPE_STEP_DETECTOR)
devuelve un sensor que no es de activación
Un detector de pasos genera un evento cada vez que el usuario da un paso.
La marca de tiempo del evento sensors_event_t.timestamp corresponde al momento en que el pie tocó el suelo, lo que generó una gran variación en la aceleración.
En comparación con el contador de pasos, el detector de pasos debe tener una latencia más baja (menos de dos segundos). Tanto el detector de pasos como el contador de pasos detectan cuando el usuario camina, corre y sube escaleras. No deben activarse cuando el usuario está en bicicleta, conduciendo o en otros vehículos.
Este sensor debe tener un bajo consumo de energía. Es decir, si la detección de pasos no se puede realizar en el hardware, no se debe definir este sensor. En particular, cuando se activa el detector de pasos y no el acelerómetro, solo los pasos deben activar interrupciones (no cada lectura del acelerómetro).
sampling_period_ns no tiene impacto en los detectores de pasos.
Cada evento del sensor informa 1 en sensors_event_t.data[0].
Contador de pasos
Sensor físico subyacente: Acelerómetro (y posiblemente otros, siempre que sean de bajo consumo)
Reporting-mode: On-change
Bajo consumo
getDefaultSensor(SENSOR_TYPE_STEP_COUNTER)
devuelve un sensor que no es de activación
Un contador de pasos informa la cantidad de pasos que dio el usuario desde el último reinicio mientras estuvo activado.
La medición se informa como un uint64_t en sensors_event_t.step_counter y se restablece a cero solo cuando se reinicia el sistema.
La marca de tiempo del evento se establece en el momento en que se realizó el último paso para ese evento.
Consulta el tipo de sensor Detector de pasos para conocer el significado del tiempo de un paso.
En comparación con el detector de pasos, el contador de pasos puede tener una latencia más alta (hasta 10 segundos). Gracias a esta latencia, el sensor tiene una alta precisión. El recuento de pasos después de un día completo de mediciones debe estar dentro del 10% del recuento de pasos real. Tanto el detector de pasos como el contador de pasos detectan cuando el usuario camina, corre y sube escaleras. No deben activarse cuando el usuario está en bicicleta, conduciendo o en otros vehículos.
El hardware debe garantizar que el recuento interno de pasos nunca se desborde. El tamaño mínimo del contador interno del hardware debe ser de 16 bits. En caso de desbordamiento inminente (como máximo, cada ~2^16 pasos), se puede activar el SoC para que el controlador pueda realizar el mantenimiento del contador.
Como se indica en Interacción, mientras este sensor esté en funcionamiento, no debe interrumpir el funcionamiento de ningún otro sensor, en particular, el acelerómetro, que podría estar en uso.
Si un dispositivo en particular no admite estos modos de funcionamiento, el HAL no debe informar este tipo de sensor. Es decir, no se acepta "emular" este sensor en el HAL.
Este sensor debe tener un bajo consumo de energía. Es decir, si la detección de pasos no se puede realizar en el hardware, no se debe definir este sensor. En particular, cuando se activa el contador de pasos y no el acelerómetro, solo los pasos deben activar interrupciones (no los datos del acelerómetro).
Detector de inclinación
Sensor físico subyacente: Acelerómetro (y posiblemente otros, siempre que sean de bajo consumo)
Modo de informes: Especial
Bajo consumo
Implementa solo la versión de activación de este sensor.
getDefaultSensor(SENSOR_TYPE_TILT_DETECTOR)
devuelve un sensor de activación
Un detector de inclinación genera un evento cada vez que se detecta un evento de inclinación.
Un evento de inclinación se define por la dirección del promedio de gravedad de la ventana de 2 segundos que cambia en al menos 35 grados desde la activación o el último evento generado por el sensor. Este es el algoritmo:
reference_estimated_gravity= promedio de las mediciones del acelerómetro durante el primer segundo después de la activación o la gravedad estimada cuando se generó el último evento de inclinación.current_estimated_gravity= Promedio de las mediciones del acelerómetro durante los últimos 2 segundos.- Se activa cuando
angle(reference_estimated_gravity, current_estimated_gravity) > 35 degrees
Las aceleraciones grandes sin un cambio en la orientación del teléfono no deberían activar un evento de inclinación. Por ejemplo, un giro brusco o una aceleración fuerte mientras conduces un automóvil no deberían activar un evento de inclinación, aunque el ángulo de la aceleración promedio podría variar en más de 35 grados.
Por lo general, este sensor se implementa solo con la ayuda de un acelerómetro. También se pueden usar otros sensores si no aumentan el consumo de energía de manera significativa. Este es un sensor de bajo consumo que debería permitir que el SoC entre en modo de suspensión. No emules este sensor en el HAL. Cada evento del sensor informa 1 en sensors_event_t.data[0].
Sensores compuestos de actitud
Vector de rotación
Sensores físicos subyacentes: acelerómetro, magnetómetro y giroscopio
Modo de informes: Continuo
getDefaultSensor(SENSOR_TYPE_ROTATION_VECTOR) devuelve un sensor que no es de activación
Un sensor de vector de rotación informa la orientación del dispositivo en relación con el marco de coordenadas Este-Norte-Arriba. Por lo general, se obtiene integrando las lecturas del acelerómetro, el giroscopio y el magnetómetro. El sistema de coordenadas Este-Norte-Arriba se define como una base ortonormal directa en la que:
- X apunta hacia el este y es tangente al suelo.
- El eje Y apunta hacia el norte y es tangente al suelo.
- El eje Z apunta hacia el cielo y es perpendicular al suelo.
La orientación del teléfono se representa con la rotación necesaria para alinear las coordenadas Este-Norte-Arriba con las coordenadas del teléfono. Es decir, aplicar la rotación al marco mundial (X,Y,Z) los alinearía con las coordenadas del teléfono (x,y,z).
La rotación se puede ver como la rotación del teléfono en un ángulo theta alrededor de un eje rot_axis para pasar de la orientación de referencia del dispositivo (alineada hacia el este, el norte y arriba) a la orientación actual del dispositivo. La rotación se codifica como los cuatro componentes x, y, z y w sin unidades de un cuaternión unitario:
sensors_event_t.data[0] = rot_axis.x*sin(theta/2)sensors_event_t.data[1] = rot_axis.y*sin(theta/2)sensors_event_t.data[2] = rot_axis.z*sin(theta/2)sensors_event_t.data[3] = cos(theta/2)
En la que:
- Los campos x, y y z de
rot_axisson las coordenadas Este-Norte-Arriba de un vector de longitud unitaria que representa el eje de rotación. thetaes el ángulo de rotación.
El cuaternión es un cuaternión unitario: debe tener una norma de 1.
Si no te aseguras de que esto se cumpla, el cliente tendrá un comportamiento errático.
Además, este sensor informa una precisión de orientación estimada:
sensors_event_t.data[4] = estimated_accuracy (en radianes)
El error de rumbo debe ser inferior a estimated_accuracy el 95% del tiempo. Este sensor debe usar un giroscopio como la principal entrada de cambio de orientación.
Este sensor también usa la entrada del acelerómetro y el magnetómetro para compensar la deriva del giroscopio, y no se puede implementar solo con el acelerómetro y el magnetómetro.
Vector de rotación del juego
Sensores físicos subyacentes: Acelerómetro y giroscopio (sin magnetómetro)
Modo de informes: Continuo
getDefaultSensor(SENSOR_TYPE_GAME_ROTATION_VECTOR)
devuelve un sensor que no es de activación
Un sensor de vector de rotación de juegos es similar a un sensor de vector de rotación, pero no usa el campo geomagnético. Por lo tanto, el eje Y no apunta hacia el norte, sino hacia alguna otra referencia. Se permite que esa referencia se desvíe en el mismo orden de magnitud que el giroscopio se desvía alrededor del eje Z.
Consulta el sensor Vector de rotación para obtener detalles sobre cómo configurar sensors_event_t.data[0-3]. Este sensor no informa una exactitud estimada del rumbo: sensors_event_t.data[4] está reservado y debe establecerse en 0.
En un caso ideal, un teléfono que se rota y vuelve a la misma orientación del mundo real debería informar el mismo vector de rotación del juego.
Este sensor debe basarse en un giroscopio y un acelerómetro. No puede usar el magnetómetro como entrada, excepto de forma indirecta, a través de la estimación de la desviación del giroscopio.
Gravity
Sensores físicos subyacentes: Acelerómetro y (si está presente) giroscopio (o magnetómetro si no está presente el giroscopio)
Modo de informes: Continuo
getDefaultSensor(SENSOR_TYPE_GRAVITY)
devuelve un sensor que no es de activación
Un sensor de gravedad informa la dirección y la magnitud de la gravedad en las coordenadas del dispositivo.
Los componentes del vector de gravedad se registran en m/s² en los campos x, y y z de sensors_event_t.acceleration.
Cuando el dispositivo está en reposo, el resultado del sensor de gravedad debe ser idéntico al del acelerómetro. En la Tierra, la magnitud es de alrededor de 9.8 m/s².
Si el dispositivo tiene un giroscopio, el sensor de gravedad debe usar el giroscopio y el acelerómetro como entrada.
Si el dispositivo no tiene un giroscopio, el sensor de gravedad debe usar el acelerómetro y el magnetómetro como entrada.
Vector de rotación geomagnética
Sensores físicos subyacentes: Acelerómetro y magnetómetro (sin giroscopio)
Modo de informes: Continuo
Bajo consumo
getDefaultSensor(SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR)
devuelve un sensor que no es de activación
Un vector de rotación geomagnético es similar a un sensor de vector de rotación, pero usa un magnetómetro y no un giroscopio.
Este sensor debe basarse en un magnetómetro. No se puede implementar con un giroscopio, y este sensor no puede usar la entrada del giroscopio.
Consulta el sensor Vector de rotación para obtener detalles sobre cómo configurar sensors_event_t.data[0-4].
Al igual que con el sensor de vector de rotación, el error de dirección debe ser inferior a la precisión estimada (sensors_event_t.data[4]) el 95% del tiempo.
Este sensor debe tener un consumo de energía bajo, por lo que debe implementarse en hardware.
Orientación (obsoleto)
Sensores físicos subyacentes: acelerómetro, magnetómetro y (si está presente) giroscopio
Modo de informes: Continuo
getDefaultSensor(SENSOR_TYPE_ORIENTATION)
devuelve un sensor que no es de activación
Nota: Este es un tipo de sensor anterior que dejó de estar disponible en el SDK de Android. Se reemplazó por el sensor de vector de rotación, que está definido con mayor claridad. Usa el sensor de vector de rotación en lugar del sensor de orientación siempre que sea posible.
Un sensor de orientación informa la actitud del dispositivo. Las mediciones se informan en grados en los campos x, y y z de sensors_event_t.orientation:
sensors_event_t.orientation.x: Acimut, el ángulo entre la dirección del norte magnético y el eje Y, alrededor del eje Z (0<=azimuth<360). 0=Norte, 90=Este, 180=Sur, 270=Oeste.sensors_event_t.orientation.y: Cabeceo, rotación alrededor del eje X (-180<=pitch<=180), con valores positivos cuando el eje Z se mueve hacia el eje Y.sensors_event_t.orientation.z: Giro, rotación alrededor del eje Y (-90<=roll<=90), con valores positivos cuando el eje X se mueve hacia el eje Z.
Ten en cuenta que, por motivos históricos, el ángulo de alabeo es positivo en el sentido de las agujas del reloj. (Matemáticamente hablando, debería ser positivo en el sentido contrario a las agujas del reloj):
Figura 3: Orientación relativa a un dispositivo
Esta definición es diferente de la guiñada, el cabeceo y el alabeo que se usan en la aviación, en los que el eje X se encuentra a lo largo del lado más largo del avión (de la cola a la nariz).
El sensor de orientación también informa qué tan precisas espera que sean sus lecturas a través de sensors_event_t.orientation.status.
Consulta las constantes
SENSOR_STATUS_* de SensorManager para obtener más información sobre los valores posibles de este campo.
Sensores sin calibrar
Los sensores sin calibrar proporcionan más resultados sin procesar y pueden incluir cierto sesgo, pero también contienen menos "saltos" de las correcciones aplicadas a través de la calibración. Algunas apps pueden preferir estos resultados sin calibrar, ya que son más fluidos y confiables. Por ejemplo, si una app intenta realizar su propia fusión de sensores, la introducción de calibraciones puede distorsionar los resultados.
Acelerómetro sin calibrar
Sensor físico subyacente: Acelerómetro
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_UNCALIBRATED)
devuelve un sensor que no es de activación
Un sensor de acelerómetro no calibrado informa la aceleración del dispositivo a lo largo de los tres ejes del sensor sin ninguna corrección de sesgo (se aplican la compensación de sesgo de fábrica y la compensación de temperatura a las mediciones no calibradas), junto con una estimación del sesgo.
Todos los valores están en unidades del SI (m/s²) y se informan en los campos de sensors_event_t.uncalibrated_accelerometer:
x_uncalib: Aceleración (sin compensación de sesgo) a lo largo del eje Xy_uncalib: Aceleración (sin compensación de sesgo) a lo largo del eje Yz_uncalib: Aceleración (sin compensación de sesgo) a lo largo del eje Zx_bias: Sesgo estimado a lo largo del eje Xy_bias: Sesgo estimado a lo largo del eje Yz_bias: Sesgo estimado a lo largo del eje Z
Giroscopio no calibrado
Sensor físico subyacente: Giroscopio
Modo de informes: Continuo
getDefaultSensor(SENSOR_TYPE_GYROSCOPE_UNCALIBRATED)
devuelve un sensor que no es de activación
Un giroscopio no calibrado informa la velocidad de rotación alrededor de los ejes del sensor sin aplicarles compensación de sesgo, junto con una estimación del sesgo. Todos los valores están en radianes por segundo y se registran en los campos de sensors_event_t.uncalibrated_gyro:
x_uncalib: Velocidad angular (sin compensación de desviación) alrededor del eje Xy_uncalib: Velocidad angular (sin compensación de desviación) alrededor del eje Yz_uncalib: Velocidad angular (sin compensación de desviación) alrededor del eje Zx_bias: Deriva estimada alrededor del eje Xy_bias: Desviación estimada alrededor del eje Yz_bias: Deriva estimada alrededor del eje Z
Conceptualmente, la medición sin calibrar es la suma de la medición calibrada y la estimación del sesgo: _uncalibrated = _calibrated + _bias.
Se espera que los valores de x_bias, y_bias y z_bias aumenten en cuanto cambie la estimación del sesgo y que se mantengan estables el resto del tiempo.
Consulta la definición del sensor de giróscopo para obtener detalles sobre el sistema de coordenadas que se usa.
Se deben aplicar la calibración de fábrica y la compensación de temperatura a las mediciones. Además, se debe implementar la estimación de la deriva del giroscopio para que se puedan informar estimaciones razonables en x_bias, y_bias y z_bias. Si la implementación no puede estimar la desviación, no se debe implementar este sensor.
Si este sensor está presente, el sensor de giroscopio correspondiente también debe estar presente, y ambos sensores deben compartir los mismos valores de sensor_t.name y sensor_t.vendor.
Campo magnético sin calibrar
Sensor físico subyacente: Magnetómetro
Modo de informes: Continuo
getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED)
devuelve un sensor que no es de activación
Un sensor de campo magnético no calibrado informa el campo magnético ambiental junto con una estimación de calibración de hierro duro. Todos los valores están en microteslas (uT) y se registran en los campos de sensors_event_t.uncalibrated_magnetic:
x_uncalib: Campo magnético (sin compensación de hierro duro) a lo largo del eje Xy_uncalib: Campo magnético (sin compensación de hierro duro) a lo largo del eje Yz_uncalib: Campo magnético (sin compensación de hierro duro) a lo largo del eje Zx_bias: Sesgo de hierro duro estimado a lo largo del eje Xy_bias: Sesgo de hierro duro estimado a lo largo del eje Yz_bias: Sesgo de hierro duro estimado a lo largo del eje Z
Conceptualmente, la medición sin calibrar es la suma de la medición calibrada y la estimación del sesgo: _uncalibrated = _calibrated + _bias.
El magnetómetro sin calibrar permite que los algoritmos de nivel superior controlen la estimación deficiente del hierro duro. Se espera que los valores de x_bias, y_bias y z_bias aumenten en cuanto cambie la estimación del hierro duro y que se mantengan estables el resto del tiempo.
Se deben aplicar la calibración de hierro dulce y la compensación de temperatura a las mediciones. Además, se debe implementar la estimación de hierro duro para que se puedan informar estimaciones razonables en x_bias, y_bias y z_bias. Si la implementación no puede estimar la desviación, no se debe implementar este sensor.
Si este sensor está presente, el sensor de campo magnético correspondiente también debe estar presente, y ambos sensores deben compartir los mismos valores de sensor_t.name y sensor_t.vendor.
Ángulo de bisagra
Reporting-mode: On-change
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
devuelve un sensor de activación
Un sensor de ángulo de bisagra mide el ángulo, en grados, entre dos partes integrales del dispositivo. Se espera que el movimiento de una bisagra medido por este tipo de sensor altere las formas en que el usuario puede interactuar con el dispositivo, por ejemplo, desplegando o revelando una pantalla.
Sensores compuestos de interacción
Algunos sensores se usan principalmente para detectar interacciones con el usuario. No definimos cómo se deben implementar esos sensores, pero deben ser de bajo consumo y es responsabilidad del fabricante del dispositivo verificar su calidad en términos de experiencia del usuario.
Gesto de activación
Sensores físicos subyacentes: Sin definir (cualquier sensor de bajo consumo)
Modo de informe: One-shot
Bajo consumo
Implementa solo la versión de activación de este sensor.
getDefaultSensor(SENSOR_TYPE_WAKE_GESTURE)
devuelve un sensor de activación
Un sensor de gestos para activar el dispositivo permite activarlo en función de un movimiento específico del dispositivo. Cuando se activa este sensor, el dispositivo se comporta como si se hubiera presionado el botón de encendido, lo que enciende la pantalla. El usuario puede desactivar este comportamiento (encender la pantalla cuando se activa este sensor) en la configuración del dispositivo. Los cambios en la configuración no afectan el comportamiento del sensor, sino solo si el framework enciende la pantalla cuando se activa. No se especifica el gesto real que se detectará, y el fabricante del dispositivo puede elegirlo.
Este sensor debe tener un bajo consumo de energía, ya que es probable que se active las 24 horas, todos los días.
Cada evento del sensor informa 1 en sensors_event_t.data[0].
Gesto de recoger
Sensores físicos subyacentes: Sin definir (cualquier sensor de bajo consumo)
Modo de informe: One-shot
Bajo consumo
Implementa solo la versión de activación de este sensor.
getDefaultSensor(SENSOR_TYPE_PICK_UP_GESTURE)
devuelve un sensor de activación
Un sensor de gestos de toma se activa cuando se toma el dispositivo, sin importar dónde estaba antes (escritorio, bolsillo, bolso).
Cada evento del sensor informa 1 en sensors_event_t.data[0].
Gesto de vistazo
Sensores físicos subyacentes: Sin definir (cualquier sensor de bajo consumo)
Modo de informe: One-shot
Bajo consumo
Implementa solo la versión de activación de este sensor.
getDefaultSensor(SENSOR_TYPE_GLANCE_GESTURE)
devuelve un sensor de activación
Un sensor de gestos de vistazo permite encender brevemente la pantalla para que el usuario pueda ver el contenido en ella según un movimiento específico. Cuando se activa este sensor, el dispositivo encenderá la pantalla por un momento para permitir que el usuario vea las notificaciones o algún otro contenido mientras el dispositivo permanece bloqueado en un estado no interactivo (en reposo). Luego, la pantalla se apagará de nuevo. El usuario puede desactivar este comportamiento (encender brevemente la pantalla cuando se activa este sensor) en la configuración del dispositivo. Los cambios en la configuración no afectan el comportamiento del sensor, sino solo si el framework enciende brevemente la pantalla cuando se activa. No se especifica el gesto real que se detectará, y el fabricante del dispositivo puede elegirlo.
Este sensor debe tener un bajo consumo de energía, ya que es probable que se active las 24 horas, todos los días.
Cada evento del sensor informa 1 en sensors_event_t.data[0].
Sensores de IMU de ejes limitados
Disponibles a partir de Android 13, los sensores IMU de ejes limitados son sensores que admiten casos de uso en los que no están disponibles los tres ejes (X, Y y Z). Los tipos de IMU estándar en Android (como
SENSOR_TYPE_ACCELEROMETER y
SENSOR_TYPE_GYROSCOPE) suponen que se admiten los tres ejes. Sin embargo, no todos los factores de forma y dispositivos admiten acelerómetros y giroscopios de 3 ejes.
Ejes limitados del acelerómetro
Sensores físicos subyacentes: Acelerómetro
Modo de informes: Continuo
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES)
devuelve un sensor que no es de activación
Un sensor de acelerómetro con ejes limitados es equivalente a TYPE_ACCELEROMETER, pero admite casos en los que no se admiten uno o dos ejes.
Los últimos tres valores de eventos del sensor que informa el sensor representan si se admite el valor de aceleración para los ejes X, Y y Z. Un valor de 1.0 indica que se admite el eje, y un valor de 0 indica que no se admite. Los fabricantes de dispositivos identifican los ejes admitidos en el momento de la compilación, y los valores no cambian durante el tiempo de ejecución.
Los fabricantes de dispositivos deben establecer los valores de aceleración para los ejes no utilizados en 0, en lugar de tener valores indefinidos.
Ejes limitados del giroscopio
Sensores físicos subyacentes: giroscopio
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES)
devuelve un sensor que no es de activación
Un sensor de giroscopio con ejes limitados es equivalente a TYPE_GYROSCOPE, pero admite casos en los que no se admiten uno o dos ejes.
Los últimos tres valores de eventos del sensor que informa el sensor representan si se admite el valor de velocidad angular para los ejes X, Y y Z. Un valor de 1.0 indica que se admite el eje, y un valor de 0 indica que no se admite. Los fabricantes de dispositivos identifican los ejes admitidos en el momento de la compilación, y los valores no cambian durante el tiempo de ejecución.
Los fabricantes de dispositivos deben establecer los valores de velocidad angular para los ejes no utilizados en 0.
Los ejes limitados del acelerómetro no están calibrados
Sensores físicos subyacentes: Acelerómetro
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED)
devuelve un sensor que no es de activación
Un sensor no calibrado de acelerómetro con ejes limitados es equivalente a TYPE_ACCELEROMETER_UNCALIBRATED, pero admite casos en los que no se admiten uno o dos ejes.
Los últimos tres valores de eventos del sensor que informa el sensor representan si se admiten los valores de aceleración y sesgo para los ejes X, Y y Z. Un valor de 1.0 indica que el eje es compatible, y un valor de 0 indica que no lo es. Los fabricantes de dispositivos identifican los ejes admitidos en el momento de la compilación, y los valores no cambian durante el tiempo de ejecución.
Los fabricantes de dispositivos deben establecer los valores de aceleración y sesgo para los ejes no utilizados en 0.
Ejes limitados del giroscopio sin calibrar
Sensores físicos subyacentes: giroscopio
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED)
devuelve un sensor que no es de activación
Un sensor de giroscopio no calibrado con ejes limitados es equivalente a TYPE_GYROSCOPE_UNCALIBRATED, pero admite casos en los que no se admiten uno o dos ejes.
Los últimos tres valores de eventos del sensor que informa el sensor representan si se admiten los valores de velocidad angular y desviación para los ejes X, Y y Z. Un valor de 1.0 indica que el eje es compatible, y un valor de 0 indica que no lo es. Los fabricantes de dispositivos identifican los ejes admitidos en el momento de la compilación, y los valores no cambian durante el tiempo de ejecución.
Los fabricantes de dispositivos deben establecer los valores de velocidad angular y desviación de los ejes no utilizados en 0.
IMU de ejes limitados compuesta
Sensores físicos subyacentes: Cualquier combinación de acelerómetro de 3 ejes, giroscopio de 3 ejes, acelerómetro no calibrado de 3 ejes y giroscopio no calibrado de 3 ejes.
Reporting-mode: Continuous
Un sensor de IMU compuesto de ejes limitados es equivalente a un sensor de IMU de ejes limitados, pero, en lugar de ser compatible con la HAL, convierte los datos del sensor de 3 ejes en las variantes equivalentes de ejes limitados. Estos sensores compuestos solo están habilitados para dispositivos automotrices.
En la siguiente tabla, se muestra un ejemplo de conversión de un acelerómetro estándar de 3 ejes a un acelerómetro compuesto de ejes limitados.
| Valores de SensorEvent para SENSOR_TYPE_ACCELEROMETER | Ejemplo de SensorEvent de SENSOR_TYPE_ACCELEROMETER | SensorEvent compuesto de SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES |
|---|---|---|
| values[0] | -0.065 |
-0.065 |
| values[1] | 0.078 |
0.078 |
| values[2] | 9.808 |
9.808 |
| values[3] | N/A |
1.0 |
| values[4] | N/A |
1.0 |
| values[5] | N/A |
1.0 |
Sensores automotrices
Sensores para admitir casos de uso automotriz
Encabezado
Sensores físicos subyacentes: Cualquier combinación de GPS, magnetómetro, acelerómetro y giroscopio.
Modo de informes: Continuo
getDefaultSensor(SENSOR_TYPE_HEADING)
devuelve un sensor que no es de activación
Disponible a partir de Android 13, un sensor de rumbo mide la dirección en la que apunta el dispositivo en relación con el norte geográfico en grados. El sensor de rumbo incluye dos valores de SensorEvent.
Una para el encabezado del dispositivo medido y otra para la precisión del valor del encabezado proporcionado.
Los valores de dirección que informa este sensor deben estar entre 0.0 (inclusive) y 360.0 (exclusive), donde 0 indica el norte, 90 el este, 180 el sur y 270 el oeste.
La precisión de este sensor se define con un 68% de confianza. En el caso en que la distribución subyacente sea normal gaussiana, la precisión es de una desviación estándar. Por ejemplo, si el sensor de orientación devuelve un valor de orientación de 60 grados y un valor de precisión de 10 grados, hay un 68% de probabilidad de que la orientación real esté entre 50 y 70 grados.