Tipos de sensores

Esta seção descreve eixos de sensores, sensores básicos e sensores compostos (atividade, atitude, não calibrado e interação).

Eixos do sensor

Os valores de eventos de muitos sensores são expressos em um frame específico que é estático em relação ao dispositivo.

Eixos de dispositivos móveis

A API 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 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 sistema de referência do veículo é o centro do eixo traseiro. O sistema de referência do veículo é orientado para 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 Sensor.

O sistema de referência do veículo é um sistema de coordenadas dextro. Portanto, o eixo Z aponta para cima.

O eixo Z do sistema de referência é alinhado à gravidade, o que significa que os eixos X e Y são horizontais. Como resultado, o eixo Y nem sempre passa pelo eixo dianteiro.

Sensores da base

Os tipos de sensores básicos recebem o nome dos sensores físicos que representam. Esses sensores transmitem dados de um único sensor físico, e não de sensores compostos que geram dados de outros sensores. Exemplos de tipos de sensores básicos:

• 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 correções (como compensação de viés e de temperatura) são aplicadas.

Por exemplo, as características de um sensor básico podem ser diferentes das características do sensor físico subjacente nos seguintes casos de uso:

• Um chip de giroscópio classificado como tendo um intervalo de viés de 1 grau/seg.
  • Após a calibragem de fábrica, a compensação de temperatura e de viés são aplicadas.O viés real do sensor Android será reduzido, talvez a um ponto em que o viés seja garantido como inferior a 0, 01 grau/segundo.
  • Nesse caso, dizemos que o sensor do Android tem um viés abaixo de 0,01 grau/segundo, mesmo que a ficha de dados do sensor subjacente diga 1 grau/segundo.
• 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 barômetro do Android pode ser muito maior, por exemplo, 1.000 uW.
  • Nessa situação, dizemos que o sensor Android tem um consumo de energia de 1.000 uW, mesmo que o consumo de energia medido nos fios do chip do barômetro seja de 100 uW.
• Um magnetômetro que consome 100 uW quando calibrado, mas consome mais durante a calibragem.
  • A rotina de calibragem pode exigir a ativação do giroscópio, consumindo 5.000 uW, e a execução de um algoritmo, custando mais 900 uW.
  • Nessa situação, dizemos que o consumo máximo de energia do sensor Android (magnetômetro) é de 6.000 uW.
  • Nesse caso, o consumo médio de energia é a medida mais útil, e é o que é informado nas características estáticas do sensor pelo HAL.

Acelerômetro

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER) retorna um sensor que não ativa o dispositivo

Um sensor de acelerômetro informa a aceleração do dispositivo ao longo dos três eixos do sensor. A aceleração medida inclui a aceleração física (mudança de velocidade) e a gravidade. A medição é informada nos campos x, y e z de sensors_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.

Confira alguns exemplos:

• A norma de (x, y, z) precisa ser próxima de 0 em queda livre.
• Quando o dispositivo está sobre uma mesa e é empurrado do lado esquerdo para a direita, o valor da aceleração x é positivo.
• Quando o dispositivo está 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á sobre uma mesa e é empurrado para cima, o valor da aceleração é maior que +9,81, o que corresponde à aceleração do dispositivo (+A m/s²) menos a força da gravidade (-9,81 m/s²).

As leituras são calibradas usando:

• Compensação de temperatura
• Calibragem de viés on-line
• Calibragem on-line da balança

A calibragem de viés e escala só pode ser atualizada quando o sensor está desativado para evitar variações nos valores durante o streaming.

O acelerômetro também informa a precisão esperada das leituras usando sensors_event_t.acceleration.status. Consulte as constantes SENSOR_STATUS_* de SensorManager para mais informações sobre os valores possíveis desse campo.

Temperatura ambiente

Reporting-mode: On-change

getDefaultSensor(SENSOR_TYPE_AMBIENT_TEMPERATURE) retorna um sensor que não ativa o dispositivo

Esse sensor fornece a temperatura ambiente (do 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 ativa o dispositivo

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, medido ao longo dos três eixos do sensor.

A medição é informada nos campos x, y e z de sensors_event_t.magnetic, e todos os valores estão em microtesla (uT).

O magnetômetro também informa a precisão esperada das leituras usando sensors_event_t.magnetic.status. Consulte as constantes SENSOR_STATUS_* do SensorManager para mais informações sobre os valores possíveis desse campo.

As leituras são calibradas usando:

• Compensação de temperatura
• Calibragem de ferro doce de fábrica (ou on-line)
• Calibragem on-line de ferro duro

Giroscópio

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_GYROSCOPE) retorna um sensor que não ativa o dispositivo

Um sensor 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 para um dispositivo posicionado na origem vai informar uma rotação positiva se o dispositivo parecer estar girando no sentido anti-horário. Essa é a definição matemática padrão de rotação positiva e não concorda com a definição aeroespacial de rotação.

A medição é informada nos campos x, y e z 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 escala de fábrica (ou on-line)
• Calibragem de viés on-line (para remover a deriva)

O giroscópio também informa a precisão esperada das leituras usando sensors_event_t.gyro.status. Consulte as constantes SENSOR_STATUS_* de SensorManager para mais informações sobre os valores possíveis desse campo.

O giroscópio não pode ser emulado com base em magnetômetros e acelerômetros, porque isso reduziria a consistência e a capacidade de resposta locais. Ele precisa ser baseado em um chip giroscópio comum.

Frequência cardíaca

Reporting-mode: On-change

getDefaultSensor(SENSOR_TYPE_HEART_RATE) retorna um sensor que não ativa o dispositivo

Um sensor de frequência cardíaca informa a frequência cardíaca atual da pessoa que está tocando 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 é informado em sensors_event_t.heart_rate.status. Consulte as constantes SENSOR_STATUS_* de SensorManager para mais informações sobre os valores possíveis desse 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 precisa ser definido como SENSOR_STATUS_UNRELIABLE. Como esse sensor é "on-change", os eventos são gerados quando e somente quando heart_rate.bpm ou heart_rate.status mudaram desde o último evento. Os eventos são gerados no máximo a cada sampling_period.

O framework substitui automaticamente sensor_t.requiredPermission pela permissão adequada para manter a compatibilidade. O framework usa a permissão SENSOR_PERMISSION_READ_HEART_RATE para Android 16 e versões mais recentes, e a permissão SENSOR_PERMISSION_BODY_SENSORS para Android 15 e versões anteriores.

Claro

Reporting-mode: On-change

getDefaultSensor(SENSOR_TYPE_LIGHT) retorna um sensor que não ativa o dispositivo

Um sensor de luz informa a iluminação atual em unidades lux do SI.

A medição é informada em sensors_event_t.light.

Proximidade

Reporting-mode: On-change

Geralmente definido como um sensor de despertar

getDefaultSensor(SENSOR_TYPE_PROXIMITY) retorna um sensor de despertar

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 sempre foram sensores de despertar, ativando o SoC ao detectar uma mudança na proximidade. Depois do Android 4.4, recomendamos implementar primeiro a versão de despertar desse sensor, já que é ela que é usada para ligar e desligar a tela durante as ligações.

A medição é informada em centímetros em sensors_event_t.distance. Alguns sensores de proximidade só oferecem suporte a uma medição binária "perto" ou "longe". Nesse caso, o sensor informa o 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 ativa o dispositivo

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
• Calibragem de viés de fábrica
• Calibragem em escala de fábrica

O barômetro é usado com frequência para estimar mudanças de elevação. Para estimar a elevação absoluta, a pressão ao nível do mar (que muda dependendo do clima) precisa ser usada como referência.

Umidade relativa

Reporting-mode: On-change

getDefaultSensor(SENSOR_TYPE_RELATIVE_HUMIDITY) retorna um sensor que não ativa o dispositivo

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 combinando 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:

• Detector de passos e movimento significativo, que geralmente são baseados em um acelerômetro, mas podem ser baseados em outros sensores também, se o consumo de energia e a precisão forem aceitáveis.
• Vetor de rotação do jogo, com base em um acelerômetro e um giroscópio.
• Giroscópio não calibrado, que é semelhante ao sensor de base do giroscópio, mas com a calibragem de tendência informada 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 dos dados finais. Por exemplo, o consumo de energia de um vetor de rotação de 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 barramentos que transportam os dados. Como outro exemplo, o desvio de um vetor de rotação de um jogo depende tanto da qualidade do algoritmo de calibragem 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 para aproximar os resultados, porque eles oferecem uma experiência ruim para o usuário.

Tipo de sensor	Categoria	Sensores físicos subjacentes	Modo de geração de relatórios
Vetor de rotação do jogo	Atitude	Acelerômetro, giroscópio, NÃO USE magnetômetro	Contínuo
Vetor de rotação geomagnética	Atitude	Acelerômetro, magnetômetro, NÃO USE giroscópio	Contínuo
Gesto de olhar rápido	Interação	Indefinido	One-shot
Gravidade	Atitude	Acelerômetro, giroscópio (se presente) ou magnetômetro (se o giroscópio não estiver presente)	Contínuo
Giroscópio não calibrado	Não calibrado	Giroscópio	Contínuo
Aceleração linear	Atividade	Acelerômetro, giroscópio (se presente) ou magnetômetro (se o giroscópio não estiver presente)	Contínuo
Campo magnético não calibrado	Não calibrado	Magnetômetro	Contínuo
Orientação (descontinuada)	Atitude	Acelerômetro, magnetômetro, giroscópio (se houver)	Contínuo
Gesto de pegar	Interação	Indefinido	One-shot
Vetor de rotação	Atitude	Acelerômetro, magnetômetro, giroscópio (se houver)	Contínuo
Movimento significativo	Atividade	Acelerômetro (ou outro, desde que seja de consumo muito baixo)	One-shot
Contador de passos	Atividade	Acelerômetro	Ao mudar
Detector de passos	Atividade	Acelerômetro	Especial
Detector de inclinação	Atividade	Acelerômetro	Especial
Gesto para ativar	Interação	Indefinido	One-shot

= Sensor de baixa potência

Sensores compostos de atividade

Aceleração linear

Sensores físicos subjacentes: acelerômetro e (se presente) giroscópio (ou magnetômetro se o giroscópio não estiver presente)

Modo de geração de relatórios: Contínuo

getDefaultSensor(SENSOR_TYPE_LINEAR_ACCELERATION) retorna um sensor que não ativa o dispositivo

Um sensor de aceleração linear informa a aceleração linear do dispositivo no frame do sensor, sem incluir a gravidade.

A saída é conceitualmente: saída do acelerômetro menos a saída do sensor de gravidade. Ele é informado em m/s^2 nos campos x, y e z de sensors_event_t.acceleration.

As leituras em todos os eixos devem estar próximas de 0 quando o dispositivo está imóvel.

Se o dispositivo tiver um giroscópio, o sensor de aceleração linear precisará usar o giroscópio e o acelerômetro como entrada.

Se o dispositivo não tiver um giroscópio, o sensor de aceleração linear precisará usar o acelerômetro e o magnetômetro como entrada.

Movimento significativo

Sensor físico subjacente: acelerômetro (ou outro, desde que seja de baixo consumo de energia)

Modo de relatório: One-shot

Baixa potência

Implemente apenas a versão de ativação desse sensor.

getDefaultSensor(SENSOR_TYPE_SIGNIFICANT_MOTION) retorna um sensor de despertar

Um detector de movimento significativo é acionado ao detectar um movimento significativo, ou seja, um movimento que pode levar a uma mudança no local do usuário.

Exemplos de movimentos significativos:

• Caminhada ou bicicleta
• Sitting in a moving car, coach, or train

Exemplos de situações que não acionam movimentos significativos:

• O smartphone está no bolso e a pessoa não está se movendo
• O smartphone está em uma mesa que treme um pouco devido ao trânsito ou à máquina de lavar por perto.

Em um nível alto, o detector de movimento significativo é usado para reduzir o consumo de energia da determinação de local. Quando os algoritmos de localização detectam que o dispositivo está parado, eles podem mudar para um modo de baixo consumo de energia, em que dependem de movimentos significativos para ativar o dispositivo quando o usuário está mudando de local.

Esse sensor precisa ser de baixa potência. Ele faz uma troca para o consumo de energia que pode resultar em uma pequena quantidade de falsos negativos. Isso é feito por alguns motivos:

• O objetivo desse sensor é economizar energia.
• Acionar um evento quando o usuário não está se movendo (falso positivo) é caro em termos de energia, então isso deve ser evitado.
• Não acionar um evento quando o usuário está se movendo (falso negativo) é aceitável, desde que não seja feito repetidamente. Se o usuário estiver caminhando há 10 segundos, não acionar um evento nesse período não é aceitável.

Cada evento de sensor informa 1 em sensors_event_t.data[0].

Detector de passos

Sensor físico subjacente: acelerômetro (e possivelmente outros, desde que de 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 ativa o dispositivo

Um detector de passos gera um evento sempre que o usuário dá um passo.

O carimbo de data/hora do evento sensors_event_t.timestamp corresponde ao momento em que o pé tocou o chão, gerando uma alta variação na aceleração.

Em comparação com o contador de passos, o detector de passos tem uma latência menor (menos de dois segundos). O detector e o contador de passos detectam quando o usuário está caminhando, correndo e subindo escadas. Eles não devem ser acionados quando o usuário estiver andando de bicicleta, dirigindo ou em outros veículos.

Esse sensor precisa ser de baixa potência. Ou seja, se a detecção de passos não puder ser feita no hardware, esse 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 (não todas as leituras do acelerômetro).

sampling_period_ns não tem impacto nos detectores de passos.

Cada evento de sensor informa 1 em sensors_event_t.data[0].

Contador de passos

Sensor físico subjacente: acelerômetro (e possivelmente outros, desde que de baixa potência)

Reporting-mode: On-change

Baixo consumo de energia

getDefaultSensor(SENSOR_TYPE_STEP_COUNTER) retorna um sensor que não ativa o dispositivo

Um contador de passos informa o número de passos dados pelo usuário desde a última reinicialização enquanto ativado.

A medição é informada como um uint64_t em sensors_event_t.step_counter e é redefinida para zero apenas em uma reinicialização do sistema.

O carimbo de data/hora do evento é definido como o momento em que a última etapa foi realizada.

Consulte o tipo de sensor Detector de passos para saber o significado do tempo de uma etapa.

Em comparação com o detector de passos, o contador de passos pode ter uma latência maior (até 10 segundos). Graças a essa latência, o sensor tem alta acurácia. A contagem de passos após um dia inteiro de medições deve estar dentro de 10% da contagem real. O detector e o contador de passos detectam quando o usuário está caminhando, correndo e subindo escadas. Eles não devem ser acionados quando o usuário estiver andando de bicicleta, dirigindo ou em outros veículos.

O hardware precisa garantir que a contagem interna de passos nunca transborde. O tamanho mínimo do contador interno do hardware precisa 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 driver faça a manutenção do contador.

Conforme declarado em Interação, enquanto esse sensor estiver em operação, ele não poderá interromper nenhum outro sensor, em especial, o acelerômetro, que pode estar em uso.

Se um dispositivo específico não for compatível com esses modos de operação, o HAL não poderá informar esse tipo de sensor. Ou seja, não é aceitável "emular" esse sensor na HAL.

Esse sensor precisa ser de baixa potência. Ou seja, se a detecção de passos não puder ser feita no hardware, esse sensor não deve ser definido. Em particular, quando o contador de passos está ativado e o acelerômetro não está, apenas os passos devem acionar interrupções (não os dados do acelerômetro).

Detector de inclinação

Sensor físico subjacente: acelerômetro (e possivelmente outros, desde que de baixa potência)

Modo de relatório: Especial

Baixo consumo de energia

Implemente apenas a versão de ativação desse sensor.

getDefaultSensor(SENSOR_TYPE_TILT_DETECTOR) retorna um sensor de despertar

Um detector de inclinação gera um evento sempre que um evento de inclinação é detectado.

Um evento de inclinação é definido pela direção da mudança de gravidade média da janela de dois segundos em pelo menos 35 graus desde a ativação ou o último evento gerado pelo sensor. Confira 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 dois segundos.
• Acionar quando angle(reference_estimated_gravity, current_estimated_gravity) > 35 degrees

Grandes acelerações sem uma mudança na orientação do smartphone não devem acionar um evento de inclinação. Por exemplo, uma curva acentuada ou uma aceleração forte ao dirigir um carro não deve acionar um evento de inclinação, mesmo que o ângulo da aceleração média varie 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. Esse é um sensor de baixa potência que permite que o SoC entre no modo de suspensão. Não emule esse sensor na HAL. Cada evento de sensor informa 1 em sensors_event_t.data[0].

Sensores compostos de atitude

Vetor de rotação

Sensores físicos: acelerômetro, magnetômetro e giroscópio

Modo de geração de relatórios: Contínuo

getDefaultSensor(SENSOR_TYPE_ROTATION_VECTOR) retorna um sensor que não é de despertar

Um sensor de vetor de rotação informa a orientação do dispositivo em relação ao frame de coordenadas leste-norte-acima. Normalmente, ele é obtido pela integração de leituras do acelerômetro, giroscópio e magnetômetro. O sistema de coordenadas leste-norte-acima é definido como uma base ortonormal direta em que:

• X aponta para leste e é tangente ao chão.
• Y aponta para o norte e é tangente ao chão.
• Z aponta para o céu e é perpendicular ao chão.

A orientação do smartphone é representada pela rotação necessária para alinhar as coordenadas leste-norte-para cima com as coordenadas do smartphone. Ou seja, aplicar a rotação ao frame mundial (X,Y,Z) os alinhariam com as coordenadas do smartphone (x,y,z).

A rotação pode ser vista como a rotação do smartphone por um ângulo theta em torno de um eixo rot_axis para ir da orientação do dispositivo de referência (alinhada a leste-norte-para cima) à orientação atual. A rotação é codificada como os quatro componentes x, y, z, w sem unidade de um quaternário 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)

Em que:

• Os campos x, y e z de rot_axis são as coordenadas leste-norte-acima de um vetor de comprimento unitário que representa o eixo de rotação.
• theta é o ângulo de rotação

O quaternion é uma unidade: ele precisa ser de norma 1. Se isso não for feito, o comportamento do cliente será instável.

Além disso, esse sensor informa uma precisão estimada do rumo:

sensors_event_t.data[4] = estimated_accuracy (em radianos)

O erro de cabeçalho precisa ser menor que estimated_accuracy 95% do tempo. Esse sensor precisa usar um giroscópio como a principal entrada de mudança de orientação.

Esse sensor também usa entradas 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 geração de relatórios: Contínuo

getDefaultSensor(SENSOR_TYPE_GAME_ROTATION_VECTOR) retorna um sensor que não ativa o dispositivo

Um sensor de vetor de rotação de jogos é 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 para alguma outra referência. Essa referência pode variar na mesma ordem de magnitude que o giroscópio varia em torno do eixo Z.

Consulte o sensor Vetor de rotação para saber como definir sensors_event_t.data[0-3]. Esse sensor não informa uma precisão estimada do rumo: sensors_event_t.data[4] é reservado e precisa ser definido como 0.

Em um caso ideal, um smartphone girado e retornado à mesma orientação no mundo real deve informar o mesmo vetor de rotação do jogo.

Esse sensor precisa ser baseado em um giroscópio e um acelerômetro. Ele não pode usar o magnetômetro como entrada, além de indiretamente, por meio da estimativa do viés do giroscópio.

Gravidade

Sensores físicos subjacentes: acelerômetro e (se presente) giroscópio (ou magnetômetro se o giroscópio não estiver presente)

Modo de geração de relatórios: Contínuo

getDefaultSensor(SENSOR_TYPE_GRAVITY) retorna um sensor que não ativa o dispositivo

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 informados em m/s^2 nos campos x, y e z de sensors_event_t.acceleration.

Quando o dispositivo está em repouso, a saída do sensor de gravidade precisa ser idêntica à do acelerômetro. Na Terra, a magnitude é de cerca de 9,8 m/s².

Se o dispositivo tiver um giroscópio, o sensor de gravidade precisará usar o giroscópio e o acelerômetro como entrada.

Se o dispositivo não tiver um giroscópio, o sensor de gravidade precisará usar 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 geração de relatórios: Contínuo

Baixo consumo de energia

getDefaultSensor(SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR) retorna um sensor que não ativa o dispositivo

Um vetor de rotação geomagnética é semelhante a um sensor de vetor de rotação, mas usa um magnetômetro e não um giroscópio.

Esse sensor precisa 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 esse sensor.

Consulte o sensor Vetor de rotação para saber como definir sensors_event_t.data[0-4].

Assim como no sensor de vetor de rotação, o erro de orientação precisa ser menor que a acurácia estimada (sensors_event_t.data[4]) em 95% do tempo.

Esse sensor precisa ser de baixa potência, então precisa ser implementado em hardware.

Orientação (descontinuada)

Sensores físicos: acelerômetro, magnetômetro e giroscópio (se houver)

Modo de geração de relatórios: Contínuo

getDefaultSensor(SENSOR_TYPE_ORIENTATION) retorna um sensor que não ativa o dispositivo

Observação:esse é um tipo de sensor mais antigo que foi descontinuado no SDK do Android. Ele foi substituído pelo sensor de vetor de rotação, que é mais claramente definido. Use o sensor de vetor de rotação em vez do sensor de orientação sempre que possível.

Um sensor de orientação informa a atitude do dispositivo. As medições são informadas em graus nos campos x, y e z 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: inclinação, 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: rotação, 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.

Por motivos históricos, o ângulo de rotação é positivo no sentido horário. Matematicamente falando, ele precisa ser positivo no sentido anti-horário:

Essa definição é diferente de rotação, inclinação e rolagem usadas na aviação, em que o eixo X fica ao longo do lado comprido da aeronave (da cauda ao nariz).

O sensor de orientação também informa a precisão esperada das leituras usando sensors_event_t.orientation.status. Consulte as constantes SensorManager’s SENSOR_STATUS_* para mais informações sobre os valores possíveis para esse campo.

Sensores não calibrados

Os sensores não calibrados fornecem resultados mais brutos e podem incluir algum viés, mas também contêm menos "saltos" das correções aplicadas pela calibragem. Alguns apps podem preferir esses resultados não calibrados por serem mais suaves e confiáveis. Por exemplo, se um app estiver tentando realizar a própria fusão de sensores, a introdução de calibragens poderá 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 ativa o dispositivo

Um sensor de acelerômetro não calibrado informa a aceleração do dispositivo ao longo dos três eixos do sensor sem correção de viés (o viés de fábrica e a compensação de temperatura são aplicados a medições não calibradas), além de uma estimativa de viés. Todos os valores estão em unidades SI (m/s^2) e são informados nos campos de sensors_event_t.uncalibrated_accelerometer:

• x_uncalib: aceleração (sem compensação de viés) ao longo do eixo X
• y_uncalib: aceleração (sem compensação de viés) ao longo do eixo Y.
• z_uncalib: aceleração (sem compensação de viés) 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 geração de relatórios: Contínuo

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_UNCALIBRATED) retorna um sensor que não ativa o dispositivo

Um giroscópio não calibrado informa a taxa de rotação em torno dos eixos do sensor sem aplicar compensação de viés a eles, além de uma estimativa de viés. Todos os valores estão em radianos/segundo e são informados 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) ao redor do eixo Z.
• x_bias: deriva estimada ao redor do eixo X
• y_bias: deriva estimada em torno do eixo Y
• z_bias: deriva estimada em torno do eixo Z.

Conceitualmente, a medição não calibrada é a soma da medição calibrada e da estimativa de viés: _uncalibrated = _calibrated + _bias.

Espera-se que os valores x_bias, y_bias e z_bias aumentem assim que a estimativa do viés mudar e permaneçam estáveis no restante do tempo.

Consulte a definição do sensor de giroscópio para detalhes sobre o sistema de coordenadas usado.

A calibragem de fábrica e a compensação de temperatura precisam ser aplicadas às medições. Além disso, a estimativa de deriva do giroscópio precisa ser implementada para que estimativas razoáveis possam ser informadas em x_bias, y_bias e z_bias. Se a implementação não conseguir estimar o drift, esse sensor não poderá ser implementado.

Se esse sensor estiver presente, o sensor de giroscópio correspondente também precisará estar presente, e ambos precisarão 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 geração de relatórios: Contínuo

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED) retorna um sensor que não ativa o dispositivo

Um sensor de campo magnético não calibrado informa o campo magnético ambiente junto com uma estimativa de calibragem de ferro duro. Todos os valores estão em microtesla (uT) e são informados 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: estimativa do viés de ferro duro ao longo do eixo X
• y_bias: estimativa do viés de ferro duro ao longo do eixo Y
• z_bias: viés de ferro duro estimado ao longo do eixo Z

Conceitualmente, a medição não calibrada é a soma da medição calibrada e da estimativa de viés: _uncalibrated = _calibrated + _bias.

O magnetômetro não calibrado permite que algoritmos de nível superior processem estimativas ruins de ferro duro. Espera-se que os valores x_bias, y_bias e z_bias aumentem assim que a estimativa da mudança de magnetização permanente for alterada, e eles devem ficar estáveis no restante do tempo.

A calibragem de ferro macio e a compensação de temperatura precisam ser aplicadas às medições. Além disso, a estimativa de ferro duro precisa ser implementada para que estimativas razoáveis possam ser informadas em x_bias, y_bias e z_bias. Se a implementação não conseguir estimar o viés, esse sensor não poderá ser implementado.

Se esse sensor estiver presente, o sensor de campo magnético correspondente também precisará estar, e ambos precisarão compartilhar os mesmos valores de sensor_t.name e sensor_t.vendor.

Ângulo de articulação

Reporting-mode: On-change

getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) retorna um sensor de despertar

Um sensor de ângulo de dobradiça mede o ângulo, em graus, entre duas partes integrais do dispositivo. O movimento de uma dobradiça medido por esse tipo de sensor deve alterar as formas de interação do usuário 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. Não definimos como esses sensores precisam ser implementados, mas eles precisam ser de baixo consumo de energia. É responsabilidade do fabricante do dispositivo verificar a qualidade deles em termos de experiência do usuário.

Gesto de ativação

Sensores físicos subjacentes: indefinido (qualquer coisa de baixa potência)

Modo de relatório: One-shot

Baixo consumo de energia

Implemente apenas a versão de ativação desse sensor.

getDefaultSensor(SENSOR_TYPE_WAKE_GESTURE) retorna um sensor de despertar

Um sensor de gesto de despertar permite ativar o dispositivo com base em um movimento específico dele. Quando esse sensor é acionado, o dispositivo se comporta como se o botão liga/desliga tivesse sido pressionado, ligando a tela. Esse comportamento (ativar a tela quando esse sensor é acionado) pode ser desativado pelo usuário nas configurações do dispositivo. As mudanças nas configurações não afetam o comportamento do sensor, apenas se a estrutura ativa a tela quando é acionada. O gesto real a ser detectado não é especificado e pode ser escolhido pelo fabricante do dispositivo.

Esse sensor precisa ser de baixa potência, já que provavelmente será ativado 24 horas por dia, 7 dias por semana.

Cada evento de sensor informa 1 em sensors_event_t.data[0].

Gesto de pegar

Sensores físicos subjacentes: indefinido (qualquer coisa de baixa potência)

Modo de relatório: One-shot

Baixo consumo de energia

Implemente apenas a versão de ativação desse sensor.

getDefaultSensor(SENSOR_TYPE_PICK_UP_GESTURE) retorna um sensor de despertar

Um sensor de gesto de pegar é acionado quando o dispositivo é pego, não importa onde ele estava antes (mesa, bolso, bolsa).

Cada evento de sensor informa 1 em sensors_event_t.data[0].

Gesto de olhar

Sensores físicos subjacentes: indefinido (qualquer coisa de baixa potência)

Modo de relatório: One-shot

Baixo consumo de energia

Implemente apenas a versão de ativação desse sensor.

getDefaultSensor(SENSOR_TYPE_GLANCE_GESTURE) retorna um sensor de despertar

Um sensor de gesto de olhar permite ligar brevemente a tela para que o usuário possa ver o conteúdo na tela com base em um movimento específico. Quando esse sensor é acionado, o dispositivo liga a tela momentaneamente para permitir que o usuário veja notificações ou outros conteúdos enquanto o dispositivo permanece bloqueado em um estado não interativo (em espera). Depois, a tela é desligada novamente. Esse comportamento (ativar brevemente a tela quando esse sensor é acionado) pode ser desativado pelo usuário nas configurações do dispositivo. As mudanças nas configurações não afetam o comportamento do sensor, apenas se o framework liga brevemente a tela quando é acionado. O gesto real a ser detectado não é especificado e pode ser escolhido pelo fabricante do dispositivo.

Esse sensor precisa ser de baixa potência, já que provavelmente será ativado 24 horas por dia, 7 dias por semana. Cada evento de sensor informa 1 em sensors_event_t.data[0].

Sensores IMU de eixos limitados

Disponíveis no Android 13, os sensores IMU de eixos limitados são sensores que oferecem suporte a casos de uso em que nem todos os três eixos (x, y, z) estão disponíveis. Os tipos padrão de IMU no Android (como SENSOR_TYPE_ACCELEROMETER e SENSOR_TYPE_GYROSCOPE) pressupõem que todos os três eixos são compatíveis. No entanto, nem todos os formatos e dispositivos são compatíveis com acelerômetros e giroscópios de três eixos.

Eixos limitados do acelerômetro

Sensores físicos subjacentes: acelerômetro

Modo de geração de relatórios: Contínuo

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES) retorna um sensor que não ativa o dispositivo

Um sensor de acelerômetro com eixos limitados é equivalente a TYPE_ACCELEROMETER, mas oferece suporte a casos em que um ou dois eixos não são compatíveis.

Os três últimos valores de eventos do sensor informados por ele representam se o valor de aceleração para os eixos x, y e z é compatível. Um valor de 1.0 indica que o eixo é compatível, e um valor de 0 indica que não é. Os fabricantes de dispositivos identificam os eixos compatíveis no momento da criação, e os valores não mudam durante a execução.

Os fabricantes de dispositivos precisam definir os valores de aceleração para eixos não usados como 0, em vez de ter valores indefinidos.

Giroscópio com eixos limitados

Sensores físicos subjacentes: giroscópio

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES) retorna um sensor que não ativa o dispositivo

Um sensor de eixos limitados do giroscópio é equivalente a TYPE_GYROSCOPE, mas oferece suporte a casos em que um ou dois eixos não são compatíveis.

Os três últimos valores de eventos do sensor informados por ele representam se o valor da velocidade angular para os eixos x, y e z é compatível. Um valor de 1.0 indica que o eixo é compatível, e um valor de 0 indica que não é. Os fabricantes de dispositivos identificam os eixos compatíveis no momento da criação, e os valores não mudam durante a execução.

Os fabricantes de dispositivos precisam definir os valores de velocidade angular para eixos não utilizados como 0.

Acelerômetro com eixos limitados não calibrados

Sensores físicos subjacentes: acelerômetro

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED) retorna um sensor que não ativa o dispositivo

Um sensor de acelerômetro com eixos limitados e não calibrado é equivalente a TYPE_ACCELEROMETER_UNCALIBRATED, mas é compatível com casos em que um ou dois eixos não são aceitos.

Os três últimos valores de eventos do sensor informados por ele representam se os valores de aceleração e polarização para os eixos x, y e z são compatíveis. Um valor de 1.0 indica que o eixo é compatível, e um valor de 0 indica que não é. Os fabricantes de dispositivos identificam os eixos compatíveis no momento da criação, e os valores não mudam durante a execução.

Os fabricantes de dispositivos precisam definir os valores de aceleração e viés para eixos não utilizados como 0.

Giroscópio com eixos limitados não calibrados

Sensores físicos subjacentes: giroscópio

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED) retorna um sensor que não ativa o dispositivo

Um sensor de giroscópio não calibrado com eixos limitados é equivalente a TYPE_GYROSCOPE_UNCALIBRATED, mas é compatível com casos em que um ou dois eixos não são compatíveis.

Os três últimos valores de eventos do sensor informados representam se a velocidade angular e os valores de desvio para os eixos x, y e z são compatíveis. Um valor de 1.0 indica que o eixo é compatível, e um valor de 0 indica que não é. Os fabricantes de dispositivos identificam os eixos compatíveis no momento da criação, e os valores não mudam durante a execução.

Os fabricantes de dispositivos precisam definir a velocidade angular e os valores de deriva para eixos não utilizados como 0.

IMU de eixos limitados compostos

Sensores físicos subjacentes: qualquer combinação de acelerômetro de três eixos, giroscópio de três eixos, acelerômetro de três eixos não calibrado e giroscópio de três eixos não calibrado.

Modo de relatório: Contínuo

Um sensor IMU de eixos limitados composto é equivalente a um sensor IMU de eixos limitados, mas, em vez de ser compatível com a HAL, ele converte os dados do sensor de três eixos nas variantes equivalentes de eixos limitados. Esses sensores compostos são ativados apenas para dispositivos automotivos.

A tabela a seguir mostra um exemplo de conversão de um acelerômetro padrão de três eixos para um acelerômetro composto de eixos limitados.

Valores de SensorEvent para SENSOR_TYPE_ACCELEROMETER	Exemplo de SensorEvent SENSOR_TYPE_ACCELEROMETER	SensorEvent SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES composto
values[0]	-0,065	-0,065
values[1]	0,078	0,078
values[2]	9.808	9.808
values[3]	N/A	1.0
values[4]	N/A	1.0
values[5]	N/A	1.0

Sensores automotivos

Sensores para oferecer suporte a casos de uso automotivos.

Título

Sensores físicos subjacentes: qualquer combinação de GPS, magnetômetro, acelerômetro e giroscópio.

Modo de geração de relatórios: Contínuo

getDefaultSensor(SENSOR_TYPE_HEADING) retorna um sensor que não ativa o dispositivo

Disponível no Android 13, um sensor de orientação mede a direção em que o dispositivo está apontando em relação ao norte verdadeiro em graus. O sensor de direção inclui dois valores SensorEvent. Um para o título do dispositivo medido e outro para a precisão do valor de título fornecido.

Os valores de direção informados por esse sensor precisam estar entre 0.0 (inclusive) e 360.0 (exclusivo), com 0 indicando norte, 90 leste, 180 sul e 270 oeste.

A precisão desse sensor é definida com 68% de confiança. No caso em que a distribuição subjacente é normal gaussiana, a acurácia é um desvio padrão. Por exemplo, se o sensor de direção retornar um valor de 60 graus e um valor de acurácia de 10 graus, há uma probabilidade de 68% de que a direção real esteja entre 50 e 70 graus.