En esta sección, se describen los ejes de los sensores, los sensores base y los sensores compuestos (actividad, actitud, no calibrados e interacción).
Ejes sensores
Los valores de eventos de sensores de muchos sensores se expresan en un marco específico que es estático en relación con el dispositivo.
Ejes de dispositivos móviles
La API de Sensor es relativa solo 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 de Sensor
Hachas para la industria automotriz
En las implementaciones de Android Automotive, los ejes se definen en relación con la estructura de la carrocería del vehículo. El origen del marco de referencia del vehículo es el centro del eje trasero. La estructura de referencia del vehículo está orientada de modo que:
- El eje X apunta a 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 de automóviles) que usa la API de Sensor
El marco de referencia del vehículo es un sistema de coordenadas de mano 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 pase por el eje delantero.
Sensores de base
Los tipos de sensores básicos se nombran 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). Entre los ejemplos de tipos de sensores base, se incluyen los siguientes:
SENSOR_TYPE_ACCELEROMETERSENSOR_TYPE_GYROSCOPESENSOR_TYPE_MAGNETOMETER
Sin embargo, los sensores base no son iguales a su sensor físico subyacente ni deben confundirse con él. Los datos de un sensor base no son el resultado sin procesar del sensor físico porque 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 características de su sensor físico subyacente en los siguientes casos de uso:
- Un chip de giroscopio con una clasificación de rango de sesgo de 1 deg/seg.
- Después de aplicar la calibración de fábrica, la compensación de temperatura y la compensación de sesgo, se reducirá el sesgo real del sensor de Android, posiblemente hasta un punto en el que se garantice que el sesgo sea inferior a 0.01 °/s.
- En esta situación, decimos que el sensor de Android tiene un sesgo inferior a 0.01 °/s, aunque la hoja de datos del sensor subyacente indique 1 °/s.
- Un barómetro con un consumo de energía de 100 uW
- Debido a que los datos generados deben transportarse del chip al SoC, el costo real de energía para recopilar datos del sensor de barómetro de Android podría ser mucho mayor, por ejemplo, 1000 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 pines del chip del barómetro es de 100 uW.
- Un magnetómetro que consume 100 µW cuando está calibrado, pero consume más durante la calibración
- Su rutina de calibración podría requerir activar el giroscopio, que consume 5,000 uW, y ejecutar algún algoritmo, 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)
muestra un sensor que no es wake-up
Un sensor de acelerómetro informa la aceleración del dispositivo a lo largo de los tres ejes del sensor. La aceleración medida incluye la aceleración física (cambio de velocidad) y la gravedad. La medición se informa en los campos x, y, y z de sensores_event_t.acceleration.
Todos los valores están en unidades del SI (m/s^2) 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 en caída libre.
- Cuando el dispositivo está sobre una mesa y se empuja hacia la derecha, el valor de la aceleración x es positivo.
- Cuando el dispositivo está sobre una mesa, el valor de aceleración a lo largo del eje z es de +9.81, que corresponde a la aceleración del dispositivo (0 m/s^2) menos la fuerza de gravedad (-9.81 m/s^2).
- Cuando el dispositivo está sobre una mesa y se levanta hacia el cielo, el valor de aceleración es mayor que +9.81, que corresponde a la aceleración del dispositivo (+A m/s^2) menos la fuerza de gravedad (-9.81 m/s^2).
Las lecturas se calibran de la siguiente manera:
- Compensación de temperatura
- Calibración de sesgo en línea
- Calibración de escalas en línea
La calibración del sesgo y la escala solo se debe actualizar mientras el sensor está desactivado para evitar que se produzcan saltos en los valores durante la transmisión.
El acelerómetro también informa la exactitud que espera que sean sus lecturas mediante 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
Reporting-mode: On-change
getDefaultSensor(SENSOR_TYPE_AMBIENT_TEMPERATURE)
devuelve un sensor que no está activo
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 está activo
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 se expresan 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 de la siguiente manera:
- Compensación de temperatura
- Calibración de hierro blando de fábrica (o en línea)
- Calibración en línea de hierro duro
Giroscopio
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_GYROSCOPE)
muestra un sensor que no es wake-up
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 sentido antihorario (regla de la derecha). Es decir, mirando desde algún lugar positivo de los ejes x, y o z de un dispositivo situado en el origen, se obtendría una rotación positiva si el dispositivo pareciera estar girando 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 aeroespacial de alabeo.
La medición se informa en los campos x, y y z de sensors_event_t.gyro, y todos los valores se expresan en radianes por segundo (rad/s).
Las mediciones se calibran usando lo siguiente:
- Compensación de temperatura
- Compensación a escala de fábrica (o en línea)
- Calibración de sesgo en línea (para quitar la deriva)
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 magnetómetros y acelerómetros, ya que esto reduciría la coherencia y la capacidad de respuesta locales. Debe basarse en un chip de giroscopio habitual.
Frecuencia cardíaca
Reporting-mode: On-change
getDefaultSensor(SENSOR_TYPE_HEART_RATE)
muestra un sensor que no es wake-up
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, 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 de cambio,
los eventos se generan cuando y solo cuando heart_rate.bpm o
heart_rate.status cambiaron desde el último evento. Los eventos no se generan más rápido que cada sampling_period.
sensor_t.requiredPermission siempre es SENSOR_PERMISSION_BODY_SENSORS.
Claro
Modo de informe: En caso de cambio
getDefaultSensor(SENSOR_TYPE_LIGHT)
muestra un sensor que no es wake-up
Un sensor de luz informa la iluminación actual en unidades de luxes 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)
muestra un sensor de activación
Un sensor de proximidad informa la distancia del sensor a la superficie visible más cercana.
Hasta Android 4.4, los sensores de proximidad siempre eran sensores de activación y activaban el SoC cuando se detectaba un cambio en la proximidad. Después de Android 4.4, te recomendamos que primero implementes 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 sensor_t.maxRange en el estado "lejos" y un valor inferior a sensor_t.maxRange en el estado "cercano".
Presionar
Modo de informe: Continuo
getDefaultSensor(SENSOR_TYPE_PRESSURE)
muestra un sensor que no es wake-up
Un sensor de presión (también conocido como barómetro) informa la presión atmosférica en hectopascales (hPa).
Las mediciones se calibran usando
- Compensación de temperatura
- Calibración del sesgo de fábrica
- Calibración a escala de fábrica
El barómetro a menudo se utiliza para estimar los cambios de elevación. Para estimar la elevación absoluta, se debe usar la presión al nivel del mar (que cambia según el clima) como referencia.
Humedad relativa
Reporting-mode: On-change
getDefaultSensor(SENSOR_TYPE_RELATIVE_HUMIDITY)
devuelve un sensor que no está activo
Un sensor de humedad relativa mide la humedad relativa del aire ambiente y muestra un valor en porcentaje.
Tipos de sensores compuestos
Un sensor compuesto genera datos a través del procesamiento o la combinación de 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:
- Detector de pasos y movimiento significativo, que suelen basarse en un acelerómetro, pero también pueden basarse en otros sensores, si el consumo de energía y la precisión son 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, el desvío del vector de rotación de un 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 depende de los datos de uno o varios sensores físicos. Evita elegir otros sensores físicos subyacentes para aproximar los resultados, ya que proporcionan una experiencia del usuario deficiente.
| Tipo de sensor | Categoría | Sensores físicos subyacentes | Modo de informes |
|---|---|---|---|
Actitud |
Acelerómetro, giroscopio, NO DEBE USAR magnetómetro |
Continuo |
|
Actitud |
Acelerómetro, magnetómetro, NO DEBE USAR giroscopio |
Continuo |
|
Gesto de mirada  |
Interacción |
Sin definir |
Una sola toma |
Actitud |
Acelerómetro, giroscopio |
Continuo |
|
Sin calibrar |
Giroscopio |
Continuo |
|
Actividad |
Acelerómetro, giroscopio (si está presente) o magnetómetro (si no hay giroscopio) |
Continuo |
|
Sin calibrar |
Magnetómetro |
Continuo |
|
Orientación (obsoleta) |
Actitud |
Acelerómetro, magnetómetro, giroscopio (si hay alguno) |
Continuo |
Interacción |
Sin definir |
Una sola toma |
|
Actitud |
Acelerómetro, magnetómetro y giroscopio |
Continuo |
|
Actividad |
Acelerómetro (o cualquier otro, siempre que tenga un consumo muy bajo) |
Una sola acción |
|
Actividad |
Acelerómetro |
Al cambiar |
|
Actividad |
Acelerómetro |
Especial |
|
Actividad |
Acelerómetro |
Especial |
|
Interacción |
Sin definir |
Una sola acción |
= 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 hay giroscopio)
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_LINEAR_ACCELERATION)
muestra un sensor que no es wake-up
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 la salida del acelerómetro menos la salida del sensor de gravedad. Se informa en m/s^2 en los campos x, y, y z de sensors_event_t.acceleration.
Las lecturas en todos los ejes deben ser cercanas a 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)
Reporting-mode: One-shot
Bajo consumo
Implementa solo la versión de activación de este sensor.
getDefaultSensor(SENSOR_TYPE_SIGNIFICANT_MOTION)
muestra un sensor de activación
Un detector de movimiento significativo se activa cuando detecta un movimiento significativo: un movimiento que puede llevar a un cambio en la ubicación del usuario.
Estos son algunos ejemplos de movimientos significativos:
- A pie o en bicicleta
- Sentarse en un auto, un vagón o un tren en movimiento
Ejemplos de situaciones que no activan un movimiento significativo:
- El teléfono está en el bolsillo y la persona no se mueve
- El teléfono está sobre una mesa y esta tiembla un poco debido al tráfico cercano o a una lavadora
En el nivel superior, el detector de movimiento significativo se usa para reducir el consumo de energía de la determinación de ubicación. Cuando los algoritmos de localización detectan que el dispositivo es 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 bajo consumo de energía. Realiza una compensación por el consumo de energía 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 mueve (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 realice varias veces. Si el usuario lleva 10 segundos caminando, no es aceptable no activar un evento dentro de esos 10 segundos.
Cada evento de sensor informa 1 en sensors_event_t.data[0].
Detector de pasos
Sensor físico subyacente: Acelerómetro (y posiblemente otros, siempre y cuando haya poca energía)
Reporting-mode: Especial (un evento por paso dado)
Bajo consumo
getDefaultSensor(SENSOR_TYPE_STEP_DETECTOR)
muestra un sensor que no es wake-up
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 golpeó el suelo, lo que genera una alta 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 las escaleras. No deben activarse cuando el usuario está en bicicleta, en un automóvil o en otros vehículos.
Este sensor debe tener poca potencia. 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 todas las lecturas del acelerómetro).
sampling_period_ns no tiene impacto en los detectores de pasos.
Cada evento de sensor informa 1 en sensors_event_t.data[0].
Contador de pasos
Sensor físico subyacente: acelerómetro (+ posiblemente otros, siempre que el consumo de energía sea bajo)
Reporting-mode: On-change
Bajo consumo
getDefaultSensor(SENSOR_TYPE_STEP_COUNTER)
muestra un sensor que no es wake-up
Un contador de pasos informa la cantidad de pasos que dio el usuario desde el último reinicio mientras estaba 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 la hora en que se realizó el último paso de 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 precisión alta. El recuento de pasos después de un día completo de mediciones debe estar dentro del 10% del recuento real de pasos. Tanto el detector de pasos como el contador de pasos detectan si el usuario está caminando, corriendo o subiendo las escaleras. No deben activarse cuando el usuario está en bicicleta, en un automóvil o en otros vehículos.
El hardware debe garantizar que el recuento de pasos interno 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 realice el mantenimiento del contador.
Como se indica en Interacción, mientras este sensor funciona, no debe interrumpir ningún otro sensor, en particular, el acelerómetro, que podría estar en uso.
Si un dispositivo en particular no puede admitir estos modos de operación, el HAL no debe informar este tipo de sensor. Es decir, no se puede “emular” este sensor en el HAL.
Este sensor debe tener 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 el acelerómetro no, 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 y cuando haya poca energía)
Reporting-mode: Especial
Bajo consumo
Implementa solo la versión de activación de este sensor.
getDefaultSensor(SENSOR_TYPE_TILT_DETECTOR)
muestra 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 que generó el sensor. Este es el algoritmo:
reference_estimated_gravity: Es el promedio de las medidas 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 deben activar un evento de inclinación. Por ejemplo, un giro brusco o una aceleración fuerte mientras se conduce un automóvil no debería activar un evento de inclinación, aunque el ángulo de la aceleración promedio pueda 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 forma significativa. Este es un sensor de bajo consumo que debería permitir que el SoC entre en modo de suspensión. No emulas este sensor en la HAL. Cada evento de 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
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_ROTATION_VECTOR) muestra un sensor que no es wake-up
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 mediante la integración de lecturas del acelerómetro, giroscopio y 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 tangencial al suelo.
- Y apunta al norte y es tangencial al suelo.
- 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 de este a norte y arriba con las 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 (orientada al este, norte y arriba) a la orientación actual del dispositivo. La rotación se codifica como los cuatro componentes sin unidades x, y, z y w de un cuaternio 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)
donde:
- Los campos x, y y z de
rot_axisson las coordenadas este, norte y arriba de un vector de longitud de unidad que representa el eje de rotación. thetaes el ángulo de rotación.
El cuaternión es un cuaternión de unidades: debe ser de la norma 1.
Si no lo haces, el cliente tendrá un comportamiento errático.
Además, este sensor informa una precisión de rumbo estimada:
sensors_event_t.data[4] = estimated_accuracy (en radianes)
El error de encabezado debe ser inferior a estimated_accuracy el 95% del tiempo. Este sensor debe usar un giroscopio como entrada principal 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)
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_GAME_ROTATION_VECTOR)
muestra un sensor que no es wake-up
Un sensor del vector de rotación de un juego es similar a un sensor del vector de rotación, pero no usa el campo geomagnético. Por lo tanto, el eje Y no apunta al norte, sino a otra referencia. A la referencia se le permite desviarse con el mismo orden de magnitud que las desviaciones del giroscopio en torno al eje Z.
Consulta el sensor del 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 gira y se vuelve a la misma orientación del mundo real debería informar el mismo vector de rotación del juego.
Este sensor se debe basar en un giroscopio y un acelerómetro. No puede usar el magnetómetro como entrada, además, de forma indirecta, a través de la estimación del sesgo del giroscopio.
Gravity
Sensores físicos subyacentes: Acelerómetro y, en caso de haber, giroscopio (o magnetómetro si no hay giroscopio)
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_GRAVITY)
devuelve un sensor que no está activo
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 informan en m/s^2 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^2.
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 informe: Continuo
Bajo consumo
getDefaultSensor(SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR)
muestra un sensor que no es wake-up
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 de giroscopio.
Consulta el sensor del vector de rotación para obtener detalles sobre cómo configurar sensors_event_t.data[0-4].
Al igual que con el sensor del vector de rotación, el error de rumbo debe ser inferior a la precisión estimada (sensors_event_t.data[4]) el 95% del tiempo.
Este sensor debe tener bajo consumo de energía, por lo que debe implementarse en el hardware.
Orientación (obsoleto)
Sensores físicos subyacentes: Acelerómetro, magnetómetro y (si está presente) giroscopio
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_ORIENTATION)
muestra un sensor que no es wake-up
Nota: Este es un tipo de sensor más antiguo que dejó de estar disponible en el SDK de Android. Se reemplazó por el sensor vectorial de rotación, que está más claramente definido. Usa el sensor vectorial 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: Es el azimut, 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: Indica el inclinación y la 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: balanceo, 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 balanceo es positivo en el sentido de las manecillas del reloj. (matemáticamente, debe ser positivo en el sentido contrario a las manecillas del reloj):
Figura 3: Orientación en relación con un dispositivo
Esta definición es diferente de la de yaw, pitch y roll que se usa en la aviación, en la que el eje X se encuentra junto al lado largo del plano (de la cola a la punta).
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 no calibrados
Los sensores no calibrados proporcionan más resultados sin procesar y pueden incluir algún sesgo, pero también contienen menos "saltos" de correcciones aplicadas a través de la calibración. Es posible que algunas apps prefieran estos resultados sin calibrar como más fluidos y confiables. Por ejemplo, si una app intenta realizar su propia fusión de sensores, introducir calibraciones puede distorsionar los resultados.
Acelerómetro sin calibrar
Sensor físico subyacente: acelerómetro
Modo de informe: Continuo
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_UNCALIBRATED)
muestra un sensor que no es wake-up
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 (el sesgo de fábrica y la compensación de temperatura se aplican a las mediciones no calibradas), junto con una estimación de sesgo.
Todos los valores están en unidades del SI (m/s2) y se informan en los campos de sensors_event_t.uncalibrated_accelerometer:
x_uncalib: aceleración (sin compensación de sesgo) en el eje Xy_uncalib: aceleración (sin compensación de sesgo) en el eje Yz_uncalib: Es la aceleración (sin compensación de sesgo) junto al eje Z.x_bias: sesgo estimado a lo largo del eje Xy_bias: sesgo estimado a lo largo del eje Yz_bias: Es el sesgo estimado a lo largo del eje Z.
Giroscopio no calibrado
Sensor físico subyacente: giroscopio
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_GYROSCOPE_UNCALIBRATED)
muestra un sensor que no es wake-up
Un giroscopio no calibrado informa la velocidad de rotación alrededor de los ejes del sensor sin aplicarles una compensación de sesgo, junto con una estimación de sesgo. Todos los valores se expresan en radiantes/segundo y se informan en los campos de sensors_event_t.uncalibrated_gyro:
x_uncalib: Velocidad angular (sin compensación de desvío) alrededor del eje Xy_uncalib: velocidad angular (sin compensación de deriva) alrededor del eje Yz_uncalib: velocidad angular (sin compensación de deriva) alrededor del eje Zx_bias: Desplazamiento estimado alrededor del eje Xy_bias: Es la deriva estimada alrededor del eje Y.z_bias: Variación estimada alrededor del eje Z
Conceptualmente, la medición no calibrada es la suma de la medición calibrada y la estimación del sesgo: _uncalibrated = _calibrated + _bias.
Se espera que los valores x_bias, y_bias y z_bias salten tan pronto como cambie la estimación del sesgo, y deben ser estables el resto del tiempo.
Consulta la definición del sensor de giroscopio 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 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 deriva, no se debe implementar este sensor.
Si se incluye este sensor, el sensor del 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
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED)
muestra un sensor que no es wake-up
Un sensor de campo magnético sin calibrar informa el campo magnético ambiental junto con una estimación de calibración de hierro resistente. Todos los valores se expresan en microteslas (uT) y se informan en los campos de sensors_event_t.uncalibrated_magnetic:
x_uncalib: campo magnético (sin compensación de hierro resistente) junto al eje Xy_uncalib: campo magnético (sin compensación de hierro resistente) junto al eje Yz_uncalib: campo magnético (sin compensación de hierro resistente) junto al eje Zx_bias: sesgo estimado de hierro resistente a lo largo del eje Xy_bias: Es el sesgo de hierro duro estimado en el eje Y.z_bias: Es el sesgo de hierro duro estimado en el eje Z.
Conceptualmente, la medición no calibrada 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 las estimaciones defectuosas de hierro resistente. Se espera que los valores x_bias, y_bias y z_bias salten tan pronto como la estimación de los cambios de hierro forjado cambie, y deben ser 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 hardware para que se puedan informar estimaciones razonables en x_bias, y_bias y z_bias. Si la implementación no puede estimar el sesgo, no se debe implementar este sensor.
Si este sensor está presente, también debe estarlo el sensor de campo magnético correspondiente, 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)
muestra 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 que mide este tipo de sensor altere las formas en que el usuario puede interactuar con el dispositivo, por ejemplo, al desplegar o revelar 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: No definido (cualquier cosa de bajo consumo)
Modo de informe: Un solo intento
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 de activación permite activar el dispositivo según 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 (activar 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, 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 poca potencia, ya que es probable que esté activado las 24 horas, todos los días.
Cada evento de sensor informa 1 en sensors_event_t.data[0].
Gesto de levantar
Sensores físicos subyacentes: No definido (cualquier cosa de bajo consumo)
Modo de informe: Un solo intento
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 levantamiento se activa cuando se levanta el dispositivo, independientemente de dónde se encontraba antes (escritorio, bolsillo o bolsa).
Cada evento de sensor informa 1 en sensors_event_t.data[0].
Gesto de Glance
Sensores físicos subyacentes: Indefinidos (cualquier energía baja)
Reporting-mode: 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 vista rápida permite encender la pantalla brevemente para que el usuario pueda ver el contenido en la pantalla según un movimiento específico. Cuando se activa este sensor, el dispositivo enciende la pantalla momentáneamente para permitir que el usuario vea notificaciones o cualquier otro contenido mientras el dispositivo permanece bloqueado en un estado no interactivo (en modo de suspensión) y, luego, la pantalla se vuelve a apagar. El usuario puede desactivar este comportamiento (activar 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; solo si el framework enciende brevemente la pantalla cuando se activa. No se especifica el gesto real que se debe detectar, y el fabricante del dispositivo puede elegirlo.
Este sensor debe tener bajo consumo de energía, ya que es probable que se active las 24 horas, todos los días.
Cada evento de sensor informa 1 en sensors_event_t.data[0].
Sensores 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, 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
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES)
muestra un sensor que no es wake-up
Un sensor de ejes limitados del acelerómetro equivale 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 el eje es compatible, y un valor de 0 indica que no lo es. Los fabricantes de dispositivos identifican los ejes admitidos en el tiempo de 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 no definidos.
Ejes limitados con giroscopio
Sensores físicos subyacentes: giroscopio
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES)
muestra un sensor que no es wake-up
Un sensor de ejes limitados del giroscopio equivale 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 el eje es compatible, y un valor de 0 indica que no lo es. Los fabricantes de dispositivos identifican los ejes admitidos en el tiempo de 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.
Ejes limitados del acelerómetro sin calibrar
Sensores físicos subyacentes: acelerómetro
Modo de informe: Continuo
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED)
muestra un sensor que no es wake-up
Un sensor no calibrado de ejes limitados del acelerómetro equivale 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 es compatible. Los fabricantes de dispositivos identifican los ejes admitidos en el tiempo de 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 que no se usan en 0.
Ejes limitados del giroscopio no calibrados
Sensores físicos subyacentes: giroscopio
Reporting-mode: Continuous
getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED)
muestra un sensor que no es wake-up
Un sensor no calibrado de ejes limitados del giroscopio equivale 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 deriva 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 es compatible. Los fabricantes de dispositivos identifican los ejes admitidos en el tiempo de 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 deriva para los ejes que no se usan en 0.
IMU de ejes limitados compuestos
Sensores físicos subyacentes: Cualquier combinación de acelerómetro de 3 ejes, giroscopio de 3 ejes, acelerómetro de 3 ejes sin calibrar y sensores de giroscopio de 3 ejes no calibrados.
Modo de informe: Continuo
Un sensor de IMU de ejes limitados compuesto equivale a un sensor de IMU de ejes limitados, pero en lugar de admitirse en el HAL, convierte los datos del sensor de 3 ejes en las variantes de ejes limitados equivalentes. 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 de ejes limitados compuesto.
| Valores de SensorEvent para SENSOR_TYPE_ACCELEROMETER | Ejemplo de SensorEvent de SENSOR_TYPE_ACCELEROMETER | SensorEvent compuesto 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 |
| valores[5] | N/A |
1.0 |
Sensores de automóviles
Sensores para admitir casos de uso de la industria automotriz.
Encabezado
Sensores físicos subyacentes: Cualquier combinación de GPS, magnetómetro, acelerómetro y giroscopio.
Modo de informe: Continuo
getDefaultSensor(SENSOR_TYPE_HEADING)
muestra un sensor que no es wake-up
Disponible a partir de Android 13, un sensor de orientación mide en grados la dirección a la que apunta el dispositivo en relación con el norte geográfico. El sensor de rumbo incluye dos valores SensorEvent.
Uno para el rumbo medido del dispositivo y otro para la exactitud del valor de rumbo proporcionado.
Los valores de rumbo que informa este sensor deben estar entre 0.0 (inclusive) y 360.0 (exclusivo), con 0 que 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. Cuando la distribución subyacente es normal gaussiana, la exactitud corresponde a una desviación estándar. Por ejemplo, si el sensor de rumbo muestra un valor de rumbo de 60 grados y un valor de precisión de 10 grados, hay un 68% de probabilidad de que el rumbo real esté entre 50 grados y 70 grados.