Typy czujników

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

W tej sekcji opisano osie czujników, czujniki podstawowe i czujniki złożone (aktywność, położenie, nieskalibrowane i interakcja).

Osie czujnika

Wartości zdarzeń czujnika z wielu czujników są wyrażone w określonej ramce, która jest statyczna względem urządzenia.

Osie urządzeń mobilnych

Interfejs Sensor API jest zależny tylko od naturalnej orientacji ekranu (osie nie są zamieniane, gdy zmienia się orientacja ekranu urządzenia.

Układ współrzędnych czujnika API dla urządzeń mobilnych

Rysunek 1. Układ współrzędnych (względem urządzenia mobilnego) używany przez Sensor API

Osie samochodowe

W implementacjach Android Automotive osie są definiowane w odniesieniu do ramy nadwozia pojazdu. Początkiem ramy odniesienia pojazdu jest środek tylnej osi. Rama odniesienia pojazdu jest zorientowana tak, że:

  • Oś X jest skierowana w prawo i znajduje się na płaszczyźnie poziomej, prostopadłej do płaszczyzny symetrii pojazdu.
  • Oś Y jest skierowana do przodu i znajduje się na płaszczyźnie poziomej.
Układ współrzędnych czujnika API dla urządzeń motoryzacyjnych

Rysunek 2. Układ współrzędnych (względem urządzenia samochodowego) używany przez Sensor API

Ramą odniesienia pojazdu jest prawoskrętny układ współrzędnych. Dlatego oś Z jest skierowana w górę.

Oś Z ramy odniesienia jest wyrównana do grawitacji, co oznacza, że ​​zarówno oś X, jak i oś Y są poziome. W rezultacie oś Y może nie zawsze przechodzić przez przednią oś.

Czujniki bazowe

Podstawowe typy czujników są nazywane po czujnikach fizycznych, które reprezentują. Czujniki te przekazują dane z pojedynczego czujnika fizycznego (w przeciwieństwie do czujników kompozytowych, które generują dane z innych czujników). Przykłady podstawowych typów czujników obejmują:

  • SENSOR_TYPE_ACCELEROMETER
  • SENSOR_TYPE_GYROSCOPE
  • SENSOR_TYPE_MAGNETOMETER

Jednak podstawowe czujniki nie są równe i nie powinny być mylone z ich podstawowym czujnikiem fizycznym. Dane z czujnika podstawowego nie są surowymi danymi wyjściowymi czujnika fizycznego, ponieważ stosowane są korekty (takie jak kompensacja odchylenia i kompensacja temperatury).

Na przykład charakterystyka czujnika podstawowego może różnić się od charakterystyki podstawowego czujnika fizycznego w następujących przypadkach użycia:

  • Chip żyroskopowy o zakresie odchylenia 1 stopnia/sek.
    • Po kalibracji fabrycznej, kompensacji temperatury i kompensacji odchylenia, rzeczywiste odchylenie czujnika Androida zostanie zmniejszone, może dojść do punktu, w którym zagwarantowane zostanie odchylenie poniżej 0,01 stopnia/s.
    • W tej sytuacji mówimy, że czujnik Androida ma odchylenie poniżej 0,01 stopnia / s, mimo że arkusz danych podstawowego czujnika mówi 1 stopień / s.
  • Barometr o poborze mocy 100 uW.
    • Ponieważ wygenerowane dane muszą zostać przetransportowane z chipa do SoC, rzeczywisty koszt energii w celu zebrania danych z czujnika barometru Android może być znacznie wyższy, na przykład 1000 uW.
    • W tej sytuacji mówimy, że czujnik Android ma pobór mocy 1000 uW, mimo że pobór mocy mierzony na przewodach układu barometru wynosi 100uW.
  • Magnetometr, który zużywa 100uW podczas kalibracji, ale zużywa więcej podczas kalibracji.
    • Jego procedura kalibracji może wymagać aktywacji żyroskopu, zużywającego 5000 uW i uruchomienia jakiegoś algorytmu, co kosztuje kolejne 900 uW.
    • W tej sytuacji mówimy, że maksymalny pobór mocy czujnika (magnetometru) Android to 6000 uW.
    • W tym przypadku bardziej użyteczną miarą jest średni pobór mocy, który jest raportowany w charakterystyce statycznej czujnika za pośrednictwem warstwy HAL.

Akcelerometr

Tryb raportowania: Ciągły

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER) zwraca czujnik inny niż wybudzanie

Czujnik przyspieszenia informuje o przyspieszeniu urządzenia wzdłuż trzech osi czujnika. Mierzone przyspieszenie obejmuje zarówno przyspieszenie fizyczne (zmianę prędkości), jak i grawitację. Pomiar jest podawany w polach x, y i z sensorów_event_t.acceleration.

Wszystkie wartości są w jednostkach SI (m/s^2) i mierzą przyspieszenie urządzenia minus siła grawitacji wzdłuż trzech osi czujnika.

Oto przykłady:

  • Norma (x, y, z) powinna być bliska 0, gdy spada swobodnie.
  • Gdy urządzenie leży płasko na stole i jest popychane z lewej strony w prawo, wartość przyspieszenia x jest dodatnia.
  • Gdy urządzenie leży płasko na stole, wartość przyspieszenia wzdłuż z wynosi +9,81, co odpowiada przyspieszeniu urządzenia (0 m/s^2) minus siła grawitacji (-9,81 m/s^2).
  • Gdy urządzenie leży płasko na stole i jest pchane ku niebu, wartość przyspieszenia jest większa niż +9,81, co odpowiada przyspieszeniu urządzenia (+A m/s^2) minus siła grawitacji (-9,81 m /s^2).

Odczyty są kalibrowane za pomocą:

  • Kompensacja temperatury
  • Kalibracja stronniczości online
  • Kalibracja wagi online

Kalibrację polaryzacji i skali należy aktualizować tylko wtedy, gdy czujnik jest dezaktywowany, aby uniknąć skoków wartości podczas przesyłania strumieniowego.

Akcelerometr informuje również o spodziewanej dokładności odczytów poprzez sensors_event_t.acceleration.status . Zobacz stałe SENSOR_STATUS_* modułu SensorManager , aby uzyskać więcej informacji na temat możliwych wartości tego pola.

Temperatura otoczenia

Tryb raportowania: Przy zmianie

getDefaultSensor(SENSOR_TYPE_AMBIENT_TEMPERATURE) zwraca czujnik niewybudzony

Czujnik ten podaje temperaturę otoczenia (pomieszczenia) w stopniach Celsjusza.

Czujnik pola magnetycznego

Tryb raportowania: Ciągły

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD) zwraca czujnik bez wybudzenia

SENSOR_TYPE_GEOMAGNETIC_FIELD == SENSOR_TYPE_MAGNETIC_FIELD

Czujnik pola magnetycznego (znany również jako magnetometr) informuje o polu magnetycznym otoczenia, mierzonym wzdłuż trzech osi czujnika.

Pomiar jest podawany w polach x, y i z sensorów_event_t.magnetic, a wszystkie wartości są podawane w mikro- sensors_event_t.magnetic (uT).

Magnetometr informuje również o spodziewanej dokładności odczytów poprzez sensors_event_t.magnetic.status . Zobacz stałe SENSOR_STATUS_* modułu SensorManager , aby uzyskać więcej informacji na temat możliwych wartości tego pola.

Odczyty są kalibrowane za pomocą:

  • Kompensacja temperatury
  • Fabryczna (lub online) kalibracja miękkiego żelaza
  • Kalibracja online z twardego żelaza

Żyroskop

Tryb raportowania: Ciągły

getDefaultSensor(SENSOR_TYPE_GYROSCOPE) zwraca czujnik bez wybudzenia

Czujnik żyroskopowy informuje o szybkości obrotu urządzenia wokół trzech osi czujnika.

Obrót jest dodatni w kierunku przeciwnym do ruchu wskazówek zegara (reguła prawej ręki). Oznacza to, że obserwator patrzący z jakiegoś dodatniego miejsca na osi x, y lub z na urządzenie umieszczone w punkcie początkowym zgłosiłby dodatni obrót, gdyby urządzenie wydawało się obracać w kierunku przeciwnym do ruchu wskazówek zegara. Należy zauważyć, że jest to standardowa matematyczna definicja obrotu dodatniego i nie zgadza się z definicją kołysania w lotnictwie.

Pomiar jest podawany w polach x, y i z sensors_event_t.gyro , a wszystkie wartości są podane w radianach na sekundę (rad/s).

Odczyty są kalibrowane za pomocą:

  • Kompensacja temperatury
  • Kompensacja skali fabrycznej (lub online)
  • Kalibracja odchylenia online (w celu usunięcia dryftu)

Żyroskop informuje również, jak dokładne spodziewane są odczyty, poprzez sensors_event_t.gyro.status . Zobacz stałe SENSOR_STATUS_* modułu SensorManager , aby uzyskać więcej informacji na temat możliwych wartości tego pola.

Żyroskopu nie można emulować w oparciu o magnetometry i akcelerometry, ponieważ spowodowałoby to zmniejszoną lokalną spójność i responsywność. Musi być oparty na zwykłym chipie żyroskopowym.

Tętno

Tryb raportowania: Przy zmianie

getDefaultSensor(SENSOR_TYPE_HEART_RATE) zwraca czujnik inny niż wybudzanie

Czujnik tętna podaje aktualne tętno osoby dotykającej urządzenia.

Bieżące tętno w uderzeniach na minutę (BPM) jest raportowane w sensors_event_t.heart_rate.bpm , a stan czujnika jest raportowany w sensors_event_t.heart_rate.status . Zobacz stałe SENSOR_STATUS_* modułu SensorManager , aby uzyskać więcej informacji na temat możliwych wartości tego pola. W szczególności, przy pierwszej aktywacji, chyba że wiadomo, że urządzenie nie znajduje się na ciele, pole statusu pierwszego zdarzenia musi być ustawione na SENSOR_STATUS_UNRELIABLE . Ponieważ ten czujnik zmienia się, zdarzenia są generowane tylko wtedy, gdy heart_rate.bpm lub heart_rate.status zmieniły się od ostatniego zdarzenia. Zdarzenia są generowane nie szybciej niż co sampling_period .

sensor_t.requiredPermission to zawsze SENSOR_PERMISSION_BODY_SENSORS .

Światło

Tryb raportowania: Przy zmianie

getDefaultSensor(SENSOR_TYPE_LIGHT) zwraca czujnik niewybudzony

Czujnik światła informuje o aktualnym oświetleniu w jednostkach SI luksów.

Pomiar jest raportowany w sensors_event_t.light .

Bliskość

Tryb raportowania: Przy zmianie

Zwykle określany jako czujnik budzenia

getDefaultSensor(SENSOR_TYPE_PROXIMITY) zwraca czujnik budzenia

Czujnik zbliżeniowy informuje o odległości od czujnika do najbliższej widocznej powierzchni.

Do Androida 4.4 czujniki zbliżeniowe zawsze były czujnikami budzenia, budząc SoC po wykryciu zmiany bliskości. Po Androidzie 4.4 zalecamy najpierw zaimplementować wersję wybudzającą tego czujnika, ponieważ to on służy do włączania i wyłączania ekranu podczas wykonywania połączeń telefonicznych.

Pomiar jest podawany w centymetrach w sensors_event_t.distance . Należy zauważyć, że niektóre czujniki zbliżeniowe obsługują tylko pomiar binarny „blisko” lub „daleko”. W tym przypadku czujnik zgłasza swoją wartość sensor_t.maxRange w stanie „daleko” i wartość mniejszą niż sensor_t.maxRange w stanie „bliskim”.

Nacisk

Tryb raportowania: Ciągły

getDefaultSensor(SENSOR_TYPE_PRESSURE) zwraca czujnik niewybudzony

Czujnik ciśnienia (znany również jako barometr) podaje ciśnienie atmosferyczne w hektopaskalach (hPa).

Odczyty są kalibrowane za pomocą

  • Kompensacja temperatury
  • Fabryczna kalibracja odchylenia
  • Kalibracja skali fabrycznej

Barometr jest często używany do szacowania zmian wysokości. Aby oszacować wysokość bezwzględną, jako odniesienie należy zastosować ciśnienie na poziomie morza (zmieniające się w zależności od pogody).

Wilgotność względna

Tryb raportowania: Przy zmianie

getDefaultSensor(SENSOR_TYPE_RELATIVE_HUMIDITY) zwraca czujnik niewybudzony

Czujnik wilgotności względnej mierzy względną wilgotność powietrza otoczenia i zwraca wartość w procentach.

Typy czujników kompozytowych

Czujnik złożony generuje dane poprzez przetwarzanie i/lub łączenie danych z jednego lub kilku czujników fizycznych. (Każdy czujnik, który nie jest czujnikiem podstawowym, nazywany jest czujnikiem złożonym). Przykłady czujników złożonych obejmują:

  • Detektor kroków i znacznego ruchu , które zwykle opierają się na akcelerometrze, ale mogłyby być również oparte na innych czujnikach, gdyby pobór mocy i dokładność były zadowalające.
  • Wektor obrotu gry oparty na akcelerometrze i żyroskopie.
  • Nieskalibrowany żyroskop , który jest podobny do czujnika podstawowego żyroskopu, ale z kalibracją odchylenia raportowaną osobno, zamiast korygowaną w pomiarze.

Podobnie jak w przypadku czujników bazowych, charakterystyki czujników kompozytowych wynikają z charakterystyk ich danych końcowych. Na przykład pobór mocy wektora rotacji gry jest prawdopodobnie równy sumie poboru mocy układu akcelerometru, układu żyroskopu, układu przetwarzającego dane i magistrali transportujących dane. Jako inny przykład, dryf wektora rotacji gry zależy w takim samym stopniu od jakości algorytmu kalibracji, jak od fizycznych właściwości czujnika.

W poniższej tabeli wymieniono dostępne typy czujników kompozytowych. Każdy czujnik złożony opiera się na danych z jednego lub kilku czujników fizycznych. Unikaj wybierania innych podstawowych czujników fizycznych w celu przybliżenia wyników, ponieważ zapewniają one słabe wrażenia użytkownika.

Typ czujnika Kategoria Podstawowe czujniki fizyczne Tryb raportowania

Wektor rotacji gry

Nastawienie

Akcelerometr, żyroskop, NIE MOŻNA UŻYWAĆ magnetometru

Ciągły

Geomagnetyczny wektor rotacji Czujnik niskiej mocy

Nastawienie

Akcelerometr, magnetometr, NIE MOŻNA UŻYWAĆ żyroskopu

Ciągły

Gest spojrzenia Czujnik niskiej mocy

Interakcja

Nieokreślony

Jeden strzał

Powaga

Nastawienie

Akcelerometr, żyroskop

Ciągły

Nieskalibrowany żyroskop

Nieskalibrowany

Żyroskop

Ciągły

Przyspieszenie liniowe

Działalność

Akcelerometr, żyroskop (jeśli jest) lub magnetometr (jeśli nie ma żyroskopu)

Ciągły

Nieskalibrowane pole magnetyczne

Nieskalibrowany

Magnetometr

Ciągły

Orientacja (przestarzałe)

Nastawienie

Akcelerometr, magnetometr, żyroskop (jeśli jest)

Ciągły

Podnieś gest Czujnik niskiej mocy

Interakcja

Nieokreślony

Jeden strzał

Wektor rotacji

Nastawienie

Akcelerometr, magnetometr, żyroskop

Ciągły

Znaczący ruch Czujnik niskiej mocy

Działalność

Akcelerometr (lub inny o bardzo małej mocy)

Jeden strzał

Licznik kroków Czujnik niskiej mocy

Działalność

Akcelerometr

Przy zmianie

Detektor kroków Czujnik niskiej mocy

Działalność

Akcelerometr

Specjalny

Detektor przechyłu Czujnik niskiej mocy

Działalność

Akcelerometr

Specjalny

Gest budzenia Czujnik niskiej mocy

Interakcja

Nieokreślony

Jeden strzał

Czujnik niskiej mocy = Czujnik niskiej mocy

Czujniki kompozytowe aktywności

Przyspieszenie liniowe

Bazowe czujniki fizyczne: Akcelerometr i (jeśli jest obecny) żyroskop (lub magnetometr, jeśli żyroskop nie jest obecny)

Tryb raportowania: Ciągły

getDefaultSensor(SENSOR_TYPE_LINEAR_ACCELERATION) zwraca czujnik inny niż wybudzanie

Czujnik przyspieszenia liniowego zgłasza przyspieszenie liniowe urządzenia w ramie czujnika, nie uwzględniając grawitacji.

Wyjście to koncepcyjnie: wyjście akcelerometru minus wyjście czujnika grawitacyjnego . Jest podawany wm/s^2 w polach x, y i z sensors_event_t.acceleration .

Odczyty na wszystkich osiach powinny być bliskie 0, gdy urządzenie jest nieruchome.

Jeśli urządzenie jest wyposażone w żyroskop, czujnik przyspieszenia liniowego musi wykorzystywać jako wejście żyroskop i akcelerometr.

Jeśli urządzenie nie posiada żyroskopu, czujnik przyspieszenia liniowego musi wykorzystywać jako wejście akcelerometr i magnetometr.

Znaczący ruch

Bazowy czujnik fizyczny: Akcelerometr (lub inny o małej mocy)

Tryb raportowania: jednorazowy

Niska moc

Zaimplementuj tylko wersję wybudzoną tego czujnika.

getDefaultSensor(SENSOR_TYPE_SIGNIFICANT_MOTION) zwraca czujnik budzenia

Detektor znacznego ruchu uruchamia się po wykryciu znaczącego ruchu : ruch, który może prowadzić do zmiany lokalizacji użytkownika.

Przykładami takich znaczących ruchów są:

  • Chodzenie lub jazda na rowerze
  • Siedzenie w jadącym samochodzie, autokarze lub pociągu

Przykłady sytuacji, które nie wywołują znaczącego ruchu:

  • Telefon w kieszeni i osoba się nie rusza
  • Telefon leży na stole, a stół lekko się trzęsie z powodu pobliskiego ruchu lub pralki

Na wysokim poziomie, znaczna czujka ruchu służy do zmniejszenia zużycia energii na określenie lokalizacji. Gdy algorytmy lokalizacyjne wykryją, że urządzenie jest statyczne, mogą przełączyć się w tryb niskiego poboru mocy, w którym wykorzystują znaczny ruch do wybudzenia urządzenia, gdy użytkownik zmienia lokalizację.

Ten czujnik musi mieć niską moc. To kompromis w zakresie zużycia energii, który może skutkować niewielką liczbą fałszywych negatywów. Dzieje się tak z kilku powodów:

  • Celem tego czujnika jest oszczędzanie energii.
  • Wyzwolenie zdarzenia, gdy użytkownik się nie porusza (fałszywie dodatnie) jest kosztowne pod względem mocy, dlatego należy tego unikać.
  • Niewywoływanie zdarzenia, gdy użytkownik się porusza (fałszywie negatywny) jest dopuszczalne, o ile nie jest powtarzane. Jeśli użytkownik chodził przez 10 sekund, niewywołanie zdarzenia w ciągu tych 10 sekund jest niedopuszczalne.

Każde zdarzenie sensora zgłasza 1 w sensors_event_t.data[0] .

Detektor kroków

Bazowy czujnik fizyczny: Akcelerometr (+ ewentualnie inne, o małej mocy)

Tryb raportowania: specjalny (jedno zdarzenie na wykonany krok)

Niska moc

getDefaultSensor(SENSOR_TYPE_STEP_DETECTOR) zwraca czujnik inny niż wybudzanie

Detektor kroków generuje zdarzenie za każdym razem, gdy użytkownik wykona krok.

Znacznik czasu zdarzenia sensors_event_t.timestamp odpowiada chwili, gdy stopa uderzyła o ziemię, generując duże zmiany przyspieszenia.

W porównaniu z licznikiem kroków detektor kroków powinien mieć mniejszą latencję (mniej niż dwie sekundy). Zarówno detektor kroków, jak i licznik kroków wykrywają, kiedy użytkownik idzie, biega i wchodzi po schodach. Nie powinny uruchamiać się, gdy użytkownik jeździ na rowerze, prowadzi samochód lub w innych pojazdach.

Ten czujnik musi mieć niską moc. Oznacza to, że jeśli wykrywanie kroku nie może być wykonane sprzętowo, czujnik ten nie powinien być definiowany. W szczególności, gdy czujnik kroku jest aktywny, a akcelerometr nie, tylko kroki powinny wyzwalać przerwania (nie każdy odczyt akcelerometru).

sampling_period_ns nie ma wpływu na detektory kroków.

Każde zdarzenie sensora zgłasza 1 w sensors_event_t.data[0] .

Licznik kroków

Bazowy czujnik fizyczny: Akcelerometr (+ ewentualnie inne, o małej mocy)

Tryb raportowania: Przy zmianie

Niska moc

getDefaultSensor(SENSOR_TYPE_STEP_COUNTER) zwraca czujnik inny niż wybudzanie

Licznik kroków informuje o liczbie kroków wykonanych przez użytkownika od ostatniego ponownego uruchomienia podczas aktywacji.

Pomiar jest zgłaszany jako uint64_t w sensors_event_t.step_counter i jest resetowany do zera dopiero po ponownym uruchomieniu systemu.

Sygnatura czasowa zdarzenia jest ustawiona na czas wykonania ostatniego kroku dla tego zdarzenia.

Zobacz typ czujnika detektora kroków dla oznaczenia czasu kroku.

W porównaniu do detektora kroków licznik kroków może mieć większe opóźnienie (do 10 sekund). Dzięki temu opóźnieniu czujnik ten ma wysoką dokładność; liczba kroków po pełnym dniu pomiarów powinna mieścić się w granicach 10% rzeczywistej liczby kroków. Zarówno detektor kroków, jak i licznik kroków wykrywają, kiedy użytkownik idzie, biega i wchodzi po schodach. Nie powinny uruchamiać się, gdy użytkownik jeździ na rowerze, prowadzi samochód lub w innych pojazdach.

Sprzęt musi zapewnić, że wewnętrzna liczba kroków nigdy się nie przepełni. Minimalny rozmiar wewnętrznego licznika sprzętu powinien wynosić 16 bitów. W przypadku nieuchronnego przepełnienia (co najwyżej co ~2^16 kroków), SoC może zostać wybudzony, aby kierowca mógł wykonać konserwację licznika.

Jak stwierdzono w Interakcji , podczas gdy ten czujnik działa, nie zakłóca działania innych czujników, w szczególności akcelerometru, który może być w użyciu.

Jeżeli dane urządzenie nie może obsługiwać tych trybów pracy, to ten typ czujnika nie może być zgłaszany przez HAL. Oznacza to, że niedopuszczalne jest „emulowanie” tego czujnika w HAL.

Ten czujnik musi mieć niską moc. Oznacza to, że jeśli wykrywanie kroku nie może być wykonane sprzętowo, czujnik ten nie powinien być definiowany. W szczególności, gdy licznik kroków jest włączony, a akcelerometr nie, tylko kroki powinny wyzwalać przerwania (nie dane akcelerometru).

Detektor przechyłu

Bazowy czujnik fizyczny: Akcelerometr (+ ewentualnie inne, o małej mocy)

Tryb raportowania: specjalny

Niska moc

Zaimplementuj tylko wersję wybudzoną tego czujnika.

getDefaultSensor(SENSOR_TYPE_TILT_DETECTOR) zwraca czujnik budzenia

Detektor przechyłu generuje zdarzenie za każdym razem, gdy zostanie wykryte zdarzenie przechyłu.

Zdarzenie przechyłu jest określone przez kierunek średniej grawitacji okna z 2 sekund, zmieniający się o co najmniej 35 stopni od aktywacji lub ostatniego zdarzenia wygenerowanego przez czujnik. Oto algorytm:

  • reference_estimated_gravity = średnia z pomiarów akcelerometru w ciągu pierwszej sekundy po aktywacji lub szacowana grawitacja, gdy wygenerowano ostatnie zdarzenie przechyłu.
  • current_estimated_gravity = średnia pomiarów akcelerometru w ciągu ostatnich 2 sekund.
  • Wyzwalaj, gdy angle(reference_estimated_gravity, current_estimated_gravity) > 35 degrees

Duże przyspieszenia bez zmiany orientacji telefonu nie powinny wyzwalać zdarzenia przechyłu. Na przykład ostry zakręt lub silne przyspieszenie podczas jazdy samochodem nie powinno powodować przechyłu, mimo że kąt średniego przyspieszenia może różnić się o więcej niż 35 stopni. Zazwyczaj ten czujnik jest realizowany za pomocą tylko akcelerometru. Można również zastosować inne czujniki, jeśli nie zwiększają znacząco zużycia energii. Jest to czujnik o małej mocy, który powinien umożliwić SoC przejście w tryb wstrzymania. Nie emuluj tego czujnika w HAL. Każde zdarzenie sensora zgłasza 1 w sensors_event_t.data[0] .

Czujniki kompozytowe Attitude

Wektor rotacji

Podstawowe czujniki fizyczne: akcelerometr, magnetometr i żyroskop

Tryb raportowania: Ciągły

getDefaultSensor(SENSOR_TYPE_ROTATION_VECTOR) zwraca czujnik bez wybudzania

Czujnik wektora obrotu informuje o orientacji urządzenia względem układu współrzędnych wschód-północ-góra. Zwykle uzyskuje się go poprzez integrację odczytów akcelerometru, żyroskopu i magnetometru. Układ współrzędnych wschód-północ-góra definiuje się jako bezpośrednią bazę ortonormalną, gdzie:

  • X wskazuje na wschód i jest styczna do ziemi.
  • Y wskazuje na północ i jest styczna do ziemi.
  • Z wskazuje na niebo i jest prostopadłe do ziemi.

Orientacja telefonu jest reprezentowana przez obrót niezbędny do wyrównania współrzędnych wschód-północ-góra ze współrzędnymi telefonu. Oznacza to, że zastosowanie obrotu do ramki świata (X,Y,Z) wyrówna je ze współrzędnymi telefonu (x,y,z).

Obrót może być postrzegany jako obrót telefonu o kąt teta wokół osi rot_axis , aby przejść od orientacji urządzenia odniesienia (wyrównanie wschód-północ-do góry) do bieżącej orientacji urządzenia. Obrót jest zakodowany jako cztery bezjednostkowe składowe x, y, z, w kwaternionu jednostkowego:

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

Gdzie:

  • Pola x, y i z rot_axis to współrzędne wschód-północ-góra wektora długości jednostki reprezentującej oś obrotu
  • theta to kąt obrotu

Quaternion jest kwaternionem jednostkowym: musi mieć normę 1 . Niezapewnienie tego spowoduje błędne zachowanie klienta.

Ponadto czujnik ten zgłasza szacunkową dokładność kursu:

sensors_event_t.data[4] = estimated_accuracy (w radianach)

Błąd nagłówka musi być mniejszy niż estimated_accuracy w 95% przypadków. Ten czujnik musi używać żyroskopu jako głównego wejścia zmiany orientacji.

Ten czujnik wykorzystuje również wejście akcelerometru i magnetometru, aby zrekompensować dryf żyroskopu i nie można go zaimplementować za pomocą tylko akcelerometru i magnetometru.

Wektor rotacji gry

Podstawowe czujniki fizyczne: Akcelerometr i żyroskop (bez magnetometru)

Tryb raportowania: Ciągły

getDefaultSensor(SENSOR_TYPE_GAME_ROTATION_VECTOR) zwraca czujnik inny niż wybudzanie

Czujnik wektora obrotu w grze jest podobny do czujnika wektora obrotu, ale nie wykorzystuje pola geomagnetycznego. Dlatego oś Y nie wskazuje na północ, ale na jakieś inne odniesienie. To odniesienie może dryfować o ten sam rząd wielkości, gdy żyroskop dryfuje wokół osi Z.

Zobacz czujnik wektora obrotu , aby uzyskać szczegółowe informacje o tym, jak ustawić sensors_event_t.data[0-3] . Ten czujnik nie podaje szacunkowej dokładności kursu: sensors_event_t.data[4] jest zarezerwowany i powinien być ustawiony na 0 .

W idealnym przypadku telefon obrócony i przywrócony do tej samej orientacji w świecie rzeczywistym powinien zgłaszać ten sam wektor obrotu gry.

Ten czujnik musi być oparty na żyroskopie i akcelerometrze. Nie może używać magnetometru jako sygnału wejściowego, poza tym pośrednio poprzez estymację odchylenia żyroskopu.

Powaga

Bazowe czujniki fizyczne: Akcelerometr i (jeśli jest obecny) żyroskop (lub magnetometr, jeśli żyroskop nie jest obecny)

Tryb raportowania: Ciągły

getDefaultSensor(SENSOR_TYPE_GRAVITY) zwraca czujnik niewybudzony

Czujnik grawitacyjny informuje o kierunku i wielkości grawitacji we współrzędnych urządzenia.

Komponenty wektora grawitacji są podawane wm/s^2 w polach x, y i z sensors_event_t.acceleration .

Gdy urządzenie jest w stanie spoczynku, sygnał wyjściowy czujnika grawitacyjnego powinien być identyczny z sygnałem akcelerometru. Na Ziemi magnitudo wynosi około 9,8 m/s^2.

Jeśli urządzenie posiada żyroskop, czujnik grawitacyjny musi używać jako danych wejściowych żyroskopu i akcelerometru.

Jeśli urządzenie nie posiada żyroskopu, czujnik grawitacyjny musi wykorzystywać jako wejście akcelerometr i magnetometr.

Geomagnetyczny wektor rotacji

Podstawowe czujniki fizyczne: Akcelerometr i magnetometr (bez żyroskopu)

Tryb raportowania: Ciągły

Niska moc

getDefaultSensor(SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR) zwraca czujnik niewybudzony

Geomagnetyczny wektor rotacji jest podobny do czujnika wektora rotacji, ale używa magnetometru, a nie żyroskopu.

Ten czujnik musi być oparty na magnetometrze. Nie można go zaimplementować za pomocą żyroskopu, a wejście żyroskopu nie może być używane przez ten czujnik.

Zobacz czujnik wektora obrotu , aby uzyskać szczegółowe informacje o tym, jak ustawić sensors_event_t.data[0-4] .

Podobnie jak w przypadku czujnika wektora obrotu, błąd kursu musi być mniejszy niż szacowana dokładność ( sensors_event_t.data[4] ) 95% czasu.

Ten czujnik musi być małej mocy, więc musi być zaimplementowany sprzętowo.

Orientacja (przestarzałe)

Podstawowe czujniki fizyczne: Akcelerometr, magnetometr i (jeśli jest) żyroskop

Tryb raportowania: Ciągły

getDefaultSensor(SENSOR_TYPE_ORIENTATION) zwraca czujnik inny niż wybudzanie

Uwaga: to starszy typ czujnika, który został wycofany w pakiecie Android SDK. Został on zastąpiony przez czujnik wektora obrotu, który jest wyraźniej zdefiniowany. Używaj czujnika wektora obrotu nad czujnikiem orientacji, gdy tylko jest to możliwe.

Czujnik orientacji informuje o położeniu urządzenia. Pomiary są podawane w stopniach w polach x, y i z sensors_event_t.orientation :

  • sensors_event_t.orientation.x : azymut, kąt pomiędzy kierunkiem północy magnetycznej a osią Y wokół osi Z ( 0<=azimuth<360 ). 0=Północ, 90=Wschód, 180=Południe, 270=Zachód.
  • sensors_event_t.orientation.y : skok, obrót wokół osi X ( -180<=pitch<=180 ), z wartościami dodatnimi, gdy oś Z porusza się w kierunku osi Y.
  • sensors_event_t.orientation.z : roll, obrót wokół osi Y ( -90<=roll<=90 ), z wartościami dodatnimi, gdy oś X porusza się w kierunku osi Z.

Należy pamiętać, że ze względów historycznych kąt przechyłu jest dodatni w kierunku zgodnym z ruchem wskazówek zegara. (Matematycznie rzecz biorąc, powinno być dodatnie w kierunku przeciwnym do ruchu wskazówek zegara):

Przedstawienie orientacji względem urządzenia

Rysunek 3. Orientacja względem urządzenia

Ta definicja różni się od odchylenia, nachylenia i przechyłu stosowanego w lotnictwie, gdzie oś X znajduje się wzdłuż dłuższego boku samolotu (od ogona do nosa).

Czujnik orientacji informuje również, jak dokładne spodziewane są odczyty za pośrednictwem sensors_event_t.orientation.status . Zobacz stałe SENSOR_STATUS_* modułu SensorManager , aby uzyskać więcej informacji na temat możliwych wartości tego pola.

Nieskalibrowane czujniki

Nieskalibrowane czujniki zapewniają bardziej surowe wyniki i mogą zawierać pewne odchylenia, ale także zawierają mniej „skoków” z korekt wprowadzonych podczas kalibracji. Niektóre aplikacje mogą preferować te nieskalibrowane wyniki jako płynniejsze i bardziej niezawodne. Na przykład, jeśli aplikacja próbuje przeprowadzić własną fuzję czujników, wprowadzenie kalibracji może w rzeczywistości zniekształcić wyniki.

Akcelerometr nieskalibrowany

Bazowy czujnik fizyczny: Akcelerometr

Tryb raportowania: Ciągły

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_UNCALIBRATED) zwraca czujnik bez wybudzania

Nieskalibrowany czujnik akcelerometru zgłasza przyspieszenie urządzenia wzdłuż trzech osi czujnika bez żadnej korekcji odchylenia (w przypadku nieskalibrowanych pomiarów stosowane są odchylenia fabryczne i kompensacja temperatury), wraz z oszacowaniem odchylenia. Wszystkie wartości podane są w jednostkach SI (m/s^2) i są podawane w polach sensors_event_t.uncalibrated_accelerometer :

  • x_uncalib : przyspieszenie (bez kompensacji odchylenia) wzdłuż osi X
  • y_uncalib : przyspieszenie (bez kompensacji odchylenia) wzdłuż osi Y
  • z_uncalib : przyspieszenie (bez kompensacji odchylenia) wzdłuż osi Z
  • x_bias : szacowane odchylenie wzdłuż osi X
  • y_bias : szacowane odchylenie wzdłuż osi Y
  • z_bias : szacowane odchylenie wzdłuż osi Z

Nieskalibrowany żyroskop

Bazowy czujnik fizyczny: żyroskop

Tryb raportowania: Ciągły

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_UNCALIBRATED) zwraca czujnik bez wybudzenia

Nieskalibrowany żyroskop zgłasza prędkość obrotu wokół osi czujnika bez stosowania do nich kompensacji odchylenia, wraz z oszacowaniem odchylenia. Wszystkie wartości podane są w radianach/sekundę i są podawane w polach sensors_event_t.uncalibrated_gyro :

  • x_uncalib : prędkość kątowa (bez kompensacji dryfu) wokół osi X
  • y_uncalib : prędkość kątowa (bez kompensacji dryfu) wokół osi Y
  • z_uncalib : prędkość kątowa (bez kompensacji dryfu) wokół osi Z
  • x_bias : szacowany dryf wokół osi X
  • y_bias : szacowany dryf wokół osi Y
  • z_bias : szacowany dryf wokół osi Z

Koncepcyjnie, niekalibrowany pomiar jest sumą skalibrowanego pomiaru i oszacowania błędu systematycznego: _uncalibrated = _calibrated + _bias .

Oczekuje się, że wartości x_bias , y_bias i z_bias będą skakać, gdy tylko zmieni się oszacowanie odchylenia i powinny być stabilne przez resztę czasu.

Zobacz definicję czujnika żyroskopowego , aby uzyskać szczegółowe informacje na temat używanego układu współrzędnych.

Do pomiarów należy zastosować kalibrację fabryczną i kompensację temperatury. Ponadto należy zaimplementować oszacowanie dryfu żyroskopu, aby rozsądne oszacowania można było zgłaszać w x_bias , y_bias i z_bias . Jeśli implementacja nie jest w stanie oszacować dryftu, nie wolno zaimplementować tego czujnika.

Jeśli ten czujnik jest obecny, musi być również obecny odpowiedni czujnik żyroskopowy i oba czujniki muszą mieć te same wartości sensor_t.name i sensor_t.vendor .

Nieskalibrowane pole magnetyczne

Bazowy czujnik fizyczny: Magnetometr

Tryb raportowania: Ciągły

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED) zwraca czujnik bez wybudzenia

Nieskalibrowany czujnik pola magnetycznego raportuje otaczające pole magnetyczne wraz z oszacowaniem kalibracji twardego żelaza. Wszystkie wartości podane są w mikro-Teslach (uT) i są raportowane w polach sensors_event_t.uncalibrated_magnetic :

  • x_uncalib : pole magnetyczne (bez kompensacji twardego żelaza) wzdłuż osi X
  • y_uncalib : pole magnetyczne (bez kompensacji twardego żelaza) wzdłuż osi Y
  • z_uncalib : pole magnetyczne (bez kompensacji twardego żelaza) wzdłuż osi Z
  • x_bias : szacowane odchylenie twarde żelaza wzdłuż osi X
  • y_bias : szacowane odchylenie twarde żelaza wzdłuż osi Y
  • z_bias : szacowane odchylenie twarde żelaza wzdłuż osi Z

Koncepcyjnie, niekalibrowany pomiar jest sumą skalibrowanego pomiaru i oszacowania błędu systematycznego: _uncalibrated = _calibrated + _bias .

Nieskalibrowany magnetometr umożliwia algorytmom wyższego poziomu radzenie sobie ze złym oszacowaniem zawartości twardego żelaza. Oczekuje się, że wartości x_bias , y_bias i z_bias będą skakać, gdy tylko zmieni się oszacowanie twardego żelaza i powinny być stabilne przez resztę czasu.

Do pomiarów należy zastosować kalibrację miękkiego żelaza i kompensację temperatury. Ponadto należy zaimplementować twarde oszacowanie, aby rozsądne oszacowania można było zgłaszać w x_bias , y_bias i z_bias . Jeśli implementacja nie jest w stanie oszacować odchylenia, ten czujnik nie może zostać zaimplementowany.

Jeśli ten czujnik jest obecny, musi być obecny odpowiedni czujnik pola magnetycznego i oba czujniki muszą mieć te same wartości sensor_t.name i sensor_t.vendor .

Kąt zawiasu

Tryb raportowania: Przy zmianie

getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) zwraca czujnik budzenia

Czujnik kąta zawiasu mierzy kąt w stopniach między dwiema integralnymi częściami urządzenia. Oczekuje się, że ruch zawiasu mierzony przez ten typ czujnika zmieni sposoby interakcji użytkownika z urządzeniem, na przykład poprzez rozłożenie lub odsłonięcie wyświetlacza.

Interakcyjne czujniki kompozytowe

Niektóre czujniki są najczęściej używane do wykrywania interakcji z użytkownikiem. 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.

SensorEvent Values for SENSOR_TYPE_ACCELEROMETER Example SENSOR_TYPE_ACCELEROMETER SensorEvent Composite SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES SensorEvent
values[0]

-0.065

-0.065

values[1]

0.078

0.078

values[2]

9.808

9.808

values[3]

N/A

1.0

values[4]

N/A

1.0

values[5]

N/A

1.0

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.