Tipos de sensores

Esta seção descreve eixos de sensores, sensores de base e sensores compostos (atividade, atitude, não calibrados e interação).

Eixos do sensor

Os valores de eventos de sensores de muitos sensores são expressos em um quadro 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.

Sistema de coordenadas de API de sensor para dispositivos móveis

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 referencial do veículo é o centro do eixo traseiro. O referencial do veículo é orientado de modo que:

  • O eixo X aponta para a direita e está num plano horizontal, perpendicular ao plano de simetria do veículo.
  • O eixo Y aponta para frente e está em um plano horizontal.
Sistema de coordenadas de API de sensor para dispositivos automotivos

Figura 2. Sistema de coordenadas (relativo a um dispositivo automotivo) usado pela Sensor API

O referencial do veículo é um sistema de coordenadas para destros. Portanto, o eixo Z aponta para cima.

O eixo Z do referencial 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 retransmitem dados de um único sensor físico (em oposição aos sensores compostos que geram dados a partir 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 base não são a saída bruta do sensor físico porque são aplicadas correções (como compensação de polarização e compensação de temperatura).

Por exemplo, as características de um sensor base podem ser diferentes das características do 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/seg.
    • Após a calibração de fábrica, a compensação de temperatura e a compensação de polarização serem aplicadas, a polarização real do sensor Android será reduzida, podendo chegar a um ponto em que a polarização é garantida abaixo de 0,01 graus/seg.
    • Nessa situação, dizemos que o sensor Android tem um viés abaixo de 0,01 graus/seg, embora a folha de dados do sensor subjacente indique 1 grau/seg.
  • Um barômetro com 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.
    • Nesta situação, dizemos que o sensor Android tem um consumo de energia de 1000 uW, embora o consumo de energia medido nos terminais do chip do barômetro seja de 100uW.
  • Um magnetômetro que consome 100uW quando calibrado, mas consome mais durante a calibração.
    • Sua rotina de calibração pode exigir a ativação do giroscópio, consumindo 5.000 uW, e a execução de algum algoritmo, custando outros 900 uW.
    • Nesta situação, dizemos que o consumo máximo de energia do sensor Android (magnetômetro) é de 6.000 uW.
    • Neste caso, o consumo médio de energia é a medida mais útil, e é o que é relatado 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 sem despertar

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, y e z 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 alguns exemplos:

  • A norma de (x, y, z) deve estar 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 em direção ao 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 polarização on-line
  • Calibração de balança on-line

O bias e a calibração da escala só devem ser atualizados enquanto o sensor estiver desativado, para evitar saltos nos valores durante a transmissão.

O acelerômetro também informa a precisão esperada de suas leituras por meio sensors_event_t.acceleration.status . Consulte as constantes 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 sem despertar

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 é relatada nos campos x, y e z de sensors_event_t.magnetic e todos os valores estão em micro-Tesla (uT).

O magnetômetro também relata a precisão que espera que suas leituras sejam através sensors_event_t.magnetic.status . Consulte as constantes 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 on-line de ferro duro

Giroscópio

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_GYROSCOPE) retorna um sensor sem despertar

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 relataria 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 rotação.

A medição é relatada 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 em escala de fábrica (ou online)
  • Calibração de polarização on-line (para remover desvios)

O giroscópio também informa a precisão que espera que suas leituras sejam através sensors_event_t.gyro.status . Consulte as constantes 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 reduziria a consistência local e a capacidade de resposta. Deve ser baseado em um chip giroscópio normal.

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 o 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 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 está em mudança, 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 rapidamente do que cada sampling_period .

sensor_t.requiredPermission é sempre SENSOR_PERMISSION_BODY_SENSORS .

Luz

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 sensors_event_t.light .

Proximidade

Modo de relatório: Em mudança

Geralmente 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, ativando o SoC ao detectar uma mudança na proximidade. Após o Android 4.4, aconselhamos implementar primeiro a versão wake-up deste sensor, pois é aquele que serve para ligar e desligar a tela durante as chamadas.

A medição é relatada 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 "distante" e um valor menor que sensor_t.maxRange no estado "próximo".

Pressão

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_PRESSURE) retorna um sensor sem despertar

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 em escala de fábrica

O barômetro é frequentemente usado para estimar mudanças de elevação. Para estimar a elevação absoluta, a pressão ao nível do mar (mudando 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 de base é 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 poderiam ser baseados em outros sensores, se o consumo de energia e a precisão fossem 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.

Tal como acontece com os sensores de base, as características dos sensores compostos vêm das características dos seus 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 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 de usuário ruim.

Tipo de sensor Categoria Sensores físicos subjacentes Modo de relatório

Vetor de rotação do jogo

Atitude

Acelerômetro, giroscópio, NÃO DEVE USAR magnetômetro

Contínuo

Vetor de rotação geomagnética Sensor de baixa potência

Atitude

Acelerômetro, magnetômetro, NÃO DEVE USAR giroscópio

Contínuo

Gesto de olhar Sensor de baixa potência

Interação

Indefinido

Um disparo

Gravidade

Atitude

Acelerômetro, giroscópio

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 (obsoleto)

Atitude

Acelerômetro, magnetômetro, giroscópio (se presente)

Contínuo

Pegar o gesto Sensor de baixa potência

Interação

Indefinido

Um disparo

Vetor de rotação

Atitude

Acelerômetro, magnetômetro, giroscópio

Contínuo

Movimento significativo Sensor de baixa potência

Atividade

Acelerômetro (ou outro, desde que com potência muito baixa)

Um disparo

Contador de passos Sensor de baixa potência

Atividade

Acelerômetro

Em mudança

Detector de passos Sensor de baixa potência

Atividade

Acelerômetro

Especial

Detector de inclinação Sensor de baixa potência

Atividade

Acelerômetro

Especial

Gesto de acordar Sensor de baixa potência

Interação

Indefinido

Um disparo

Sensor de baixa potência = 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 relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_LINEAR_ACCELERATION) retorna um sensor sem despertar

Um sensor de aceleração linear informa a aceleração linear do dispositivo na estrutura 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, y e z 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 giroscópio, o sensor de aceleração linear deverá utilizar o giroscópio e o acelerômetro como entrada.

Caso o dispositivo não possua giroscópio, o sensor de aceleração linear deverá utilizar o acelerômetro e o magnetômetro como entrada.

Movimento significativo

Sensor físico subjacente: Acelerômetro (ou outro, desde que de baixa potência)

Modo de relatório: One-shot

Baixo consumo de energia

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 desencadeiam movimentos significativos:

  • Telefone no bolso e a pessoa não se move
  • O telefone está sobre uma mesa e a mesa treme um pouco devido ao trânsito próximo ou à máquina de lavar

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

Este sensor deve ser de baixa potência. Ele compensa o consumo de energia que pode resultar em uma pequena quantidade de falsos negativos. Isso é feito por alguns motivos:

  • O objetivo deste sensor é economizar energia.
  • Disparar um evento quando o usuário não está em movimento (falso positivo) é caro em termos de energia, portanto deve ser evitado.
  • Não disparar um evento quando o usuário estiver em movimento (falso negativo) é aceitável, desde que não seja feito repetidamente. Se o usuário estiver caminhando por 10 segundos, não será aceitável não acionar um evento nesses 10 segundos.

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 com baixa potência)

Modo de relatório: Especial (um evento por etapa realizada)

Baixo consumo de energia

getDefaultSensor(SENSOR_TYPE_STEP_DETECTOR) retorna um sensor sem despertar

Um detector de etapas gera um evento cada vez que uma etapa é executada pelo usuário.

O timestamp do sensors_event_t.timestamp corresponde ao momento em que o pé toca o solo, gerando uma grande variação na aceleração.

Comparado ao 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 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 degrau não puder ser feita no hardware, este sensor não deverá ser definido. Em particular, quando o detector de passos está 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 etapas.

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 com baixa potência)

Modo de relatório: Em mudança

Baixo consumo de energia

getDefaultSensor(SENSOR_TYPE_STEP_COUNTER) retorna um sensor sem despertar

Um contador de passos informa o número de passos dados pelo usuário desde a última reinicialização enquanto estava 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 como a hora em que a última etapa desse evento foi realizada.

Consulte o tipo de sensor detector de passo 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 esta latência, este 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 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 passos), o SoC pode ser ativado para que o driver possa fazer a manutenção do contador.

Conforme declarado em Interação , enquanto este sensor estiver operando, ele não deverá perturbar nenhum outro sensor, em particular o acelerômetro, que pode muito bem estar em uso.

Se um dispositivo específico não puder suportar esses modos de operação, esse tipo de sensor não deverá ser relatado pelo HAL. Ou seja, não é aceitável “emular” este sensor no HAL.

Este sensor deve ser de baixa potência. Ou seja, se a detecção do passo não puder ser feita no hardware, este sensor não deverá ser definido. Em particular, quando o contador de passos está 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 com baixa potência)

Modo de relatório: Especial

Baixo consumo de energia

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 durante o 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.
  • Aciona quando angle(reference_estimated_gravity, current_estimated_gravity) > 35 degrees

Grandes acelerações sem alteração na orientação do telefone não devem desencadear um evento de inclinação. Por exemplo, uma curva fechada ou uma forte aceleração ao dirigir um carro não deveria desencadear um evento de inclinação, mesmo que o ângulo da aceleração média possa variar em mais de 35 graus. Normalmente, este sensor é implementado apenas com a ajuda de 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 sem despertar

Um sensor vetorial de rotação informa a orientação do dispositivo em relação ao quadro de coordenadas Leste-Norte-Cima. Geralmente é obtido pela integração de leituras de acelerômetro, giroscópio e magnetômetro. O sistema de coordenadas Leste-Norte-Cima é 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-Cima 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 em um ângulo teta em torno de um eixo rot_axis para ir da orientação do dispositivo de referência (alinhado Leste-Norte-Cima) até a orientação atual do dispositivo. A rotação é codificada como os quatro componentes x, y, z, w sem unidade de um quatérnio 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_axis são as coordenadas Leste-Norte-Cima de um vetor de comprimento unitário que representa o eixo de rotação
  • theta é o ângulo de rotação

O quatérnio é um quatérnio 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 rumo deve ser menor que estimated_accuracy em 95% das vezes. Este sensor deve usar um giroscópio como entrada principal de mudança de orientação.

Este sensor também usa entrada de acelerômetro e 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 vetorial de rotação de jogo é semelhante a um sensor vetorial 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 oscilar na mesma ordem de grandeza que o giroscópio oscila em torno do eixo Z.

Consulte o sensor vetorial 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] está reservado e deve ser definido como 0 .

Em um caso ideal, um telefone girado e retornado à mesma orientação do mundo real deveria reportar 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 o magnetômetro como entrada, além disso, indiretamente, através da estimativa da polarização 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 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, y e z 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 giroscópio, o sensor de gravidade deverá utilizar o giroscópio e o acelerômetro como entrada.

Caso o dispositivo não possua giroscópio, o sensor de gravidade deverá 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

Baixo consumo de energia

getDefaultSensor(SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR) retorna um sensor sem despertar

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

Este sensor deve ser baseado em um magnetômetro. 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 vetorial de rotação para obter detalhes sobre como definir sensors_event_t.data[0-4] .

Assim como para o sensor vetorial 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 presente) giroscópio

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_ORIENTATION) retorna um sensor sem despertar

Observação: este é um tipo de sensor mais antigo que foi descontinuado no Android SDK. Ele foi substituído pelo sensor vetorial de rotação, que está mais claramente definido. Use o sensor vetorial 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, y e z de sensors_event_t.orientation :

  • sensors_event_t.orientation.x : azimute, o ângulo entre a direção norte magnética 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):

Representação da orientação relativa a um dispositivo

Figura 3. Orientação relativa a um dispositivo

Esta definição é diferente da guinada, inclinação e rotação usada na aviação, onde o eixo X está ao longo do lado mais longo do avião (cauda ao nariz).

O sensor de orientação também informa o quão preciso ele espera que suas leituras sejam por meio sensors_event_t.orientation.status . Consulte as constantes 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 resultados mais brutos e podem incluir alguma tendência, mas também contêm menos “saltos” de correções aplicadas por meio de calibração. Alguns aplicativos podem preferir esses resultados não calibrados como mais suaves e confiáveis. Por exemplo, se um aplicativo estiver tentando realizar sua própria fusão de sensores, a introdução de calibrações pode 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 sem despertar

Um sensor acelerômetro não calibrado informa a aceleração do dispositivo ao longo dos três eixos do sensor sem qualquer 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 : tendência estimada ao longo do eixo X
  • y_bias : tendência estimada ao longo do eixo Y
  • z_bias : polarização estimada 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 informa 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 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 da estimativa de polarização: _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 devem permanecer estáveis ​​no resto do tempo.

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

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 deverá ser implementado.

Se este sensor estiver presente, então o sensor giroscópio correspondente também deverá estar presente e ambos os sensores deverão compartilhar os mesmos valores 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 sem despertar

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 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 : tendência estimada de ferro duro ao longo do eixo X
  • y_bias : tendência estimada de ferro duro ao longo do eixo Y
  • z_bias : polarização estimada de ferro duro ao longo do eixo Z

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

O magnetômetro não calibrado permite algoritmos de nível superior para lidar com estimativas de ferro duro ruim. Espera-se que os valores x_bias , y_bias e z_bias aumentem assim que a estimativa do hard-iron mudar, e eles devem permanecer estáveis ​​no resto do tempo.

A calibração do ferro macio e a 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, então este sensor não deverá ser implementado.

Se este sensor estiver presente, então o sensor de campo magnético correspondente deverá estar presente e ambos os sensores deverão compartilhar os mesmos valores sensor_t.name e sensor_t.vendor .

Ângulo da 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 este 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. Não definimos como esses sensores devem ser implementados, mas devem ser de baixo consumo e é responsabilidade do fabricante do dispositivo verificar sua qualidade em termos de experiência do usuário.

Gesto de acordar

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

Modo de relatório: One-shot

Baixo consumo de energia

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

getDefaultSensor(SENSOR_TYPE_WAKE_GESTURE) retorna um sensor de ativação

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

Esse sensor deve ser de baixa potência, pois provavelmente será ativado 24/7.

Cada evento do sensor relata 1 em sensors_event_t.data[0] .

Pegue gesto

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

Modo de relatório: um tiro

Baixo consumo de energia

Implementar apenas a versão de despertar deste sensor.

getDefaultSensor(SENSOR_TYPE_PICK_UP_GESTURE) retorna um sensor de despertar

Um sensor de gesto de coleta desencadeia quando o dispositivo é recolhido, independentemente de onde quer que estivesse antes (mesa, bolso, bolsa).

Cada evento do sensor relata 1 em sensors_event_t.data[0] .

OLHE GESTRE

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

Modo de relatório: um tiro

Baixo consumo de energia

Implementar apenas a versão de despertar deste sensor.

getDefaultSensor(SENSOR_TYPE_GLANCE_GESTURE) retorna um sensor de despertar

Um sensor de gesto de olhar permite ligar brevemente a tela para permitir que o usuário olhe o conteúdo na tela com base em um movimento específico. Quando esse sensor aciona, o dispositivo liga a tela momentaneamente para permitir que o usuário olhe notificações ou outro conteúdo enquanto o dispositivo permanece bloqueado em um estado não interativo (cochilando), a tela desligará novamente. Esse comportamento (ativando brevemente a tela quando esse sensor desencadeia) 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 liga brevemente a tela quando aciona. O gesto real a ser detectado não é especificado e pode ser escolhido pelo fabricante do dispositivo.

Esse sensor deve ser de baixa potência, pois provavelmente será ativado 24/7. Cada evento do sensor relata 1 em sensors_event_t.data[0] .

Sensores IMU de eixos limitados

Disponível no Android 13, os sensores IMU eixos limitados são sensores que suportam casos de uso em que nem todos os três eixos (x, y, z) estão disponíveis. Tipos de IMU padrão no Android (como SENSOR_TYPE_ACCELEROMETER e SENSOR_TYPE_GYROSCOPE ) assumem que todos os três eixos são suportados. No entanto, nem todos os fatores e dispositivos de forma suportam acelerômetros de 3 eixos e giroscópios de 3 eixos.

Acelerômetro eixos limitados

Sensores físicos subjacentes: acelerômetro

Modo de relatório: contínuo

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES) retorna um sensor de não-despertar

Um sensor de eixos limitados do acelerômetro é equivalente ao TYPE_ACCELEROMETER , mas suporta casos em que um ou dois eixos não são suportados.

Os últimos três valores de eventos do sensor relatados pelo sensor representam se o valor de aceleração para os eixos x, y e z é suportado. Um valor de 1.0 indica que o eixo é suportado e um valor 0 indica que não é suportado. Os fabricantes de dispositivos identificam os eixos suportados no horário de construção e os valores não mudam durante o tempo de execução.

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

Eixos limitados do giroscópio

Sensores físicos subjacentes: giroscópio

Modo de relatório: contínuo

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES) retorna um sensor de não despertar

Um sensor de eixos limitados do giroscópio é equivalente ao TYPE_GYROSCOPE , mas suporta casos em que um ou dois eixos não são suportados.

Os últimos três valores de evento sensor relatados pelo sensor representam se o valor de velocidade angular dos eixos x, y e z é suportado. Um valor de 1.0 indica que o eixo é suportado e um valor 0 indica que não é suportado. Os fabricantes de dispositivos identificam os eixos suportados no horário de construção e os valores não mudam durante o tempo de execução.

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

Acelerômetro 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 não despertado

Um sensor de eixos limitados do acelerômetro é equivalente a TYPE_ACCELEROMETER_UNCALIBRATED , mas suporta casos em que um ou dois eixos não são suportados.

Os últimos três valores de evento do sensor relatados pelo sensor representam se os valores de aceleração e viés para os eixos x, y e z são suportados. Um valor de 1.0 indica que o eixo é suportado e um valor 0 indica que não é suportado. Os fabricantes de dispositivos identificam os eixos suportados no horário de construção e os valores não mudam durante o tempo de execução.

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

Giroscópio 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 não despertado

Um sensor não calibrado do giroscópio limitado é equivalente a TYPE_GYROSCOPE_UNCALIBRATED , mas suporta casos em que um ou dois eixos não são suportados.

Os últimos três valores de evento do sensor relatados pelo sensor representam se os valores de velocidade e desvio angular para os eixos x, y e z são suportados. Um valor de 1.0 indica que o eixo é suportado e um valor 0 indica que não é suportado. Os fabricantes de dispositivos identificam os eixos suportados no horário de construção e os valores não mudam durante o tempo de execução.

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

Eixos limitados compostos imu

Sensores físicos subjacentes: qualquer combinação de acelerômetro de 3 eixos, giroscópio de 3 eixos, acelerômetro de 3 eixos não calibrado e sensores não calibrados do giroscópio de 3 eixos.

Modo de relatório: contínuo

Um sensor IMU de eixos limitados composto é equivalente a um sensor de eixos limitados, mas, em vez de ser suportado no HAL, converte os dados do sensor de 3 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 3 eixos para um acelerômetro de eixos limitados compostos.

Valores sensorevent para sensor_type_acceleromômetro Exemplo sensor_type_acceleromômetro Sensorevent Sensor composto_type_acceleromômetro_limited_axes sensorevent
Valores [0]

-0,065

-0,065

Valores [1]

0,078

0,078

Valores [2]

9.808

9.808

Valores [3]

N / D

1,0

Valores [4]

N / D

1,0

valores [5]

N / D

1,0

Sensores automotivos

Sensores para suportar casos de uso automotivo.

Cabeçalho

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

Modo de relatório: contínuo

getDefaultSensor(SENSOR_TYPE_HEADING) retorna um sensor não-despertado

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

Os valores de título relatados por esse sensor devem estar entre 0.0 (inclusive) e 360.0 (exclusivos), com 0 indicando norte, 90 leste, 180 sul e 270 oeste.

A precisão deste sensor é definida com 68 % de confiança. No caso em que a distribuição subjacente é normal gaussiana, a precisão é um desvio padrão. Por exemplo, se o sensor de cabeçalho retornar um valor de título de 60 graus e um valor de precisão de 10 graus, há uma probabilidade de 68 % do cabeçalho verdadeiro estar entre 50 graus e 70 graus.