Wybór czujnika obrotu do robota

[gogu]

Witam!

Chciałbym zaprojektować robota poruszającego się po płaszczyźnie, który będzie trzymał ustalony prędzej kierunek. Jestem początkującym, więc proszę o wyrozumiałość Wink

Zasada działania (ustalony kierunek - 0 stopni):

1. robot porusza się w linii prostej ze stałą prędkością

2. jeśli skręcimy robota np. o 30 stopni w prawo, ten sterując pracą dwóch silników i kół skoryguje pozycje na 0 stopni i ruszy dalej.

Do pomiaru kąta skrętu planuje wykorzystać żyroskop analogowy. Z tego co wyczytałem to wskazuję on prędkość kątową odczytywaną z napięcia. Całkując to otrzymujemy kąt.

Bazując na tym wyniku chciałbym sterować pracą silników, aby powrócić do ustalonego kierunku.

Jednak wyczytałem też, że z żyroskopem wiążą się błędy i tzw 'dryf'. Zagłębiającej się dalej w temat doczytałem, że dryf można zlikwidować przez akcelerometr. I tutaj moje pytanie - Jak to zrobić?

Znalazłem informacje, że musiałbym obliczyć błąd między odczytem kąta z żyroskopu, a kątem z akcelerometru (kąt_żyroskop - kąt_acc) , jednak akcelerometr podaje przyspieszenie liniowe. Jak rozwiązać ten problem ?

Dziękuje za pomoc.

Pozdrawiam!

[marek1707]

Utrzymywanie kierunku to bardzo ogólne pojęcie. Jeżeli dokładnie kierunek jest tą najważniejszą rzeczą dla Twojego robota, to zacząłbym od czujników które w sposób bezwzględny taki pomiar robią, np. magnetometru/kompasu. Takie coś nie płynie w czasie i błędy kolejnych odczytów nie nawarstwiają się. Wszystko zależy jednak od konkretnego zastosowania. Jeżeli będzie to mysz w labiryncie to masz dużo więcej informacji które możesz wykorzystać i akurat kompas jest tu raczej niepotrzebny. Jeżeli będzie to pomieszczenie i to zastawione np. jakimiś maszynami czy stalowymi regałami to magnetometr po prostu zgłupieje. Dryf żyroskopu i powstający w ten sposób błąd całkowania można eliminować akcelerometrem bo zauważ, że na zakręcie powstaje siła odśrodkowa i pomiar przyśpieszeń poprzecznych (a dokładniej kierunku wektora wypadkowego dla 2 osi) pomaga oszacować czy jedziesz prosto czy skręcasz. Nie wiem też, czy dla Twojego robota ważne będzie tylko utrzymywanie kierunku (i wtedy przesuniecia równoległe są bez znaczenia) czy trafianie z daleka do jakiegoś celu (i wtedy trzeba mieć informację o położeniu XY względem celu a tu już wiedza o zakrętach nie wystarczy).

Generalnie problem fuzji sygnałów z kilku czujników nie jest trywialny i naprawdę niewielu ludzi wie jak to naprawdę zrobić dobrze. Reszta korzysta z gotowych rozwiązań. Dobrym przykładem mogą tu być tak popularne ostatnio wielowirnikowce. Tam orientacja przestrzenna jest rzeczą podstawową a stosowanie wszystkich możliwych czujników (accel, żyro, baro, magnetometry) jest już standardem. Na początku wydaje to się proste - wystarczy policzyć kilka wielkości fizycznych, ale gdy się dokładniej przyjrzysz to się okazuje, że każdy pomiar jest obarczony pewnymi błędami: stałymi i losowymi. Orientacje policzone na podstawie każdego czujnika osobno nie pokrywają się ze sobą i rozwiązanie takiego układu równań nie jest już punktem, tylko stanowi raczej pewną przestrzeń możliwych orientacji. To właśnie sprytne algorytmy filtrowania nadążnego pozwalają na bieżąco śledzić "zaufanie" do każdego z czujników i bazując dodatkowo na wiedzy od systemów napędowych i modelu dynamiki samego pojazdu pozwalają wyznaczyć najbardziej prawdopodobne rozwiązanie. I tak 100 razy na sekundę 🙂

Wiele zależy od tego jak dobrze chcesz to zrobić, jakie to jest zastosowanie, w jakim środowisku i ile masz czasu/pieniędzy. Napisz coś więcej.

[gogu]

Robot wydaje się nie być tak bardzo skomplikowany. Nie ma przeszukiwać żadnego labiryntu, ani dotrzeć do określonego celu. Po prostu musi jechać cały czas prosto, a gdy go skręcimy (np. przestawimy ręka o 30 stopni w prawo) to musi to wykryć, obrócić się znowu do początkowego kierunku i ruszyć dalej. Nie musi działać szybko, lecz poprawnie. Poruszać się będzie po płaszczyźnie, pod górkę i z górki (na stole, podłodze - bez metalowych przedmiotów i innych takich).

Czas to około 2 miesiące, a fundusz w granicach rozsądku 😉

Mamy do dyspozycji Atmege32, a w razie czego możesz zaproponować coś innego?

[marek1707]

Czy w takim razie kompas nie wydaje się dobrym rozwiązaniem? Czy widzisz jakieś ograniczenia takiego sposobu orientacji kierunkowej w tej konkretnej aplikacji?

[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

[gogu]

W sumie racja, używając kompasu uniknę przecież dryfu i błędów. Zaproponuję to nowe rozwiązanie i dam znać.

[gogu]

Podbijam Niestety kompas odpada. Prowadzący twierdzi, że muszę wykorzystać żyroskop i akcelerometr. Także ponawiam pytanie. Jak z tym dryfem? Jak sie go pozbyć przy pomocy akcelerometru?

[OldSkull]

Za pomocą akcelerometru pozbędziesz się tylko dryfu w osiach X i Y (do tego jest zwykle używany popularny filtr Kalmana). Przyspieszeń w osi Z nie wykryjesz (nawet jak dasz 2 akcelerometry na narożnikach to przy obrocie zmiana przyspieszeń będzie zbyt mała aby ją wykryć). Z racji iż przy wolnych zmianach można uznać, że pomiar akcelerometru można przełożyć bezpośrednio na kąt, służą one do określania kąta obrotu w osiach X i Y, natomiast w osi Z działa magnetometr. Ale uwaga, aby był na pcb daleko od ścieżek szybkozmiennych sygnałów i prądowych, a samo pcb daleko od silników i przewodów prądowych. Zresztą jakbyś miał zwykły kompas to możesz sam próbować ocenić gdzie najlepiej zamontować.

[MirekCz]

Ja widzę dwie możliwości:

a) użyć kompas mimo wszystko, ale tylko do kalibracji żyroskopu ( filtr Kalmana itd.)

b) Zastosować pomiar prędkości kół i na tej podstawie kalibrować żyroskop. Oczywiście w momencie uślizgu kół i/lub podniesienia i obrócenia robota koła się nie obrócą - wtedy korzystasz tylko z żyroskopu, który w czasie wcześniejszej normalnej jazdy masz szansę skalibrować i dane będą dosyć dokładne.

[marek1707]

Podsumowując: nie da się. Nie dysponując czujnikiem wartości bezwzględnej możesz tylko robić lepsze lub gorsze estymacje położenia, ale błędu nie wyeliminujesz z definicji. Używając coraz doskonalszych (i droższych) sensorów oraz zaprzęgając coraz bardziej wyrafinowaną matematykę do obróbki ich sygnałów będziesz miał coraz lepsze pojęcie o orientacji ale to wszystko. Rozumiem, że celem "Prowadzącego" nie jest tak naprawdę zbudowanie pojazdu który w coś trafia przy wykorzystaniu odpowiednich rozwiązań, tylko zmuszenie Ciebie do zdobycia wiedzy na temat używania akcelerometrów i żyroskopów. Inaczej przyjąłby z radością pomysł magnetometru jako bardzo sensownego czujnika wielkości bezwzględnej - azymutu.

No to nie ma rady, musisz zacząć przeszukiwać literaturę. Zacznij od praktyków - to najłatwiej przemawia akurat do mnie. Filtry komplementarne:

http://robottini.altervista.org/tag/complementary-filter

http://web.mit.edu/scolton/www/filter.pdf

to początek, ale pewnie i tak skończy się na filtrze Kalmana:

http://forum.arduino.cc/index.php?topic=58048.0

http://www.csulb.edu/~hill/ee400d/Reference%20Folder/Kalman%20Filter%20Research.pdf

Problem nie jest nowy i nie jest trywialny więc i opracowań teoretycznych uzbierało się trochę. Nawet coś tu na Forbocie leży "w tym temacie". Od czasów lotów Mercury/Gemini/Apollo zmieniły się czujniki i możliwości obliczeniowe więc z jednej strony mamy trochę łatwiej, ale z drugiej wymagania wzrosły znacznie czyli: nadal nie jest to kaszka z mleczkiem 😐

[gogu]

Aktualizacja tematu 🙂

I. Przybliżenie, przypomnienie zasady działania robota:

1. Robot rusza, jedzie cały czas prosto.

2. Następuje obrót robota w dowolnym kierunku wykonany przez nas (np. ręką)

3. Robot wykrywa zmianę, koryguję ją i wraca do dalszej jazdy w początkowym kierunku. Jeśli w punkcie 2-gim przejechał kawałek drogi w góre czy dół - nie musi wracać na trasę, lecz trzyma się tylko prawidłowego kierunku.

II. Ostatecznie dostaliśmy wolną rękę na wybór czujników/sprzętu. Z wcześniejszych postów w tym temacie, wynika, że najlepiej użyć kompasu. Dlatego prosiłbym o dokładny model (może nawet link do sklepu) czegoś w rozsądnej cenie w stosunku cena/jakość.

uC to ATmega. Myślałem nawet nad zestawem arudino, żeby było łatwiej.

Opcja żyroskop, akcelerometr + np. filtr kalmana wydaję się o wiele trudniejsza niż kompas.

III. To będzie mój początek 'w praktyce'. Czy sposób w jaki chciałbym to zrobić ma szansę zadziałać?

1. W chwili startu zapisujemy wartość z kompasu, jako kierunek który robot ma utrzymywać (załózmy 0 stopni).

2. Podczas dalszej jazdy cały czas monitorujemy wskazanie kompasu.

3. Jeśli kompas nagle wskaże (30 stopni) , robot się zatrzymuje. kontrolując pracę silników korygujemy pozycje, tak długo, aż kierunek znowu wyniesie 0 stopni.

4. Robot rusza dalej.

Pozdrawiam! 🙂

[marek1707]

Może zamiast od razu ograniać całość funkcji i zachowań projektu oprogramowania lepiej od razu na początku podziel go na mniejsze zadania. Będziesz mógł skupiać się na jednym tylko zagadnieniu na raz i nie będzie to przerażająca ściana wielu krzyżujących się interakcji. Proponuję coś takiego:

1. Proces "opiekujący się" kompasem. Zakładając, że wyniki odczytywane z kompasu są obarczone błędami "szybkimi" i "wolnymi" zastanów się nad obróbką tych danych tak, by reszta rzeczy korzystających z najważniejszego parametru - azymutu nie musiała już się zastanawiać czy jest on dobry, w miarę dobry czy też zaszumiony i właściwie - niepewny. Poczytaj o próbkowaniu, o filtrowaniu itp. Zacznij od najproszych algorytmów typu moving average lub IIR. Potrafią zrobić zaskakująco dużo dobrego. Niech wyjściem z tego procesu będzie aktualny azymut czyli położenie czujnika względem północy.

2. Proces współpracy z użytkownikiem. To on powienien być odpowiedzialny za zmianę stanów pracy (stoimy, jedziemy, ustawiamy kierunek czyli celujemy w coś itp). Z jednej storny będzie miał we/wy typu przyciski, LCD, LEDy czy też Bluetooth - nie wiem co tam wymyślisz a z drugiej powinien wysyłać komunikaty do zainteresowanych procesów typu: start jazdy, stop, ustawienie kierunku docelowego itp.

3. Proces kontroli kierunku. Ten powinien pobierać aktualny azymut i na bieżąco porównywać go z zapamiętanym azymutem wzorcowym. Na tej podstawie powinien wypracowywać komendy typu skręć w lewo, skręć bardziej w lewo itp Porównywanie to tylko hasło. To może być rzeczywiście zwykłe odejmowanie (regulator typu P) ale możesz tu wprowadzić całą masę fajnych ulepszeń (wykrywanie szybkich zmian - regulator PI, wykrywanie małych ale nawarstwiających się w czasie błędów - regulator PD itp). Wyjściem z tego powinien być sygnał błędu.

4. Proces kontroli napędu. Ten - na podstawie sygnału błędu powinien umieć sterować silnikami, czyli zmieniać róznicę ich prędkości. Prędkość wspólna czyli to co będzie wyznaczało szybkość robota powinna być otrzymywana od użytkownika lub wypracowywana na podstawie np. błędu - ostatnio były małe więc jedziemy dobrze i możemy przyśpieszać.

Co wymyślisz to tak będzie ale taki (lub inny) podział powoduje, że możesz np. łatwiej rozdzielać zadania w grupie. Każdy odpowiada za swoją działkę i nawet jeśli popełni błąd, nie rozwala całości. Każdy proces powinien być tak napisany by był w miarę odporny na głupoty - jeśli takie dostanie i powienien w takiej sytuacji wysyłać jasne komunikaty do procesu interfejsu z użytkownikiem. Mając taką modułową konstrukcję możesz w łatwy sposób dodawać nowe kawałki. Jeżeli na płytce od razu przewidzisz miejsce na akceleromer i żyroskop, to późniejsze ich oprogramowanie i zmiana procesu kontroli trajektorii z prostego regulatora kompasu na np. filtr komplementarny lub nawet Kalmana nie wywali całości projektu w powietrze. W przyszłości możesz dodać proces sterowania zachowaniem robota na wyższym poziomie abstrakcji np. reakcje na ew. przeszkody i omijanie, liczenie trasy, próby wracania do miejsca startu itd.. Zabawa na długie zimowe wieczory, ale ważne jest dobre zaprojektowanie samej platformy, żeby nie było głupich ograniczeń 🙂

[gogu]

Odkopując temat.

Robot wygląda tak:

Użyliśmy:

- 2x slinik mini-Pololu (Pobór prądu: 80mA bez obciążenia / 800mA maks, Prędkość obrotowa: 120obr/min bez obciążenia), sterowne mostkiem L293D

- Moduł 3-osiowy magnetometr (kompas) HMC5883L

- Arduino Uno

Kompas umieszczony jest na plastikowej rurce, ponieważ łapał zakłocenia od płytki Arduino i w dość oryginalny sposób rozwiązaliśmy ten problem.

Wszystko zasilane jest z Arduino, a sama płytka z baterii 9V

Soft mamy napisany - program wyłapuje 1szy odczyt kompasu, zapisuje go do zmiennej i porównując bieżący odczyt z zapisanym (w pętli while co 0,1s) steruję pracą silników.

Wszystko było fajnie i pięknie, dopóki nie pojawił się problem. Kompas działał poprawnie, a nagle (nie wiemy czemu) odczyty zaczeły wariować - tzn. trzymając robota w jednej pozycji, kompas przez kilka sekund pokazuję dobry odczyt (mniej więcej stały), a po chwili odczyt spada lub rośnie gwałtownie o 10-20 stopni.

Przez to robot jeździ jak połamany. Nie za bardzo wiemy czym to może być spowodowane. Odczyt jest prawidłowy (od 0 do 360 stopni), lecz trzymając dłuzej w jednej pozycji są te dziwne skoki.

Może ktoś ma jakiś pomysł?

[MirekCz]

Skąd macie płytkę kompasu? Macie do niej schemat?

Próbowaliście podłączyć tylko kompas do arduino i sprawdzić czy wtedy też się dzieją takie rzeczy?

Jak wygląda zasilanie (oscyloskop) dochodzące do kompasu?

Mam takie moduły własnej produkcji i nigdy nie widziałem takiego zachowania. Zakłócenia natomiast raczej łapaliście z silników a nie z Arduino 😉

[gogu]

Możliwe, że od silników.

Schemat kompasu

Moduł wyposażony magnetometr HMC5883L (wbudowany stablizator)

Napięcie zasilania 3,3V/5V

Interfejs: I2C

Podłączony mamy pod 3,3 w Arduino.

Co do pytań. Niestety dostępu do oscyloskopu nie mamy, a rozbierać go będziemy jutro i sprawdzimy wszystko na spokojnie. Dziś już nam czasu nie starczyło.

Przez przypadek raz na szybko podłaczyliśmy odwrotnie VCC z GND do kompasu i mniej wiecej po tym zaczely sie problemy tak teraz sobie przypomialem - czy to mozliwe?

[MirekCz]

1. Złe podłączenie zasilania jak najbardziej mogło ubić układ.

2. Nie za bardzo rozumiem podłączenie tego 3,3V? Podłączone powinniście mieć tylko 5,0V pod tą płytkę, a arduino najlepiej żeby pracowało na 3,3V. 3.3V z płytki kompasu nie powinno iść do arduino, bo tylko zaśmiecacie napięcie idące do czujnika, a ono powinno mieć możliwie mało zakłóceń.

Najlepiej pokaż schemat podłączenia kompasu i arduino