Google is committed to advancing racial equity for Black communities. See how.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Tipos de sensor

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

Eixos do sensor

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

Eixos de dispositivos móveis

O Sensor API é relativo 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 sensor API para dispositivos móveis

Figura 1. Sistema de coordenadas (em relação a um dispositivo móvel) usado pelo Sensor API

Eixos automotivos

Nas implementações do Android Automotive, os eixos são definidos em relação à estrutura da carroceria do veículo.

Sistema de coordenadas de sensor API para dispositivos automotivos

Figura 2. Sistema de coordenadas (em relação a um dispositivo automotivo) usado pelo Sensor API

  • X aumenta em direção à direita do veículo
  • Y aumenta em direção ao nariz da estrutura corporal
  • Z aumenta em direção ao teto da estrutura do corpo

A origem do sistema de coordenadas está localizada no centro do eixo traseiro do veículo. Ao olhar na direção positiva de um eixo, as rotações positivas são no sentido anti-horário. Portanto, quando um veículo está fazendo uma curva à esquerda, espera-se que a taxa de curva do giroscópio do eixo z seja um valor positivo.

Sensores de base

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 aos 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 seu sensor físico subjacente. Os dados de um sensor de base 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 de base podem ser diferentes das características de seu sensor físico subjacente nos seguintes casos de uso:

  • Um chip de giroscópio avaliado 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 são aplicadas, a polarização real do sensor Android será reduzida, pode ser a um ponto onde a polarização é garantida como abaixo de 0,01 graus / seg.
    • Nesta situação, dizemos que o sensor Android tem uma tendência abaixo de 0,01 graus / seg, embora a folha de dados do sensor subjacente diga 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 do barômetro Android pode ser muito maior, por exemplo, 1000 uW.
    • Nessa situação, dizemos que o sensor do Android tem um consumo de energia de 1000 uW, embora o consumo de energia medido nos terminais do chip do barômetro seja de 100 uW.
  • 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 5000 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 6000 uW.
    • Nesse caso, o consumo médio de energia é a medida mais útil e é o que é relatado nas características estáticas do sensor por meio do HAL.

Acelerômetro

Modo de relatório: contínuo

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER) retorna um sensor sem despertar

Um sensor de acelerômetro relata 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 é 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 ser próxima a 0 quando em queda livre.
  • Quando o dispositivo fica deitado sobre uma mesa e é empurrado do lado esquerdo para a direita, o valor de aceleração x é positivo.
  • Quando o dispositivo está deitado sobre uma mesa, o valor de 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 fica deitado sobre uma mesa e é empurrado em direção ao céu, o valor de 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 online
  • Calibração de balança online

A calibração do bias e da escala deve ser atualizada apenas enquanto o sensor estiver desativado, para evitar saltos nos valores durante o streaming.

O acelerômetro também relata o quão preciso ele espera que suas leituras sejam por meio de sensors_event_t.acceleration.status . Veja a SensorManager 's SENSOR_STATUS_* constantes 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 sem despertar

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) relata o campo magnético ambiente, conforme 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 o quão preciso ele espera que suas leituras sejam por meio de sensors_event_t.magnetic.status . Veja a SensorManager 's SENSOR_STATUS_* constantes 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 sem despertar

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 roll.

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 de escala de fábrica (ou online)
  • Calibração de polarização online (para remover o desvio)

O giroscópio também relata o quão preciso ele espera que suas leituras sejam por meio de sensors_event_t.gyro.status . Veja a SensorManager 's SENSOR_STATUS_* constantes 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 tivesse consistência local reduzida e capacidade de resposta. Deve ser baseado em um chip de giroscópio comum.

Frequência cardíaca

Modo de relatório: em mudança

getDefaultSensor(SENSOR_TYPE_HEART_RATE) retorna um sensor sem despertar

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) é relatada em sensors_event_t.heart_rate.bpm e o status do sensor é relatado em sensors_event_t.heart_rate.status . Veja a SensorManager 's SENSOR_STATUS_* constantes 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 constante 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 são gerados não mais rápido 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 sem despertar

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 despertar

Um sensor de proximidade relata 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 ativação, ativando o SoC ao detectar uma mudança na proximidade. Após o Android 4.4, aconselhamos implementar primeiro a versão wake-up desse sensor, pois é o que serve para ligar e desligar a tela durante as ligações.

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óxima" ou "distante". Nesse 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 de escala de fábrica

O barômetro é freqüentemente 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 sem despertar

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 poderiam ser baseados em outros sensores também, 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 da 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 de 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, a deriva 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 se baseia em dados de um ou vários sensores físicos. Evite escolher outros sensores físicos subjacentes para aproximar os resultados, pois eles fornecem uma experiência do 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 relance 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 houver) ou magnetômetro (se não houver giroscópio)

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 houver)

Contínuo

Gesto de pegar 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, enquanto 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 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 sem despertar

Um sensor de aceleração linear relata a aceleração linear do dispositivo na estrutura do sensor, não incluindo 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 ser próximas a 0 quando o dispositivo está imóvel.

Se o dispositivo possuir um giroscópio, o sensor de aceleração linear deve usar 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 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 despertar

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:

  • Caminhando ou pedalando
  • Sentado em um carro em movimento, treinador ou trem

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

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

No nível alto, o detector de movimento significativo é usado para reduzir o consumo de energia da determinação da 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, onde dependem de um movimento significativo para despertar 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.
  • Acionar um evento quando o usuário não está se movendo (falso positivo) é caro em termos de energia, portanto, 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 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, contanto 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 sem despertar

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

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

Em comparação com o contador de etapas, o detector de etapas deve ter uma latência mais baixa (menos de dois segundos). Tanto o detector de passos quanto o contador de passos detectam quando o usuário está caminhando, 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 de passos não pode ser feita em hardware, este sensor não deve 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, contanto que 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 etapas relata o número de etapas realizadas 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 apenas na reinicialização do sistema.

O registro de data e hora do evento é definido como a hora em que a última etapa desse evento foi realizada.

Consulte o tipo de sensor do detector de etapa para obter o significado do tempo de uma etapa.

Comparado ao detector de etapas, o contador de etapas pode ter uma latência mais alta (até 10 segundos). Graças a esta latência, este sensor tem uma 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á caminhando, 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 de etapas internas nunca ultrapasse. O tamanho mínimo do contador interno do hardware deve ser 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 opera, 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 for compatível com 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 de passos não pode ser feita em hardware, este sensor não deve ser definido. Em particular, quando o contador de passos está ativado e o acelerômetro não, apenas os passos devem disparar interrupções (não os dados do acelerômetro).

Detector de inclinação

Sensor físico subjacente: acelerômetro (+ possivelmente outros, contanto que 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 despertar

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 o 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 fechada ou forte aceleração ao dirigir um carro não deve desencadear um evento de inclinação, embora 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 suspenso. 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 de vetor de rotação informa a orientação do dispositivo em relação ao quadro de coordenadas Leste-Norte-Acima. Geralmente é obtido pela integração de leituras de acelerômetro, giroscópio e magnetômetro. O sistema de coordenadas Leste-Norte-Up é definido como uma base ortonormal direta onde:

  • X aponta para o 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-Acima 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 theta em torno de um eixo rot_axis para ir da orientação do dispositivo de referência (alinhamento leste-norte para 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-Acima de um vetor de comprimento unitário que representa o eixo de rotação
  • theta é o ângulo de rotação

O quatérnion é um quatérnio unitário: deve ser da norma 1 . A falha em garantir isso causará um comportamento errático do cliente.

Além disso, este sensor informa uma estimativa de precisão do rumo:

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

O erro de rumo deve ser menor do que a estimated_accuracy 95% do tempo. Este sensor deve usar um giroscópio como a principal entrada de mudança de orientação.

Este sensor também usa acelerômetro e entrada de 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 sem despertar

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 para alguma outra referência. Essa referência pode desviar na mesma ordem de magnitude que o giroscópio deriva 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 relata 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. Ele não pode usar o magnetômetro como uma entrada, além disso, 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 sem despertar

Um sensor de gravidade informa a direção e 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.

Se o dispositivo possuir um giroscópio, o sensor de gravidade deve usar 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

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 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 os 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% do tempo.

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 sem despertar

Nota: Este é um tipo de sensor mais antigo que se tornou obsoleto 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, 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 rolagem é positivo no sentido horário. (Matematicamente falando, deve ser positivo no sentido anti-horário):

Representação da orientação em relação a um dispositivo

Figura 3. Orientação em relação a um dispositivo

Esta definição é diferente de guinada, inclinação e rotação usados ​​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 relata o quão preciso ele espera que suas leituras sejam por meio de sensors_event_t.orientation.status . Veja a SensorManager 's SENSOR_STATUS_* constantes 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 alguma polarização, 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 conduzir 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 de acelerômetro não calibrado relata a aceleração do dispositivo ao longo dos três eixos do sensor sem qualquer correção de polarização (polarização de fábrica e 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 : tendência 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 é de ativação

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, junto 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 deriva) em torno do eixo X
  • y_uncalib : velocidade angular (sem compensação de deriva) em torno do eixo Y
  • z_uncalib : velocidade angular (sem compensação de deriva) em torno do eixo Z
  • x_bias : deriva estimada em torno 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 a estimativa de polarização: _uncalibrated = _calibrated + _bias .

z_bias valores de x_bias , y_bias e z_bias assim que a estimativa da tendência mudar, e eles devem permanecer estáveis ​​pelo 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 da deriva 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 a deriva, então este sensor não deve ser implementado.

Se este sensor está presente, então o sensor de giroscópio correspondente também deve estar presente e os dois sensores devem compartilhar a mesma sensor_t.name e sensor_t.vendor valores.

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 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 de polarização de ferro duro ao longo do eixo Y
  • z_bias : estimativa de polarização 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 polarização: _uncalibrated = _calibrated + _bias .

O magnetômetro não calibrado permite que algoritmos de nível superior lidem com a estimativa de ferro duro ruim. z_bias valores de x_bias , y_bias e z_bias assim que a estimativa do hard-iron mudar, e eles 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 de ferro duro 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 bias, então este sensor não deve ser implementado.

Se este sensor está presente, então o sensor de campo magnético correspondente deve estar presente e os dois sensores devem compartilhar a mesma sensor_t.name e sensor_t.vendor valores.

Â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 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 eles devem ter baixo consumo de energia e é responsabilidade do fabricante do dispositivo verificar sua qualidade em termos de experiência do usuário.

Gesto de acordar

Sensores físicos subjacentes: Indefinido (qualquer coisa com baixa potência)

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] .