Esta sección describe los ejes de los sensores, los sensores base y los sensores compuestos (actividad, actitud, no calibrados e interacción).
Ejes de 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 del sensor es relativa únicamente a la orientación natural de la pantalla (los ejes no se intercambian cuando cambia la orientación de la pantalla del dispositivo).
Ejes automotrices
En las implementaciones de Android Automotive, los ejes se definen con respecto al bastidor 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 está orientado de modo que:
- El eje X apunta hacia la derecha y está en un plano horizontal, perpendicular al plano de simetría del vehículo.
- El eje Y apunta hacia adelante y está en un plano horizontal.
El sistema de referencia del vehículo es un sistema de coordenadas diestro. Por 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 ambos horizontales. Como resultado, es posible que el eje Y no siempre pase por el eje delantero.
Sensores básicos
Los tipos de sensores básicos reciben el nombre de los sensores físicos que representan. Estos sensores transmiten datos desde un único sensor físico (a diferencia de los sensores compuestos que generan datos a partir de otros sensores). Ejemplos de tipos de sensores básicos incluyen:
-
SENSOR_TYPE_ACCELEROMETER
-
SENSOR_TYPE_GYROSCOPE
-
SENSOR_TYPE_MAGNETOMETER
Sin embargo, los sensores base no son iguales y no deben confundirse con su sensor físico subyacente. Los datos de un sensor base no son la salida sin procesar del sensor físico porque se aplican correcciones (como compensación de polarización y 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 giroscópico clasificado para tener un rango de polarización de 1 grado/seg.
- Después de la calibración de fábrica, se aplican la compensación de temperatura y la compensación de polarización, la polarización real del sensor de Android se reducirá, puede llegar a un punto en el que se garantice que la polarización sea inferior a 0,01 grados/seg.
- En esta situación, decimos que el sensor de Android tiene una desviación inferior a 0,01 grados/s, aunque la hoja de datos del sensor subyacente dice 1 grado/s.
- Un barómetro con un consumo de energía de 100 uW.
- Debido a que los datos generados deben transportarse desde el chip al SoC, el costo de energía real para recopilar datos del sensor 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 1000 uW, aunque el consumo de energía medido en los cables del chip del barómetro es de 100 uW.
- Un magnetómetro que consume 100uW al calibrarse, pero consume más al calibrar.
- Su rutina de calibración puede requerir activar el giroscopio, consumir 5000 uW y ejecutar algún algoritmo, lo que cuesta otros 900 uW.
- En esta situación, decimos que el consumo máximo de energía del sensor (magnetómetro) de Android es 6000 uW.
- En este caso, el consumo medio de energía 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
Modo de informe: continuo
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER)
devuelve un sensor sin activación
Un sensor acelerómetro informa de 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 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.
Aquí hay ejemplos:
- La norma de (x, y, z) debe estar cerca de 0 en caída libre.
- Cuando el dispositivo reposa sobre una mesa y se empuja del lado izquierdo hacia la derecha, el valor de aceleración x es positivo.
- Cuando el dispositivo reposa sobre una mesa, el valor de aceleración a lo largo de z es +9,81 alo, 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 reposa sobre una mesa y se empuja 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 usando:
- Compensación de temperatura
- Calibración de sesgo en línea
- Calibración de báscula en línea
La calibración de polarización y escala solo debe actualizarse mientras el sensor está desactivado, para evitar provocar 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
. Consulte las constantes SENSOR_STATUS_*
del SensorManager
para obtener más información sobre los posibles valores para este campo.
Temperatura ambiente
Modo de informe: en cambio
getDefaultSensor(SENSOR_TYPE_AMBIENT_TEMPERATURE)
devuelve un sensor sin activación
Este sensor proporciona la temperatura ambiente (habitación) en grados Celsius.
Sensor de campo magnético
Modo de informe: continuo
getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD)
devuelve un sensor sin activación
SENSOR_TYPE_GEOMAGNETIC_FIELD == SENSOR_TYPE_MAGNETIC_FIELD
Un sensor de campo magnético (también conocido como magnetómetro) informa del 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 micro-Tesla (uT).
El magnetómetro también informa qué tan precisas espera que sean sus lecturas a través de sensors_event_t.magnetic.status
. Consulte las constantes SENSOR_STATUS_*
del SensorManager
para obtener más información sobre los posibles valores para este campo.
Las lecturas se calibran usando:
- Compensación de temperatura
- Calibración de hierro dulce en fábrica (o en línea)
- Calibración de hierro duro en línea
Giroscopio
Modo de informe: continuo
getDefaultSensor(SENSOR_TYPE_GYROSCOPE)
devuelve un sensor sin activación
Un sensor giroscópico informa de 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 mano derecha). Es decir, un observador que mirara desde algún lugar positivo en el eje x, y, z a un dispositivo colocado en el origen informaría una rotación positiva si el dispositivo pareciera girar en el sentido contrario a las agujas del reloj. Tenga en cuenta que esta es la definición matemática estándar de rotación positiva y no concuerda con la definición aeroespacial de balanceo.
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 usando:
- Compensación de temperatura
- Compensación a escala de fábrica (o en línea)
- Calibración de polarización en línea (para eliminar la deriva)
El giroscopio también informa qué tan precisas espera que sean sus lecturas a través de sensors_event_t.gyro.status
. Consulte las constantes SENSOR_STATUS_*
del SensorManager
para obtener más información sobre los posibles valores para este campo.
El giroscopio no se puede emular basándose en magnetómetros y acelerómetros, ya que esto reduciría la consistencia local y la capacidad de respuesta. Debe basarse en un chip giroscópico habitual.
Ritmo cardiaco
Modo de informe: en cambio
getDefaultSensor(SENSOR_TYPE_HEART_RATE)
devuelve un sensor sin 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 latidos por minuto (BPM) se informa en sensors_event_t.heart_rate.bpm
y el estado del sensor se informa en sensors_event_t.heart_rate.status
. Consulte las constantes SENSOR_STATUS_*
del SensorManager
para obtener más información sobre los posibles valores para este campo. En particular, tras 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 está en constante cambio, los eventos se generan cuando y solo cuando heart_rate.bpm
o heart_rate.status
hayan cambiado desde el último evento. Los eventos no se generan más rápido que cada sampling_period
.
sensor_t.requiredPermission
es siempre SENSOR_PERMISSION_BODY_SENSORS
.
Luz
Modo de informe: en cambio
getDefaultSensor(SENSOR_TYPE_LIGHT)
devuelve un sensor que no activa
Un sensor de luz informa de la iluminación actual en unidades SI lux.
La medición se informa en sensors_event_t.light
.
Proximidad
Modo de informe: en cambio
Generalmente definido como un sensor de despertador.
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 eran sensores de activación, activando el SoC al detectar un cambio de proximidad. Después de Android 4.4, recomendamos implementar primero la versión despertador de este sensor, ya que es el que se utiliza para encender y apagar la pantalla mientras se realizan llamadas telefónicas.
La medida se informa en centímetros en sensors_event_t.distance
. Tenga en cuenta que algunos sensores de proximidad solo admiten una medición binaria "cerca" o "lejana". En este caso, el sensor informa su valor sensor_t.maxRange
en el estado "lejos" y un valor menor que sensor_t.maxRange
en el estado "cerca".
Presión
Modo de informe: continuo
getDefaultSensor(SENSOR_TYPE_PRESSURE)
devuelve un sensor sin activación
Un sensor de presión (también conocido como barómetro) informa la presión atmosférica en hectopascal (hPa).
Las lecturas se calibran usando
- Compensación de temperatura
- Calibración de polarización de fábrica
- Calibración de báscula de fábrica
El barómetro se utiliza a menudo para estimar los cambios de elevación. Para estimar la elevación absoluta, se debe utilizar como referencia la presión al nivel del mar (que cambia según el clima).
Humedad relativa
Modo de informe: en cambio
getDefaultSensor(SENSOR_TYPE_RELATIVE_HUMIDITY)
devuelve un sensor que no activa
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 y/o fusionando datos de uno o varios sensores físicos. (Cualquier sensor que no sea un sensor base se denomina sensor compuesto). Algunos ejemplos de sensores compuestos incluyen:
- Detector de pasos y de movimiento significativo , que normalmente se basan en un acelerómetro, pero que 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 base del giroscopio, pero con la calibración de polarización que se informa por separado en lugar de corregirse en la medición.
Al igual que ocurre con los sensores base, 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 un juego es probablemente 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 deriva 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.
La siguiente tabla enumera los tipos de sensores compuestos disponibles. Cada sensor compuesto se basa en datos de uno o varios sensores físicos. Evite elegir otros sensores físicos subyacentes para aproximar los resultados, ya que brindan una mala experiencia de usuario.
Tipo de sensor | Categoría | Sensores físicos subyacentes | Modo de informe |
---|---|---|---|
Actitud | Acelerómetro, giroscopio, NO DEBE UTILIZAR magnetómetro | Continuo | |
Actitud | Acelerómetro, magnetómetro, NO DEBE UTILIZAR giroscopio | Continuo | |
gesto de mirada | Interacción | Indefinido | Un trago |
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 (en desuso) | Actitud | Acelerómetro, magnetómetro, giroscopio (si está presente) | Continuo |
Interacción | Indefinido | Un trago | |
Actitud | Acelerómetro, magnetómetro, giroscopio. | Continuo | |
Actividad | Acelerómetro (u otro siempre que sea de muy baja potencia) | Un trago | |
Actividad | Acelerómetro | En cambio | |
Actividad | Acelerómetro | Especial | |
Actividad | Acelerómetro | Especial | |
Interacción | Indefinido | Un trago |
= Sensor de baja potencia
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)
Modo de informe: continuo
getDefaultSensor(SENSOR_TYPE_LINEAR_ACCELERATION)
devuelve un sensor sin activación
Un sensor de aceleración lineal informa de la aceleración lineal del dispositivo en el marco del sensor, sin incluir la gravedad.
La salida es conceptualmente: 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 estar cercanas a 0 cuando el dispositivo está inmóvil.
Si el dispositivo posee un giroscopio, el sensor de aceleración lineal debe utilizar el giroscopio y el acelerómetro como entrada.
Si el dispositivo no posee giroscopio, el sensor de aceleración lineal debe utilizar el acelerómetro y el magnetómetro como entrada.
Movimiento significativo
Sensor físico subyacente: Acelerómetro (u otro siempre que sea de baja potencia)
Modo de informe: One-shot
Baja potencia
Implemente 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 : un movimiento que podría provocar un cambio en la ubicación del usuario.
Ejemplos de mociones tan importantes son:
- Caminar o andar en bicicleta
- Sentarse en un automóvil, autocar o tren en movimiento
Ejemplos de situaciones que no provocan un movimiento significativo:
- Teléfono en el bolsillo y la persona no se mueve
- El teléfono está sobre una mesa y la mesa tiembla un poco debido al tráfico cercano o a la lavadora.
En el nivel alto, el detector de movimiento significativo se utiliza para reducir el consumo de energía al determinar la ubicación. Cuando los algoritmos de localización detectan que el dispositivo está estático, pueden cambiar a un modo de bajo consumo, donde dependen de un movimiento significativo para despertar el dispositivo cuando el usuario cambia de ubicación.
Este sensor debe ser de baja potencia. Hace una compensación por el consumo de energía que puede resultar en una pequeña cantidad de falsos negativos. Esto se hace por varias razones:
- 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 debe evitarse.
- No desencadenar un evento cuando el usuario se está moviendo (falso negativo) es aceptable siempre y cuando no se haga repetidamente. Si el usuario ha estado caminando durante 10 segundos, 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 (+ posiblemente otros siempre que sean de bajo consumo)
Modo de informe: Especial (un evento por paso realizado)
Baja potencia
getDefaultSensor(SENSOR_TYPE_STEP_DETECTOR)
devuelve un sensor sin 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 toca el suelo, generando una alta variación en la aceleración.
En comparación con el contador de pasos, el detector de pasos debería 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 deberían activarse cuando el usuario está en bicicleta, conduciendo o en otros vehículos.
Este sensor debe ser de baja potencia. Es decir, si la detección de pasos no se puede realizar en hardware, este sensor no debería definirse. En particular, cuando el detector de pasos está activado y el acelerómetro no, solo los pasos deberían provocar interrupciones (no todas las lecturas del acelerómetro).
sampling_period_ns
no tiene ningún 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 sean de bajo consumo)
Modo de informe: en cambio
Bajo consumo
getDefaultSensor(SENSOR_TYPE_STEP_COUNTER)
devuelve un sensor sin activación
Un contador de pasos informa la cantidad de pasos realizados por el usuario desde el último reinicio mientras estaba activado.
La medición se informa como uint64_t
en sensors_event_t.step_counter
y se restablece a cero solo al reiniciar el sistema.
La marca de tiempo del evento se establece en la hora en que se realizó el último paso para ese evento.
Consulte 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 mayor (hasta 10 segundos). Gracias a esta latencia, este sensor tiene una alta precisión; el recuento de pasos después de un día completo de medidas 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 deberían activarse cuando el usuario está en bicicleta, conduciendo 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 será de 16 bits. En caso de desbordamiento inminente (como máximo cada ~2^16 pasos), el SoC se puede activar para que el controlador pueda realizar el mantenimiento del contador.
Como se indica en Interacción , mientras este sensor esté funcionando, no interrumpirá ningún otro sensor, en particular el acelerómetro, que bien podría estar en uso.
Si un dispositivo en particular no puede soportar estos modos de operación, entonces HAL no debe informar sobre este tipo de sensor. Es decir, no es aceptable "emular" este sensor en el HAL.
Este sensor debe ser de baja potencia. Es decir, si la detección de pasos no se puede realizar en hardware, este sensor no debería definirse. En particular, cuando el contador de pasos está activado y el acelerómetro no, solo los pasos deberían provocar interrupciones (no los datos del acelerómetro).
detector de inclinación
Sensor físico subyacente: Acelerómetro (+ posiblemente otros siempre que sean de bajo consumo)
Modo de informe: Especial
Bajo consumo
Implemente 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 el cambio de la dirección de la gravedad promedio de la ventana de 2 segundos en al menos 35 grados desde la activación o el último evento generado por el sensor. Aquí está 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 mediciones del acelerómetro durante los últimos 2 segundos. - Se activa cuando
angle(reference_estimated_gravity, current_estimated_gravity) > 35 degrees
Las grandes aceleraciones sin un cambio en la orientación del teléfono no deberían provocar un evento de inclinación. Por ejemplo, un giro brusco o una fuerte aceleración mientras se conduce un automóvil no debería provocar un evento de inclinación, aunque el ángulo de la aceleración promedio pueda variar en más de 35 grados. Normalmente, este sensor se implementa únicamente con la ayuda de un acelerómetro. También se pueden utilizar otros sensores si no aumentan significativamente el consumo de energía. Este es un sensor de bajo consumo que debería permitir que el SoC entre en modo de suspensión. No emule este sensor en el 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
Modo de informe: continuo
getDefaultSensor(SENSOR_TYPE_ROTATION_VECTOR)
devuelve un sensor sin activación
Un sensor de vector de rotación informa la orientación del dispositivo con respecto al marco de coordenadas Este-Norte-Arriba. Generalmente se obtiene integrando las lecturas del acelerómetro, giroscopio y magnetómetro. El sistema de coordenadas Este-Norte-Arriba se define como una base ortonormal directa donde:
- X apunta al 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 está representada por 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 puede verse como una rotación del teléfono en un ángulo theta alrededor de un eje rot_axis
para pasar de la orientación del dispositivo de referencia (alineada Este-Norte-Arriba) a la orientación actual del dispositivo. La rotación se codifica como los cuatro componentes x, y, z, 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)
Dónde:
- Los campos x, y y z de
rot_axis
son las coordenadas Este-Norte-Arriba de un vector unitario de longitud que representa el eje de rotación. -
theta
es el ángulo de rotación
El cuaternión es un cuaternión unitario: debe ser de norma 1
. No garantizar esto provocará un comportamiento errático del cliente.
Además, este sensor informa una precisión de rumbo 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 utilizar 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 usando solo 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 informe: continuo
getDefaultSensor(SENSOR_TYPE_GAME_ROTATION_VECTOR)
devuelve un sensor sin activación
Un sensor de vector de rotación de juego es similar a un sensor de vector de rotación pero no utiliza el campo geomagnético. Por lo tanto, el eje Y no apunta al norte sino a alguna otra referencia. Se permite que esa referencia se desvíe en el mismo orden de magnitud que el giroscopio se desplaza alrededor del eje Z.
Consulte el sensor de vector de rotación para obtener detalles sobre cómo configurar sensors_event_t.data[0-3]
. Este sensor no informa una precisión de rumbo estimada: sensors_event_t.data[4]
está reservado y debe establecerse en 0
.
En un caso ideal, un teléfono girado y devuelto 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 utilizar el magnetómetro como entrada, excepto, indirectamente, mediante la estimación del sesgo del giroscopio.
Gravedad
Sensores físicos subyacentes: acelerómetro y (si está presente) giroscopio (o magnetómetro si no hay giroscopio)
Modo de informe: continuo
getDefaultSensor(SENSOR_TYPE_GRAVITY)
devuelve un sensor que no activa
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, la salida del sensor de gravedad debe ser idéntica a la del acelerómetro. En la Tierra, la magnitud es de alrededor de 9,8 m/s^2.
Si el dispositivo posee un giroscopio, el sensor de gravedad debe utilizar el giroscopio y el acelerómetro como entrada.
Si el dispositivo no posee giroscopio, el sensor de gravedad debe utilizar 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)
devuelve un sensor sin activación
Un vector de rotación geomagnético es similar a un sensor de vector de rotación pero utiliza un magnetómetro y no un giroscopio.
Este sensor debe basarse en un magnetómetro. No se puede implementar usando un giroscopio y este sensor no puede usar la entrada del giroscopio.
Consulte el sensor de 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 rumbo debe ser menor que la precisión estimada ( sensors_event_t.data[4]
) el 95% del tiempo.
Este sensor debe ser de baja potencia, por lo que debe implementarse en hardware.
Orientación (en desuso)
Sensores físicos subyacentes: acelerómetro, magnetómetro y (si está presente) giroscopio
Modo de informe: continuo
getDefaultSensor(SENSOR_TYPE_ORIENTATION)
devuelve un sensor sin activación
Nota: Este es un tipo de sensor más antiguo que ha quedado obsoleto en el SDK de Android. Ha sido sustituido por el sensor de vector de rotación, que está más claramente definido. Utilice el sensor de vector de rotación sobre el sensor de orientación siempre que sea posible.
Un sensor de orientación informa de 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
: 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
: paso, 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.
Tenga en cuenta que, por razones históricas, el ángulo de balanceo 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):
Esta definición es diferente de la guiñada, el cabeceo y el balanceo utilizados en la aviación, donde el eje X está a lo largo del lado largo del avión (de la cola al morro).
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
. Consulte las constantes SENSOR_STATUS_*
del SensorManager
para obtener más información sobre los posibles valores para este campo.
Sensores no calibrados
Los sensores no calibrados proporcionan resultados más brutos y pueden incluir cierto sesgo, pero también contienen menos "saltos" de las correcciones aplicadas durante la calibración. Algunas aplicaciones pueden preferir estos resultados no calibrados por ser más fluidos y confiables. Por ejemplo, si una aplicación intenta realizar su propia fusión de sensores, la introducción de calibraciones puede distorsionar los resultados.
Acelerómetro no calibrado
Sensor físico subyacente: acelerómetro
Modo de informe: continuo
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_UNCALIBRATED)
devuelve un sensor sin 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 (el sesgo de fábrica y la compensación de temperatura se aplican a mediciones no calibradas), junto con una estimación de sesgo. Todos los valores están en unidades SI (m/s^2) y se informan en los campos de sensors_event_t.uncalibrated_accelerometer
:
-
x_uncalib
: aceleración (sin compensación de polarización) a lo largo del eje X -
y_uncalib
: aceleración (sin compensación de polarización) a lo largo del eje Y -
z_uncalib
: aceleración (sin compensación de polarización) a lo largo del eje Z -
x_bias
: sesgo estimado a lo largo del eje X -
y_bias
: sesgo estimado a lo largo del eje Y -
z_bias
: sesgo estimado a lo largo del eje Z
Giroscopio no calibrado
Sensor físico subyacente: giroscopio
Modo de informe: continuo
getDefaultSensor(SENSOR_TYPE_GYROSCOPE_UNCALIBRATED)
devuelve un sensor sin 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 de sesgo. Todos los valores están en radianes/segundo y se informan en los campos de sensors_event_t.uncalibrated_gyro
:
-
x_uncalib
: velocidad angular (sin compensación de deriva) alrededor del eje X -
y_uncalib
: velocidad angular (sin compensación de deriva) alrededor del eje Y -
z_uncalib
: velocidad angular (sin compensación de deriva) alrededor del eje Z -
x_bias
: deriva estimada alrededor del eje X -
y_bias
: deriva estimada alrededor del eje Y -
z_bias
: deriva 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 deberían permanecer estables el resto del tiempo.
Consulte la definición del sensor giroscópico para obtener detalles sobre el sistema de coordenadas utilizado.
Se debe aplicar calibración de fábrica y 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 es capaz de estimar la deriva, entonces no se debe implementar este sensor.
Si este sensor está presente, entonces el sensor giroscopio correspondiente también debe estar presente y ambos sensores deben compartir los mismos valores sensor_t.name
y sensor_t.vendor
.
Campo magnético no calibrado
Sensor físico subyacente: magnetómetro
Modo de informe: continuo
getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED)
devuelve un sensor que no se activa
Un sensor de campo magnético no calibrado informa del campo magnético ambiental junto con una estimación de calibración de hierro duro. Todos los valores están en micro-Tesla (uT) y se informan en los campos de sensors_event_t.uncalibrated_magnetic
:
-
x_uncalib
: campo magnético (sin compensación de hierro) a lo largo del eje X -
y_uncalib
: campo magnético (sin compensación de hierro) a lo largo del eje Y -
z_uncalib
: campo magnético (sin compensación de hierro) a lo largo del eje Z -
x_bias
: sesgo duro estimado a lo largo del eje X -
y_bias
: sesgo duro estimado a lo largo del eje Y -
z_bias
: sesgo duro estimado a lo largo 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
.
El magnetómetro no calibrado permite que algoritmos de nivel superior manejen una mala estimación del hierro duro. Se espera que los valores x_bias
, y_bias
y z_bias
salten tan pronto como cambie la estimación del hierro duro, y deberían permanecer estables el resto del tiempo.
A las mediciones se les debe aplicar calibración de hierro dulce y compensación de temperatura. Además, se debe implementar una estimación estricta para que se puedan informar estimaciones razonables en x_bias
, y_bias
y z_bias
. Si la implementación no puede estimar el sesgo, entonces este sensor no debe implementarse.
Si este sensor está presente, entonces el sensor de campo magnético correspondiente debe estar presente y ambos sensores deben compartir los mismos valores sensor_t.name
y sensor_t.vendor
.
Ángulo de bisagra
Modo de informe: en cambio
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 utilizan principalmente para detectar interacciones con el usuario. No definimos cómo se deben implementar esos sensores, pero deben ser de baja potencia y es responsabilidad del fabricante del dispositivo verificar su calidad en términos de experiencia de usuario.
gesto de despertar
Sensores físicos subyacentes: indefinidos (cualquier cosa de baja potencia)
Modo de informe: One-shot
Bajo consumo
Implemente 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 en función de un movimiento específico del dispositivo. Cuando este sensor se activa, el dispositivo se comporta como si se presionara el botón de encendido, encendiendo la pantalla. Este comportamiento (encender la pantalla cuando se activa este sensor) puede ser desactivado por el usuario en la configuración del dispositivo. Los cambios en la configuración no afectan el comportamiento del sensor: solo si el marco enciende la pantalla cuando se activa. El gesto real que se detectará no está especificado y puede ser elegido por el fabricante del dispositivo.
Este sensor debe ser de baja potencia, ya que es probable que esté activado las 24 horas del día, los 7 días de la semana.
Cada evento de sensor informa 1
en sensors_event_t.data[0]
.
gesto de recoger
Sensores físicos subyacentes: indefinidos (cualquier cosa de baja potencia)
Modo de informe: One-shot
Bajo consumo
Implemente solo la versión de activación de este sensor.
getDefaultSensor(SENSOR_TYPE_PICK_UP_GESTURE)
Devuelve un sensor de despertar
Un sensor de gestos de recogida se desencadena cuando el dispositivo se recoge independientemente de donde estuviera antes (escritorio, bolsillo, bolsa).
Cada evento del sensor informa 1
en sensors_event_t.data[0]
.
Gesto de mirada
Sensores físicos subyacentes: indefinido (cualquier cosa baja de potencia)
Modo de informes: un solo disparo
Bajo consumo
Implemente solo la versión de activación de este sensor.
getDefaultSensor(SENSOR_TYPE_GLANCE_GESTURE)
Devuelve un sensor de despertar
Un sensor de gestos de mirada permite activar brevemente la pantalla para permitir que el usuario mire el contenido en la pantalla en función de un movimiento específico. Cuando este sensor se desencadena, el dispositivo activará la pantalla momentáneamente para permitir que el usuario mire las notificaciones u otro contenido mientras el dispositivo permanece bloqueado en un estado no interactivo (docenas), luego la pantalla se apagará nuevamente. Este comportamiento (enciende brevemente la pantalla cuando este sensor desencadene) podría ser desactivado por el usuario en la configuración del dispositivo. Los cambios en la configuración no afectan el comportamiento del sensor: solo si el marco enciende brevemente la pantalla cuando se activa. El gesto real que se detectará no se especifica, y puede ser elegido por el fabricante del dispositivo.
Este sensor debe ser de baja potencia, ya que es probable que se active las 24 horas, los 7 días de la semana. Cada evento del sensor informa 1
en sensors_event_t.data[0]
.
Sensores de imu de hachas limitadas
Disponible en Android 13, los sensores de 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 y dispositivos de forma admiten acelerómetros de 3 ejes y giroscopios de 3 ejes.
Ejes de acelerómetro limitado
Sensores físicos subyacentes: acelerómetro
Modo de informes: continuo
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES)
Devuelve un sensor no despertador
Un sensor de ejes limitados de acelerómetro es equivalente al TYPE_ACCELEROMETER
, pero admite casos en los que no se admiten uno o dos ejes.
Los últimos tres valores del evento del sensor informados por el sensor representan si se admiten 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 es compatible. Los fabricantes de dispositivos identifican los ejes compatibles 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 ejes no utilizados en 0
, en lugar de tener valores indefinidos.
Ejes limitados de giroscopio
Sensores físicos subyacentes: giroscopio
Modo de informes: continuo
getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES)
Devuelve un sensor que no se despierta
Un sensor de ejes limitados de giroscopio es equivalente a TYPE_GYROSCOPE
, pero admite casos en los que no se admiten uno o dos ejes.
Los últimos tres valores de evento del sensor informados por el sensor representan si se admiten 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 es compatible. Los fabricantes de dispositivos identifican los ejes compatibles 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
.
Acelerómetro ejes limitados no calibrados
Sensores físicos subyacentes: acelerómetro
Modo de informes: continuo
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED)
Devuelve un sensor no despilado
Un acelerómetro de ejes limitados del sensor no calibrado es equivalente a TYPE_ACCELEROMETER_UNCALIBRATED
pero admite casos en los que no se admiten uno o dos ejes.
Los últimos tres valores de evento del sensor informados por 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 compatibles 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 no utilizados en 0
.
Giroscopio ejes limitados no calibrados
Sensores físicos subyacentes: giroscopio
Modo de informes: continuo
getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED)
Devuelve un sensor no despilado
Un giroscopio de ejes limitados del sensor no calibrado es equivalente a TYPE_GYROSCOPE_UNCALIBRATED
pero admite casos en los que no se admiten uno o dos ejes.
Los últimos tres valores de evento del sensor informados por el sensor representan si se admiten la velocidad angular y los valores de 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 compatibles en el tiempo de compilación y los valores no cambian durante el tiempo de ejecución.
Los fabricantes de dispositivos deben establecer la velocidad angular y los valores de deriva para los ejes no utilizados en 0
.
Hachas limitadas compuestas imu
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 3 ejes de giroscopio de 3 ejes.
Modo de informes: continuo
Un sensor de IMU de ejes limitados compuestos es equivalente a un sensor IMU de ejes limitados, pero en lugar de ser soportado en el 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.
La siguiente tabla muestra una conversión de ejemplo de un acelerómetro estándar de 3 ejes a un acelerómetro compuesto de ejes limitados.
Valores de SensorEvent para sensor_type_accelerómetro | Ejemplo Sensor_type_accelerometer sensorEvent | Sensor compuesto_type_accelerometer_limited_axes sensorevent |
---|---|---|
valores [0] | -0,065 | -0,065 |
valores [1] | 0,078 | 0,078 |
valores [2] | 9.808 | 9.808 |
valores [3] | N / A | 1.0 |
valores [4] | N / A | 1.0 |
valores [5] | N / A | 1.0 |
Sensores automotrices
Sensores para admitir casos de uso automotriz.
Título
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 no despertador
Disponible en Android 13, un sensor de encabezado mide la dirección en la que el dispositivo apunta en relación con el verdadero norte en grados. El sensor de encabezado incluye dos valores SensorEvent
. Uno para el encabezado del dispositivo medido y otro para la precisión del valor de encabezado proporcionado.
Los valores de encabezado informados por este sensor deben estar entre 0.0
(inclusive) y 360.0
(exclusivo), con 0
que indican Norte, 90
este, 180
Sur y 270
West.
La precisión para este sensor se define con un 68 por ciento de confianza. En el caso de que la distribución subyacente sea normal gaussiana, la precisión es una desviación estándar. Por ejemplo, si el sensor de encabezado devuelve un valor de encabezado de 60 grados y un valor de precisión de 10 grados, hay una probabilidad del 68 por ciento de que el verdadero encabezado sea entre 50 grados y 70 grados.