Esta seção descreve os eixos do sensor, sensores básicos e sensores compostos (atividade, atitude, não calibrado e interação).
Eixos do sensor
Os valores de eventos do sensor de muitos sensores são expressos em um quadro específico que é estático em relação ao dispositivo.
Eixos do dispositivo móvel
A API do Sensor é relativa apenas à orientação natural da tela (os eixos não são trocados quando a orientação da tela do dispositivo muda.
Figura 1. Sistema de coordenadas (relativo a um dispositivo móvel) usado pela API do Sensor
Eixos automotivos
Nas implementações do Android Automotive, os eixos são definidos em relação à estrutura da carroceria do veículo. A origem do referencial do veículo é o centro do eixo traseiro. O referencial do veículo é orientado de forma que:
- O eixo X aponta para a direita e está em um plano horizontal, perpendicular ao plano de simetria do veículo.
- O eixo Y aponta para frente e está em um plano horizontal.
Figura 2. Sistema de coordenadas (relativo a um dispositivo automotivo) usado pela API do Sensor
O quadro de referência do veículo é um sistema de coordenadas destro. Portanto, o eixo Z aponta para cima.
O eixo Z do quadro de referência está alinhado à gravidade, o que significa que o eixo X e o eixo Y são horizontais. Como resultado, o eixo Y nem sempre passa pelo eixo dianteiro.
Sensores básicos
Os tipos de sensores básicos são nomeados de acordo com os sensores físicos que representam. Esses sensores transmitem dados de um único sensor físico (em oposição a sensores compostos que geram dados de outros sensores). Exemplos de tipos de sensores básicos incluem:
-
SENSOR_TYPE_ACCELEROMETER -
SENSOR_TYPE_GYROSCOPE -
SENSOR_TYPE_MAGNETOMETER
No entanto, os sensores básicos não são iguais e não devem ser confundidos com o sensor físico subjacente. Os dados de um sensor básico não são a saída bruta do sensor físico porque as correções (como compensação de polarização e compensação de temperatura) são aplicadas.
Por exemplo, as características de um sensor básico podem ser diferentes das características de seu sensor físico subjacente nos seguintes casos de uso:
- Um chip de giroscópio classificado para ter uma faixa de polarização de 1 grau/s.
- Após a calibração de fábrica, a compensação de temperatura e a compensação de polarização são aplicadas, a polarização real do sensor Android será reduzida, podendo chegar a um ponto em que a polarização seja garantida abaixo de 0,01 graus/s.
- Nesta situação, dizemos que o sensor Android tem um viés abaixo de 0,01 graus/s, mesmo que a folha de dados do sensor subjacente tenha dito 1 grau/s.
- Um barômetro com um consumo de energia de 100 uW.
- Como os dados gerados precisam ser transportados do chip para o SoC, o custo real de energia para coletar dados do sensor Android do barômetro pode ser muito maior, por exemplo, 1000 uW.
- Nesta situação, dizemos que o sensor Android tem um consumo de energia de 1000 uW, embora o consumo de energia medido nos cabos do chip do barômetro seja de 100 uW.
- Um magnetômetro que consome 100uW quando calibrado, mas consome mais quando calibrado.
- Sua rotina de calibração pode exigir a ativação do giroscópio, consumindo 5000 uW, e executando algum algoritmo, custando outros 900 uW.
- Nesta situação, dizemos que o consumo máximo de energia do sensor Android (magnetômetro) é de 6000 uW.
- Neste caso, o consumo médio de energia é a medida mais útil, e é o que é reportado nas características estáticas do sensor através do HAL.
Acelerômetro
Modo de relatório: Contínuo
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER) retorna um sensor que não desperta
Um sensor acelerômetro informa a aceleração do dispositivo ao longo dos três eixos do sensor. A aceleração medida inclui tanto a aceleração física (mudança de velocidade) quanto a gravidade. A medição é relatada nos campos x, yez de sensores_event_t.acceleration.
Todos os valores estão em unidades SI (m/s^2) e medem a aceleração do dispositivo menos a força da gravidade ao longo dos três eixos do sensor.
Aqui estão exemplos:
- A norma de (x, y, z) deve ser próxima de 0 quando em queda livre.
- Quando o dispositivo está deitado sobre uma mesa e é empurrado do lado esquerdo para a direita, o valor da aceleração x é positivo.
- Quando o dispositivo está deitado sobre uma mesa, o valor da aceleração ao longo de z é +9,81 alo, que corresponde à aceleração do dispositivo (0 m/s^2) menos a força da gravidade (-9,81 m/s^2).
- Quando o dispositivo está deitado sobre uma mesa e é empurrado para o céu, o valor da aceleração é maior que +9,81, que corresponde à aceleração do dispositivo (+A m/s^2) menos a força da gravidade (-9,81 m /s^2).
As leituras são calibradas usando:
- Compensação de temperatura
- Calibração de viés online
- Calibração de balança online
A calibração de bias e escala só deve ser atualizada enquanto o sensor estiver desativado, para evitar saltos nos valores durante a transmissão.
O acelerômetro também informa a precisão que espera que suas leituras sejam por meio de sensors_event_t.acceleration.status . Consulte as constantes SensorManager SENSOR_STATUS_* do SensorManager para obter mais informações sobre os valores possíveis para este campo.
Temperatura ambiente
Modo de relatório: em mudança
getDefaultSensor(SENSOR_TYPE_AMBIENT_TEMPERATURE) retorna um sensor que não desperta
Este sensor fornece a temperatura ambiente (ambiente) em graus Celsius.
Sensor de campo magnético
Modo de relatório: Contínuo
getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD) retorna um sensor que não desperta
SENSOR_TYPE_GEOMAGNETIC_FIELD == SENSOR_TYPE_MAGNETIC_FIELD
Um sensor de campo magnético (também conhecido como magnetômetro) informa o campo magnético ambiente, conforme medido ao longo dos três eixos do sensor.
A medição é relatada nos campos x, yez de sensors_event_t.magnetic e todos os valores estão em micro-Tesla (uT).
O magnetômetro também informa a precisão que espera que suas leituras sejam por meio de sensors_event_t.magnetic.status . Consulte as constantes SensorManager SENSOR_STATUS_* do SensorManager para obter mais informações sobre os valores possíveis para este campo.
As leituras são calibradas usando:
- Compensação de temperatura
- Calibração de ferro macio de fábrica (ou online)
- Calibração de ferro duro online
Giroscópio
Modo de relatório: Contínuo
getDefaultSensor(SENSOR_TYPE_GYROSCOPE) retorna um sensor que não desperta
Um sensor de giroscópio informa a taxa de rotação do dispositivo em torno dos três eixos do sensor.
A rotação é positiva no sentido anti-horário (regra da mão direita). Ou seja, um observador olhando de algum local positivo no eixo x, y ou z em um dispositivo posicionado na origem relataria uma rotação positiva se o dispositivo parecesse estar girando no sentido anti-horário. Observe que esta é a definição matemática padrão de rotação positiva e não concorda com a definição aeroespacial de rolagem.
A medição é relatada nos campos x, yez de sensors_event_t.gyro e todos os valores estão em radianos por segundo (rad/s).
As leituras são calibradas usando:
- Compensação de temperatura
- Compensação de balança de fábrica (ou online)
- Calibração de polarização online (para remover o desvio)
O giroscópio também informa a precisão que espera que suas leituras sejam por meio de sensors_event_t.gyro.status . Consulte as constantes SensorManager SENSOR_STATUS_* do SensorManager para obter mais informações sobre os valores possíveis para este campo.
O giroscópio não pode ser emulado com base em magnetômetros e acelerômetros, pois isso faria com que ele tivesse consistência e capacidade de resposta locais reduzidas. Deve ser baseado em um chip de giroscópio usual.
Frequência cardíaca
Modo de relatório: em mudança
getDefaultSensor(SENSOR_TYPE_HEART_RATE) retorna um sensor que não desperta
Um sensor de frequência cardíaca informa a frequência cardíaca atual da pessoa que toca no dispositivo.
A frequência cardíaca atual em batimentos por minuto (BPM) é informada em sensors_event_t.heart_rate.bpm e o status do sensor é relatado em sensors_event_t.heart_rate.status . Consulte as constantes SensorManager SENSOR_STATUS_* do SensorManager para obter mais informações sobre os valores possíveis para este campo. Em particular, na primeira ativação, a menos que se saiba que o dispositivo não está no corpo, o campo de status do primeiro evento deve ser definido como SENSOR_STATUS_UNRELIABLE . Como esse sensor é alterado, os eventos são gerados quando e somente quando heart_rate.bpm ou heart_rate.status foram alterados desde o último evento. Os eventos não são gerados mais rápido do que cada sampling_period .
sensor_t.requiredPermission é sempre SENSOR_PERMISSION_BODY_SENSORS .
Leve
Modo de relatório: em mudança
getDefaultSensor(SENSOR_TYPE_LIGHT) retorna um sensor que não desperta
Um sensor de luz informa a iluminação atual em unidades SI lux.
A medição é relatada em sensors_event_t.light .
Proximidade
Modo de relatório: em mudança
Normalmente definido como um sensor de despertar
getDefaultSensor(SENSOR_TYPE_PROXIMITY) retorna um sensor de ativação
Um sensor de proximidade informa a distância do sensor até a superfície visível mais próxima.
Até o Android 4.4, os sensores de proximidade eram sempre sensores de despertar, despertando o SoC ao detectar uma mudança de proximidade. Após o Android 4.4, aconselhamos implementar primeiro a versão de ativação deste sensor, pois é a que é usada para ligar e desligar a tela durante as chamadas telefônicas.
A medição é informada em centímetros em sensors_event_t.distance . Observe que alguns sensores de proximidade suportam apenas uma medição binária "próximo" ou "distante". Neste caso, o sensor reporta seu valor sensor_t.maxRange no estado "far" e um valor menor que sensor_t.maxRange no estado "near".
Pressão
Modo de relatório: Contínuo
getDefaultSensor(SENSOR_TYPE_PRESSURE) retorna um sensor que não desperta
Um sensor de pressão (também conhecido como barômetro) informa a pressão atmosférica em hectopascal (hPa).
As leituras são calibradas usando
- Compensação de temperatura
- Calibração de polarização de fábrica
- Calibração de balança de fábrica
O barômetro é frequentemente usado para estimar as mudanças de elevação. Para estimar a elevação absoluta, a pressão ao nível do mar (que varia dependendo do clima) deve ser usada como referência.
Humidade relativa
Modo de relatório: em mudança
getDefaultSensor(SENSOR_TYPE_RELATIVE_HUMIDITY) retorna um sensor que não desperta
Um sensor de umidade relativa mede a umidade relativa do ar ambiente e retorna um valor em porcentagem.
Tipos de sensores compostos
Um sensor composto gera dados processando e/ou fundindo dados de um ou vários sensores físicos. (Qualquer sensor que não seja um sensor básico é chamado de sensor composto.) Exemplos de sensores compostos incluem:
- Detector de passos e movimento significativo , que geralmente são baseados em um acelerômetro, mas também podem ser baseados em outros sensores, se o consumo de energia e a precisão forem aceitáveis.
- Vetor de rotação do jogo , baseado em um acelerômetro e um giroscópio.
- Giroscópio não calibrado , que é semelhante ao sensor base do giroscópio, mas com a calibração de polarização sendo relatada separadamente em vez de ser corrigida na medição.
Assim como os sensores básicos, as características dos sensores compostos vêm das características de seus dados finais. Por exemplo, o consumo de energia de um vetor de rotação do jogo é provavelmente igual à soma dos consumos de energia do chip do acelerômetro, do chip do giroscópio, do chip que processa os dados e dos ônibus que transportam os dados. Como outro exemplo, o desvio de um vetor de rotação do jogo depende tanto da qualidade do algoritmo de calibração quanto das características físicas do sensor.
A tabela a seguir lista os tipos de sensores compostos disponíveis. Cada sensor composto depende de dados de um ou vários sensores físicos. Evite escolher outros sensores físicos subjacentes para aproximar os resultados, pois eles proporcionam uma experiência ruim ao usuário.
| Tipo de sensor | Categoria | Sensores físicos subjacentes | Modo de relatório |
|---|---|---|---|
Atitude | Acelerômetro, giroscópio, NÃO DEVE USAR magnetômetro | Contínuo | |
Atitude | Acelerômetro, magnetômetro, NÃO DEVE USAR giroscópio | Contínuo | |
Gesto de olhar  | Interação | Indefinido | Um disparo |
Atitude | Acelerômetro, giroscópio | Contínuo | |
Não calibrado | Giroscópio | Contínuo | |
Atividade | Acelerômetro, giroscópio (se houver) ou magnetômetro (se o giroscópio não estiver presente) | Contínuo | |
Não calibrado | Magnetômetro | Contínuo | |
Orientação (obsoleto) | Atitude | Acelerômetro, magnetômetro, giroscópio (se houver) | Contínuo |
Interação | Indefinido | Um disparo | |
Atitude | Acelerômetro, magnetômetro, giroscópio | Contínuo | |
Atividade | Acelerômetro (ou outro, desde que com potência muito baixa) | Um disparo | |
Atividade | Acelerômetro | Em mudança | |
Atividade | Acelerômetro | Especial | |
Atividade | Acelerômetro | Especial | |
Interação | Indefinido | Um disparo |
= Sensor de baixa potência
Sensores compostos de atividade
Aceleração linear
Sensores físicos subjacentes: Acelerômetro e (se houver) giroscópio (ou magnetômetro se o giroscópio não estiver presente)
Modo de relatório: Contínuo
getDefaultSensor(SENSOR_TYPE_LINEAR_ACCELERATION) retorna um sensor que não desperta
Um sensor de aceleração linear relata a aceleração linear do dispositivo no quadro do sensor, sem incluir a gravidade.
A saída é conceitualmente: saída do acelerômetro menos a saída do sensor de gravidade . É relatado em m/s^2 nos campos x, yez de sensors_event_t.acceleration .
As leituras em todos os eixos devem estar próximas de 0 quando o dispositivo estiver imóvel.
Caso o dispositivo possua um giroscópio, o sensor de aceleração linear deve utilizar o giroscópio e o acelerômetro como entrada.
Caso o aparelho não possua giroscópio, o sensor de aceleração linear deve utilizar o acelerômetro e o magnetômetro como entrada.
Movimento significativo
Sensor físico subjacente: Acelerômetro (ou outro, desde que seja de baixa potência)
Modo de relatório: One-shot
Baixa potência
Implemente apenas a versão de ativação deste sensor.
getDefaultSensor(SENSOR_TYPE_SIGNIFICANT_MOTION) retorna um sensor de ativação
Um detector de movimento significativo é acionado ao detectar um movimento significativo : um movimento que pode levar a uma mudança na localização do usuário.
Exemplos de tais movimentos significativos são:
- Caminhar ou andar de bicicleta
- Sentado em um carro, ônibus ou trem em movimento
Exemplos de situações que não acionam movimento significativo:
- Telefone no bolso e a pessoa não está se movendo
- O telefone está em uma mesa e a mesa treme um pouco devido ao tráfego nas proximidades ou à máquina de lavar
No nível alto, o detector de movimento significativo é usado para reduzir o consumo de energia da determinação de localização. Quando os algoritmos de localização detectam que o dispositivo está estático, eles podem alternar para um modo de baixo consumo de energia, no qual dependem de movimento significativo para ativar o dispositivo quando o usuário está mudando de local.
Este sensor deve ser de baixa potência. Ele faz uma compensação pelo consumo de energia que pode resultar em uma pequena quantidade de falsos negativos. Isso é feito por alguns motivos:
- O objetivo deste sensor é economizar energia.
- Acionar um evento quando o usuário não está se movendo (falso positivo) é caro em termos de energia, por isso deve ser evitado.
- Não acionar um evento quando o usuário está em movimento (falso negativo) é aceitável desde que não seja feito repetidamente. Se o usuário estiver andando por 10 segundos, não acionar um evento dentro desses 10 segundos não é aceitável.
Cada evento de sensor relata 1 em sensors_event_t.data[0] .
Detector de passos
Sensor físico subjacente: Acelerômetro (+ possivelmente outros, desde que baixa potência)
Modo de relatório: Especial (um evento por etapa realizada)
Baixa potência
getDefaultSensor(SENSOR_TYPE_STEP_DETECTOR) retorna um sensor que não desperta
Um detector de passos gera um evento cada vez que um passo é dado pelo usuário.
O timestamp do evento sensors_event_t.timestamp corresponde ao momento em que o pé toca o solo, gerando uma grande variação na aceleração.
Comparado com o contador de passos, o detector de passos deve ter uma latência menor (menos de dois segundos). Tanto o detector de passos quanto o contador de passos detectam quando o usuário está andando, correndo e subindo as escadas. Eles não devem ser acionados quando o usuário estiver andando de bicicleta, dirigindo ou em outros veículos.
Este sensor deve ser de baixa potência. Ou seja, se a detecção do passo não puder ser feita em hardware, este sensor não deve ser definido. Em particular, quando o detector de passos é ativado e o acelerômetro não, apenas os passos devem acionar interrupções (nem todas as leituras do acelerômetro).
sampling_period_ns não tem impacto nos detectores de passos.
Cada evento de sensor relata 1 em sensors_event_t.data[0] .
Contador de passos
Sensor físico subjacente: Acelerômetro (+ possivelmente outros, desde que baixa potência)
Modo de relatório: em mudança
Baixa potência
getDefaultSensor(SENSOR_TYPE_STEP_COUNTER) retorna um sensor que não desperta
Um contador de passos informa o número de passos dados pelo usuário desde a última reinicialização enquanto ativado.
A medição é relatada como uint64_t em sensors_event_t.step_counter e é redefinida para zero somente na reinicialização do sistema.
O carimbo de data/hora do evento é definido para a hora em que a última etapa desse evento foi realizada.
Consulte o tipo de sensor do detector de etapas para saber o significado do tempo de uma etapa.
Comparado ao detector de passos, o contador de passos pode ter uma latência maior (até 10 segundos). Graças a essa latência, esse sensor possui alta precisão; a contagem de passos após um dia inteiro de medidas deve estar dentro de 10% da contagem real de passos. Tanto o detector de passos quanto o contador de passos detectam quando o usuário está andando, correndo e subindo as escadas. Eles não devem ser acionados quando o usuário estiver andando de bicicleta, dirigindo ou em outros veículos.
O hardware deve garantir que a contagem interna de etapas nunca exceda. O tamanho mínimo do contador interno do hardware deve ser de 16 bits. Em caso de estouro iminente (no máximo a cada ~2^16 etapas), o SoC pode ser ativado para que o motorista possa fazer a manutenção do contador.
Conforme declarado em Interação , enquanto este sensor estiver operando, ele não deve interromper nenhum outro sensor, em particular, o acelerômetro, que pode muito bem estar em uso.
Se um determinado dispositivo não suportar esses modos de operação, esse tipo de sensor não deve ser relatado pelo HAL. Ou seja, não é aceitável "emular" esse sensor no HAL.
Este sensor deve ser de baixa potência. Ou seja, se a detecção do passo não pode ser feita em hardware, este sensor não deve ser definido. Em particular, quando o contador de passos é ativado e o acelerômetro não, apenas os passos devem acionar interrupções (não os dados do acelerômetro).
Detector de inclinação
Sensor físico subjacente: Acelerômetro (+ possivelmente outros, desde que baixa potência)
Modo de relatório: Especial
Baixa potência
Implemente apenas a versão de ativação deste sensor.
getDefaultSensor(SENSOR_TYPE_TILT_DETECTOR) retorna um sensor de ativação
Um detector de inclinação gera um evento cada vez que um evento de inclinação é detectado.
Um evento de inclinação é definido pela direção da gravidade média da janela de 2 segundos mudando em pelo menos 35 graus desde a ativação ou o último evento gerado pelo sensor. Aqui está o algoritmo:
-
reference_estimated_gravity= média das medições do acelerômetro no primeiro segundo após a ativação ou a gravidade estimada quando o último evento de inclinação foi gerado. -
current_estimated_gravity= média das medições do acelerômetro nos últimos 2 segundos. - Acionar quando
angle(reference_estimated_gravity, current_estimated_gravity) > 35 degrees
Grandes acelerações sem uma mudança na orientação do telefone não devem desencadear um evento de inclinação. Por exemplo, uma curva acentuada ou forte aceleração ao dirigir um carro não deve desencadear um evento de inclinação, mesmo que o ângulo da aceleração média possa variar em mais de 35 graus. Normalmente, esse sensor é implementado com a ajuda de apenas um acelerômetro. Outros sensores também podem ser usados se não aumentarem significativamente o consumo de energia. Este é um sensor de baixa potência que deve permitir que o SoC entre no modo de suspensão. Não emule este sensor no HAL. Cada evento de sensor relata 1 em sensors_event_t.data[0] .
Sensores compostos de atitude
Vetor de rotação
Sensores físicos subjacentes: Acelerômetro, magnetômetro e giroscópio
Modo de relatório: Contínuo
getDefaultSensor(SENSOR_TYPE_ROTATION_VECTOR) retorna um sensor que não desperta
Um sensor de vetor de rotação informa a orientação do dispositivo em relação ao quadro de coordenadas Leste-Norte-Cima. Geralmente é obtido pela integração das leituras do acelerômetro, giroscópio e magnetômetro. O sistema de coordenadas Leste-Norte-Up é definido como uma base ortonormal direta onde:
- X aponta para leste e é tangencial ao solo.
- Y aponta para o norte e é tangencial ao solo.
- Z aponta para o céu e é perpendicular ao solo.
A orientação do telefone é representada pela rotação necessária para alinhar as coordenadas Leste-Norte com as coordenadas do telefone. Ou seja, aplicar a rotação ao quadro mundial (X,Y,Z) os alinharia com as coordenadas do telefone (x,y,z).
A rotação pode ser vista como girar o telefone por um ângulo teta em torno de um eixo rot_axis para ir da orientação do dispositivo de referência (alinhado leste-norte para cima) para a orientação do dispositivo atual. A rotação é codificada como os quatro componentes x, y, z, w sem unidade de um quatérnion unitário:
-
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)
Onde:
- Os campos x, y e z de
rot_axissão as coordenadas Leste-Norte-Up de um vetor de comprimento unitário que representa o eixo de rotação -
thetaé o ângulo de rotação
O quaternion é um quaternion unitário: deve ser de norma 1 . A falha em garantir isso causará um comportamento errático do cliente.
Além disso, este sensor informa uma precisão de rumo estimada:
sensors_event_t.data[4] = estimated_accuracy (em radianos)
O erro de direção deve ser menor que a estimated_accuracy em 95% das vezes. Este sensor deve usar um giroscópio como a principal entrada de mudança de orientação.
Este sensor também usa a entrada do acelerômetro e do magnetômetro para compensar o desvio do giroscópio, e não pode ser implementado usando apenas o acelerômetro e o magnetômetro.
Vetor de rotação do jogo
Sensores físicos subjacentes: Acelerômetro e giroscópio (sem magnetômetro)
Modo de relatório: Contínuo
getDefaultSensor(SENSOR_TYPE_GAME_ROTATION_VECTOR) retorna um sensor que não desperta
Um sensor de vetor de rotação de jogo é semelhante a um sensor de vetor de rotação, mas não usa o campo geomagnético. Portanto, o eixo Y não aponta para o norte, mas sim para alguma outra referência. Essa referência pode flutuar na mesma ordem de magnitude que o giroscópio flutua em torno do eixo Z.
Consulte o sensor de vetor de rotação para obter detalhes sobre como definir sensors_event_t.data[0-3] . Este sensor não informa uma precisão de rumo estimada: sensors_event_t.data[4] é reservado e deve ser definido como 0 .
Em um caso ideal, um telefone girado e retornado à mesma orientação do mundo real deve relatar o mesmo vetor de rotação do jogo.
Este sensor deve ser baseado em um giroscópio e um acelerômetro. Não pode usar magnetômetro como entrada, além de, indiretamente, através da estimativa do viés do giroscópio.
Gravidade
Sensores físicos subjacentes: Acelerômetro e (se houver) giroscópio (ou magnetômetro se o giroscópio não estiver presente)
Modo de relatório: Contínuo
getDefaultSensor(SENSOR_TYPE_GRAVITY) retorna um sensor que não desperta
Um sensor de gravidade informa a direção e a magnitude da gravidade nas coordenadas do dispositivo.
Os componentes do vetor de gravidade são relatados em m/s^2 nos campos x, yez de sensors_event_t.acceleration .
Quando o dispositivo está em repouso, a saída do sensor de gravidade deve ser idêntica à do acelerômetro. Na Terra, a magnitude é de cerca de 9,8 m/s^2.
Caso o dispositivo possua um giroscópio, o sensor de gravidade deve utilizar o giroscópio e o acelerômetro como entrada.
Caso o aparelho não possua giroscópio, o sensor de gravidade deve utilizar o acelerômetro e o magnetômetro como entrada.
Vetor de rotação geomagnética
Sensores físicos subjacentes: Acelerômetro e magnetômetro (sem giroscópio)
Modo de relatório: Contínuo
Baixa potência
getDefaultSensor(SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR) retorna um sensor que não desperta
Um vetor de rotação geomagnético é semelhante a um sensor de vetor de rotação, mas usando um magnetômetro e nenhum giroscópio.
Este sensor deve ser baseado em um magnetômetro. Ele não pode ser implementado usando um giroscópio e a entrada do giroscópio não pode ser usada por este sensor.
Consulte o sensor de vetor de rotação para obter detalhes sobre como definir sensors_event_t.data[0-4] .
Assim como para o sensor de vetor de rotação, o erro de rumo deve ser menor que a precisão estimada ( sensors_event_t.data[4] ) 95% das vezes.
Este sensor deve ser de baixa potência, por isso deve ser implementado em hardware.
Orientação (obsoleto)
Sensores físicos subjacentes: Acelerômetro, magnetômetro e (se houver) giroscópio
Modo de relatório: Contínuo
getDefaultSensor(SENSOR_TYPE_ORIENTATION) retorna um sensor que não desperta
Observação: este é um tipo de sensor mais antigo que foi preterido no Android SDK. Ele foi substituído pelo sensor de vetor de rotação, que é mais claramente definido. Use o sensor de vetor de rotação sobre o sensor de orientação sempre que possível.
Um sensor de orientação informa a atitude do dispositivo. As medições são relatadas em graus nos campos x, yez de sensors_event_t.orientation :
-
sensors_event_t.orientation.x: azimute, o ângulo entre a direção do norte magnético e o eixo Y, em torno do eixo Z (0<=azimuth<360). 0=Norte, 90=Leste, 180=Sul, 270=Oeste. -
sensors_event_t.orientation.y: pitch, rotação em torno do eixo X (-180<=pitch<=180), com valores positivos quando o eixo Z se move em direção ao eixo Y. -
sensors_event_t.orientation.z: roll, rotação em torno do eixo Y (-90<=roll<=90), com valores positivos quando o eixo X se move em direção ao eixo Z.
Observe que, por razões históricas, o ângulo de rotação é positivo no sentido horário. (Matematicamente falando, deve ser positivo no sentido anti-horário):
Figura 3. Orientação relativa a um dispositivo
Esta definição é diferente de guinada, inclinação e rotação usadas na aviação, onde o eixo X está ao longo do lado longo do avião (cauda ao nariz).
O sensor de orientação também informa a precisão que espera que suas leituras sejam por meio de sensors_event_t.orientation.status . Consulte as constantes SensorManager SENSOR_STATUS_* do SensorManager para obter mais informações sobre os valores possíveis para este campo.
Sensores não calibrados
Sensores não calibrados fornecem mais resultados brutos e podem incluir algum viés, mas também contêm menos "saltos" de correções aplicadas por meio da calibração. Alguns aplicativos podem preferir esses resultados não calibrados como mais suaves e confiáveis. Por exemplo, se um aplicativo está tentando realizar sua própria fusão de sensores, a introdução de calibrações pode realmente distorcer os resultados.
Acelerômetro não calibrado
Sensor físico subjacente: Acelerômetro
Modo de relatório: Contínuo
getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_UNCALIBRATED) retorna um sensor que não desperta
Um sensor de acelerômetro não calibrado relata a aceleração do dispositivo ao longo dos três eixos do sensor sem nenhuma correção de polarização (a polarização de fábrica e a compensação de temperatura são aplicadas a medições não calibradas), juntamente com uma estimativa de polarização. Todos os valores estão em unidades SI (m/s^2) e são relatados nos campos de sensors_event_t.uncalibrated_accelerometer :
-
x_uncalib: aceleração (sem compensação de polarização) ao longo do eixo X -
y_uncalib: aceleração (sem compensação de polarização) ao longo do eixo Y -
z_uncalib: aceleração (sem compensação de polarização) ao longo do eixo Z -
x_bias: viés estimado ao longo do eixo X -
y_bias: viés estimado ao longo do eixo Y -
z_bias: viés estimado ao longo do eixo Z
Giroscópio não calibrado
Sensor físico subjacente: Giroscópio
Modo de relatório: Contínuo
getDefaultSensor(SENSOR_TYPE_GYROSCOPE_UNCALIBRATED) retorna um sensor que não desperta
Um giroscópio não calibrado relata a taxa de rotação em torno dos eixos do sensor sem aplicar compensação de polarização a eles, juntamente com uma estimativa de polarização. Todos os valores estão em radianos/segundo e são relatados nos campos de sensors_event_t.uncalibrated_gyro :
-
x_uncalib: velocidade angular (sem compensação de desvio) em torno do eixo X -
y_uncalib: velocidade angular (sem compensação de desvio) em torno do eixo Y -
z_uncalib: velocidade angular (sem compensação de desvio) em torno do eixo Z -
x_bias: desvio estimado em torno do eixo X -
y_bias: desvio estimado em torno do eixo Y -
z_bias: desvio estimado em torno do eixo Z
Conceitualmente, a medição não calibrada é a soma da medição calibrada e a estimativa de viés: _uncalibrated = _calibrated + _bias .
Espera-se que os valores de x_bias , y_bias e z_bias saltem assim que a estimativa do viés mudar e devem permanecer estáveis no resto do tempo.
Consulte a definição do sensor do giroscópio para obter detalhes sobre o sistema de coordenadas usado.
A calibração de fábrica e a compensação de temperatura devem ser aplicadas às medições. Além disso, a estimativa de desvio do giroscópio deve ser implementada para que estimativas razoáveis possam ser relatadas em x_bias , y_bias e z_bias . Se a implementação não for capaz de estimar o desvio, então este sensor não deve ser implementado.
Se este sensor estiver presente, então o sensor de giroscópio correspondente também deve estar presente e ambos os sensores devem compartilhar os mesmos valores de sensor_t.name e sensor_t.vendor .
Campo magnético não calibrado
Sensor físico subjacente: Magnetômetro
Modo de relatório: Contínuo
getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED) retorna um sensor que não desperta
Um sensor de campo magnético não calibrado informa o campo magnético ambiente junto com uma estimativa de calibração de ferro duro. Todos os valores estão em micro-Tesla (uT) e são relatados nos campos de sensors_event_t.uncalibrated_magnetic :
-
x_uncalib: campo magnético (sem compensação de ferro duro) ao longo do eixo X -
y_uncalib: campo magnético (sem compensação de ferro duro) ao longo do eixo Y -
z_uncalib: campo magnético (sem compensação de ferro duro) ao longo do eixo Z -
x_bias: viés estimado de ferro duro ao longo do eixo X -
y_bias: viés estimado de ferro duro ao longo do eixo Y -
z_bias: viés estimado de ferro duro ao longo do eixo Z
Conceitualmente, a medição não calibrada é a soma da medição calibrada e a estimativa de viés: _uncalibrated = _calibrated + _bias .
O magnetômetro não calibrado permite que algoritmos de nível superior lidem com estimativas ruins de ferro duro. Espera-se que os valores de x_bias , y_bias e z_bias saltem assim que a estimativa do hard-iron mudar, e devem permanecer estáveis o resto do tempo.
Calibração de ferro macio e compensação de temperatura devem ser aplicadas às medições. Além disso, a estimativa hard-iron deve ser implementada para que estimativas razoáveis possam ser relatadas em x_bias , y_bias e z_bias . Se a implementação não for capaz de estimar o viés, esse sensor não deve ser implementado.
Se este sensor estiver presente, então o sensor de campo magnético correspondente deve estar presente e ambos os sensores devem compartilhar os mesmos valores de sensor_t.name e sensor_t.vendor .
Ângulo de dobradiça
Modo de relatório: em mudança
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) retorna um sensor de ativação
Um sensor de ângulo de dobradiça mede o ângulo, em graus, entre duas partes integrantes do dispositivo. Espera-se que o movimento de uma dobradiça medido por esse tipo de sensor altere as maneiras pelas quais o usuário pode interagir com o dispositivo, por exemplo, desdobrando ou revelando uma tela.
Sensores compostos de interação
Alguns sensores são usados principalmente para detectar interações com o usuário. We don't define how those sensors must be implemented, but they must be low power and it's the responsibility of the device manufacturer to verify their quality in terms of user experience.
Wake up gesture
Underlying physical sensors: Undefined (anything low power)
Reporting-mode: One-shot
Low-power
Implement only the wake-up version of this sensor.
getDefaultSensor(SENSOR_TYPE_WAKE_GESTURE) returns a wake-up sensor
A wake up gesture sensor enables waking up the device based on a device specific motion. When this sensor triggers, the device behaves as if the power button was pressed, turning the screen on. This behavior (turning on the screen when this sensor triggers) might be deactivated by the user in the device settings. Changes in settings don't impact the behavior of the sensor: only whether the framework turns the screen on when it triggers. The actual gesture to be detected isn't specified, and can be chosen by the manufacturer of the device.
This sensor must be low power, as it's likely to be activated 24/7.
Each sensor event reports 1 in sensors_event_t.data[0] .
Pick up gesture
Underlying physical sensors: Undefined (anything low power)
Reporting-mode: One-shot
Low-power
Implement only the wake-up version of this sensor.
getDefaultSensor(SENSOR_TYPE_PICK_UP_GESTURE) returns a wake-up sensor
A pick-up gesture sensor triggers when the device is picked up regardless of wherever it was before (desk, pocket, bag).
Each sensor event reports 1 in sensors_event_t.data[0] .
Glance gesture
Underlying physical sensors: Undefined (anything low power)
Reporting-mode: One-shot
Low-power
Implement only the wake-up version of this sensor.
getDefaultSensor(SENSOR_TYPE_GLANCE_GESTURE) returns a wake-up sensor
A glance gesture sensor enables briefly turning the screen on to enable the user to glance content on screen based on a specific motion. When this sensor triggers, the device will turn the screen on momentarily to allow the user to glance notifications or other content while the device remains locked in a non-interactive state (dozing), then the screen will turn off again. This behavior (briefly turning on the screen when this sensor triggers) might be deactivated by the user in the device settings. Changes in settings do not impact the behavior of the sensor: only whether the framework briefly turns the screen on when it triggers. The actual gesture to be detected isn't specified, and can be chosen by the manufacturer of the device.
This sensor must be low power, as it's likely to be activated 24/7. Each sensor event reports 1 in sensors_event_t.data[0] .