Sensortypen

Dieser Abschnitt beschreibt Sensorachsen, Basissensoren und zusammengesetzte Sensoren (Aktivität, Lage, unkalibriert und Interaktion).

Sensorachsen

Sensorereigniswerte von vielen Sensoren werden in einem bestimmten Rahmen ausgedrückt, der relativ zum Gerät statisch ist.

Achsen für mobile Geräte

Die Sensor-API ist nur relativ zur natürlichen Ausrichtung des Bildschirms (Achsen werden nicht vertauscht, wenn sich die Bildschirmausrichtung des Geräts ändert.

Abbildung 1. Koordinatensystem (relativ zu einem mobilen Gerät), das von der Sensor-API verwendet wird

Kfz-Achsen

In Android Automotive-Implementierungen werden Achsen in Bezug auf den Fahrzeugkarosserierahmen definiert. Der Ursprung des Fahrzeugbezugssystems ist die Mitte der Hinterachse. Der Fahrzeugreferenzrahmen ist so ausgerichtet, dass:

• Die X-Achse zeigt nach rechts und liegt auf einer horizontalen Ebene senkrecht zur Symmetrieebene des Fahrzeugs.
• Die Y-Achse zeigt nach vorne und liegt auf einer horizontalen Ebene.

Abbildung 2. Koordinatensystem (relativ zu einem Fahrzeuggerät), das von der Sensor-API verwendet wird

Das Fahrzeugbezugssystem ist ein rechtshändiges Koordinatensystem. Daher zeigt die Z-Achse nach oben.

Die Z-Achse des Referenzrahmens ist auf die Schwerkraft ausgerichtet, was bedeutet, dass die X-Achse und die Y-Achse beide horizontal sind. Infolgedessen geht die Y-Achse möglicherweise nicht immer durch die Vorderachse.

Basissensoren

Basissensortypen werden nach den physischen Sensoren benannt, die sie darstellen. Diese Sensoren leiten Daten von einem einzelnen physischen Sensor weiter (im Gegensatz zu zusammengesetzten Sensoren, die Daten aus anderen Sensoren generieren). Beispiele für Basissensortypen sind:

• SENSOR_TYPE_ACCELEROMETER
• SENSOR_TYPE_GYROSCOPE
• SENSOR_TYPE_MAGNETOMETER

Basissensoren sind jedoch nicht gleichbedeutend mit ihrem zugrunde liegenden physischen Sensor und sollten nicht mit ihm verwechselt werden. Die Daten von einem Basissensor sind nicht die Rohausgabe des physischen Sensors, da Korrekturen (wie z. B. Bias-Kompensation und Temperaturkompensation) angewendet werden.

Beispielsweise können sich die Eigenschaften eines Basissensors in den folgenden Anwendungsfällen von den Eigenschaften seines zugrunde liegenden physischen Sensors unterscheiden:

• Ein Gyroskop-Chip mit einem Bias-Bereich von 1 Grad/Sek.
  • Nach der Werkskalibrierung werden Temperaturkompensation und Bias-Kompensation angewendet, die tatsächliche Bias des Android-Sensors wird reduziert, möglicherweise bis zu einem Punkt, an dem die Bias garantiert unter 0,01 Grad/Sekunde liegt.
  • In dieser Situation sagen wir, dass der Android-Sensor eine Abweichung von weniger als 0,01 Grad/Sek. hat, obwohl das Datenblatt des zugrunde liegenden Sensors 1 Grad/Sek.
• Ein Barometer mit einer Leistungsaufnahme von 100 uW.
  • Da die generierten Daten vom Chip zum SoC transportiert werden müssen, können die tatsächlichen Stromkosten zum Sammeln von Daten vom Barometer-Android-Sensor viel höher sein, beispielsweise 1000 uW.
  • In dieser Situation sagen wir, dass der Android-Sensor einen Stromverbrauch von 1000 uW hat, obwohl der am Barometer-Chip gemessene Stromverbrauch 100 uW beträgt.
• Ein Magnetometer, das beim Kalibrieren 100 uW verbraucht, beim Kalibrieren jedoch mehr verbraucht.
  • Seine Kalibrierungsroutine erfordert möglicherweise die Aktivierung des Gyroskops, das 5000 uW verbraucht, und die Ausführung eines Algorithmus, was weitere 900 uW kostet.
  • In dieser Situation sagen wir, dass der maximale Stromverbrauch des (Magnetometer-) Android-Sensors 6000 uW beträgt.
  • In diesem Fall ist der durchschnittliche Stromverbrauch das sinnvollere Maß, und es ist das, was in den statischen Eigenschaften des Sensors durch die HAL gemeldet wird.

Beschleunigungsmesser

Reporting-Modus: Kontinuierlich

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER) gibt einen Nicht- Aktivierungssensor zurück

Ein Beschleunigungssensor meldet die Beschleunigung des Geräts entlang der drei Sensorachsen. Die gemessene Beschleunigung umfasst sowohl die physikalische Beschleunigung (Geschwindigkeitsänderung) als auch die Schwerkraft. Die Messung wird in den x-, y- und z-Feldern von sensors_event_t.acceleration gemeldet.

Alle Werte sind in SI-Einheiten (m/s^2) und messen die Beschleunigung des Geräts abzüglich der Schwerkraft entlang der drei Sensorachsen.

Hier sind Beispiele:

• Die Norm von (x, y, z) sollte im freien Fall nahe 0 sein.
• Wenn das Gerät flach auf einem Tisch liegt und auf der linken Seite nach rechts geschoben wird, ist der Beschleunigungswert x positiv.
• Wenn das Gerät flach auf einem Tisch liegt, beträgt der Beschleunigungswert entlang z +9,81 alo, was der Beschleunigung des Geräts (0 m/s^2) minus der Schwerkraft (-9,81 m/s^2) entspricht.
• Wenn das Gerät flach auf einem Tisch liegt und gen Himmel geschoben wird, ist der Beschleunigungswert größer als +9,81, was der Beschleunigung des Geräts (+A·m/s^2) minus der Schwerkraft (–9,81 m) entspricht /s^2).

Die Messwerte werden kalibriert mit:

• Temperaturkompensation
• Online-Bias-Kalibrierung
• Waagenkalibrierung online

Die Bias- und Skalenkalibrierung darf nur bei deaktiviertem Sensor aktualisiert werden, um beim Streaming keine Wertesprünge zu verursachen.

Der Beschleunigungsmesser meldet auch, wie genau seine Messwerte über sensors_event_t.acceleration.status erwartet werden. Weitere Informationen zu möglichen Werten für dieses Feld finden Sie in den Konstanten SENSOR_STATUS_* des SensorManager .

Umgebungstemperatur

Meldemodus: Bei Änderung

getDefaultSensor(SENSOR_TYPE_AMBIENT_TEMPERATURE) gibt einen Nicht- Aktivierungssensor zurück

Dieser Sensor liefert die Umgebungs- (Raum-) Temperatur in Grad Celsius.

Magnetfeldsensor

Reporting-Modus: Kontinuierlich

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD) gibt einen Nicht- Aktivierungssensor zurück

SENSOR_TYPE_GEOMAGNETIC_FIELD == SENSOR_TYPE_MAGNETIC_FIELD

Ein Magnetfeldsensor (auch Magnetometer genannt) meldet das Umgebungsmagnetfeld, gemessen entlang der drei Sensorachsen.

Die Messung wird in den x-, y- und z-Feldern von sensors_event_t.magnetic und alle Werte sind in Mikro-Tesla (uT) angegeben.

Das Magnetometer meldet auch, wie genau es seine Messwerte erwartet, durch sensors_event_t.magnetic.status . Weitere Informationen zu möglichen Werten für dieses Feld finden Sie in den Konstanten SENSOR_STATUS_* des SensorManager .

Die Messwerte werden kalibriert mit:

• Temperaturkompensation
• Werkseitige (oder Online-) Weicheisenkalibrierung
• Online-Harteisenkalibrierung

Gyroskop

Reporting-Modus: Kontinuierlich

getDefaultSensor(SENSOR_TYPE_GYROSCOPE) gibt einen Nicht- Aktivierungssensor zurück

Ein Gyroskopsensor meldet die Rotationsgeschwindigkeit des Geräts um die drei Sensorachsen.

Die Rotation im Gegenuhrzeigersinn ist positiv (Rechte-Hand-Regel). Das heißt, ein Beobachter, der von einem positiven Ort auf der x-, y- oder z-Achse auf ein Gerät blickt, das auf dem Ursprung positioniert ist, würde eine positive Drehung melden, wenn das Gerät scheinbar gegen den Uhrzeigersinn rotiert. Beachten Sie, dass dies die mathematische Standarddefinition der positiven Rotation ist und nicht mit der Luft- und Raumfahrtdefinition des Rollens übereinstimmt.

Die Messung wird in den x-, y- und z-Feldern von sensors_event_t.gyro und alle Werte sind in Radiant pro Sekunde (rad/s).

Die Messwerte werden kalibriert mit:

• Temperaturkompensation
• Waagenkompensation ab Werk (oder online).
• Online-Bias-Kalibrierung (um Drift zu entfernen)

Das Gyroskop meldet auch, wie genau seine Messwerte über sensors_event_t.gyro.status erwartet werden. Weitere Informationen zu möglichen Werten für dieses Feld finden Sie in den Konstanten SENSOR_STATUS_* des SensorManager .

Das Gyroskop kann nicht basierend auf Magnetometern und Beschleunigungsmessern emuliert werden, da dies dazu führen würde, dass es eine verringerte lokale Konsistenz und Reaktionsfähigkeit aufweist. Es muss auf einem üblichen Gyroskop-Chip basieren.

Pulsschlag

Meldemodus: Bei Änderung

getDefaultSensor(SENSOR_TYPE_HEART_RATE) gibt einen Nicht- Aktivierungssensor zurück

Ein Herzfrequenzsensor meldet die aktuelle Herzfrequenz der Person, die das Gerät berührt.

Die aktuelle Herzfrequenz in Schlägen pro Minute (BPM) wird in sensors_event_t.heart_rate.bpm gemeldet und der Status des Sensors wird in sensors_event_t.heart_rate.status gemeldet. Weitere Informationen zu möglichen Werten für dieses Feld finden Sie in den Konstanten SENSOR_STATUS_* des SensorManager . Insbesondere muss bei der ersten Aktivierung das Statusfeld des ersten Ereignisses auf SENSOR_STATUS_UNRELIABLE gesetzt werden, es sei denn, es ist bekannt, dass sich das Gerät nicht am Körper befindet. Da sich dieser Sensor bei Änderungen befindet, werden Ereignisse nur dann generiert, wenn sich heart_rate.bpm oder heart_rate.status seit dem letzten Ereignis geändert haben. Die Ereignisse werden nicht schneller als jede sampling_period generiert.

sensor_t.requiredPermission ist immer SENSOR_PERMISSION_BODY_SENSORS .

Licht

Meldemodus: Bei Änderung

getDefaultSensor(SENSOR_TYPE_LIGHT) gibt einen Nicht- Aktivierungssensor zurück

Ein Lichtsensor meldet die aktuelle Beleuchtung in SI-Lux-Einheiten.

Die Messung wird in sensors_event_t.light gemeldet.

Nähe

Meldemodus: Bei Änderung

Üblicherweise als Wecksensor definiert

getDefaultSensor(SENSOR_TYPE_PROXIMITY) gibt einen Wecksensor zurück

Ein Näherungssensor meldet die Entfernung vom Sensor zur nächsten sichtbaren Oberfläche.

Bis Android 4.4 waren die Näherungssensoren immer Wecksensoren, die den SoC aufweckten, wenn sie eine Änderung der Nähe erkannten. Nach Android 4.4 empfehlen wir, zuerst die Wake-up-Version dieses Sensors zu implementieren, da dieser zum Ein- und Ausschalten des Bildschirms beim Telefonieren verwendet wird.

Die Messung wird in Sensoren_event_t.distance in Zentimetern sensors_event_t.distance . Beachten Sie, dass einige Näherungssensoren nur eine binäre „Nah“- oder „Fern“-Messung unterstützen. In diesem Fall meldet der Sensor im Zustand „fern“ seinen Wert sensor_t.maxRange und im Zustand „nah“ einen Wert kleiner als sensor_t.maxRange .

Druck

Reporting-Modus: Kontinuierlich

getDefaultSensor(SENSOR_TYPE_PRESSURE) gibt einen nicht aktivierten Sensor zurück

Ein Drucksensor (auch Barometer genannt) meldet den Luftdruck in Hektopascal (hPa).

Die Messwerte werden mit kalibriert

• Temperaturkompensation
• Werkseitige Bias-Kalibrierung
• Kalibrierung im Werksmaßstab

Das Barometer wird oft verwendet, um Höhenänderungen abzuschätzen. Um die absolute Höhe abzuschätzen, muss der Meeresspiegeldruck (der sich je nach Wetter ändert) als Referenz verwendet werden.

Relative Luftfeuchtigkeit

Meldemodus: Bei Änderung

getDefaultSensor(SENSOR_TYPE_RELATIVE_HUMIDITY) gibt einen Nicht- Aktivierungssensor zurück

Ein Relative-Feuchte-Sensor misst die relative Luftfeuchtigkeit der Umgebung und gibt einen Wert in Prozent zurück.

Zusammengesetzte Sensortypen

Ein zusammengesetzter Sensor erzeugt Daten, indem er Daten von einem oder mehreren physikalischen Sensoren verarbeitet und/oder fusioniert. (Jeder Sensor, der kein Basissensor ist, wird als zusammengesetzter Sensor bezeichnet.) Beispiele für zusammengesetzte Sensoren sind:

• Schrittdetektor und signifikante Bewegung , die normalerweise auf einem Beschleunigungsmesser basieren, aber auch auf anderen Sensoren basieren könnten, wenn der Stromverbrauch und die Genauigkeit akzeptabel wären.
• Spielrotationsvektor , basierend auf einem Beschleunigungsmesser und einem Gyroskop.
• Unkalibriertes Gyroskop , das dem Gyroskop-Basissensor ähnelt, wobei jedoch die Bias-Kalibrierung separat gemeldet wird, anstatt in der Messung korrigiert zu werden.

Wie bei Basissensoren stammen die Eigenschaften der zusammengesetzten Sensoren aus den Eigenschaften ihrer endgültigen Daten. Beispielsweise ist der Stromverbrauch eines Spielrotationsvektors wahrscheinlich gleich der Summe des Stromverbrauchs des Beschleunigungsmesser-Chips, des Gyroskop-Chips, des Chips, der die Daten verarbeitet, und der Busse, die die Daten transportieren. Als weiteres Beispiel hängt die Drift eines Wildrotationsvektors sowohl von der Qualität des Kalibrierungsalgorithmus als auch von den physikalischen Sensoreigenschaften ab.

Die folgende Tabelle listet verfügbare Verbundsensortypen auf. Jeder zusammengesetzte Sensor stützt sich auf Daten von einem oder mehreren physikalischen Sensoren. Vermeiden Sie es, andere zugrunde liegende physische Sensoren auszuwählen, um die Ergebnisse anzunähern, da diese eine schlechte Benutzererfahrung bieten.

Sensorart	Kategorie	Zugrunde liegende physikalische Sensoren	Meldemodus
Rotationsvektor des Spiels	Attitüde	Beschleunigungsmesser, Gyroskop, Magnetometer DÜRFEN NICHT VERWENDET WERDEN	Kontinuierlich
Geomagnetischer Rotationsvektor	Attitüde	Beschleunigungsmesser, Magnetometer, Gyroskop DARF NICHT VERWENDET WERDEN	Kontinuierlich
Blickgeste	Interaktion	Nicht definiert	One-Shot
Schwere	Attitüde	Beschleunigungsmesser, Gyroskop	Kontinuierlich
Gyroskop unkalibriert	Unkalibriert	Gyroskop	Kontinuierlich
Lineare Beschleunigung	Aktivität	Beschleunigungsmesser, Gyroskop (falls vorhanden) oder Magnetometer (falls kein Gyroskop vorhanden)	Kontinuierlich
Magnetfeld unkalibriert	Unkalibriert	Magnetometer	Kontinuierlich
Ausrichtung (veraltet)	Attitüde	Beschleunigungsmesser, Magnetometer, Gyroskop (falls vorhanden)	Kontinuierlich
Abholgeste	Interaktion	Nicht definiert	One-Shot
Rotationsvektor	Attitüde	Beschleunigungsmesser, Magnetometer, Gyroskop	Kontinuierlich
Bedeutende Bewegung	Aktivität	Beschleunigungsmesser (oder ein anderer, solange sehr geringer Stromverbrauch)	One-Shot
Schrittzähler	Aktivität	Beschleunigungsmesser	Bei Änderung
Schrittdetektor	Aktivität	Beschleunigungsmesser	Speziell
Neigungsdetektor	Aktivität	Beschleunigungsmesser	Speziell
Geste zum Aufwachen	Interaktion	Nicht definiert	One-Shot

= Low-Power-Sensor

Aktivitäts-Verbundsensoren

Lineare Beschleunigung

Zugrunde liegende physikalische Sensoren: Beschleunigungsmesser und (falls vorhanden) Gyroskop (oder Magnetometer, falls Gyroskop nicht vorhanden)

Reporting-Modus: Kontinuierlich

getDefaultSensor(SENSOR_TYPE_LINEAR_ACCELERATION) gibt einen Nicht- Aktivierungssensor zurück

Ein linearer Beschleunigungssensor meldet die lineare Beschleunigung des Geräts im Sensorrahmen, ohne die Schwerkraft.

Die Ausgabe ist konzeptionell: Ausgabe des Beschleunigungsmessers minus Ausgabe des Schwerkraftsensors . Sie wird in m/s^2 in den x-, y- und z-Feldern von sensors_event_t.acceleration .

Die Messwerte auf allen Achsen sollten nahe 0 sein, wenn das Gerät nicht bewegt wird.

Wenn das Gerät über ein Gyroskop verfügt, muss der lineare Beschleunigungssensor das Gyroskop und den Beschleunigungsmesser als Eingang verwenden.

Wenn das Gerät kein Gyroskop besitzt, muss der lineare Beschleunigungssensor den Beschleunigungsmesser und den Magnetometer als Eingang verwenden.

Bedeutende Bewegung

Zugrundeliegender physikalischer Sensor: Beschleunigungsmesser (oder ein anderer, solange er wenig Strom hat)

Meldemodus: One-Shot

Geringer Strom

Implementieren Sie nur die Aktivierungsversion dieses Sensors.

getDefaultSensor(SENSOR_TYPE_SIGNIFICANT_MOTION) gibt einen Wecksensor zurück

Ein Detektor für signifikante Bewegungen löst aus, wenn er eine signifikante Bewegung erkennt: eine Bewegung, die zu einer Änderung des Standorts des Benutzers führen könnte.

Beispiele für solche bedeutenden Bewegungen sind:

• Wandern oder Radfahren
• Sitzen in einem fahrenden Auto, Bus oder Zug

Beispiele für Situationen, die keine signifikante Bewegung auslösen:

• Telefon in der Tasche und Person bewegt sich nicht
• Das Telefon liegt auf einem Tisch und der Tisch wackelt ein wenig aufgrund des Verkehrs oder der Waschmaschine in der Nähe

Auf der hohen Ebene wird der signifikante Bewegungsdetektor verwendet, um den Stromverbrauch der Standortbestimmung zu reduzieren. Wenn die Lokalisierungsalgorithmen erkennen, dass das Gerät statisch ist, können sie in einen Energiesparmodus wechseln, in dem sie auf eine erhebliche Bewegung angewiesen sind, um das Gerät aufzuwecken, wenn der Benutzer den Standort wechselt.

Dieser Sensor muss eine geringe Leistung haben. Es macht einen Kompromiss für den Stromverbrauch, der zu einer kleinen Menge falscher negativer Ergebnisse führen kann. Dies geschieht aus mehreren Gründen:

• Das Ziel dieses Sensors ist es, Strom zu sparen.
• Das Auslösen eines Ereignisses, wenn sich der Benutzer nicht bewegt (falsch positiv), ist energieintensiv und sollte daher vermieden werden.
• Es ist akzeptabel, kein Ereignis auszulösen, wenn sich der Benutzer bewegt (falsch negativ), solange dies nicht wiederholt geschieht. Wenn der Benutzer 10 Sekunden lang gegangen ist, ist es nicht akzeptabel, innerhalb dieser 10 Sekunden kein Ereignis auszulösen.

Jedes Sensorereignis meldet 1 in sensors_event_t.data[0] .

Schrittdetektor

Zugrundeliegender physikalischer Sensor: Beschleunigungsmesser (+ möglicherweise andere, solange niedriger Stromverbrauch)

Meldemodus: Spezial (ein Ereignis pro gemachtem Schritt)

Geringer Strom

getDefaultSensor(SENSOR_TYPE_STEP_DETECTOR) gibt einen Nicht- Aktivierungssensor zurück

Ein Schrittdetektor generiert jedes Mal ein Ereignis, wenn der Benutzer einen Schritt macht.

Der Zeitstempel des Ereignisses sensors_event_t.timestamp entspricht dem Aufsetzen des Fußes auf den Boden, wodurch eine hohe Beschleunigungsschwankung erzeugt wird.

Im Vergleich zum Schrittzähler sollte der Schrittdetektor eine geringere Latenz haben (weniger als zwei Sekunden). Sowohl der Schrittdetektor als auch der Schrittzähler erkennen, wenn der Benutzer geht, läuft und die Treppe hinaufgeht. Sie sollten nicht ausgelöst werden, wenn der Benutzer Rad fährt, fährt oder in anderen Fahrzeugen sitzt.

Dieser Sensor muss eine geringe Leistung haben. Das heißt, wenn die Schritterkennung nicht in Hardware durchgeführt werden kann, sollte dieser Sensor nicht definiert werden. Insbesondere wenn der Schrittdetektor aktiviert ist und der Beschleunigungsmesser nicht, sollten nur Schritte Interrupts auslösen (nicht jeder Messwert des Beschleunigungsmessers).

sampling_period_ns hat keinen Einfluss auf Schrittdetektoren.

Jedes Sensorereignis meldet 1 in sensors_event_t.data[0] .

Schrittzähler

Zugrundeliegender physikalischer Sensor: Beschleunigungsmesser (+ möglicherweise andere, solange niedriger Stromverbrauch)

Meldemodus: Bei Änderung

Geringer Strom

getDefaultSensor(SENSOR_TYPE_STEP_COUNTER) gibt einen Nicht- Aktivierungssensor zurück

Ein Schrittzähler meldet die Anzahl der Schritte, die der Benutzer seit dem letzten Neustart im aktivierten Zustand zurückgelegt hat.

Die Messung wird als uint64_t in sensors_event_t.step_counter und nur bei einem Systemneustart auf Null zurückgesetzt.

Der Zeitstempel des Ereignisses wird auf die Zeit gesetzt, zu der der letzte Schritt für dieses Ereignis unternommen wurde.

Siehe Sensortyp Schrittdetektor für die Bedeutung der Zeit eines Schritts.

Im Vergleich zum Schrittdetektor kann der Schrittzähler eine höhere Latenz haben (bis zu 10 Sekunden). Dank dieser Latenz hat dieser Sensor eine hohe Genauigkeit; Die Schrittzahl nach einem ganzen Tag mit Maßnahmen sollte innerhalb von 10 % der tatsächlichen Schrittzahl liegen. Sowohl der Schrittdetektor als auch der Schrittzähler erkennen, wenn der Benutzer geht, läuft und die Treppe hinaufgeht. Sie sollten nicht ausgelöst werden, wenn der Benutzer Rad fährt, fährt oder in anderen Fahrzeugen sitzt.

Die Hardware muss sicherstellen, dass die interne Schrittzahl niemals überläuft. Die Mindestgröße des internen Zählers der Hardware soll 16 Bit betragen. Im Falle eines bevorstehenden Überlaufs (höchstens alle ~2^16 Schritte) kann der SoC aufgeweckt werden, damit der Treiber die Zählerwartung durchführen kann.

Wie in Interaktion angegeben, darf dieser Sensor, während er arbeitet, keine anderen Sensoren stören, insbesondere den Beschleunigungsmesser, der sehr wohl in Gebrauch sein könnte.

Wenn ein bestimmtes Gerät diese Betriebsarten nicht unterstützen kann, darf dieser Sensortyp nicht von der HAL gemeldet werden. Das heißt, es ist nicht akzeptabel, diesen Sensor in der HAL zu "emulieren".

Dieser Sensor muss eine geringe Leistung haben. Das heißt, wenn die Schritterkennung nicht in Hardware erfolgen kann, sollte dieser Sensor nicht definiert werden. Insbesondere wenn der Schrittzähler aktiviert ist und der Beschleunigungsmesser nicht, sollten nur Schritte Interrupts auslösen (keine Beschleunigungsmesserdaten).

Neigungsdetektor

Zugrundeliegender physikalischer Sensor: Beschleunigungsmesser (+ möglicherweise andere, solange niedriger Stromverbrauch)

Meldemodus: Spezial

Geringer Strom

Implementieren Sie nur die Aktivierungsversion dieses Sensors.

getDefaultSensor(SENSOR_TYPE_TILT_DETECTOR) gibt einen Wecksensor zurück

Ein Neigungsdetektor erzeugt jedes Mal ein Ereignis, wenn ein Neigungsereignis erkannt wird.

Ein Neigungsereignis wird durch die Richtung der durchschnittlichen Schwerkraft des 2-Sekunden-Fensters definiert, die sich seit der Aktivierung oder dem letzten vom Sensor erzeugten Ereignis um mindestens 35 Grad ändert. Hier ist der Algorithmus:

• reference_estimated_gravity = Durchschnitt der Beschleunigungsmessermessungen über die erste Sekunde nach der Aktivierung oder die geschätzte Schwerkraft, als das letzte Neigungsereignis erzeugt wurde.
• current_estimated_gravity = Durchschnitt der Beschleunigungsmessermessungen der letzten 2 Sekunden.
• Trigger wenn angle(reference_estimated_gravity, current_estimated_gravity) > 35 degrees

Große Beschleunigungen ohne Änderung der Telefonausrichtung sollten kein Neigungsereignis auslösen. Beispielsweise sollte eine scharfe Kurve oder starke Beschleunigung beim Autofahren kein Neigungsereignis auslösen, auch wenn der Winkel der durchschnittlichen Beschleunigung um mehr als 35 Grad variieren kann. Typischerweise wird dieser Sensor nur mit Hilfe eines Beschleunigungsmessers implementiert. Andere Sensoren können ebenfalls verwendet werden, wenn sie den Stromverbrauch nicht wesentlich erhöhen. Dies ist ein Low-Power-Sensor, der es dem SoC ermöglichen sollte, in den Suspend-Modus zu wechseln. Emulieren Sie diesen Sensor nicht in der HAL. Jedes Sensorereignis meldet 1 in sensors_event_t.data[0] .

Composite-Sensoren für die Lage

Rotationsvektor

Zugrunde liegende physikalische Sensoren: Beschleunigungsmesser, Magnetometer und Gyroskop

Reporting-Modus: Kontinuierlich

getDefaultSensor(SENSOR_TYPE_ROTATION_VECTOR) gibt einen Nicht- Aktivierungssensor zurück

Ein Rotationsvektorsensor meldet die Ausrichtung des Geräts relativ zum Ost-Nord-Oben-Koordinatenrahmen. Es wird normalerweise durch Integration von Beschleunigungsmesser-, Gyroskop- und Magnetometermesswerten erhalten. Das East-North-Up-Koordinatensystem ist als direkte orthonormale Basis definiert, wobei:

• X zeigt nach Osten und ist tangential zum Boden.
• Y zeigt nach Norden und ist tangential zum Boden.
• Z zeigt zum Himmel und steht senkrecht zum Boden.

Die Ausrichtung des Telefons wird durch die Drehung dargestellt, die erforderlich ist, um die Ost-Nord-Oben-Koordinaten mit den Koordinaten des Telefons auszurichten. Das heißt, das Anwenden der Drehung auf den Weltrahmen (X, Y, Z) würde sie an den Telefonkoordinaten (x, y, z) ausrichten.

Die Drehung kann als Drehen des Telefons um einen Winkel Theta um eine Achse rot_axis werden, um von der Referenzgeräteausrichtung (Ost-Nord-oben ausgerichtet) zu der aktuellen Geräteausrichtung zu gelangen. Die Drehung wird als die vier einheitslosen x-, y-, z-, w-Komponenten einer Einheitsquaternion kodiert:

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

Wo:

• Die x-, y- und z-Felder von rot_axis sind die Ost-Nord-Oben-Koordinaten eines Einheitslängenvektors, der die Rotationsachse darstellt
• theta ist der Rotationswinkel

Die Quaternion ist eine Einheitsquaternion: Sie muss die Norm 1 haben. Wird dies nicht sichergestellt, führt dies zu fehlerhaftem Verhalten des Clients.

Zusätzlich meldet dieser Sensor eine geschätzte Kursgenauigkeit:

sensors_event_t.data[4] = estimated_accuracy (in Radiant)

Der Steuerkursfehler muss in 95 % der Fälle kleiner als estimated_accuracy sein. Dieser Sensor muss ein Gyroskop als Haupteingabe für die Orientierungsänderung verwenden.

Dieser Sensor verwendet auch Beschleunigungsmesser- und Magnetometereingaben, um die Gyroskopdrift auszugleichen, und er kann nicht nur mit Beschleunigungsmesser und Magnetometer implementiert werden.

Rotationsvektor des Spiels

Zugrunde liegende physikalische Sensoren: Beschleunigungsmesser und Gyroskop (kein Magnetometer)

Reporting-Modus: Kontinuierlich

getDefaultSensor(SENSOR_TYPE_GAME_ROTATION_VECTOR) gibt einen Nicht- Aktivierungssensor zurück

Ein Wildrotationsvektorsensor ähnelt einem Rotationsvektorsensor, verwendet jedoch nicht das Erdmagnetfeld. Daher zeigt die Y-Achse nicht nach Norden, sondern auf eine andere Referenz. Diese Referenz darf um die gleiche Größenordnung driften wie das Gyroskop um die Z-Achse driftet.

Einzelheiten zum Festlegen von sensors_event_t.data[0-3] Sie unter Rotationsvektorsensor . Dieser Sensor meldet keine geschätzte Kursgenauigkeit: sensors_event_t.data[4] ist reserviert und sollte auf 0 gesetzt werden.

Im Idealfall sollte ein Telefon, das gedreht und in dieselbe reale Ausrichtung zurückgebracht wird, denselben Spielrotationsvektor melden.

Dieser Sensor muss auf einem Gyroskop und einem Beschleunigungsmesser basieren. Es kann kein Magnetometer als Eingabe verwenden, außer indirekt durch Schätzung der Gyroskop-Vorspannung.

Schwere

Zugrunde liegende physikalische Sensoren: Beschleunigungsmesser und (falls vorhanden) Gyroskop (oder Magnetometer, falls Gyroskop nicht vorhanden)

Reporting-Modus: Kontinuierlich

getDefaultSensor(SENSOR_TYPE_GRAVITY) gibt einen nicht aktivierten Sensor zurück

Ein Schwerkraftsensor meldet die Richtung und Größe der Schwerkraft in den Koordinaten des Geräts.

Die Gravitationsvektorkomponenten werden in m/s^2 in den x-, y- und z-Feldern von sensors_event_t.acceleration .

Wenn sich das Gerät im Ruhezustand befindet, sollte die Ausgabe des Schwerkraftsensors mit der des Beschleunigungsmessers identisch sein. Auf der Erde beträgt die Magnitude etwa 9,8 m/s^2.

Wenn das Gerät über ein Gyroskop verfügt, muss der Schwerkraftsensor das Gyroskop und den Beschleunigungsmesser als Eingang verwenden.

Wenn das Gerät kein Gyroskop besitzt, muss der Schwerkraftsensor den Beschleunigungsmesser und den Magnetometer als Eingang verwenden.

Geomagnetischer Rotationsvektor

Zugrunde liegende physikalische Sensoren: Beschleunigungsmesser und Magnetometer (kein Gyroskop)

Reporting-Modus: Kontinuierlich

Geringer Strom

getDefaultSensor(SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR) gibt einen Nicht- Aktivierungssensor zurück

Ein geomagnetischer Rotationsvektor ähnelt einem Rotationsvektorsensor, verwendet jedoch ein Magnetometer und kein Gyroskop.

Dieser Sensor muss auf einem Magnetometer basieren. Es kann nicht mit einem Gyroskop implementiert werden, und der Gyroskopeingang kann von diesem Sensor nicht verwendet werden.

Einzelheiten zum Festlegen von sensors_event_t.data[0-4] Sie unter Rotationsvektorsensor .

Genau wie beim Rotationsvektorsensor muss der Kursfehler zu 95 % der Zeit unter der geschätzten Genauigkeit ( sensors_event_t.data[4] ) liegen.

Dieser Sensor muss einen geringen Stromverbrauch haben, also muss er in Hardware implementiert werden.

Ausrichtung (veraltet)

Zugrunde liegende physikalische Sensoren: Beschleunigungsmesser, Magnetometer und (falls vorhanden) Gyroskop

Reporting-Modus: Kontinuierlich

getDefaultSensor(SENSOR_TYPE_ORIENTATION) gibt einen Nicht- Aktivierungssensor zurück

Hinweis: Dies ist ein älterer Sensortyp, der im Android SDK veraltet ist. Er wurde durch den klarer definierten Rotationsvektorsensor ersetzt. Verwenden Sie nach Möglichkeit den Rotationsvektorsensor anstelle des Ausrichtungssensors.

Ein Orientierungssensor meldet die Lage des Geräts. Die Messungen werden in Grad in den x-, y- und z-Feldern von sensors_event_t.orientation :

• sensors_event_t.orientation.x : Azimut, der Winkel zwischen der magnetischen Nordrichtung und der Y-Achse um die Z-Achse ( 0<=azimuth<360 ). 0=Norden, 90=Osten, 180=Süden, 270=Westen.
• sensors_event_t.orientation.y : Pitch, Drehung um die X-Achse ( -180<=pitch<=180 ), mit positiven Werten, wenn sich die Z-Achse in Richtung der Y-Achse bewegt.
• sensors_event_t.orientation.z : roll, Drehung um die Y-Achse ( -90<=roll<=90 ), mit positiven Werten, wenn sich die X-Achse in Richtung der Z-Achse bewegt.

Bitte beachten Sie, dass der Rollwinkel aus historischen Gründen im Uhrzeigersinn positiv ist. (Mathematisch gesehen sollte es gegen den Uhrzeigersinn positiv sein):

Diese Definition unterscheidet sich von Gieren, Nicken und Rollen, die in der Luftfahrt verwendet werden, wo sich die X-Achse entlang der langen Seite des Flugzeugs (Heck bis Nase) befindet.

Der Orientierungssensor meldet auch, wie genau seine Messwerte über sensors_event_t.orientation.status erwartet werden. Weitere Informationen zu möglichen Werten für dieses Feld finden Sie in den Konstanten SENSOR_STATUS_* des SensorManager .

Nicht kalibrierte Sensoren

Unkalibrierte Sensoren liefern rohere Ergebnisse und können eine gewisse Abweichung enthalten, enthalten aber auch weniger "Sprünge" von Korrekturen, die durch Kalibrierung angewendet werden. Einige Apps bevorzugen diese unkalibrierten Ergebnisse möglicherweise als glatter und zuverlässiger. Wenn beispielsweise eine App versucht, ihre eigene Sensorfusion durchzuführen, kann das Einführen von Kalibrierungen die Ergebnisse tatsächlich verfälschen.

Beschleunigungsmesser nicht kalibriert

Zugrunde liegender physikalischer Sensor: Beschleunigungsmesser

Reporting-Modus: Kontinuierlich

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_UNCALIBRATED) gibt einen nicht aktivierten Sensor zurück

Ein unkalibrierter Beschleunigungssensor meldet die Beschleunigung des Geräts entlang der drei Sensorachsen ohne Bias-Korrektur (werkseitige Bias und Temperaturkompensation werden auf unkalibrierte Messungen angewendet) zusammen mit einer Bias-Schätzung. Alle Werte sind in SI-Einheiten (m/s^2) und werden in den Feldern von sensors_event_t.uncalibrated_accelerometer :

• x_uncalib : Beschleunigung (ohne Bias-Kompensation) entlang der X-Achse
• y_uncalib : Beschleunigung (ohne Bias-Kompensation) entlang der Y-Achse
• z_uncalib : Beschleunigung (ohne Bias-Kompensation) entlang der Z-Achse
• x_bias : geschätzte Abweichung entlang der X-Achse
• y_bias : geschätzte Abweichung entlang der Y-Achse
• z_bias : geschätzte Abweichung entlang der Z-Achse

Gyroskop unkalibriert

Zugrundeliegender physikalischer Sensor: Gyroskop

Reporting-Modus: Kontinuierlich

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_UNCALIBRATED) gibt einen nicht aktivierten Sensor zurück

Ein unkalibriertes Gyroskop meldet die Rotationsgeschwindigkeit um die Sensorachsen, ohne eine Bias-Kompensation auf sie anzuwenden, zusammen mit einer Bias-Schätzung. Alle Werte sind in Radiant/Sekunde und werden in den Feldern von sensors_event_t.uncalibrated_gyro :

• x_uncalib : Winkelgeschwindigkeit (ohne Driftkompensation) um die X-Achse
• y_uncalib : Winkelgeschwindigkeit (ohne Driftkompensation) um die Y-Achse
• z_uncalib : Winkelgeschwindigkeit (ohne Driftkompensation) um die Z-Achse
• x_bias : geschätzte Drift um die X-Achse
• y_bias : geschätzte Abweichung um die Y-Achse
• z_bias : geschätzte Drift um die Z-Achse

Konzeptionell ist die unkalibrierte Messung die Summe der kalibrierten Messung und der Bias-Schätzung: _uncalibrated = _calibrated + _bias .

Es wird erwartet, dass die Werte x_bias , y_bias und z_bias springen, sobald sich die Schätzung der Abweichung ändert, und sie sollten für den Rest der Zeit stabil sein.

Einzelheiten zum verwendeten Koordinatensystem finden Sie in der Definition des Gyroskopsensors .

Die Messungen müssen werkseitig kalibriert und temperaturkompensiert werden. Außerdem muss eine Gyroskop-Driftschätzung implementiert werden, damit vernünftige Schätzungen in x_bias , y_bias und z_bias gemeldet werden können. Wenn die Implementierung die Drift nicht abschätzen kann, darf dieser Sensor nicht implementiert werden.

Wenn dieser Sensor vorhanden ist, muss auch der entsprechende Gyroskop-Sensor vorhanden sein und beide Sensoren müssen dieselben sensor_t.name und sensor_t.vendor Werte aufweisen.

Magnetfeld unkalibriert

Zugrundeliegender physikalischer Sensor: Magnetometer

Reporting-Modus: Kontinuierlich

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED) gibt einen nicht aktivierten Sensor zurück

Ein unkalibrierter Magnetfeldsensor meldet das Umgebungsmagnetfeld zusammen mit einer Schätzung der Harteisenkalibrierung. Alle Werte sind in Mikro-Tesla (uT) angegeben und werden in den Feldern von sensors_event_t.uncalibrated_magnetic :

• x_uncalib : Magnetfeld (ohne Harteisenkompensation) entlang der X-Achse
• y_uncalib : Magnetfeld (ohne Harteisenkompensation) entlang der Y-Achse
• z_uncalib : Magnetfeld (ohne Harteisenkompensation) entlang der Z-Achse
• x_bias : geschätzte Vorspannung entlang der X-Achse
• y_bias : geschätzte Vorspannung entlang der Y-Achse
• z_bias : geschätzte Vorspannung entlang der Z-Achse

Konzeptionell ist die unkalibrierte Messung die Summe der kalibrierten Messung und der Bias-Schätzung: _uncalibrated = _calibrated + _bias .

Das unkalibrierte Magnetometer ermöglicht Algorithmen auf höherer Ebene, eine schlechte Harteisenschätzung zu handhaben. Es wird erwartet, dass die Werte x_bias , y_bias und z_bias springen, sobald sich die Schätzung des Harteisens ändert, und sie sollten den Rest der Zeit stabil bleiben.

Die Messungen müssen mit Weicheisenkalibrierung und Temperaturkompensation durchgeführt werden. Außerdem muss eine harte Eisenschätzung implementiert werden, damit vernünftige Schätzungen in x_bias , y_bias und z_bias gemeldet werden können. Wenn die Implementierung den Bias nicht schätzen kann, darf dieser Sensor nicht implementiert werden.

Wenn dieser Sensor vorhanden ist, muss der entsprechende Magnetfeldsensor vorhanden sein und beide Sensoren müssen dieselben sensor_t.name und sensor_t.vendor Werte aufweisen.

Scharnierwinkel

Meldemodus: Bei Änderung

getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) gibt einen Wecksensor zurück

Ein Scharnierwinkelsensor misst den Winkel in Grad zwischen zwei integralen Teilen des Geräts. Es wird erwartet, dass die von diesem Sensortyp gemessene Bewegung eines Scharniers die Art und Weise verändert, wie der Benutzer mit dem Gerät interagieren kann, beispielsweise durch Aufklappen oder Aufdecken eines Displays.

Interaktionsverbundsensoren

Einige Sensoren werden hauptsächlich verwendet, um Interaktionen mit dem Benutzer zu erkennen. 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] .