Micromouse IPreferPI

[baton]

Po długim czasie postanowiłem w końcu opisać szerszemu gronu moją pierwszą poważną konstrukcję (pomijając LFa sprzed roku, robiącego teraz za płytkę uniwersalną z przetwornicą). Postaram się zgrubnie opisać konstrukcję, a szczególny nacisk położyć na szereg popełnionych błędów i spostrzeżeń powstałych podczas konstrukcji i programowania.

Robot "IPreferPI" powstał w ramach warsztatów rekrutacyjnych Koła Naukowego Robotyków KoNaR na PWr. Gdy zaczynałem nad nim pracę, Devil jeszcze nie istniał, a inne myszy startujące w zawodach (chyba w Krakowie już wtedy była kategoria MM) przeważnie obijały się o ściany i raczej do żwawych nie należały. Celem projektu było... cóż, skopanie im tyłków. Dlatego też w założeniach miała to być lekka, zwrotna i szybka mysz o sensoryce, napędzie i płynności ruchów (choć niekoniecznie prędkości) robotów japońskich. Częściowo udało się to osiągnąć, lecz w trakcie programowania trafiłem na problem z enkoderami, którego nie udało się rozwiązać - szczegóły niżej.

Mechanika

Cała mechanika oparta jest o płytkę laminatu grubości 1,5mm. Bezpośrednio do niej przykręcone się silniki, od spodu na taśmę izolacyjną przyklejona jest kulka podporowa. Z powodu zastosowania enkoderów magnetycznych mocowanych na zewnątrz kół konieczne było wyrzeźbienie odpowiednich stelaży. Magnesy zostały wklejone w "kołpaki" wycięte z laminatu, a te przyklejone kropelką do felgi. Mimo że wszystko robione było na oko - magnesy zostały umieszczone idealnie nad środkiem enkodera i nie przemieszczają się w trakcie obrotu koła.

Montaż kulki podporowej

Szczegóły montażu enkodera

W teorii jest to konstrukcja bardzo prosta, ale jednak popełnionych zostało sporo błędów:

[*]nie przewidziano miejsca na otwory pod śruby mocujące kulkę podporową, przez co jest ona przyklejona taśmą izolacyjną. Ma to też swoje zalety - mocowanie takie dobrze tłumi drgania i ewentualne nierówności podłoża;

[*]diody IR oraz fototranzystory użyte w roli czujników odległości wychodzą poza obrys płytki, przez co każde zderzenie ze ścianą, których ciężko uniknąć podczas początkowego pisania oprogramowania robota, skutkuje ich wyginaniem i koniecznością ponownego ustawiania w poprawnej pozycji;

[*]tylna oś została umiejscowiona za daleko względem środka robota, przez co czasem podczas robienia obrotu o 180° robot zahacza przodem o ściankę - no i mamy bubę opisaną wyżej, albo po prostu nie robi całego zwrotu;

[*]nie przemyślano sposobu wygodnego i bezpiecznego mocowania ogniw dostarczających zasilania - z pomocą znów musiała ruszyć taśma izolacyjna;

[*]nie przewidziano mechanicznego wyłącznika odcinającego zasilanie, zgodnie z naszą akademikową tradycją uznanego za zbędny - a potem trzeba się było szarpać z kablami.

Robot napędzany jest przez silniki Polulu HP z przekładnią 30:1, jeździ na oponach Solarbotics, które mi akurat bardzo się podobają (choć musiały zostać przyklejone do osi klejem na gorąco, bo firmowa śrubka się luzuje i generalnie jest beznadziejna).

Elektronika

Silniki zasilane są bezpośrednio z baterii. Cała logika oraz diody IR dostają 5V ze stabilizatora LM1117. W układzie wydzielone zostały 3 pola masy - cyfrowa (procesor i logika mostka H), analogowa (diody sygnalizacyjne i czujniki) oraz przeznaczona dla silników. Łączą się one tuż przy baterii i kondensatorze 220uF.

Całość działa pod kontrolą ATMegi1284P. Wersja -4 głównie z racji na przerwania zew. na wszystkich pinach, a pamięci taki ogrom, gdyż inne były w trakcie konstrukcji niedostępne. Mikrokontroler taktowany jest przez kwarc 20MHz. Mysz wyposażona została w odbiornik podczerwieni TSOP4840 umożliwiający zdalny start/stop. Bardzo udanym pomysłem było wyprowadzenie złącza interfejsu UART, który poprzez moduł BT został wykorzystany do bezprzewodowej kontroli myszy w trakcie pisania oprogramowania i pierwszych chwil w labiryncie - bardzo polecam takie rozwiązanie, choć niestety nie da się w ten sposób wizualizować danych w matlabie (po prostu nie da się wykorzystać połączenia COM tworzonego przez BT w komputerze - potwierdzone przez pracownika na forum Matlaba).

IPreferPI z zainstalowanym modułem BT

Sensory zostały oparte na bazie diod IR SFH4550 oraz fototranzystorów BPV11. Diody uruchamiane są impulsowo poprzez układ ULN2003. Rozwiązanie to jest wyjątkowo skuteczne - byłem zaskoczony jak czysty, niezaszumiony i łatwy w interpretacji daje to odczyt. Rezystory między emiterami fototranzystorów a masą zostały dobrane doświadczalnie i z pewnością nie jest to 470Ohm jak na rysunku poniżej - zatrzymałem się chyba w okolicach pojedynczych kiloomów, nie mam teraz myszy pod ręką, żeby to sprawdzić. Diody IR połączone są bezpośrednio z driverem, bez oporników - zapalane są na ułamki sekund, a pozwoliło to na zwiększenie odległości i czułości czujników.

Wykorzystane enkodery to AS5040 firmy AMS.

Mysz zasilana jest z dwóch ogniw LiPo kupionych kiedyś-gdzieś o pojemności 250mAh. Są wystarczające do dość długiego szperania po labiryncie, a ważą niewiele i zajmują mało miejsca.

Schemat ideowy elektroniki robota

Oprogramowanie

I tu pojawił się problem. W skrócie - ATMega najwyraźniej nie jest w stanie wyrobić się z liczeniem impulsów z enkodera. Poniżej zamieszczam najlepszy kod, jaki byłem w stanie wymyślić, ale nadal nie pozwał on na poprawną obsługę enkoderów. Objawy były następujące - przy zadaniu przejechania np. 1000 tików enkodera z prędkością powiedzmy 250 tików na sekundę robot przemieszczał się o 50 jednostek. Gdy natomiast miał przemieścić się o 1000 tików, ale z prędkością 500t/s, to jechał oczywiście szybciej, ale na odległość znacznie większą - np. 75 jednostek. Wniosek jest prosty - im szybciej jechał robot, tym więcej tików zostawało pominiętych, przez co kontrola odległości ze zmienną prędkością jazdy była niewykonalna. Byś może dałoby się to rozwiązać wykorzystując interfejs SPI w enkoderach, dokładając tam jakiś układ poboczny zajmujący się tylko obsługą enkoderów albo stosując inną sztuczkę, ale prawdę mówiąc po wykryciu źródła problemów zostałem bardzo zniechęcony do dalszej walki.

Pomimo tych problemów udało się zaimplementować w miarę sensowne poruszanie się po labiryncie - chyba jedyny istniejący filmik zamieszony jest na dole. Ponieważ jednak z racji na problemy z enkoderami nie dało się polepszyć parametrów jazdy, np. wprowadzić łagodnego pokonywania zakrętów, pełen algorytm przeszukiwania algorytmu nigdy nie został do końca zaimplementowany. Zamiast tego zaczęła powstawać nowa konstrukcja, pozbawiona wszystkich wymienionych błędów, która mam nadzieję zawojuje RA2012 😉

ISR(PCINT2_vect) // aktualna wartość enkoderów w globalnych int enkoderL, enkoderP
{
 enkl = (PINC & (3 << 0)) >> 0; // enkodery podłączone do pinów 0,1,2,3 portu C
 enkp = (PINC & (3 << 2)) >> 2; // enkl - akt. stan lewego , penkl - poprzedni
 if(enkl != penkl)
 {
   if( (penkl & 1) ^ ((enkl & 2) >> 1) )
     enkoderL--;
   else
     enkoderL++;
 }
 if(enkp != penkp)
 {
   if( (penkp & 1) ^ ((enkp & 2) >> 1) )
     enkoderP--;
   else
     enkoderP++;
 }
 penkl = enkl;
 penkp = enkp;
}

Podsumowując, budowa IPreferPI przyniosła głównie olbrzymią dawkę doświadczenia jeśli chodzi o budowę, działanie i wymagania robota klasy MM. Plany były ambitne, rzeczywistość dość je unormowała, ale z pewnością całość pracy zaprocentuje w trakcie tworzenia TAU, myszy która już jest w budowie.

Starałem się wspomnieć o wszystkim, co zasługuje na uwagę, ale chętnie odpowiem na wszelkie pytania i wysłucham krytyki Sabre 😋

Podążanie za kartką:

Jedyny film z "labiryntu":

Szczerzy kły!

[Treker (Damian Szymański)]

Bardzo ciekawa konstrukcja, czekam na następce.

Mam pytanie co do tego problemu z programem czytającym enkodery.

Czy nie lepiej byłoby podpiąć wyjścia enko jako osobne przerwania, bo tutaj widzę, że masz oba enkodery w jednym przerwaniu. Dodatkowo jak dla mnie (chociaż, nie jestem ekspertem w tym) brakuje chyba blokowania przerwania po wejściu do niego i odblokowania na wyjściu. Testowałeś takie rozwiązania?

[piotreks-89]

Robot naprawdę zacny 🙂 Szkoda, że płytki nie zabezpieczyłeś przed utlenianiem (albo ją nadtrawiłeś 😋 ). W Inżynierze obsługa enkoderów magnetycznych zajmują się Tiny13 i może warto iść w tym kierunku? Na jak długo włączasz diody (bo prąd przez nie płynący musi być pokaźnych wartości)?

Komentatorów w filmiku masz najlepszych 🤣

[Harnas]

Całkiem ciekawa mysz. Czemu nie założyłeś osłon również na diody IR?

Może warto było by spróbować zmniejszyć rozdzielczość enkoderów na minimum?

Powodzenia z następną konstrukcją, mam nadzieje że na RA2012 będziemy ze sobą rywalizować 🙂

Polulu HP

🙂

[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

[MatManiak]

Może warto było by spróbować zmniejszyć rozdzielczość enkoderów na minimum?

🙂

Dokładnie - jak miałeś problem z gubieniem impulsów bo się atmega nie wyrabiała, to mogłeś sobie zmniejszyć rozdzielczość tych enkoderów - w nocie katalogowej jest opis programowania tych enkoderów. Mogłeś też spróbować użyć innego trybu ich użycia, bo tam są chyba 3 z tego co pamiętam (jeden z trybów zwraca "na żądanie" odpowiednią wartość którą inkrementuje sobie w pamięci sam enkoder, dzięki czemu masz gotową obsługę tego enkodera).

Ogólnie jednak konstrukcja bardzo dobra, choć z tymi wystającymi diodami poza obrys to trochę wpadka 😉 Nie mniej jednak, całość działa a to najważniejsze:) No i w końcu kolejny MM na forum jest! Oby więcej tego typu konstrukcji:)

A może zdradzisz coś więcej na temat nowej myszy TAU? Jak idą postępy? Może workloga założysz? :>

[dondu]

Twój problem z enkoderami nie musi wynikać z długości pracy Twojej funkcji ich obsługi, tylko z blokowania dostępu do tej funkcji przez inne funkcje obsługi przerwań.

Innymi słowy przy 20MHz zegarze 500tików/s to żadne obciążenie dla uC. Ale jeżeli inna funkcja przyblokuje przerwania na dłużej, to możliwe jest pominięcie któregoś impulsu enkodera, ponieważ flaga przerwania PCINT2 zostanie nadpisana pomimo, że poprzednie przerwanie jeszcze nie zostało obsłużone.

Zastanów się nad całym programem pod tym kątem.

EDIT:

Dodatkowo jak dla mnie (chociaż, nie jestem ekspertem w tym) brakuje chyba blokowania przerwania po wejściu do niego i odblokowania na wyjściu.

Generalnie globalne przerwania są wyłączane sprzętowo w momencie rozpoczęcia obsługi przerwania i odblokowywane w momencie wyjścia z funkcji assemblerowym rozkazem reti który jest przez kompilator dodawany na końcu funkcji.

Dlatego funkcja obsługi przerwania zadeklarowana przez baton'a w taki sposób:

ISR(PCINT2_vect) // aktualna wartość enkoderów w globalnych int enkoderL, enkoderP 
{ 
  ...
} 

nie wymaga blokowania przerwań na jej początku, ani uruchamiania ich na końcu.

Jeżeli natomiast chcemy by funkcję mogło przerwać inne przerwanie należy dodać do kodu na samym początku sei():

ISR(PCINT2_vect) // aktualna wartość enkoderów w globalnych int enkoderL, enkoderP 
{ 
  sei();
  ...
} 

lub użyć atrybutu ISR_NOBLOCK:

ISR(PCINT2_vect, ISR_NOBLOCK) // aktualna wartość enkoderów w globalnych int enkoderL, enkoderP 
{ 
  ...
} 

który zrobi dokładnie to samo co powyżej, czyli doda sei() na początku funkcji.

[danioto]

Gratuluję ukończonej konstrukcji!

Z mojej strony powiem, że masz jeszcze sporo do dopracowania pod względem algorytmicznym. Myszą strasznie rzuca na lewo i prawo, na Twoim miejscu zaostrzyłbym nastawy w PID'zie (bo chyba tym kontrolujesz ruch?).

Co do elektroniki, to wszystko super, tylko zastanawiam się, czemu zrezygnowałeś z czujników ustawionych pod kątem? Nie przydałyby się do szybszego wykrywania zakrętów i lepszej kontroli ruchu? Ciekawi mnie też, dlaczego nie odciąłeś składowej stałej z sygnału z fototranzystora? Kondensator i opornik w postaci filtru górnoprzepustowego i miałbyś załatwiony problem z każdorazową kalibracją czujników przy różnym świetle.

Myślę, że warto byłoby również popracować na estetyką 😋 Wiem, że ciężko jest w takim maleństwie zmieścić wszystko, ale jakby się troszeczkę dłużej zastanowić, to na pewno byś na coś wpadł 🙂

Podsumowując: dobry opis dobrej konstrukcji, jest wszystko czego by się tylko chciało: schemat, kawałek kodu, zdjęcia, opis, subiektywna opinia. Takie mocne 4, ale... Za ten filmik z labiryntem oraz "rozmowę" w tle daję 5! 😃

Pzdr.

[MatManiak]

Ciekawi mnie też, dlaczego nie odciąłeś składowej stałej z sygnału z fototranzystora? Kondensator i opornik w postaci filtru górnoprzepustowego i miałbyś załatwiony problem z każdorazową kalibracją czujników przy różnym świetle.

Pewnie dlatego, że wszystkie japońskie roboty (które widziałem) nie stosują takiego filtra, więc coś w tym musi być 😉 Jak najszybsza na świecie czołówka MM za każdym razem miga diodami by każdorazowo kalibrować czujniki (odejmują wartość odczytaną przy zgaszonych diodach chwilkę wcześniej lub później) to widocznie tak jest lepiej - ludzie budujący tetrę, min7, eggtorte, excel, czy decimusa siedzą w temacie parę(naście) lat, więc zapewne nie przegapili by takiego błędu jak brak kondensatora 😉 Zakładam, że przetestowali, że bez działa lepiej.

I jeszcze jedno pytanko mam: Skąd pomysł na nazwę? Bo dość nietypowa 😉

Bardzo udanym pomysłem było wyprowadzenie złącza interfejsu UART, który poprzez moduł BT został wykorzystany do bezprzewodowej kontroli myszy w trakcie pisania oprogramowania i pierwszych chwil w labiryncie - bardzo polecam takie rozwiązanie, choć niestety nie da się w ten sposób wizualizować danych w matlabie (po prostu nie da się wykorzystać połączenia COM tworzonego przez BT w komputerze - potwierdzone przez pracownika na forum Matlaba).

A normalny port COM (nie tworzony przez BT) się da? Bo jeśli tak, to możecie użyć wirtualnego portu COM i zrobić przekierowanie - jest sporo takich programów.. więcej info tutaj -> http://en.wikipedia.org/wiki/COM_port_redirector - na dole są linki do programów.

[mog123]

Po 1.

Twoja obsługa enkoderów jest daleka od optymalnej. Masz tyle ifów że głowa boli 😋 średnio wejście w ifa i wyjście z niego + jakaś operacja wewnątrz to są min. 4 operacje asm.

Po 2.

Używasz tryb kwadraturowy enkoderów do czego ta mega nie jest po prostu przystosowana. Po pierwsze przydałoby się zmienić to tak by jak najmniej zewnętrznych przerwań mieć. Więc tryb LSB + DIR jest w tym wypadku najlepszy. Idealne by było podpięcie LSB do wejścia countera ale do tego potrzebne by było co najmniej 4 timery na pokładzie megi (1 do pwm'a na silniki, po 1 na każdy enkoder oraz 1 na mierzenie czasu/pętle regulacji). Ewentualne szybka obsługa przerwań (najlepiej wstawka asm i zmienne rejestrowe) i wtedy juz wystarcza 2 timery.

Po 3.

Na pewno to dobrze liczysz? 500imp/s to strasznie mało. Oba wyjścia kwadraturowe z jednego enkodera dają Ci po 256cpr. Czyli de fakto masz 512cpr a jak policzysz oba zbocza to 1024cpr. Przy przekładni 1:30 to masz ponad 30000cpr. 500imp/s to jest więc obrót o 6 stopni/s 😋 mi przy maksymalnej prędkości wychodzi 512000imp/s z jednego koła więc policz to jeszcze raz 😋

[mactro]

Tak na moje oko, to te enkodery są zamocowane na kole, a nie na wale silnika 😋

[mog123]

Nie przyglądałem się zbytnio ale coś w tym musi być 😋

[danioto]

Ciekawi mnie też, dlaczego nie odciąłeś składowej stałej z sygnału z fototranzystora? Kondensator i opornik w postaci filtru górnoprzepustowego i miałbyś załatwiony problem z każdorazową kalibracją czujników przy różnym świetle.

Pewnie dlatego, że wszystkie japońskie roboty (które widziałem) nie stosują takiego filtra, więc coś w tym musi być 😉 Jak najszybsza na świecie czołówka MM za każdym razem miga diodami by każdorazowo kalibrować czujniki (odejmują wartość odczytaną przy zgaszonych diodach chwilkę wcześniej lub później) to widocznie tak jest lepiej - ludzie budujący tetrę, min7, eggtorte, excel, czy decimusa siedzą w temacie parę(naście) lat, więc zapewne nie przegapili by takiego błędu jak brak kondensatora 😉 Zakładam, że przetestowali, że bez działa lepiej.

No właśnie, to założenia. Ja oczywiście nie mówię, że nie należy korzystać z doświadczeń innych, ale jednak sam wolę wszystko wcześniej przetestować, dlatego pytałem autora o motywację takiego a nie innego rozwiązania. Jak testowałem swój czujnik DIY to po bardzo szybkich pomiarach stwierdziłem, że sygnał po filtrze wygląda baaaardzo ładnie, dlatego osobiście wolałbym odciąć składową stałą. Ciekawi mnie co na to autor? 😉

[baton]

Niestety mam teraz dostęp do internetu tylko przez telefon, a nie chciałbym nikogo pominąć przy odpisywaniu. Dziękuję za wszelkie uwagi, odpowiem na pytania jutro wieczorem, gdy będę już w domu.

[Elvis]

Jak chodzi o problem z przerwaniami to może być jeszcze jedna przyczyna.

Podczas przełączania odczytywanego stanu mogą pojawiać się zakłócenia i procesor zamiast jednego impulsu (przerwania) otrzymuje ich całe mnóstwo.

Jeśli masz dostęp do oscyloskopu, proponuję zobaczyć jak wygląda sygnał. Na próbę można też programowo liczyć liczbę wywołań przerwań.

Najprościej jest dodać układ z przerzutnikiem Schmitta, można też po odebraniu przerwania na pewien czas wyłączać detekcję kolejnych przerwań.

[MatManiak]

No właśnie, to założenia. Ja oczywiście nie mówię, że nie należy korzystać z doświadczeń innych, ale jednak sam wolę wszystko wcześniej przetestować, dlatego pytałem autora o motywację takiego a nie innego rozwiązania. Jak testowałem swój czujnik DIY to po bardzo szybkich pomiarach stwierdziłem, że sygnał po filtrze wygląda baaaardzo ładnie, dlatego osobiście wolałbym odciąć składową stałą. Ciekawi mnie co na to autor? 😉

A widzisz, skoro testowałeś i wypadało bardzo dobrze, to kwestia warta zastanowienia. Swoją drogą na forbocie jest ciekawy wątek poświęcony temu zagadnieniowi, gdzie marek1707, koval oraz kubik udzielają bardzo merytorycznych wypowiedzi:) -> https://www.forbot.pl/forum/topics38/filtr-gornoprzepustowy-w-czujniku-odleglosci-vt7303.htm