Dokładność akcelerometru Android (Nawigacja inercyjna)

Zastanawiałem się nad wdrożeniem bezwładnościowego systemu nawigacji dla telefonu z Androidem, który jest trudny, biorąc pod uwagę dokładność akcelerometru i ciągłe wahania odczytów.

Na początek ustawiłem telefon na płaskiej powierzchni i pobrałem 1000 odczytów akcelerometru w kierunkach X i Y (równolegle do tabeli, więc nie działa grawitacja w tych kierunkach). Następnie uśredniłem te odczyty i użyłem tej wartości do kalibracji telefonu (odejmując tę wartość od każdego kolejne czytanie).

Następnie przetestowałem system, ponownie umieszczając go na stole i pobierając próbki 5000 odczytów akcelerometru w kierunkach X i Y. Spodziewałbym się, biorąc pod uwagę kalibrację, że te przyspieszenia powinny sumować się do 0 (mniej więcej) w każdym kierunku. Jednak tak nie jest, a całkowite przyspieszenie ponad 5000 iteracji nie jest bliskie 0 (średnio około 10 na każdej osi).

Zdaję sobie sprawę, że nie widząc mojego kodu może to być trudne do odpowiedzi, ale w bardziej ogólny sens...

Czy jest to po prostu przykład na to, jak niedokładne są odczyty akcelerometru w telefonie komórkowym (HTC Desire S), czy jest bardziej prawdopodobne, że popełniłem kilka błędów w kodowaniu?

6 answers

Otrzymujesz pozycję, całkując Przyspieszenie liniowe dwukrotnie, ale błąd jest okropny. Jest bezużyteczny w praktyce.

Oto wyjaśnienie dlaczego (Google Tech Talk) W 23:20. Gorąco polecam ten film.

To nie szum akcelerometru powoduje problem, ale biały szum żyroskopowy, patrz podpunkt 6.2.3 propagacja błędów. (Nawiasem mówiąc, będziesz też potrzebował żyroskopów.)

Co do pozycjonowania wnętrz, mam okazało się, że są przydatne:

Lokalizacja i śledzenie pomieszczeń w oparciu o RSSI przy użyciu Wygładzaczy Sigma-Point Kalman

Śledzenie pieszych z czujnikami Inercyjnymi montowanymi na butach

Zwiększenie wydajności krokomierzy za pomocą pojedynczego akcelerometru

Nie mam pojęcia, jak te metody będą działać w rzeczywistych aplikacjach lub jak przekształcić je w ładną aplikację na Androida.

Podobne pytanie brzmi to .

UPDATE:

Najwyraźniej istnieje nowsza wersja niż wyżej Oliver J. Woodman, "wprowadzenie do nawigacji inercyjnej", jego praca doktorska:

Lokalizacja pieszych dla środowisk wewnętrznych

 119
Author: Ali,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:18:22

Myślę na głos, a nie grałem jeszcze z API akcelerometru Androida, więc proszę o cierpliwość.

Przede wszystkim tradycyjnie, aby uzyskać nawigację z akcelerometrów, potrzebujesz akcelerometru 6-osiowego. Potrzebujesz przyspieszeń W X, Y i Z, ale także obrotów Xr, Yr i Zr. Bez danych o rotacji nie masz wystarczającej ilości danych, aby ustalić wektor, chyba że założysz, że urządzenie nigdy nie zmieni swojego nastawienia, co byłoby dość ograniczające. Nikt nie czyta TOS w każdym razie.

I wiesz, że INS dryfuje wraz z obrotem Ziemi, prawda? Więc to też. Godzinę później w tajemniczy sposób wspinasz się na 15-stopniowym zboczu w kosmos. Zakładając, że masz INS zdolnego utrzymać lokalizację tak długo, czego telefon nie może jeszcze zrobić. [2]}lepszym sposobem wykorzystania akcelerometrów-nawet z akcelerometrem 3-osiowym - do nawigacji byłoby połączenie z GPS w celu kalibracji INS, gdy tylko to możliwe. Gdzie brakuje GPS, INS ładnie. GPS może nagle wystrzelić Cię 3 przecznice stąd, ponieważ masz zbyt blisko drzewa. INS nie jest świetny, ale przynajmniej wie, że nie uderzył cię meteor. Możesz rejestrować dane z akcelerometru i wiele z nich. Tygodnie warte. Porównaj go z dobrymi (mam na myśli naprawdę dobre) danymi GPS i użyj datamining do ustalenia korelacji trendów między danymi akcelerometru i znanych danych GPS. (Pro wskazówka: będziesz chciał sprawdzić Almanach GPS na dni z dobrą geometrią i dużo satelitów. Czasami możesz mieć tylko 4 satelity i to nie wystarczy) to, co możesz zrobić, to odkryć, że gdy osoba idzie z telefonem w kieszeni, dane akcelerometru rejestrują bardzo specyficzny wzór. Bazując na danych, ustalasz profil tego urządzenia, z tym użytkownikiem, i jaką prędkość reprezentuje ten wzór, gdy miał Dane GPS, aby iść z nim. Powinieneś być w stanie wykryć zakręty, wchodzenie po schodach, Siadanie (kalibracja do 0 prędkość!) i różne inne zadania. Sposób przechowywania telefonu musiałby być traktowany jako osobne dane wejściowe. Wyczuwam sieć neuronową używaną do eksploracji danych. Coś ślepego na to, co oznaczają wejścia, innymi słowy. Algorytm będzie tylko szukać trendów we wzorcach, a tak naprawdę nie zwracając uwagi na rzeczywiste pomiary INS. Wiedziałby tylko historically, when this pattern occurs, the device is traveling and 2.72 m/s X, 0.17m/s Y, 0.01m/s Z, so the device must be doing that now. i odpowiednio posunąłby kawałek do przodu. Ważne, że jest całkowicie ślepy., ponieważ samo Wkładanie telefonu do kieszeni może być zorientowane w jednej z 4 różnych orientacji, a 8 jeśli zmienisz kieszenie. Jest też wiele sposobów na trzymanie telefonu. Mówimy tu o wielu danych. Oczywiście nadal będziesz miał dużo dryfu, ale myślę, że będziesz miał więcej szczęścia w ten sposób, ponieważ urządzenie będzie wiedzieć, kiedy przestałeś chodzić, a dryf pozycyjny nie będzie utrwalający. Wie, że stoisz nieruchomo na podstawie danych historycznych. Tradycyjne INS systemy nie mają tej funkcji. Dryf utrwala się we wszystkich przyszłych pomiarach i związkach wykładniczo. Bezbożna dokładność, lub posiadanie dodatkowej nawigacji do sprawdzenia w regularnych odstępach czasu, jest absolutnie niezbędna w tradycyjnych INS. Każde urządzenie i każda osoba musiałaby mieć swój własny profil. To dużo danych i obliczeń. Każdy chodzi z różnymi prędkościami, z różnymi krokami, wkłada telefony do różnych kieszeni itp. Z pewnością wdrożyć to w świat rzeczywisty wymagałby, aby crunching number był obsługiwany po stronie serwera.

Jeśli używałeś GPS do początkowej linii bazowej, część problemu polega na tym, że GPS ma tendencję do własnych migracji w czasie, ale są to błędy nieodwracalne. Umieść odbiornik w jednym miejscu i zaloguj dane. Jeśli nie ma poprawek WAAS, możesz łatwo uzyskać poprawki lokalizacji dryfujące w losowych kierunkach 100 stóp wokół ciebie. Z WAAS, może do 6 stóp. Możesz mieć więcej szczęścia z pod-licznikiem System RTK na plecaku, aby przynajmniej wyłączyć algorytm ANN.

Nadal będziesz miał kątowy dryf z INS przy użyciu mojej metody. To jest problem. Ale jeśli posunąłeś się tak daleko, aby zbudować ANN, aby wylewać tygodniowe dane GPS i INS wśród użytkowników n, i faktycznie działa do tego momentu, oczywiście nie masz nic przeciwko dużym danym do tej pory. Podążaj tą ścieżką i wykorzystaj więcej danych, aby pomóc rozwiązać dryf kątowy: ludzie są stworzeniami z przyzwyczajenia. W zasadzie robimy to samo, jak idź po chodnikach, przez drzwi, po schodach i nie rób szalonych rzeczy, takich jak chodzenie po autostradach, przez ściany lub z balkonów. Więc załóżmy, że bierzesz stronę od Wielkiego Brata i zaczynasz przechowywać dane o tym, dokąd idą ludzie. Możesz zacząć mapować miejsca, w których ludzie będą chodzić. Jest to całkiem pewny zakład, że jeśli użytkownik zacznie chodzić po schodach, jest na tej samej podstawie schodów, na którą weszła osoba przed nią. Po 1000 iteracji i kilka najmniejszych kwadratów korekty, twoja baza danych wie, gdzie te schody są z dużą dokładnością. Teraz możesz skorygować dryf kątowy i lokalizację, gdy osoba zaczyna chodzić. Kiedy uderzy w te schody, albo skręci w dół korytarza, albo zjedzie chodnikiem, każdy dryf może zostać poprawiony. Twoja baza danych będzie zawierać sektory, które są ważone przez prawdopodobieństwo, że dana osoba będzie chodzić tam, lub że ten użytkownik chodził tam w przeszłości. Bazy danych przestrzennych są do tego optymalizowane za pomocą divide and conquer, aby przydzielać tylko sektory, które mają znaczenie. Byłoby to coś w rodzaju tych projektów MIT, w których robot wyposażony w laser zaczyna od czarnego obrazu i maluje labirynt w pamięci, wykonując każdy obrót, oświetlając wszystkie ściany.

Obszary o dużym natężeniu ruchu będą miały wyższe wagi, a obszary, w których nikt nigdy nie był, otrzymają wagę 0. Obszary o większym natężeniu ruchu mają wyższą rozdzielczość. W zasadzie skończyłbyś z mapą wszędzie, gdzie ktokolwiek był i użyłbyś jej jako prognozy model.

Nie zdziwiłbym się, gdybyś mógł określić, jakie miejsce zajęła osoba w teatrze przy użyciu tej metody. Biorąc pod uwagę wystarczającą liczbę użytkowników idących do teatru i wystarczającą rozdzielczość, będziesz miał dane mapujące każdy wiersz teatru i jak szeroki jest każdy wiersz. Im więcej osób odwiedza daną lokalizację, tym większa wierność, z jaką można przewidzieć, że dana osoba się znajduje.

Również, gorąco polecam dostać (bezpłatny) prenumerata GPS World magazine, jeśli jesteś zainteresowany aktualne badania nad tego typu rzeczami. Co miesiąc się tym przejmuję.

 17
Author: RyanJMcGowan,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-05-01 19:15:15

Nie jestem pewien, jak wielki jest Twój offset, ponieważ zapomniałeś dołączyć jednostki. ("Około 10 na każdej osi" niewiele mówi. : P) To powiedziawszy, to nadal prawdopodobnie ze względu na niedokładność w sprzęcie.

Akcelerometr jest odpowiedni do takich rzeczy, jak określenie orientacji telefonu w stosunku do grawitacji lub wykrywanie gestów (potrząsanie lub uderzanie w telefon itp.)

Jednak próba wykonania dead reckoning za pomocą akcelerometru spowoduje wiele błędów złożonych. Na w przeciwnym razie akcelerometr musiałby być szalenie dokładny, a to nie jest powszechny przypadek użycia, więc wątpię, aby producenci sprzętu optymalizowali go.

 8
Author: Trevor Johns,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-10-19 23:22:12

Android akcelerometr jest cyfrowy, próbki przyspieszenia przy użyciu tej samej liczby "wiadra", powiedzmy, że jest 256 wiadra i akcelerometr jest w stanie wykrywać od - 2g do +2g. oznacza to, że Twoje dane wyjściowe będą kwantyzowane w kategoriach tych "wiadra" i będzie skakać wokół jakiegoś zestawu wartości.

Aby skalibrować akcelerometr Androida, musisz pobrać dużo więcej niż 1000 punktów i znaleźć "tryb", wokół którego zmienia się akcelerometr. Następnie znajdź liczba punktów cyfrowych przez to, jak bardzo zmienia się wyjście i użyj tego do filtrowania.

Polecam filtrowanie Kalmana po uzyskaniu trybu i +/- fluktuacji.

 7
Author: Alex Stone,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-05-31 12:31:46

Zdaję sobie sprawę, że jest to dość stare, ale omawiany problem nie jest poruszany w żadnej z udzielonych odpowiedzi.

To, co widzisz, to liniowe przyspieszenie urządzenia, w tym efekt grawitacji. Jeśli położysz telefon na płaskiej powierzchni, czujnik zgłosi przyspieszenie spowodowane grawitacją, które wynosi w przybliżeniu 9.80665 m/s2, co daje 10, które widzisz. Czujniki są niedokładne, ale nie aż tak niedokładne! Zobacz tutaj {[5] } po kilka przydatnych linków i informacji na temat czujnik może być po.
 5
Author: Simon O'Hanlon,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 11:54:57

Zakładasz, że odczyty akcelerometru w kierunkach X i Y, które w tym przypadku są wyłącznie szumem sprzętowym, utworzyłyby normalny rozkład wokół Twojej średniej. Najwyraźniej tak nie jest.

Jedną z rzeczy, którą możesz spróbować, to wykreślić te wartości na wykresie i sprawdzić, czy wyłania się jakiś wzór. Jeśli nie, to szum jest statystycznie losowy i nie może być skalibrowany względem-przynajmniej dla konkretnego sprzętu telefonicznego.

 0
Author: Hai Phan,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-04-17 04:14:35