Types de capteur

Cette section décrit les axes des capteurs, les capteurs de base et les capteurs composites (activité, attitude, non calibré et interaction).

Axes de capteur

Les valeurs d'événement de capteur de nombreux capteurs sont exprimées dans un cadre spécifique qui est statique par rapport à l'appareil.

Axes d'appareils mobiles

L'API du capteur est relative uniquement à l'orientation naturelle de l'écran (les axes ne sont pas permutés lorsque l'orientation de l'écran de l'appareil change.

Figure 1. Système de coordonnées (par rapport à un appareil mobile) utilisé par l'API Sensor

Axes automobiles

Dans les implémentations d'Android Automotive, les axes sont définis par rapport à la carrosserie du véhicule. L'origine du repère du véhicule est le centre de l'essieu arrière. Le référentiel véhicule est orienté pour que :

• L'axe X pointe vers la droite et se trouve sur un plan horizontal, perpendiculaire au plan de symétrie du véhicule.
• L'axe Y pointe vers l'avant et se trouve sur un plan horizontal.

Figure 2. Système de coordonnées (par rapport à un appareil automobile) utilisé par l'API Sensor

Le référentiel véhicule est un système de coordonnées droitier. Par conséquent, l'axe Z pointe vers le haut.

L'axe Z du cadre de référence est aligné sur la gravité, ce qui signifie que l'axe X et l'axe Y sont tous deux horizontaux. Par conséquent, l'axe Y peut ne pas toujours passer par l'essieu avant.

Capteurs de base

Les types de capteurs de base sont nommés d'après les capteurs physiques qu'ils représentent. Ces capteurs relaient les données d'un seul capteur physique (par opposition aux capteurs composites qui génèrent des données à partir d'autres capteurs). Voici des exemples de types de capteurs de base :

• SENSOR_TYPE_ACCELEROMETER
• SENSOR_TYPE_GYROSCOPE
• SENSOR_TYPE_MAGNETOMETER

Cependant, les capteurs de base ne sont pas égaux et ne doivent pas être confondus avec leur capteur physique sous-jacent. Les données d'un capteur de base ne sont pas la sortie brute du capteur physique car des corrections (telles que la compensation de biais et la compensation de température) sont appliquées.

Par exemple, les caractéristiques d'un capteur de base peuvent être différentes des caractéristiques de son capteur physique sous-jacent dans les cas d'utilisation suivants :

• Une puce de gyroscope conçue pour avoir une plage de polarisation de 1 deg/sec.
  • Après l'étalonnage en usine, la compensation de température et la compensation de biais sont appliquées, le biais réel du capteur Android sera réduit, peut être à un point où le biais est garanti inférieur à 0,01 deg/sec.
  • Dans cette situation, nous disons que le capteur Android a un biais inférieur à 0,01 deg/sec, même si la fiche technique du capteur sous-jacent indique 1 deg/sec.
• Un baromètre avec une consommation électrique de 100 uW.
  • Étant donné que les données générées doivent être transportées de la puce au SoC, le coût énergétique réel pour collecter les données du capteur Android du baromètre peut être beaucoup plus élevé, par exemple 1000 uW.
  • Dans cette situation, nous disons que le capteur Android a une consommation électrique de 1000 uW, même si la consommation électrique mesurée au niveau des fils de la puce du baromètre est de 100 uW.
• Un magnétomètre qui consomme 100uW lorsqu'il est calibré, mais consomme plus lors de l'étalonnage.
  • Sa routine d'étalonnage peut nécessiter l'activation du gyroscope, la consommation de 5000 uW et l'exécution d'un algorithme, coûtant 900 uW supplémentaires.
  • Dans cette situation, on dit que la consommation électrique maximale du capteur Android (magnétomètre) est de 6000 uW.
  • Dans ce cas, la consommation électrique moyenne est la mesure la plus utile, et c'est ce qui est rapporté dans les caractéristiques statiques du capteur via HAL.

Accéléromètre

Mode de rapport : continu

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER) renvoie un capteur de non-réveil

Un capteur accéléromètre signale l'accélération de l'appareil le long des trois axes du capteur. L'accélération mesurée comprend à la fois l'accélération physique (changement de vitesse) et la gravité. La mesure est rapportée dans les champs x, y et z de sensors_event_t.acceleration.

Toutes les valeurs sont en unités SI (m/s^2) et mesurent l'accélération de l'appareil moins la force de gravité le long des trois axes du capteur.

Voici des exemples :

• La norme de (x, y, z) doit être proche de 0 en chute libre.
• Lorsque l'appareil repose à plat sur une table et est poussé sur son côté gauche vers la droite, la valeur d'accélération x est positive.
• Lorsque l'appareil repose à plat sur une table, la valeur d'accélération selon z est de +9,81 alo, ce qui correspond à l'accélération de l'appareil (0 m/s^2) moins la force de gravité (-9,81 m/s^2).
• Lorsque l'appareil repose à plat sur une table et est poussé vers le ciel, la valeur d'accélération est supérieure à +9,81, ce qui correspond à l'accélération de l'appareil (+A m/s^2) moins la force de gravité (-9,81 m /s^2).

Les lectures sont calibrées à l'aide de :

• Compensation de température
• Étalonnage du biais en ligne
• Étalonnage de la balance en ligne

Le calibrage du biais et de l'échelle ne doit être mis à jour que lorsque le capteur est désactivé, afin d'éviter de provoquer des sauts de valeurs pendant le streaming.

L'accéléromètre signale également la précision qu'il s'attend à ce que ses lectures soient par le biais de sensors_event_t.acceleration.status . Voir les SensorManager SENSOR_STATUS_* du SensorManager pour plus d'informations sur les valeurs possibles pour ce champ.

Température ambiante

Mode de rapport : en cas de changement

getDefaultSensor(SENSOR_TYPE_AMBIENT_TEMPERATURE) renvoie un capteur de non-réveil

Ce capteur fournit la température ambiante (pièce) en degrés Celsius.

Capteur de champ magnétique

Mode de rapport : continu

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD) renvoie un capteur de non-réveil

SENSOR_TYPE_GEOMAGNETIC_FIELD == SENSOR_TYPE_MAGNETIC_FIELD

Un capteur de champ magnétique (également appelé magnétomètre) signale le champ magnétique ambiant, tel que mesuré le long des trois axes du capteur.

La mesure est rapportée dans les champs x, y et z de sensors_event_t.magnetic et toutes les valeurs sont en micro-Tesla (uT).

Le magnétomètre indique également la précision qu'il s'attend à ce que ses lectures soient par le biais de sensors_event_t.magnetic.status . Voir les SensorManager SENSOR_STATUS_* du SensorManager pour plus d'informations sur les valeurs possibles pour ce champ.

Les lectures sont calibrées à l'aide de :

• Compensation de température
• Étalonnage du fer doux en usine (ou en ligne)
• Étalonnage en ligne du fer dur

Gyroscope

Mode de rapport : continu

getDefaultSensor(SENSOR_TYPE_GYROSCOPE) renvoie un capteur de non-réveil

Un capteur gyroscopique signale la vitesse de rotation de l'appareil autour des trois axes du capteur.

La rotation est positive dans le sens antihoraire (règle de la main droite). Autrement dit, un observateur regardant depuis un emplacement positif sur l'axe x, y ou z un appareil positionné sur l'origine signalerait une rotation positive si l'appareil semblait tourner dans le sens inverse des aiguilles d'une montre. Notez qu'il s'agit de la définition mathématique standard de la rotation positive et qu'elle ne correspond pas à la définition aérospatiale du roulis.

La mesure est rapportée dans les champs x, y et z de sensors_event_t.gyro et toutes les valeurs sont en radians par seconde (rad/s).

Les lectures sont calibrées à l'aide de :

• Compensation de température
• Compensation d'échelle en usine (ou en ligne)
• Étalonnage du biais en ligne (pour éliminer la dérive)

Le gyroscope indique également la précision à laquelle il s'attend à ce que ses lectures soient par le biais de sensors_event_t.gyro.status . Voir les SensorManager SENSOR_STATUS_* du SensorManager pour plus d'informations sur les valeurs possibles pour ce champ.

Le gyroscope ne peut pas être émulé sur la base de magnétomètres et d'accéléromètres, car cela entraînerait une cohérence et une réactivité locales réduites. Il doit être basé sur une puce de gyroscope habituelle.

Rythme cardiaque

Mode de rapport : en cas de changement

getDefaultSensor(SENSOR_TYPE_HEART_RATE) renvoie un capteur de non-réveil

Un capteur de fréquence cardiaque signale la fréquence cardiaque actuelle de la personne qui touche l'appareil.

La fréquence cardiaque actuelle en battements par minute (BPM) est signalée dans sensors_event_t.heart_rate.bpm et l'état du capteur est signalé dans sensors_event_t.heart_rate.status . Voir les SensorManager SENSOR_STATUS_* du SensorManager pour plus d'informations sur les valeurs possibles pour ce champ. En particulier, lors de la première activation, à moins que l'appareil ne soit connu comme n'étant pas sur le corps, le champ d'état du premier événement doit être défini sur SENSOR_STATUS_UNRELIABLE . Étant donné que ce capteur est en cours de modification, les événements sont générés lorsque et uniquement lorsque heart_rate.bpm ou heart_rate.status ont changé depuis le dernier événement. Les événements ne sont pas générés plus rapidement que chaque sampling_period .

sensor_t.requiredPermission est toujours SENSOR_PERMISSION_BODY_SENSORS .

Lumière

Mode de rapport : en cas de changement

getDefaultSensor(SENSOR_TYPE_LIGHT) renvoie un capteur de non-réveil

Un capteur de lumière signale l'éclairement actuel en unités SI lux.

La mesure est rapportée dans sensors_event_t.light .

Proximité

Mode de rapport : en cas de changement

Habituellement défini comme un capteur de réveil

getDefaultSensor(SENSOR_TYPE_PROXIMITY) renvoie un capteur de réveil

Un capteur de proximité signale la distance entre le capteur et la surface visible la plus proche.

Jusqu'à Android 4.4, les capteurs de proximité étaient toujours des capteurs de réveil, réveillant le SoC lors de la détection d'un changement de proximité. Après Android 4.4, nous conseillons d'implémenter d'abord la version de réveil de ce capteur, car c'est celle qui sert à allumer et éteindre l'écran lors des appels téléphoniques.

La mesure est rapportée en centimètres dans sensors_event_t.distance . Notez que certains capteurs de proximité ne prennent en charge qu'une mesure binaire "proche" ou "éloignée". Dans ce cas, le capteur rapporte sa valeur sensor_t.maxRange dans l'état "far" et une valeur inférieure à sensor_t.maxRange dans l'état "near".

Pression

Mode de rapport : continu

getDefaultSensor(SENSOR_TYPE_PRESSURE) renvoie un capteur de non-réveil

Un capteur de pression (également appelé baromètre) indique la pression atmosphérique en hectopascal (hPa).

Les lectures sont calibrées à l'aide

• Compensation de température
• Étalonnage du biais en usine
• Étalonnage de la balance en usine

Le baromètre est souvent utilisé pour estimer les changements d'altitude. Pour estimer l'altitude absolue, la pression au niveau de la mer (variant en fonction de la météo) doit être utilisée comme référence.

Humidité relative

Mode de rapport : en cas de changement

getDefaultSensor(SENSOR_TYPE_RELATIVE_HUMIDITY) renvoie un capteur de non-réveil

Un capteur d'humidité relative mesure l'humidité relative de l'air ambiant et renvoie une valeur en pourcentage.

Types de capteurs composites

Un capteur composite génère des données en traitant et/ou en fusionnant des données provenant d'un ou plusieurs capteurs physiques. (Tout capteur qui n'est pas un capteur de base est appelé un capteur composite.) Voici des exemples de capteurs composites :

• Détecteur de pas et mouvement significatif , qui sont généralement basés sur un accéléromètre, mais pourraient également être basés sur d'autres capteurs, si la consommation d'énergie et la précision étaient acceptables.
• Jeu de vecteur de rotation , basé sur un accéléromètre et un gyroscope.
• Gyroscope non calibré, qui est similaire au capteur de base du gyroscope, mais avec l'étalonnage du biais signalé séparément au lieu d'être corrigé dans la mesure.

Comme pour les capteurs de base, les caractéristiques des capteurs composites proviennent des caractéristiques de leurs données finales. Par exemple, la consommation électrique d'un vecteur de rotation de jeu est probablement égale à la somme des consommations électriques de la puce accéléromètre, de la puce gyroscope, de la puce traitant les données et des bus transportant les données. Autre exemple, la dérive d'un vecteur de rotation de jeu dépend autant de la qualité de l'algorithme de calibration que des caractéristiques physiques du capteur.

Le tableau suivant répertorie les types de capteurs composites disponibles. Chaque capteur composite s'appuie sur les données d'un ou plusieurs capteurs physiques. Évitez de choisir d'autres capteurs physiques sous-jacents pour obtenir des résultats approximatifs, car ils offrent une mauvaise expérience utilisateur.

Type de capteur	Catégorie	Capteurs physiques sous-jacents	Mode de rapport
Vecteur de rotation du jeu	Attitude	Accéléromètre, gyroscope, NE PAS UTILISER de magnétomètre	Continu
Vecteur de rotation géomagnétique	Attitude	Accéléromètre, magnétomètre, NE DOIT PAS UTILISER de gyroscope	Continu
Geste du regard	Interaction	Indéfini	Un tir
La gravité	Attitude	Accéléromètre, gyroscope	Continu
Gyroscope non calibré	Non calibré	Gyroscope	Continu
Accélération linéaire	Activité	Accéléromètre, gyroscope (le cas échéant) ou magnétomètre (si le gyroscope n'est pas présent)	Continu
Champ magnétique non calibré	Non calibré	Magnétomètre	Continu
Orientation (obsolète)	Attitude	Accéléromètre, magnétomètre, gyroscope (si présent)	Continu
Prendre le geste	Interaction	Indéfini	Un tir
Vecteur de rotation	Attitude	Accéléromètre, magnétomètre, gyroscope	Continu
Mouvement important	Activité	Accéléromètre (ou autre tant qu'à très faible puissance)	Un tir
Compteur de pas	Activité	Accéléromètre	Sur le changement
Détecteur de pas	Activité	Accéléromètre	Spécial
Détecteur d'inclinaison	Activité	Accéléromètre	Spécial
Geste de réveil	Interaction	Indéfini	Un tir

= Capteur de faible puissance

Capteurs composites d'activité

Accélération linéaire

Capteurs physiques sous-jacents : Accéléromètre et (le cas échéant) gyroscope (ou magnétomètre si le gyroscope n'est pas présent)

Mode de rapport : continu

getDefaultSensor(SENSOR_TYPE_LINEAR_ACCELERATION) renvoie un capteur de non-réveil

Un capteur d'accélération linéaire signale l'accélération linéaire de l'appareil dans le cadre du capteur, sans compter la gravité.

La sortie est conceptuellement : la sortie de l' accéléromètre moins la sortie du capteur de gravité . Il est indiqué en m/s^2 dans les champs x, y et z de sensors_event_t.acceleration .

Les lectures sur tous les axes doivent être proches de 0 lorsque l'appareil est immobile.

Si l'appareil possède un gyroscope, le capteur d'accélération linéaire doit utiliser le gyroscope et l'accéléromètre comme entrée.

Si l'appareil ne possède pas de gyroscope, le capteur d'accélération linéaire doit utiliser l'accéléromètre et le magnétomètre en entrée.

Mouvement important

Capteur physique sous-jacent : accéléromètre (ou autre tant que la puissance est faible)

Mode de rapport : One-shot

Batterie faible

Implémentez uniquement la version de réveil de ce capteur.

getDefaultSensor(SENSOR_TYPE_SIGNIFICANT_MOTION) renvoie un capteur de réveil

Un détecteur de mouvement significatif se déclenche lors de la détection d'un mouvement significatif : un mouvement pouvant entraîner un changement de position de l'utilisateur.

Voici des exemples de ces mouvements importants :

• Marche ou vélo
• Assis dans une voiture, un car ou un train en mouvement

Exemples de situations qui ne déclenchent pas de mouvement significatif :

• Téléphone dans la poche et la personne ne bouge pas
• Le téléphone est sur une table et la table tremble un peu en raison de la circulation ou de la machine à laver à proximité

Au niveau haut, le détecteur de mouvement significatif est utilisé pour réduire la consommation d'énergie de la localisation. Lorsque les algorithmes de localisation détectent que l'appareil est statique, ils peuvent passer en mode basse consommation, où ils s'appuient sur un mouvement important pour réveiller l'appareil lorsque l'utilisateur change d'emplacement.

Ce capteur doit être de faible puissance. Cela fait un compromis sur la consommation d'énergie qui peut entraîner une petite quantité de faux négatifs. Ceci est fait pour plusieurs raisons :

• Le but de ce capteur est d'économiser de l'énergie.
• Le déclenchement d'un événement alors que l'utilisateur ne bouge pas (faux positif) est coûteux en énergie, il faut donc l'éviter.
• Ne pas déclencher un événement lorsque l'utilisateur se déplace (faux négatif) est acceptable tant que cela n'est pas répété. Si l'utilisateur a marché pendant 10 secondes, ne pas déclencher d'événement dans ces 10 secondes n'est pas acceptable.

Chaque événement de capteur signale 1 dans sensors_event_t.data[0] .

Détecteur de pas

Capteur physique sous-jacent : accéléromètre (+ éventuellement d'autres tant que la puissance est faible)

Mode de rapport : spécial (un événement par étape effectuée)

Batterie faible

getDefaultSensor(SENSOR_TYPE_STEP_DETECTOR) renvoie un capteur de non-réveil

Un détecteur de pas génère un événement à chaque fois qu'un pas est effectué par l'utilisateur.

L'horodatage de l'événement sensors_event_t.timestamp correspond au moment où le pied touche le sol, générant une forte variation d'accélération.

Comparé au compteur de pas, le détecteur de pas devrait avoir une latence plus faible (moins de deux secondes). Le détecteur de pas et le compteur de pas détectent quand l'utilisateur marche, court et monte les escaliers. Ils ne doivent pas se déclencher lorsque l'utilisateur est à vélo, en voiture ou dans d'autres véhicules.

Ce capteur doit être de faible puissance. Autrement dit, si la détection de pas ne peut pas être effectuée dans le matériel, ce capteur ne doit pas être défini. En particulier, lorsque le détecteur de pas est activé et que l'accéléromètre ne l'est pas, seuls les pas doivent déclencher des interruptions (pas toutes les lectures de l'accéléromètre).

sampling_period_ns n'a aucun impact sur les détecteurs de pas.

Chaque événement de capteur signale 1 dans sensors_event_t.data[0] .

Compteur de pas

Capteur physique sous-jacent : accéléromètre (+ éventuellement d'autres tant que la puissance est faible)

Mode de rapport : en cas de changement

Batterie faible

getDefaultSensor(SENSOR_TYPE_STEP_COUNTER) renvoie un capteur de non-réveil

Un compteur de pas indique le nombre de pas effectués par l'utilisateur depuis le dernier redémarrage lorsqu'il est activé.

La mesure est signalée comme uint64_t dans sensors_event_t.step_counter et est remise à zéro uniquement lors d'un redémarrage du système.

L'horodatage de l'événement est défini sur l'heure à laquelle la dernière étape de cet événement a été effectuée.

Voir le type de capteur Détecteur de pas pour la signification du temps d'un pas.

Par rapport au détecteur de pas, le compteur de pas peut avoir une latence plus élevée (jusqu'à 10 secondes). Grâce à cette latence, ce capteur a une grande précision ; le nombre de pas après une journée complète de mesures doit être inférieur à 10 % du nombre de pas réel. Le détecteur de pas et le compteur de pas détectent quand l'utilisateur marche, court et monte les escaliers. Ils ne doivent pas se déclencher lorsque l'utilisateur est à vélo, en voiture ou dans d'autres véhicules.

Le matériel doit garantir que le nombre de pas internes ne dépasse jamais. La taille minimale du compteur interne du matériel doit être de 16 bits. En cas de débordement imminent (au maximum toutes les ~2^16 étapes), le SoC peut être réveillé afin que le conducteur puisse effectuer la maintenance du compteur.

Comme indiqué dans Interaction , pendant que ce capteur fonctionne, il ne doit perturber aucun autre capteur, en particulier l'accéléromètre, qui pourrait très bien être utilisé.

Si un appareil particulier ne peut pas prendre en charge ces modes de fonctionnement, ce type de capteur ne doit pas être signalé par la HAL. C'est-à-dire qu'il n'est pas acceptable d'"émuler" ce capteur dans HAL.

Ce capteur doit être de faible puissance. Autrement dit, si la détection de pas ne peut pas être effectuée dans le matériel, ce capteur ne doit pas être défini. En particulier, lorsque le compteur de pas est activé et que l'accéléromètre ne l'est pas, seuls les pas doivent déclencher des interruptions (pas les données de l'accéléromètre).

Détecteur d'inclinaison

Capteur physique sous-jacent : accéléromètre (+ éventuellement d'autres tant que la puissance est faible)

Mode de rapport : spécial

Batterie faible

Implémentez uniquement la version de réveil de ce capteur.

getDefaultSensor(SENSOR_TYPE_TILT_DETECTOR) renvoie un capteur de réveil

Un détecteur d'inclinaison génère un événement chaque fois qu'un événement d'inclinaison est détecté.

Un événement d'inclinaison est défini par la direction de la gravité moyenne de la fenêtre de 2 secondes changeant d'au moins 35 degrés depuis l'activation ou le dernier événement généré par le capteur. Voici l'algorithme :

• reference_estimated_gravity = moyenne des mesures de l'accéléromètre sur la première seconde après l'activation ou la gravité estimée lorsque le dernier événement d'inclinaison a été généré.
• current_estimated_gravity = moyenne des mesures de l'accéléromètre sur les 2 dernières secondes.
• Déclencher lorsque l' angle(reference_estimated_gravity, current_estimated_gravity) > 35 degrees

De fortes accélérations sans changement d'orientation du téléphone ne devraient pas déclencher d'événement d'inclinaison. Par exemple, un virage serré ou une forte accélération lors de la conduite d'une voiture ne devrait pas déclencher d'événement d'inclinaison, même si l'angle de l'accélération moyenne peut varier de plus de 35 degrés. Typiquement, ce capteur est mis en œuvre à l'aide d'un seul accéléromètre. D'autres capteurs peuvent également être utilisés s'ils n'augmentent pas la consommation d'énergie de manière significative. Il s'agit d'un capteur basse consommation qui devrait permettre au SoC de passer en mode veille. N'émulez pas ce capteur dans HAL. Chaque événement de capteur signale 1 dans sensors_event_t.data[0] .

Capteurs composites d'attitude

Vecteur de rotation

Capteurs physiques sous-jacents : accéléromètre, magnétomètre et gyroscope

Mode de rapport : continu

getDefaultSensor(SENSOR_TYPE_ROTATION_VECTOR) renvoie un capteur de non-réveil

Un capteur de vecteur de rotation signale l'orientation de l'appareil par rapport au cadre de coordonnées Est-Nord-Haut. Il est généralement obtenu par l'intégration des lectures de l'accéléromètre, du gyroscope et du magnétomètre. Le système de coordonnées Est-Nord-Haut est défini comme une base orthonormée directe où :

• X pointe vers l'est et est tangent au sol.
• Y pointe vers le nord et est tangent au sol.
• Z pointe vers le ciel et est perpendiculaire au sol.

L'orientation du téléphone est représentée par la rotation nécessaire pour aligner les coordonnées Est-Nord-Haut avec les coordonnées du téléphone. C'est-à-dire que l'application de la rotation au cadre du monde (X, Y, Z) les alignerait avec les coordonnées téléphoniques (x, y, z).

La rotation peut être considérée comme une rotation du téléphone d'un angle thêta autour d'un axe rot_axis pour passer de l'orientation de l'appareil de référence (aligné Est-Nord-Haut) à l'orientation actuelle de l'appareil. La rotation est codée comme les quatre composants x, y, z, w sans unité d'un quaternion unitaire :

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

Où:

• Les champs x, y et z de rot_axis sont les coordonnées Est-Nord-Haut d'un vecteur de longueur unitaire représentant l'axe de rotation
• theta est l'angle de rotation

Le quaternion est un quaternion unitaire : Il doit être de norme 1 . Ne pas s'assurer que cela entraînera un comportement erratique du client.

De plus, ce capteur rapporte une précision de cap estimée :

sensors_event_t.data[4] = estimated_accuracy (en radians)

L'erreur de cap doit être inférieure à estimated_accuracy 95 % du temps. Ce capteur doit utiliser un gyroscope comme entrée principale de changement d'orientation.

Ce capteur utilise également l'entrée de l'accéléromètre et du magnétomètre pour compenser la dérive du gyroscope, et il ne peut pas être mis en œuvre en utilisant uniquement l'accéléromètre et le magnétomètre.

Vecteur de rotation du jeu

Capteurs physiques sous-jacents : accéléromètre et gyroscope (pas de magnétomètre)

Mode de rapport : continu

getDefaultSensor(SENSOR_TYPE_GAME_ROTATION_VECTOR) renvoie un capteur non réveil

Un capteur de vecteur de rotation de jeu est similaire à un capteur de vecteur de rotation mais n'utilise pas le champ géomagnétique. Par conséquent, l'axe Y ne pointe pas vers le nord mais vers une autre référence. Cette référence est autorisée à dériver du même ordre de grandeur que le gyroscope dérive autour de l'axe Z.

Voir le capteur de vecteur de rotation pour plus de détails sur la façon de définir sensors_event_t.data[0-3] . Ce capteur ne signale pas une précision de cap estimée : sensors_event_t.data[4] est réservé et doit être défini sur 0 .

Dans un cas idéal, un téléphone tourné et revenu à la même orientation dans le monde réel devrait signaler le même vecteur de rotation de jeu.

Ce capteur doit être basé sur un gyroscope et un accéléromètre. Il ne peut pas utiliser le magnétomètre comme entrée, d'ailleurs, indirectement, par l'estimation du biais du gyroscope.

La gravité

Capteurs physiques sous-jacents : Accéléromètre et (le cas échéant) gyroscope (ou magnétomètre si le gyroscope n'est pas présent)

Mode de rapport : continu

getDefaultSensor(SENSOR_TYPE_GRAVITY) renvoie un capteur non réveil

Un capteur de gravité signale la direction et l'amplitude de la gravité dans les coordonnées de l'appareil.

Les composantes du vecteur de gravité sont rapportées en m/s^2 dans les champs x, y et z de sensors_event_t.acceleration .

Lorsque l'appareil est au repos, la sortie du capteur de gravité doit être identique à celle de l'accéléromètre. Sur Terre, la magnitude est d'environ 9,8 m/s^2.

Si l'appareil possède un gyroscope, le capteur de gravité doit utiliser le gyroscope et l'accéléromètre comme entrée.

Si l'appareil ne possède pas de gyroscope, le capteur de gravité doit utiliser l'accéléromètre et le magnétomètre en entrée.

Vecteur de rotation géomagnétique

Capteurs physiques sous-jacents : accéléromètre et magnétomètre (pas de gyroscope)

Mode de rapport : continu

Batterie faible

getDefaultSensor(SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR) renvoie un capteur non réveil

Un vecteur de rotation géomagnétique est similaire à un capteur de vecteur de rotation mais utilise un magnétomètre et pas de gyroscope.

Ce capteur doit être basé sur un magnétomètre. Il ne peut pas être mis en œuvre à l'aide d'un gyroscope et l'entrée du gyroscope ne peut pas être utilisée par ce capteur.

Voir le capteur de vecteur de rotation pour plus de détails sur la façon de définir sensors_event_t.data[0-4] .

Tout comme pour le capteur de vecteur de rotation, l'erreur de cap doit être inférieure à la précision estimée ( sensors_event_t.data[4] ) 95 % du temps.

Ce capteur doit être de faible puissance, il doit donc être implémenté dans le matériel.

Orientation (obsolète)

Capteurs physiques sous-jacents : accéléromètre, magnétomètre et (le cas échéant) gyroscope

Mode de rapport : continu

getDefaultSensor(SENSOR_TYPE_ORIENTATION) renvoie un capteur non réveil

Remarque : il s'agit d'un ancien type de capteur qui a été déprécié dans le SDK Android. Il a été remplacé par le capteur de vecteur de rotation, qui est plus clairement défini. Utilisez le capteur de vecteur de rotation sur le capteur d'orientation chaque fois que possible.

Un capteur d'orientation signale l'attitude de l'appareil. Les mesures sont rapportées en degrés dans les champs x, y et z de sensors_event_t.orientation :

• sensors_event_t.orientation.x : azimut, l'angle entre la direction du nord magnétique et l'axe Y, autour de l'axe Z ( 0<=azimuth<360 ). 0=Nord, 90=Est, 180=Sud, 270=Ouest.
• sensors_event_t.orientation.y : pitch, rotation autour de l'axe X ( -180<=pitch<=180 ), avec des valeurs positives lorsque l'axe Z se déplace vers l'axe Y.
• sensors_event_t.orientation.z : roll, rotation autour de l'axe Y ( -90<=roll<=90 ), avec des valeurs positives lorsque l'axe X se déplace vers l'axe Z.

Veuillez noter que pour des raisons historiques, l'angle de roulis est positif dans le sens des aiguilles d'une montre. (Mathématiquement parlant, il devrait être positif dans le sens antihoraire):

Figure 3. Orientation par rapport à un appareil

Cette définition est différente du lacet, du tangage et du roulis utilisés dans l'aviation où l'axe X est le long du côté long de l'avion (de la queue au nez).

Le capteur d'orientation signale également la précision à laquelle il s'attend à ce que ses lectures soient par le biais de sensors_event_t.orientation.status . Voir les SensorManager SENSOR_STATUS_* du SensorManager pour plus d'informations sur les valeurs possibles pour ce champ.

Capteurs non calibrés

Les capteurs non calibrés fournissent des résultats plus bruts et peuvent inclure un certain biais, mais contiennent également moins de "sauts" à partir des corrections appliquées par calibrage. Certaines applications peuvent préférer ces résultats non calibrés comme plus fluides et plus fiables. Par exemple, si une application tente de réaliser sa propre fusion de capteurs, l'introduction d'étalonnages peut en fait fausser les résultats.

Accéléromètre non calibré

Capteur physique sous-jacent : Accéléromètre

Mode de rapport : continu

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_UNCALIBRATED) renvoie un capteur de non-réveil

Un capteur d'accéléromètre non calibré signale l'accélération de l'appareil le long des trois axes du capteur sans aucune correction de biais (le biais d'usine et la compensation de température sont appliqués aux mesures non calibrées), ainsi qu'une estimation du biais. Toutes les valeurs sont en unités SI (m/s^2) et sont reportées dans les champs de sensors_event_t.uncalibrated_accelerometer :

• x_uncalib : accélération (sans compensation de biais) le long de l'axe X
• y_uncalib : accélération (sans compensation de biais) le long de l'axe Y
• z_uncalib : accélération (sans compensation de biais) le long de l'axe Z
• x_bias : biais estimé le long de l'axe X
• y_bias : biais estimé le long de l'axe Y
• z_bias : biais estimé le long de l'axe Z

Gyroscope non calibré

Capteur physique sous-jacent : Gyroscope

Mode de rapport : continu

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_UNCALIBRATED) renvoie un capteur de non-réveil

Un gyroscope non calibré rapporte le taux de rotation autour des axes du capteur sans leur appliquer de compensation de biais, ainsi qu'une estimation du biais. Toutes les valeurs sont en radians/seconde et sont reportées dans les champs de sensors_event_t.uncalibrated_gyro :

• x_uncalib : vitesse angulaire (sans compensation de dérive) autour de l'axe X
• y_uncalib : vitesse angulaire (sans compensation de dérive) autour de l'axe Y
• z_uncalib : vitesse angulaire (sans compensation de dérive) autour de l'axe Z
• x_bias : dérive estimée autour de l'axe X
• y_bias : dérive estimée autour de l'axe Y
• z_bias : dérive estimée autour de l'axe Z

Conceptuellement, la mesure non calibrée est la somme de la mesure calibrée et de l'estimation du biais : _uncalibrated = _calibrated + _bias .

Les x_bias , y_bias et z_bias sont censées sauter dès que l'estimation du biais change, et elles devraient être stables le reste du temps.

Voir la définition du capteur gyroscopique pour plus de détails sur le système de coordonnées utilisé.

L'étalonnage en usine et la compensation de température doivent être appliqués aux mesures. De plus, l'estimation de la dérive du gyroscope doit être mise en œuvre afin que des estimations raisonnables puissent être rapportées dans x_bias , y_bias et z_bias . Si l'implémentation n'est pas capable d'estimer la dérive, alors ce capteur ne doit pas être implémenté.

Si ce capteur est présent, le capteur Gyroscope correspondant doit également être présent et les deux capteurs doivent partager les mêmes valeurs sensor_t.name et sensor_t.vendor .

Champ magnétique non calibré

Capteur physique sous-jacent : Magnétomètre

Mode de rapport : continu

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED) renvoie un capteur non réveil

Un capteur de champ magnétique non étalonné signale le champ magnétique ambiant avec une estimation d'étalonnage en fer dur. Toutes les valeurs sont en micro-Tesla (uT) et sont rapportées dans les champs de sensors_event_t.uncalibrated_magnetic :

• x_uncalib : champ magnétique (sans compensation fer-dur) selon l'axe X
• y_uncalib : champ magnétique (sans compensation fer-dur) selon l'axe Y
• z_uncalib : champ magnétique (sans compensation fer-dur) selon l'axe Z
• x_bias : biais de fer dur estimé le long de l'axe X
• y_bias : biais de fer dur estimé le long de l'axe Y
• z_bias : biais de fer dur estimé le long de l'axe Z

Conceptuellement, la mesure non calibrée est la somme de la mesure calibrée et de l'estimation du biais : _uncalibrated = _calibrated + _bias .

Le magnétomètre non calibré permet à des algorithmes de niveau supérieur de gérer une mauvaise estimation du fer dur. Les x_bias , y_bias et z_bias devraient bondir dès que l'estimation du fer dur change, et elles devraient être stables le reste du temps.

L'étalonnage du fer doux et la compensation de température doivent être appliqués aux mesures. De plus, une estimation au fer dur doit être mise en œuvre afin que des estimations raisonnables puissent être rapportées dans x_bias , y_bias et z_bias . Si l'implémentation n'est pas capable d'estimer le biais, alors ce capteur ne doit pas être implémenté.

Si ce capteur est présent, le capteur de champ magnétique correspondant doit être présent et les deux capteurs doivent partager les mêmes valeurs sensor_t.name et sensor_t.vendor .

Angle de charnière

Mode de rapport : en cas de changement

getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) renvoie un capteur de réveil

Un capteur d'angle de charnière mesure l'angle, en degrés, entre deux parties intégrantes de l'appareil. Le mouvement d'une charnière mesuré par ce type de capteur devrait modifier les façons dont l'utilisateur peut interagir avec le dispositif, par exemple, en dépliant ou en révélant un affichage.

Capteurs composites interactifs

Certains capteurs sont principalement utilisés pour détecter les interactions avec l'utilisateur. 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] .

Limited axes IMU sensors

Available from Android 13, limited axes IMU sensors are sensors that support use cases where not all three axes (x, y, z) are available. Standard IMU types in Android (such as SENSOR_TYPE_ACCELEROMETER and SENSOR_TYPE_GYROSCOPE ) assume that all three axes are supported. However, not all form factors and devices support 3-axis accelerometers and 3-axis gyroscopes.

Accelerometer limited axes

Underlying physical sensors: Accelerometer

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES) returns a non-wake-up sensor

An accelerometer limited axes sensor is equivalent to TYPE_ACCELEROMETER but supports cases where one or two axes aren't supported.

The last three sensor event values reported by the sensor represent whether the acceleration value for the x, y, and z axes are supported. A value of 1.0 indicates that the axis is supported, and a value of 0 indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.

Device manufacturers must set the acceleration values for unused axes to 0 , instead of having undefined values.

Gyroscope limited axes

Underlying physical sensors: Gyroscope

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES) returns a non-wake-up sensor

A gyroscope limited axes sensor is equivalent to TYPE_GYROSCOPE but supports cases where one or two axes aren't supported.

The last three sensor event values reported by the sensor represent whether the angular speed value for the x, y, and z axes are supported. A value of 1.0 indicates that the axis is supported, and a value of 0 indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.

Device manufacturers must set the angular speed values for unused axes to 0 .

Accelerometer limited axes uncalibrated

Underlying physical sensors: Accelerometer

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED) returns a non-wake-up sensor

An accelerometer limited axes uncalibrated sensor is equivalent to TYPE_ACCELEROMETER_UNCALIBRATED but supports cases where one or two axes aren't supported.

The last three sensor event values reported by the sensor represent whether the acceleration and bias values for the x, y, and z axes are supported. A value of 1.0 indicates that the axis is supported, and a value of 0 indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.

Device manufacturers must set the acceleration and bias values for unused axes to 0 .

Gyroscope limited axes uncalibrated

Underlying physical sensors: Gyroscope

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED) returns a non-wake-up sensor

A gyroscope limited axes uncalibrated sensor is equivalent to TYPE_GYROSCOPE_UNCALIBRATED but supports cases where one or two axes aren't supported.

The last three sensor event values reported by the sensor represent whether the angular speed and drift values for the x, y, and z axes are supported. A value of 1.0 indicates that the axis is supported, and a value of 0 indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.

Device manufacturers must set the angular speed and drift values for unused axes to 0 .

Composite limited axes IMU

Underlying physical sensors: Any combination of 3-axis accelerometer, 3-axis gyroscope, 3-axis accelerometer uncalibrated, and 3-axis gyroscope uncalibrated sensors.

Reporting-mode: Continuous

A composite limited axes IMU sensor is equivalent to a limited axes IMU sensor but instead of being supported at the HAL, it converts the 3-axis sensor data into the equivalent limited axes variants. These composite sensors are only enabled for automotive devices.

The following table shows an example conversion from a standard 3-axis accelerometer to a composite limited axes accelerometer.

Automotive sensors

Sensors to support automotive use cases.

Heading

Underlying physical sensors: Any combination of GPS, magnetometer, accelerometer, and gyroscope.

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_HEADING) returns a non-wake-up sensor

Available from Android 13, a heading sensor measures the direction in which the device is pointing relative to true north in degrees. The heading sensor includes two SensorEvent values. One for the measured device heading and one for the accuracy of the provided heading value.

Heading values reported by this sensor must be between 0.0 (inclusive) and 360.0 (exclusive), with 0 indicating north, 90 east, 180 south, and 270 west.

Accuracy for this sensor is defined at 68 percent confidence. In the case where the underlying distribution is Gaussian normal, the accuracy is one standard deviation. For example, if the heading sensor returns a heading value of 60 degrees and an accuracy value of 10 degrees, there's a 68 percent probability of the true heading being between 50 degrees and 70 degrees.