O Google está comprometido em promover a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Tipos de sensores

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

Eixos sensores

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 para dispositivos móveis

A API do sensor é relativa apenas à orientação natural da tela (os eixos não são trocados quando a orientação da tela do dispositivo é alterada.

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

Figura 1. Sistema de coordenadas (relativo a um dispositivo móvel) usado pela API do sensor

Eixos automotivos

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

Sistema de coordenadas da API do sensor para dispositivos automotivos

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

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

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

Sensores de base

Os tipos de sensores de base são nomeados após os sensores físicos que representam. Esses sensores retransmitem dados de um único sensor físico (ao contrário de sensores compostos que geram dados de outros sensores). Exemplos de tipos de sensores de base incluem:

  • SENSOR_TYPE_ACCELEROMETER
  • SENSOR_TYPE_GYROSCOPE
  • SENSOR_TYPE_MAGNETOMETER

No entanto, os sensores de base não são iguais e não devem ser confundidos com o 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 classificado com um intervalo de desvio de 1 grau / s.
    • 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 / s.
    • Nessa situação, dizemos que o sensor Android tem um viés abaixo de 0,01 graus / s, mesmo que a folha de dados do sensor subjacente tenha dito 1 graus / s.
  • Um barômetro com um consumo de energia de 100 uW.
    • Como os dados gerados precisam ser transportados do chip para o SoC, o custo real de energia para coletar dados do sensor Android do barômetro pode ser muito maior, por exemplo, 1000 uW.
    • Nesta situação, dizemos que o sensor Android tem um consumo de energia de 1000 uW, mesmo que 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 ao calibrar.
    • Sua rotina de calibração pode exigir a ativação do giroscópio, consumindo 5000 uW e executando algum algoritmo, custando outros 900 uW.
    • Nesta situação, dizemos que o consumo máximo de energia do sensor Android (magnetômetro) é de 6000 uW.
    • Nesse 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 que não é de ativação

Um sensor 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, ye z da aceleração sensores_evento_t.

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 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 de aceleração ao longo de z é +9,81, o 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, o 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 em escala online

A calibração de polarização e escala deve ser atualizada apenas enquanto o sensor estiver desativado, para evitar saltos nos valores durante a transmissão.

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: On-change

getDefaultSensor(SENSOR_TYPE_AMBIENT_TEMPERATURE) retorna um sensor que não é de ativação

Este sensor fornece a temperatura ambiente (ambiente) em graus Celsius.

Sensor de campo magnético

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD) retorna um sensor que não é de ativação

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, ye 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 online de ferro duro

Giroscópio

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_GYROSCOPE) retorna um sensor que não é de ativação

Um sensor de giroscópio relata 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 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 aparecesse 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 rolo.

A medição é relatada nos campos x, ye 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 a deriva)

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 reduziria a consistência e a capacidade de resposta locais. Ele deve ser baseado em um chip de giroscópio comum.

Frequência cardíaca

Modo de relatório: On-change

getDefaultSensor(SENSOR_TYPE_HEART_RATE) retorna um sensor que não é de ativação

Um sensor de frequência cardíaca relata a freqüência cardíaca atual da pessoa que toca no dispositivo.

A freqüê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 o dispositivo não esteja 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 são gerados não mais rapidamente do que todos os sampling_period .

sensor_t.requiredPermission é sempre SENSOR_PERMISSION_BODY_SENSORS .

Luz

Modo de relatório: On-change

getDefaultSensor(SENSOR_TYPE_LIGHT) retorna um sensor que não é de ativação

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

A medida é relatada em sensors_event_t.light .

Proximidade

Modo de relatório: On-change

Geralmente definido como um sensor de despertar

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

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 eram sempre sensores de ativação, ativando o SoC ao detectar uma alteração na proximidade. Após o Android 4.4, recomendamos que você implemente a versão de ativação desse sensor, pois ele é usado para ligar e desligar a tela durante as chamadas telefônicas.

A medida é relatada em centímetros em sensors_event_t.distance . Observe que alguns sensores de proximidade suportam apenas uma medição binária "near" ou "far". Nesse caso, o sensor relata 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 que não é de ativação

Um sensor de pressão (também conhecido como barômetro) relata 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 alterações de altitude. Para estimar a elevação absoluta, a pressão do nível do mar (alterando dependendo do clima) deve ser usada como referência.

Humidade relativa

Modo de relatório: On-change

getDefaultSensor(SENSOR_TYPE_RELATIVE_HUMIDITY) retorna um sensor que não é de ativação

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:

Assim como 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 do jogo é provavelmente igual à soma dos consumos de energia do chip do acelerômetro, do giroscópio, do chip que processa os dados e dos barramentos que os transportam. Como outro exemplo, o desvio de um vetor de rotação do jogo depende tanto da qualidade do algoritmo de calibração quanto das características físicas do sensor.

A tabela a seguir lista os tipos de sensores compostos disponíveis. Cada sensor composto depende de dados de um ou vários sensores físicos. Evite escolher outros sensores físicos subjacentes para aproximar os resultados, pois eles fornecem uma experiência ruim ao usuário.

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

Olhar gesto 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 não houver giroscópio)

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

Contínuo

Pegue 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, contanto que a energia seja muito baixa)

Um disparo

Contador de passos Sensor de baixa potência

Atividade

Acelerômetro

Em mudança

Detector de passo 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 giroscópio (se presente) (ou magnetômetro se giroscópio não estiver presente)

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_LINEAR_ACCELERATION) retorna um sensor que não é de ativação

Um sensor de aceleração linear relata 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, ye z da sensors_event_t.acceleration de sensors_event_t.acceleration .

As leituras em todos os eixos devem ser próximas de 0 quando o dispositivo estiver imóvel.

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

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

Movimento significativo

Sensor físico subjacente: Acelerômetro (ou outro, desde que com baixa energia)

Modo de relatório: One-shot

Baixa potência

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

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

Um detector de movimento significativo é acionado ao detectar um movimento significativo : um movimento que pode levar a uma alteração na localização do usuário.

Exemplos de tais movimentos significativos são:

  • Caminhar ou andar de bicicleta
  • Sentado em um carro, ônibus ou trem em movimento

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

  • Telefone no bolso e a pessoa não está se movendo
  • O telefone está sobre uma mesa e a mesa treme um pouco devido ao tráfego ou máquina de lavar nas proximidades

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ático, eles podem alternar para o modo de baixo consumo de energia, onde dependem de movimentos significativos para ativar o dispositivo quando o usuário está mudando de local.

Este sensor deve estar com pouca energia. Faz uma compensação pelo consumo de energia que pode resultar em uma pequena quantidade de falsos negativos. Isso é feito por alguns motivos:

  • O objetivo deste sensor é economizar energia.
  • Acionar um evento quando o usuário não está se movendo (falso positivo) é caro em termos de energia, 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 caminhando por 10 segundos, não é possível acionar um evento nesses 10 segundos.

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

Detector de passo

Sensor físico subjacente: Acelerômetro (+ possivelmente outros, desde que com baixa energia)

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

Baixa potência

getDefaultSensor(SENSOR_TYPE_STEP_DETECTOR) retorna um sensor que não é de ativação

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

O registro de data e hora do evento sensors_event_t.timestamp corresponde a quando o pé atinge o chão, gerando uma alta variação na aceleração.

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

Este sensor deve estar com pouca energia. Ou seja, se a detecção de etapas não puder ser realizada no hardware, esse sensor não deverá ser definido. Em particular, quando o detector de etapas é ativado e o acelerômetro não, apenas as etapas devem acionar interrupções (nem todas as leituras do acelerômetro).

sampling_period_ns não tem impacto nos detectores de etapas.

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

Contador de passos

Sensor físico subjacente: Acelerômetro (+ possivelmente outros, desde que com baixa energia)

Modo de relatório: On-change

De baixa potência

getDefaultSensor(SENSOR_TYPE_STEP_COUNTER) retorna um sensor que não é de ativação

Um contador de etapas relata o número de etapas executadas pelo usuário desde a última reinicialização enquanto ativado.

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

O registro de data e hora do evento é definido para o horário em que a última etapa desse evento foi executada.

Consulte o tipo de sensor do detector de passos para obter a indicação da hora de um passo.

Comparado ao detector de etapas, o contador de etapas pode ter uma latência mais alta (até 10 segundos). Graças a essa latência, este sensor tem uma alta precisão; a contagem de etapas após um dia inteiro de medidas deve estar dentro de 10% da contagem real de etapas. O detector de etapas e o contador de etapas detectam quando o usuário está andando, correndo e subindo as escadas. Eles não devem ser acionados quando o usuário estiver andando de bicicleta, dirigindo ou em outros veículos.

O hardware deve garantir que a contagem 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 acordado para que o motorista faça a manutenção do contador.

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

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

Este sensor deve estar com pouca energia. Ou seja, se a detecção de etapas não puder ser feita no hardware, esse sensor não deverá ser definido. Em particular, quando o contador de etapas é ativado e o acelerômetro não, apenas as etapas 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 energia)

Modo de relatório: especial

De baixa potência

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

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

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

Um evento de inclinação é definido pela direção da gravidade média da janela de 2 segundos, alterando em pelo menos 35 graus desde a ativação ou o último evento gerado pelo sensor. Aqui está o algoritmo:

  • reference_estimated_gravity = média das medições do acelerômetro no primeiro segundo após a ativação ou a gravidade estimada quando o último evento de inclinação foi gerado.
  • current_estimated_gravity = média das medições do acelerômetro nos últimos 2 segundos.
  • Disparar quando o angle(reference_estimated_gravity, current_estimated_gravity) > 35 degrees

Grandes acelerações sem alteração na orientação do telefone não devem acionar um evento de inclinação. Por exemplo, uma curva acentuada ou forte aceleração ao dirigir um carro não deve desencadear um evento de inclinação, mesmo que o ângulo da aceleração média possa variar mais de 35 graus. Normalmente, esse sensor é implementado com a ajuda de apenas um acelerômetro. Outros sensores também podem ser usados ​​se não aumentarem significativamente o consumo de energia. Este é um sensor de baixa potência que deve permitir que o SoC entre no modo de suspensão. Não emule este sensor no HAL. Cada evento do sensor relata 1 em sensors_event_t.data[0] .

Sensores compostos de atitude

Vetor de rotação

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

Modo de relatório: Contínuo

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

Um sensor de vetor de rotação relata a orientação do dispositivo em relação ao quadro de coordenadas Leste-Norte-Acima. Geralmente é obtido pela integração das leituras do acelerômetro, giroscópio e magnetômetro. O sistema de coordenadas East-North-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 a rotação do telefone por um ângulo teta em torno de um eixo rot_axis para ir da orientação do dispositivo de referência (alinhado leste-norte-para cima) até a orientação atual do dispositivo. A rotação é codificada como os quatro componentes x, y, z, w sem unidade de um quaternion de unidade:

  • 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, ye z de rot_axis são as coordenadas leste-norte-para cima de um vetor de comprimento unitário que representa o eixo de rotação
  • theta é o ângulo de rotação

O quaternion é um quaternion unitário: deve ser da norma 1 . A falha em garantir isso causará um comportamento irregular do cliente.

Além disso, este sensor relata uma precisão estimada da direção:

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

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

Esse sensor também usa a entrada do acelerômetro e magnetômetro para compensar a deriva 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 é de ativação

Um sensor vetorial de rotação do 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 para outra referência. É permitido que essa referência flutue na mesma ordem de magnitude que o giroscópio flutua em torno do eixo Z.

Consulte o sensor vetorial de rotação para obter detalhes sobre como configurar o sensors_event_t.data[0-3] . Este sensor não relata uma precisão estimada da direção: os sensors_event_t.data[4] são reservados e devem ser definidos como 0 .

Em um caso ideal, um telefone girado e retornado à mesma orientação do mundo real deve 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 de, indiretamente, através da estimativa do viés do giroscópio.

Gravidade

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

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_GRAVITY) retorna um sensor que não é de ativação

Um sensor de gravidade relata 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, ye z da sensors_event_t.acceleration de sensors_event_t.acceleration .

Quando o dispositivo estiver 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.

Se o dispositivo não possuir um giroscópio, o sensor de gravidade deve 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 relatório: Contínuo

De baixa potência

getDefaultSensor(SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR) retorna um sensor de não ativação

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

Consulte o sensor vetorial de rotação para obter detalhes sobre como configurar o sensors_event_t.data[0-4] .

Assim como no 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, portanto deve ser implementado em hardware.

Orientação (descontinuada)

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

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_ORIENTATION) retorna um sensor que não é de ativação

Nota: Este é um tipo de sensor mais antigo que foi descontinuado no Android SDK. Foi substituído pelo sensor de vetor de rotação, que é definido com mais clareza. Use o sensor de vetor de rotação sobre o sensor de orientação sempre que possível.

Um sensor de orientação relata a atitude do dispositivo. As medições são relatadas em graus nos campos x, ye 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 : 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 rotação -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 em relação a um dispositivo

Figura 3. Orientação relativa a um dispositivo

Essa 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 (da 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

Os sensores não calibrados fornecem resultados mais brutos e podem incluir alguns desvios, mas também contêm menos "saltos" das correções aplicadas na calibração. Alguns aplicativos podem preferir esses resultados não calibrados como mais suaves e mais confiáveis. Por exemplo, se um aplicativo está tentando realizar sua própria fusão de sensores, a introdução de calibrações pode realmente distorcer os resultados.

Acelerômetro não calibrado

Sensor físico subjacente: Acelerômetro

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_UNCALIBRATED) retorna um sensor de não ativação

Um sensor acelerômetro não calibrado relata a aceleração do dispositivo ao longo dos três eixos do sensor sem nenhuma correção de polarização (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 do 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 : desvio estimado ao longo do eixo Y
  • z_bias : desvio estimado ao longo do eixo Z

Giroscópio não calibrado

Sensor físico subjacente: Giroscópio

Modo de relatório: Contínuo

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_UNCALIBRATED) retorna um sensor de não 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, juntamente com uma estimativa de polarização. Todos os valores estão em radianos / segundo e são relatados nos campos de sensors_event_t.uncalibrated_gyro :

  • x_uncalib : velocidade angular (sem compensação de desvio) ao redor do eixo X
  • y_uncalib : velocidade angular (sem compensação de desvio) ao redor do eixo Y
  • z_uncalib : velocidade angular (sem compensação de desvio) ao redor 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 medida não calibrada é a soma da medida calibrada e a estimativa de polarização: _uncalibrated = _calibrated + _bias .

z_bias valores x_bias , y_bias e z_bias saltem assim que a estimativa do viés mudar, e eles devem permanecer estáveis ​​o resto do tempo.

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

A calibração de fábrica e a compensação de temperatura devem ser aplicadas às medições. Além disso, a estimativa de desvio do giroscópio deve ser implementada para que estimativas razoáveis ​​possam ser relatadas em x_bias , y_bias e z_bias . Se a implementação não puder estimar a deriva, esse sensor não deverá 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 que não é de ativação

Um sensor de campo magnético não calibrado relata o campo magnético ambiente juntamente 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 do 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 : x_bias estimado de ferro-duro ao longo do eixo X
  • y_bias : y_bias estimado de ferro-duro ao longo do eixo Y
  • z_bias : z_bias estimado de ferro-duro ao longo do eixo Z

Conceitualmente, a medida não calibrada é a soma da medida 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 estimativas ruins de ferro duro. z_bias valores x_bias , y_bias e z_bias saltem assim que a estimativa do ferro for alterado, e eles devem permanecer estáveis ​​o resto do tempo.

A calibração de ferro macio e a 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 puder estimar o viés, esse sensor não deverá 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.

Sensores compostos de interação

Alguns sensores são usados ​​principalmente para detectar interações com o usuário. We don't define how those sensors must be implemented, but they must be low power and it's the responsibility of the device manufacturer to verify their quality in terms of user experience.

Wake up gesture

Underlying physical sensors: Undefined (anything low power)

Reporting-mode: One-shot

Low-power

Implement only the wake-up version of this sensor.

getDefaultSensor(SENSOR_TYPE_WAKE_GESTURE) returns a wake-up sensor

A wake up gesture sensor enables waking up the device based on a device specific motion. When this sensor triggers, the device behaves as if the power button was pressed, turning the screen on. This behavior (turning on the screen when this sensor triggers) might be deactivated by the user in the device settings. Changes in settings don't impact the behavior of the sensor: only whether the framework turns the screen on when it triggers. The actual gesture to be detected isn't specified, and can be chosen by the manufacturer of the device.

This sensor must be low power, as it's likely to be activated 24/7.

Each sensor event reports 1 in sensors_event_t.data[0] .

Pick up gesture

Underlying physical sensors: Undefined (anything low power)

Reporting-mode: One-shot

Low-power

Implement only the wake-up version of this sensor.

getDefaultSensor(SENSOR_TYPE_PICK_UP_GESTURE) returns a wake-up sensor

A pick-up gesture sensor triggers when the device is picked up regardless of wherever it was before (desk, pocket, bag).

Each sensor event reports 1 in sensors_event_t.data[0] .

Glance gesture

Underlying physical sensors: Undefined (anything low power)

Reporting-mode: One-shot

Low-power

Implement only the wake-up version of this sensor.

getDefaultSensor(SENSOR_TYPE_GLANCE_GESTURE) returns a wake-up sensor

A glance gesture sensor enables briefly turning the screen on to enable the user to glance content on screen based on a specific motion. When this sensor triggers, the device will turn the screen on momentarily to allow the user to glance notifications or other content while the device remains locked in a non-interactive state (dozing), then the screen will turn off again. This behavior (briefly turning on the screen when this sensor triggers) might be deactivated by the user in the device settings. Changes in settings do not impact the behavior of the sensor: only whether the framework briefly turns the screen on when it triggers. The actual gesture to be detected isn't specified, and can be chosen by the manufacturer of the device.

This sensor must be low power, as it's likely to be activated 24/7. Each sensor event reports 1 in sensors_event_t.data[0] .