Problem z całkowaniem wartości odczytu przyspieszenia z akcelerometru

[Banan3xL]

Witam wszystkich!

Mam dostęp do dosyć dokładnego i wysokiej klasy akcelerometru. Chciałem sprawdzić dokładność z jaką będzie wskazywał swoje położenie. Za pomocą funkcji wbudowanych do jego bibliotek, odczytuję wartość przyspieszenia w osi (dajmy na to y). Problem jest w tym, że błędy jakie się nawarstwiają są na tyle duże, że jego położenie początkowe dosyć różni się od końcowego. Odczyt koniecznie musi odbywać się w czasie rzeczywistym.

Przykładowo wygląda to tak, dosyć łopatologicznie, jednak wydaje mi się, że powinno działać, a jednak jest inaczej:

a- przyspieszenie, V - prędkość, s-droga, dt -jakaś stała całkowa którą wcześniej przyjąłem odpowiednio niską

a=(odczytuje wartość z interesującego mnie czujnika),
V+=a*dt (czyli jakaś stała całkowa którą wcześniej przyjąłem odpowiednio niską)

s+=V*dt

Błędy pojawiają się już po pierwszym całkowaniu, gdzie V, w pewnym momencie ustala się na jakiejś wartości, przez co odległość stale się zmienia.

Macie jakieś pomysły w jaki sposób można uniknąć tego błędu?

Całość wygląda jak na rysunku, a-czerwony, V-niebieski, s-czarny

__________

Komentarz dodany przez: Sabre

[marek1707]

Witamy w rzeczywistym świecie 🙂

Jak rozumiem, odczyty z akcelerometru są czerwone, prędkość jest niebieska a droga czarna, czy tak? No to teraz popatrz na to z dystansu: czy Twój akcelerometr dostał drgawek, ręce Ci latają z przejęcia eksperymentem czy jednak coś źle mierzysz? Nie twierdzę, że "źle" to znaczy, że nie umiesz. Po prostu Twój system pomiarowy (cokolwiek to jest) wprowadza tyle zakłóceń, że prawdziwe przyśpieszenie ginie w tych śmieciach bezpowrotnie. Czy rzeczywiście czujnik tak wariuje jak pokazują te zęby na wykresie? Nie chce mi się wierzyć, że umieściłeś go do tak prostego testu na bloku silnika swojego samochodu. A jeśli przyśpieszenie nie było takie jak pokazuje wykres, to żebyś nie wiem jak dobrze całkował, dalej wszystko już jest źle.

Napisz coś więcej: co to za czujnik, jak go mierzysz, czym, jakie masz skale pionowe (w fizycznych jednostkach) i poziome itd. Bez tego trudno ocenić, co może być nie tak - a jest bezsprzecznie. Być może mierzysz coś na granicy rozdzielczości pomiarów (np. przyśpieszenia 1mm/s²), być może szumy wchodzą z kabli analogowych, być może z zasilania, z referencji przetwornika. Nie wiemy nawet, czy dostajesz sygnał analogowy, czy już obrobiony w akcelerometrze słowa cyfrowe.

I na koniec: metoda całkowania przyśpieszeń z definicji będzie miała błąd jaki zauważyłeś. Całą sztuką jest go zmniejszyć do wielkości akceptowalnej, najpierw przez poprawne mocowanie czujnika (amortyzacje itp), zrobienie jak najlepszego toru pomiarowego a na koniec, gdy i tak błąd jest zbyt duży - także poprzez fuzję sygnału z kilku różnych czujników.

[Banan3xL]

Tak czerwony kolor to ten odczyt.

Model czujnika to VectorNAV 100-Rugged, a więc jest to mikrosystem orientacji.

Podpięty jest do komputera przez RS232.

Zasilany jest przez USB z komputera.

Jego zakres +/- 16g w każdej z trzech osi.

Żyroskop 2000°/s.

Błędy wyrównania w obu przypadkach mają 0,05°.

Hehe oczywiście nie mierzyłem silnika, stresuje się rzadko 😃 :D 😃

Próbowałem ruchy wykonywać w różny sposób. Czy to normalnie w ręce, czy z jednego punktu do drugiego po lini prostej, normalnie go przesuwając po powierzchni i np podczas takiego pomiaru z punku A do punktu B, gdzie zupełnie nie wracałem do punktu początkowego, a wręcz stale odjeżdżałem na około 50cm, wykres drogi jaką przebył potrafi pokazać, że odjechał na jakąś odległość, po czym wrócił do punktu początkowego i nagle zaczął się cofać, czyli tak jakbym jednak wrócił do punktu A

.

Zdaję sobie sprawę, że stale na czujnik działa siła przyspieszenia ziemskiego, ale żeby takie błędy się nawarstwiały?!

Mierzone w tym przypadku było przyspieszenie w osi y, a więc prostopadłej do przyspieszenia ziemskiego. W takim wypadku wiem, że zawsze będzie występowała jakaś wartość przyspieszenia ziemskiego, a to będzie miało wpływ na całkowanie prędkości itd.

Szczerze mówiąc ja błędu szukałem raczej w kierunku zbyt prostego całkowania, lub już sam nie wiem czego. Sam odczyt przyspieszeń wydawał mi się dosyć poprawny.

Sabre - przepraszam, poprawiłem. 😉

[marek1707]

Acha, czyli masz czujnik umieszczony w jakiejś kostce/obudowie wysyłający co jakiś czas przyśpieszenie w którejś osi poziomej do PC, tak? Suwasz nim po stole i oczekujesz, że dostaniesz z tego prędkość a następnie pozycję.

Jeżeli czujnik jest rzeczywiście dobry a Ty nie masz wpływu na otrzymywane przyśpieszenia bo dostajesz je w postaci cyfrowej to w takim razie - masz rację - problem leży "w okolicach" całkowania.

Po pierwsze dostajesz jakieś wartości co jakiś czas. Co robi Twój algorytm? Jak rozumiem sumuje je w czasie. To jest całkowanie numeryczne które zakłada, że pomiędzy pomiarami wielkość się nie zmieniała. To tak, jakbyś sumował pola kolejnych prostokątów o szerokościach takich jak odstęp między pomiarami i wysokościach takich jak otrzymane pomiary. Gdzie jest błąd? Leży na samych "szczytach" tych prostokątów, gdzie wartość rzeczywista jest ciągła, ale wcale nie jest stała. Kiedy to będzie dokładniejsze? Wiadomo, gdy szerokość prostokątów będzie dążyła do zera. Wtedy "schodki" będą coraz węższe a "trójkąty błędów" leżące między "dachem" prostokąta a wartością rzeczywistą będą coraz mniejsze. Gdy odstępy czasu spadną do zera będzie to już prawdziwe całkowanie "analogowe" - oczywiście nie do zrobienia. Czy masz możliwość regulacji częstotliwości pomiarów i odsyłania ich wyników do PC? Jeżeli tak, zażądaj najwyższej. Być może będzie to wymagało zmiany prędkości portu szeregowego. Jeżeli nie masz wpływu na szybkość pomiarów, musisz poprawić swój algorytm. To co możesz zrobić to zaimplementować interpolator czyli funkcję, która "wymyśla" pośrednie wartości przyśpieszeń na podstawie kilku sąsiednich pomiarów. Wtedy - mając dużo więcej próbek - możesz całkować dużo częściej. Im lepszy zrobisz interpolator, tym dokładniej będziesz całkował. Im więcej będzie on "wiedział" o systemie którego dane dostaje - tym będzie lepszy. W najprostszym przypadku możesz zrobić liniowy, to wiadomo. Bierzesz dwa sąsiednie punkty, wyznaczasz parametry łączącej je prostej a potem dowolnie dużo punktów na niej - i je sumujesz. Wtedy dostaniesz to, co pokazuje Twój zębaty wykres - dopiero wtedy. Zauważ, że obecnie nie całkujesz tego co na wykresie, tylko raczej poziome schodki o wysokości takiej jak wyniki pomiarów. Potem możesz zacząć bawić się w interpolatory wielomianów wyższego rzędu - już z kwadratowym powinno być dużo lepiej. Im będzie więcej przetwarzania tym będzie dokładniej, ale zapłacisz za to dość wysoką cenę - czas. Im do obliczeń będziesz potrzebował więcej punktów tym opóźnienie będzie większe i tym bardziej Twój system będzie spóźniał się za aktualnym stanem obiektu mierzonego.

Możesz też podejść inaczej: założyć, że wyniki obarczone są dużym szumem losowym albo, że zawierają częstotliwości których nie spodziewasz się w odbieranym sygnale. Jeżeli jesteś absolutnie pewien, że zęby na wykresie są "nieprawidłowe" możesz zacząć od filtrowania. To nie miejsce na wykład o tym, ale - jakkolwiek to zrobisz - sprowadzi się do spowolnienia zmian wielkości mierzonej. To tak, jakbyś (przy niezmienionej szerokości prostokątów) nie pozwalał przyśpieszeniu na szybkie zmiany i zbytnie "oddalanie się" od pomiaru który zrobiłeś ostatnio. Wypłaszczasz krzywą pozbywając się zębów i tym samym przybliżając ją do poziomych "dachów" całkowanych prostokątow. Poszukaj haseł "moving average filter" oraz "IIR filter (Infinite Impulse Response)" - to najprostsze w implementacji i przynoszące czasem zdumiewająco dobre efekty.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay