Przeszukaj forum

Od dłuższego czasu chciałem stworzyć działającego robota Micromouse, a jednocześnie chciałem nauczyć się obsługiwać inne mikrokontrolery niż Arduino. Idealna okazja spełnienia obu tych rzeczy nadeszła gdy wszedłem w posiadanie płytki STM32F429I-DISC1. Tak o to rozpocząłem projekt o zaskakującej nazwie "Micromouse Robot". KONSTRUKCJA ROBOTA Komponenty, które postanowiłem wykorzystać w robocie to: Mikrokontroler STM32F429I-DISC1 Czujniki odległości (odbiciowe) skonstruowane z pary: dioda IR SFH4550 i fototranzystor SFH-313FA Silniki DC FIT0450 wraz z enkoderami magnetycznymi SJ01 Sterownik silników L298N Moduł bluetooth HC-06 Koła DFRobot Na samym początku zaplanowałem ogólny schemat robota: Na podstawie schematu ogólnego stworzyłem schemat elektroniczny przy użyciu programu KiCad: Następnie przyszedł czas na zlutowanie potrzebnych układów, w pierwszej kolejności był to moduł z czujnikami - zdecydowałem się na prostopadłe rozstawienie czujników, dwie pary wykrywające przeszkody po bokach oraz dwie pary wykrywające ścianę na wprost dzięki czemu możliwe będzie wykorzystanie ich odczytów do korekcji orientacji robota (oba przednie czujniki powinny odczytywać tą samą odległość od ściany). Dodatkowo zlutowałem pomocniczy układ z przełącznikiem i stabilizatorem step-down (gdyż zasilanie, którego użyłem dochodziło do 8V przy pełnym naładowaniu, a płytka potrzebowała 5V). Dzięki niemu miałem łatwy dostęp do pinów 5V lub 8V w zależności od potrzeby: W celu sprawdzenia działania stworzonego modułu czujników wykonałem testy przy użyciu programu STMStudio, które pozwoliło na łatwą wizualizację odczytów mikrokontrolera. Przeprowadzone testy potwierdziły poprawne działanie każdego z 4 czujników (niższa wartość oznacza przewodzenie fototranzystora w diodzie odbiorczej, tym samym sygnalizując, odbiór światła wysłanego przez diodę IR i odbitego od białej ściany - w skrócie, wykrycie przeszkody przez dany czujnik): Niestety w tym momencie okazało się, że pomieszczenie wszystkich elementów wraz z utrzymaniem sensownych rozmiarów robota będzie niemożliwe, dlatego po wykonaniu wielu pomiarów powstał model 3D przyszłej konstrukcji, na którego podstawie stworzona została rzeczywista konstrukcja stworzona z wyciętej płyty ebonitowej oraz drucianych podpór: Jak widać dzięki wymyślnej konstrukcji udało się pomieścić wszystkie elementy. Nadszedł czas na programowanie. OPROGRAMOWANIE ROBOTA Ze względu, że użyta płytka należała do rodziny STM32 to do pomocy w programowaniu użyłem środowiska STM32CubeIDE. Ponieważ jak już pisałem, była to moja pierwsza styczność z płytką inną niż Arduino, to bardzo pomocny okazał się Kurs STM32 F4 ze strony Forbota. Końcowo wykorzystałem: 4 piny ADC w celu odczytywania wartości z czujników odległości, 2 piny PWM w trybie countera w celu odczytywania wartości z enkoderów silników, 4 piny PWM do sterowania silnikami, oraz 2 piny USART w celu komunikacji z modułem bluetooth. Schemat blokowy przyszłego programu robota wygląda następująco: W tym momencie głównym zadaniem stało się zaimplementowanie najważniejszych funkcji, czyli: przeszukania labiryntu, znalezienia najkrótszej ścieżki i jej przejechania. Również w tym przypadku Forbot nie zawiódł i poratował mnie artykułem Roboty MicroMouse – 5 metod przeszukiwania labiryntu. To właśnie on skłonił mnie do wykorzystania metody propagacji fali. Wzorując się na przykładach z artykułu udało mi się stworzyć własną wersję algorytmu. W międzyczasie stworzyłem funkcje odpowiedzialne za ruch robota w przestrzeni. Odpowiednie przechowywanie aktualnej pozycji (x, y) oraz orientacji robota (północ, południe, zachód, wschód) pozwoliło na proste zaimplementowanie funkcji typu jedz(kierunek), która pozwalała na nawigację po labiryncie jak gdybyśmy patrzyli na niego z góry i zadawali, w którym kierunku ma przemieścić się robot. Dzięki temu możliwe stało się stworzenie symulacji, która pozwalałaby na przetestowanie działania zaimplementowanego algorytmu i funkcji ruchu. Tak też zrobiłem: Jak widać funkcje ruchu pozwalają na przemieszczanie się po poszczególnych polach labiryntu, natomiast algorytm bez problemu znajduje najkrótszą ścieżkę do celu. Przyszedł czas na rzeczywiste testy. W tym celu używając wyciętych kartonów oraz białych kartek A4 złożyłem własny labirynt (na zdjęciu jeszcze bez kartek), niestety ze względu na ograniczoną przestrzeń składał się on tylko z 4x4 pól, jednak nie był to zbyt duży problem, gdyż algorytm zdołał już udowodnić symulacyjnie, że działa także dla pełnowymiarowego labiryntu. Kolejnym wyzwaniem było zaprogramowanie ruchu robota po labiryncie. Z pomocą przyszły enkodery silników oraz czujniki na podstawie których napisałem proste regulatory PD. Pierwszy z nich używając enkoderów gwarantuje, że dystans pokonany przez oba silniki jest stały, natomiast drugi używający czujników zapewnia równy odstęp robota od wszystkich ścian labiryntu. Ich połączenie zapewnia sprawne przemieszczanie się robota po kolejnych polach labiryntu. PODSUMOWANIE Ostatecznemu wynikowi daleko do idealnych. Robot jest dosyć powolny i czasami gubi trasę - myślę, że jest to spowodowane w pewnym stopni jego wagą i wielkością użytych silników, co w połączeniu skutkuje brakiem możliwości wykonywania małych i precyzyjnych ruchów. Dodatkowo brakuje tu wielu usprawnień funkcji ruchu, np. nie zatrzymywanie się na każdym polu jeśli jedziemy prosto kilka razy z rządu. Pomimo to myślę, że robot wcale nie wypada tak źle jak na pierwszy tak duży projekt, przecież jednak jeździ i ma się dobrze. Dodatkowo ilości nowej wiedzy którą zdobyłem podczas jego tworzenia nie da się zastąpić. Ogólnie jestem zadowolony z efektu oraz całego projektu, jednak także świadomy jego niedoskonałości i możliwości poprawy w miarę zdobycia nowej wiedzy. Efekt końcowy (przeszukiwanie labiryntu oraz przejazd najkrótszą ścieżką przyspieszone prawie 5-krotnie) można obejrzeć na filmiku:

"Apollo" to projekt robota MicroMouse z roku 2017 o wymiarach 110 x 120 x 140 mm. Był drugim podejściem do tematu po pierwszym moim robocie tej klasy, InfraRed Co ważne, InfraRed podążał zasadą prawej (lub lewej) ręki, która mówi, że jeżeli środkowy kwadrat będący celem robota jest połączony z brzegiem labiryntu, to na 100% cel zostanie osiągnięty, jeżeli "mysz" będzie jechać ciągle przy prawej (lub lewej) ścianie - jest to tzw. WallFollower. Mówiąc inaczej, robot nie zna swojego położenia w labiryncie, jedzie "na oślep". W tej konstrukcji chciałem, aby robot "znał" swoje położenie w labiryncie i pokonał je może nie w błyskawicznym tempie 🙂, ale nieco inteligentniej. Zdecydowałem się na algorytm odcinania ślepych zaułków. Poniżej film z krótkiego testu: Konstrukcja Robot przypomina wieżę w formie "kanapki", z trzema poziomami z drukarki 3D (każdy o grubości 5mm): pierwszy - zawiera dwa silniki krokowe NEMA11, na osie których gumowe koła wbijałem "na gorąco" (rozwiercone na średnicę 4,8mm i wykąpane w wodzie 80°C bez problemu weszły na osie silników o średnicy 5mm - kiedy całość ostygła, połączenie jest bardzo pewne), cztery czujniki dioda IR + fototranzystor i 2 punkty podparcia (dioda LED wklejona na żywicę); drugi - 2x pakiet LiPol 2S 900 mAh, połączone szeregowo, co nominalnie daje 14,4V - im wyższe napięcie, tym prąd w cewkach uzwojeń silników krokowych narasta szybciej, co pozwala na osiąganie większych prędkości obrotowych (w moim przypadku maksymalnie kilka obrotów na sekundę); trzeci - zawiera kolejną "kanapkę", dwóch płytek uniwersalnych z elektroniką 🙂 Elektronika Czujniki to klasyczne rozwiązanie, do każdej z diod i fototranzystorów przylutowany jest za pomocą takich, rozciętych na pół, przewodów i podłączonych do płytek za pomocą męskich goldpinów. Rezystory znajdują się już na płytce. Ponadto na dolnej płytce znajdują się dwa złącza T-DEAN do podłączenia akumulatorów, stabilizator 5V LM7805 oraz Arduino Nano. Odczytuje ono napięcia z fototranzystorów, linearyzuje odczyty z dokładnością do 0,5cm i na podstawie wykonanych wcześniej charakterystyk i instrukcji switch...case. Następnie przesyła je przez I2C do Arduino Nano na górnej płytce. Zastosowanie dwóch Nano wynikało z obawy przed niewystarczającą mocą obliczeniową jednego, ale jak się potem okazało, było ono zbyteczne. Natomiast wysterowaniem silników krokowych i tworzeniem mapy labiryntu zajmuje się Arduino na górze. Ponadto znajdują się tam 3 diody LED, bardzo przydatne przy testach. Sterowniki silników krokowych to A4988. Algorytm https://forbot.pl/blog/roboty-micromouse-5-metod-przeszukiwania-labiryntu-id17354 Polecam powyższy artykuł, okazał się bardzo przydatny. Algorytm odcinania ślepych zaułków to udoskonalona metoda podążania za ścianą. Robot w pierwszym przejeździe tworzy mapę i jeżeli zawrócił, to w komórce, w której pojawił się dwukrotnie stawia wirtualną ścianę. Następnie w drugim przejeździe jedzie z pamięci 🙂 Kilka zdjęć Osiągnięcia Robot brał udział w konkurencji MicroMouse podczas XIV Festiwalu Robotyki CyberBot w Poznaniu w roku 2017, gdzie zajął VI miejsce. Warto zaznaczyć, że robotów startowało 6 🤣 Liczy się jednak fakt, że robot przejechał labirynt, ukończył przejazd i znalazł najkrótszą ścieżkę. Podstawowym czynnikiem ograniczającym prędkość jest konieczność zatrzymywania się co komórkę, niestety tak rozwiązałem algorytm sterowania silnika, wykorzystałem znaną i lubianą bibliotekę AccelStepper() Chętnie odpowiem na wszelkie pytania jeżeli takowe się pojawią, pozdrawiam 🙂

Rapid jest moją drugą konstrukcją micromouse. Zawiera ona kilka poprawek względem pierwszej (robot Wariat), z których najważniejszą jest użycie żyroskopu. Konstrukcja mechaniczna i zasilanie Robot zbudowany jest na płytce PCB, która stanowi jego podwozie. Założeniem projektu było uzyskanie nisko położonego środka cieżkości oraz jak najmniejszej masy. Dodatkowym atutem robota miała być jego mała szerokość, która pozwalałaby na poruszanie się po "skosie". Napędem robota są silniki Pololu 10:1 sterowane przez dwa mostki TB6612. Jako zasilanie wykorzystywane są akumulatory litowo-polimerowe o jak najmniejszym rozmiarze i niewielkiej masie. Z powodu małych pojemności konieczna jest częsta wymiana i ładowanie pakietów. W robocie używane są różne pakiety, różnych producentów. Mikrokontroler Sercem robota jest mikrokontroler STM32F405RGT6. O wyborze zdecydowała chęć nauki programowania mikrokontrolerów STM32 z najpotężniejszym rdzeniem Cortex-M4F oraz najmniejsza obudowa spośród wszystich procesorów rodziny STM32F4. Najważniejszymi cechami mikrokontrolera są: taktowanie 168MHz, 192kB RAM, 1MB flash, bardzo duża liczba timerów (m.in. ze sprzętową obsługą PWM oraz wyjść kwadraturowych enkoderów), wiele kanałów przetwornika ADC, DMA, sprzętowa obsługa liczb zmiennoprzecinkowych, wiele dostępnych interfejsów komunikacyjnych. Czujniki W robocie wykorzystano trzy rodzaje czujników: dalmierze optyczne, enkodery oraz żyroskop. Jako czujniki odległości wykorzystano diody SFH4511 oraz fototranzystory TEFT4300 (podłączenie takie samo jak w przypadku robota MIN7 autorstwa Ng Beng Kiat). Diody są sterowane impulsowo, każda z osobna. Wybranym żyroskopem jest analogowy czujnik ISZ-650 firmy Invensense. Jego zakres pomiarowy to +-2000st/s. O jego wyborze zdecydowała głównie dostępność i cena podczas zakupu. Podczas testów robota uszkodzono sensor, dlatego konieczna była wymiana. Zdecydowano się na moduł z żyroskopem L3GD20. Do podłączenia wykorzystano miejsce na wyświetlacz N3310 wraz z wyprowadzonym interfejsem SPI. Zamontowanie enkoderów obrotowych z magnesami na osiach silników powodowałoby poszerzenie całej konstrucji, więc zdecydowano się na użycie enkoderów liniowych wraz z odpowiednimi magnesami. Wykorzystane enkodery AS5304 oraz zamocowane magnesy na kołach robota przedstawiono na rysunkach poniżej. Użyte enkodery pozwalają uzyskać rozdzielczość 3520 impulsów na obrót koła, co daje w wyniku 0.028 mm/impuls. Interfejs użytkownika Założeniem projektu było wykorzystanie joysticka oraz wyświetlacza z telefonu Nokia 3310. Obecnie oprogramowanie nie zawiera obsługi wyświetlacza, dlatego nie jest on zamontowany. Do wyboru prostych komend służy joystick oraz zamontowany buzzer. Buzzer służy także jako powiadomienie o charakterystycznych sytuacjach w labiryncie, np. wykrycie ścianki, dojechanie do środka labiryntu. Oprogramowanie Program opiera się o cykliczne wywoływanie funkcji z częstotliwością 1kHz. W funkcji tej wykonywane są pomiary czujników, aktualizowana jest pozycja robota oraz wyliczane są wartości współczynnika wypełnienia PWM na silniki. Robot posiada trapezoidalny profil sterowania prędkością. Implementacja i zasada działania jest bardzo podobna jak w artykule [Programowanie] Sterowanie robotem mobilnym klasy (2,0). Przeszukiwanie robota odbywa się z użyciem algorytmu floodfill. Po znalezieniu środka labiryntu, robot rozpoczyna wyznaczanie najszybszej ścieżki. Do tego celu użyto zmodyfikowanego algorytmu floodfill, którego wagami jest czas przejazdu. Podsumowanie Robot Rapid zachowuje się w labiryncie dosyć stabilnie i przewidywalnie. Jest to bardzo ważna cecha, ponieważ pozwala na dalszą pracę nad konstrukcją oraz rozwijanie oprogramowania. Pomysłów na poprawienie działania robota jest wiele. Ograniczeniem jest jedynie poświęcony temu czas. Galeria Osiągnięcia I miejsce w kategorii Micromouse na zawodach Robotic Arena 2012 II miejsce w kategorii Micromouse na zawodach Robomaticon 2013 I miejsce w kategorii Micromouse na zawodach Trójmiejski Turniej Robotów 2013 I miejsce w kategorii Micromouse na zawodach ROBO~motion 2013

Witam. Po pierwszej konstrukcji jaką był linefollower postanowiłem zrobić coś ambitniejszego. Wybór padł na robota typu micromouse. Praktycznie wszystkie części zostały zasponsorowane prze moją szkołę. Elektronika Robotem steruje mikrokontroler z rodziny stm32f103 taktowany kwarcem 8Mhz i z włączoną wewnętrzną pętlą PLL, która mnoży zegar x9, taktując ostatecznie procesor 72MHz. Jako mostki do silników zostały użyte 2x tb6612, po jednym na silnik. Jako czujniki początkowo używane były sharpy 5 i 10 cm a od niedawna są to analogowe dalmierze zbudowane z diody ir i fototranzystora. Do zasilania używam akumulatora modelarskiego typy li-pol 2 celowego o pojemności 500mAh. Silniki są zasilane bezpośrednio z akumulatora przez diodę zapobiegająca uszkodzeniu mostków na skutek błędnego podłączenia akumulatora. Elektronika również jest zasilana przez połączone kaskadowo stabilizatory 5V i 3.3V które też są zabezpieczone osobną diodą. Mechanika Podstawą jest płytka drukowana wykonana z laminatu 1.5mm wykonana w firmie Satland Prototype . Silniki to Pololu HP 30:1 z przedłużona osią. Jako enkodery początkowo służyły wydrukowane tarcze 5 czarnych pół i po dwa czujniki TCRT1000 dając 20 impulsów na obrót wału silnika. Obecnie są to enkodery wymontowane z myszki kulkowej. Oprogramowanie Cały program został napisany w języku C w środowisku Atollic TrueSTUDIO. Mysz posiada algorytm mapowania oraz rozwiązywania labiryntu, jednak wykonywanie korekcji wobec ścian nie jest tak skuteczne aby przejechanie dużego labiryntu obyło się bez dotknięcia ściany. Obsługa enkoderów jest wykonana sprzętowo przy użyciu jednego timera na każdy enkoder w specjalnym trybie przeznaczonym do obsługi enkoderów kwadraturowych. Filmy i zdjęcia wersji z sharpami i enkoderami wydrukowanymi na papierze - stan na Robotic Arena 2011 https://www.youtube.com/watch?v=kMqzrvSACqc Aktualny stan - dalmierze i enkodery z myszki - Robotic Tournament 2012 https://www.youtube.com/watch?v=Kcb8uWGm-as Podziękowania dla użytkownika Matmaniak za filmik z zawodów Istrobot 2012: https://www.youtube.com/watch?v=FSQFybaACO0https://www.youtube.com/watch?v=qSlVX2fVSts Płynne skręty, nowy labirynt i parę innych rzeczy. https://www.youtube.com/watch?v=rufoc3rPTvI Udział w zawodach: Robotic Arena 2011 - 4. miejsce. Robotic Tournament 2012 - 4. miejsce. Istrobot 2012 - 1. miejsce. Roboxy 2012 - 2. miejsce. Pozdrawiam 🙂

InfraRed jest robotem klasy Micromouse, który wykorzystuje zasadę prawej dłoni (wall-follower). Konstrukcja powstawała około 2 miesiące i licząc wszystkie koszty pochłonęła około 300 PLN. Robot był budowany na zawody CYBERBOT 2016, w których zajął 5 miejsce. Należy jednak podkreślić iż był chyba najbardziej budżetową myszą, tym bardziej, że inne micromouse'y były malutkie, z silniczkami Pololu lub Faulhauber, a tu taki "opancerzony". Niemniej jednak, robot przejechał labirynt w 49 sekund i nie musiałem go ani razu popchnąć 🙂 Mechanika: Korpus robota składa się z dwóch kół z odpowiednimi otworami i wnękami o średnicy 130mm, które zostały zaprojektowane w Google SketchUp i wykonane w technologii druku 3D. Połączone są one 4 prętami gwintowanymi M3. Wysokość robota wynosi, licząc z pętelką kabli u góry (służącą do wyciągania z labiryntu) około 150mm. Bez pętelki ponad 100mm. Jako punkt podparcia wykorzystałem 2 duże diody LED, które zresztą się świecą (ot, taki bajer 🙂 ). Napęd i zasilanie: Napęd stanowią dwa silniki Dagu, kątowe, na napięcie 3V, kupione w Botlandzie. Są one ogromne, jednak udało mi się je jakoś upchnąć 😋 . Jeżeli chodzi o zasilanie - zastosowałem po raz pierwszy pakiet LiPol (Kokam / 2S 7,4V 910mAh). Napięcie dla logiki daje moduł stabilizatora 5V LM1117. Do silników z kolei napięcie idzie bezpośrednio z akumulatora, przez mostek L293D. Czujniki: Znów wykorzystałem najtańsze elementy z Botlandu, dokładnie diody IR TSAL6400 i fototranzystory LIRT5B. Obydwa działają na paśmie 940nm. Do diody dołączony jest rezystor 33om, a do fototranzystora - 3300om. Daje to zadowalające odczyty, diody są sterowane impulsowo przez ULN2003 (najpierw zapalane są obydwie przednie, a potem boczne). W celu poprawienia jakości odczytów robot mierzy napięcie na fototranzystorze przy włączonej i wyłączonej diodzie, oblicza różnicę, a następnie powtarza tą operacje 2-krotnie - końcowym wynikiem jest średnia arytmetyczna z 3 takich pomiarów. Cała pętla wykonuje się w bodajże 15ms - jest to złoty środek, gdyż że program jest stabilny i jednocześnie robot szybko reaguje na zmiany wartości na czujnkach. Elektronika: Jako mikrokontroler wykorzystałem Arduino Pro Micro z Atmegą 32U4. W robocie są dwie płytki uniwersalne - jedna z rezystorami i ULN2003 do czujników (schowana) i druga właściwa, z mostkiem H, mikroprocesorem, stabilizatorem, a także kilkoma dodatkami - tact-switchem, buzzerem i diodą LED. Nie wykorzystywałem ich jednak, gdyż wygodniej mi jest debugować przez Serial Monitor. Właściwy program składa się z regulatora PD (jazda prosto i skręt w prawo) i kilku IFów (skręt w lewo, zablokowanie się robota). Robot wprawdzie czasami wjeżdża w ścianki, ale dzięki temu, że PLA jest śliskie, rzadko kiedy przyblokuje się 😃 Jednym z wad tych czujników jest to, że ich odpowiedź nie jest proporcjonalna do odległości, a co za tym idzie - żeby człon P reagował poprawnie, trzeba było wprowadzić pewne uproszczenie: if (wzadane-obp<=-130) skret=(wzadane-obp)*0.03+(obp-pre)*0.01; else if (wzadane-obp>-130) skret=(wzadane-obp)*0.3+(obp-pre)*0.06; Po prostu jeżeli robot zbytnio zbliży się do ścianki, to błąd gwałtownie narasta, więc musi być pomnożony przez mniejsze wzmocnienie (wzadane - wartość zadana, obp - odległość po prawej, pre - poprzednia wartość obp, skret - poprawka dla PMW silników 🙂 ). Zdjęcia: Film z zawodów: Podsumowanie: Jestem bardzo zadowolony z tej konstrukcji, dużo się przy niej nauczyłem i przede wszystkim spełniła podstawowe założenie - przejechała labirynt i to bez popychania 😉 Z chęcią odpowiem na wszystkie pytania 🙂

Cześć, Jestem z Koła Naukowego Robotyków z Politechniki Warszawskiej. Niedawno stwierdziliśmy, że w sumie fajnie by było opisać gdzieś nasze konstrukcje. Jako, że zdarza nam się korzystać z zasilaczy z czarnej listy, padło na forbota 😃 . Na pierwszy ogień chcieliśmy wypuścić jedną ze starszych maszyn – Minotaura. Jego historia była dość ciekawa – na 3 tygodnie przed ubiegłorocznymi zawodami Robomaticon razem z kolegą stwierdziliśmy, że może fajnie byłoby wystawić tam jakiegoś Micromouse’a. Postawiliśmy zatem na jak najprostsze rozwiązania, które z jednej strony pozwoliłyby nam przetestować różne algorytmy jazdy, z drugiej zaś zaoszczędziłyby czasu na wykonanie oraz programowanie. Dzięki temu jednak konstrukcja jest dość prosta i może być dobrym projektem dla początkujących robotyków. Mechanika Bazę montażową dla całego robota stanowi obudowa wydrukowana na drukarce 3D. Pierwsza wersja zakładała, że podstawa robota będzie rozpostarta na kwadracie o długości 110 mm o zaokrąglonych narożach. Po wykonaniu prototypu oraz pierwszych testach bardzo szybko okazało się jednak, że robot jest zdecydowanie za duży. Z uwagi na to, że możliwe okazało się zmniejszenie odległości pomiędzy silnikami bez uszczerbku na działaniu enkoderów magnetycznych, zdecydowano się znacznie ograniczyć wymiary robota. Kolejna (ostateczna) wersja robota miała już w podstawie kwadrat o boku 80 mm. Aby móc ograniczyć wymiary, zdecydowano się na węższe ścianki boczne. Z uwagi na dużą łamliwość, zrezygnowano z drukowanych mocowań do płytek z elektroniką i zastąpiono je gotowymi, plastikowymi dystansami. Ostateczny wynik można oglądać na zdjęciu poniżej: W robocie Minotaur zdecydowano się na zastosowanie silników POLOLU z metalową mikroprzekładnią 50:1 z obustronnym wałem. Pozwoliło to na zastosowanie enkoderów magnetycznych tej samej firmy. Na wałach silników zamocowano wykonane metodą druku 3D koła. W pierwszej wersji zastosowano opony odlewane z silikonu, jednak później (ze względu na dość szybkie zużywanie się silikonowych) zdecydowano się na wykorzystanie opon Kyosho Mini-Z. Pozwoliło to zminimalizować poślizgi. Dodatkowymi elementami są elementy podporowe, oklejone taśmą teflonową oraz górna pokrywa robota, do której jest mocowana bateria. Elektronika Ze względu na małe zasoby czasowe oraz dostępność części w laboratorium elektronika robota Minotaur została oparta na Arduino Uno. Prawie cała pozostała elektronika (z wyjątkiem sensorów) została umiejscowiona na shieldzie wpinanym w Arduino. Poza wspomnianymi wcześniej silnikami z enkoderami, zastosowano jedynie kilka komponentów. mostki TB6612FNG, które (ze względu na przykre doświadczenia w poprzednich konstrukcjach) zastosowano po jednym dla każdego silnika (zwarto wyprowadzenia). Za interfejs użytkownika służyły 1 przycisk oraz 1 dioda. Poza tym za pomocą dzielnika napięcia monitorowano stan baterii. Aby poprawić jazdę, zdecydowano się na zastosowanie czujnika IMU (Pololu Mini-IMU 9), który znaleźliśmy w laboratorium. Jednak, nawet przy wyłączonym żyroskopie robot radził sobie w labiryncie. Wypinany moduł Bluetooth służył głównie do doboru nastaw podczas programowania (obecnie nie jest on wykorzystywany). W robotach zastosowano czujniki odległości stworzone z 2 diód IR oraz fototranzystora. Światło emitowane przez diodę IR odbija się od ściany labiryntu i wraca do fototranzystora. Zastosowano jedynie 3 takie czujniki, umiejscowione na środku ścian robota. Jeden z nich ma za zadanie sprawdzać, czy ściana jest na wprost. Pozostałe 2 umiejscowione na bokach sprawdzają, czy ścianka istnieje z boku. Pozwalają także robotowi utrzymać stałą odległość pomiędzy ściankami. Innym ich wykorzystaniem jest snapowanie – jeżeli robot ma mały błąd kątowy (liczony na bieżąco), to w momencie gdy jakaś ścianka mu się kończy, aktualizuje swoje położenie. Algorytm Podobnie jak w większości konstrukcji, które nie poruszają się metodą prawej/lewej dłoni, w robocie został zaimplementowany algorytm „flood fill” - zalewania wodą (Bellmana - Forda). Naszą jedyną modyfikacją, była preferencja jazdy prosto (obrót jest dla nas bardziej kosztowny). Aby nie zmuszać bardziej zaawansowanych czytelników do przewijania, początkujących odsyłam do linku: [LINK] Aby móc choć nieco przystosować się do warunków zmiennego oświetlenia, na początku każdego przejazdu dokonujemy kalibracji. Aby robot mógł swobodnie poruszać się po labiryncie powinien on potrafić wykonywać 2 podstawowe ruchy: jazda do przodu oraz skręt (o 90o w prawo i lewo, obrót o 180o). Przed jazdą powinien on jednak skalibrować czujniki. Do obrotu wykorzystywane są dwa czujniki: enkodery oraz żyroskop. Wiodącym czujnikiem jest żyroskop, z którego po scałkowaniu prędkości otrzymujemy kąt obrotu. Enkodery wykorzystywane są głównie do kontroli prędkości obrotowej kół, aby robot obracał się w miejscu bez zbędnego przemieszczenia (jeśli oba koła kręcą się z ta samą szybkością wówczas robot obraca się wokół swojego środka). Aby zminimalizować szanse kolizji robota ze ścianami labiryntu podczas jazdy wykorzystuje się odczyty z trzech typów czujników: odległości, enkoderów oraz żyroskopu. Każda z tych wartości jest uwzględniana z odpowiednią wagą, która została dobrana w sposób eksperymentalny. Wagi nie są jednak stałe, ale zależne od ułożenia ścianek lub ich braku. Do utrzymywania kierunku wykorzystywane są enkodery oraz żyroskop, natomiast czujniki odległości służą do utrzymywania robota w równych odstępach od bocznych ścianek niwelując niedokładności obrotów. Do jazdy na wprost podobnie jak podczas obrotu wykorzystywany jest regulator PD. Innym ważnym aspektem jest pokonywanie zadanego dystansu, jest to długość pojedynczej komórki. Błędy podczas pomiaru odległości mogą skutkować złym zmapowaniem labiryntu bądź kolizją ze ścianką. Korzystając z faktu, że kształt labiryntu jest znormalizowany możemy bazować robota do punktów charakterystycznych (w tym wypadku jest to początek bądź koniec ścianki). Korzystając z bazowania co pewien czas zerowany jest błąd położenia (np. w miejscach pokazanych na rys. poniżej). I na koniec coś co wszyscy lubią najbardziej, czyli robot w akcji. Niestety nie jest to najnowsze wideo, ale na pewno w najlepszej jakości, czyli przejazd robota podczas zawodów ISTROBOT w Bratysławie.

Witam wszystkich! =) Od dłuższego czasu zbieram się do opisu mojej pierwszej "poważniejszej" konstrukcji. Jako że semestr się dopiero zaczyna i jeszcze jest czas na cokolwiek, a na dodatek w ciągu ostatnich dni została otworzona kolejna edycja konkursu z Proxxonem, przyszedł czas na zrealizowanie tego planu. Tym samym z wielką przyjemnością prezentuję robota mobilnego klasy micromouse: Let Me Out 1. Pomysł Podczas zeszłorocznych wakacji moje zainteresowanie zostało skierowane w kierunku dwóch zagadnień: roboty klasy micromouse oraz silniki krokowe. Z tego pierwszego bardzo szybko podjąłem decyzję o budowie takiego robota. Interesując się zaganieniem drugim (silników krokowych), dowiadując się o ich możliwościach i ograniczeniach zacząłem się zastanawiać nad ich wykorzystaniem w robocie klasy micromouse. Niestety, przewalając internet dniami i nocami nie znalazłem żadnego sensownego opisu zrealizowanej i zbadanej konstrukcji napędu robota mobilnego opartego na silnikach krokowych. W ten sposób narodził się pomysł o zaprojektowaniu, zbudowaniu i przetestowaniu takiego rozwiązania. 2. Założenia projektowe • Spełnienie podstawowych warunków konstrukcyjnych oraz programowych zawartych w regulaminie konkurencji micromouse. Robot projektowany był tak, żeby mógł wziąć udział w zawodach w Polsce. • Oparcie projektu o procesor z rodziny AVR W tamtym momencie STM-y dopiero wynurzały mi się zza horyzontu, więc zdecydowałem się na popularnego AVR-a, którego już dobrze znałem i umiałem go programować. • Konstrukcja umożliwiająca poruszanie się po skosie labiryntu Aby móc zastosować bardziej złożone algorytmy przemierzania labiryntu. • Zastosowanie silników krokowych jako napęd główny robota • Umożliwienie bezprzewodowej komunikacji z robotem Głównie w celu odbierania danych o aktualnym stanie zmapowania labiryntu przez robota i możliwości wizualizacji aktualnej sytuacji na komputerze. • Zaprojektowanie płytki PCB w sposób umożliwiający wykonanie jej metodą fototransferu Oczywiście w celu zaoszczędzenia na czasie i funduszach, zdecydowałem się na warsztatową metodę wykonywania płytki. • Implementacja algorytmu pozwalającego na rozwiązywanie algorytmu metodą "floodfill" 3. Konstrukcja Mechaniczna 3.1 Napęd 3.1.1 Silniki Jako napęd zdecydowałem się na użycie silników krokowych. Zalety silników krokowych (+) Sterowanie pozycją - dokładne sterowanie w otwartej pętli sterowania (+) Silnik pracuje z pełnym momentem w stanie spoczynku (+) Żywotność silnika wyznaczona wytrzymałością łożysk i cewek - brak szczotek Wady silników krokowych (-) Przeznaczone do pracy z małymi prędkościami (-) Możliwość wystąpienia zjawiska "gubienia kroków" (-) Duża emisja ciepła (-) Duża masa i rozmiary (-) Skomplikowany sposób sterowania Ze wszystkich silników krokowych dostępnych na polskim rynku, silniki o kodzie producenta S20STH30-0604A firmy Pololu najbardziej nadawały się do projektowanej konstrukcji. Porównanie parametrów wybranych silników krokowych z popularnymi mikrosilnikami Pololu Parametr • Silnik krokowy • Mikrosilnik Pololu 30:1 Waga • 60g • 10g Wymiary • 20 x 20 x 30 mm • 10 x 12 x 24 mm Napięcie zasilania • 3.9 V • 3-9 V Pobór prądu • 600 mA • 120-1600 mA Moment obrotowy • 140 g*cm (0.017 Nm) • 600 g*cm (0.059 Nm) Średnica wału • 4 mm • 3 mm Cena • 100 zł • 70zł Sterowanie • Trudne • Proste Problemy do rozwiązania w projektowaniu napędu opartego o silniki krokowe: Problem: Silniki krokowe przeznaczone są do pracy przy niewielkich prędkościach obrotowych (zazwyczaj 4-10 RPS to ich maksymalne osiągi). Rozwiązanie: Zasilanie silników z dużo wyższego napięcia (w tym wypadku 24 V). Pozwala to na skrócenie czasu narastania prądu na cewkach, prez co można je przełączać częściej, w efekcie uzyskując wyższą prędkość obrotową. (Udało mi się rozkręcić te silniki do 45 RPS - w powietrzu, nie na jadącym robocie) Problem: W robocie potrzebne jest napięcie 24 V Rozwiązanie: Zasilanie silników z przetwornicy step-up, generującej 24 V z napięcia zasilania (7.4 V bądź 15.8 V) Problem: Zasilając silnik z wyższego napięcia, prąd na cewkach będzie proporcjonalnie większy, co po przekroczeniu wartości nominalnej (600 mA) prowadzić będzie do ich spalenia Rozwiązanie: Zastosowanie gotowego modułu sterownika silnika krokowego z ogranicznikiem prądu (funkcja Chopper) 3.1.2 Koła Jako koła wybrano gumowe koła firmy Solarbotics o średnicy 2.8 mm i szerokości 13 mm. Koła mają świetną przyczepność i doskonale nadają się do tego zastosowania. Jedyną jak dotąd zaobserwowaną wadą jest bardzo duża zdolność do zbierania kurzu i drobnych odpadów, przez co jazda po zabrudzonej powierzchni bardzo szybko doprowadza do zmniejszenia przyczepności kół. 3.1.3 Mocowania silników Niestety na rynku nie istnieją mocowania do silników krokowych w tym rozmiarze (Nema 8), więc musiałem takie mocowania wyprodukować sam. Mocowania silników zostały zaprojektowane w programie TinkerCad dostępnym w wersji przeglądarkowej. Zamówienie przyjęło i wykonało techniką druku 3D koło naukowe działające przy Politechnice Wrocławskiej "Rapid Troopers". Mocowania zawierają 4 otwory na śruby mocujące silnik do elementu, oraz 4 otwory na śruby służące do przytwierdzenia silnika wraz z mocowaniem do platformy. 3.1.4 Podwozie Jako podwozie wykorzystałem płytkę PCB z elektroniką, przedstawioną w dalszej części artykułu 4 Elektronika Schemat elektroniczny jak i płytka PCB zostały zaprojektowane w programie CadSoft Eagle. 4.1 Zasilanie Robot może być zasilany z jednego bądź dwóch (połączonych szeregowo) akumulatorów Li-Po 7.4 V o pojemności 250 mAh. Dwa akumulatory stosowane są w celu podwyższenia napięcia na wejściu przetwornicy, co skutkuje obniżeniem poboru prądu z akumulatora i wydłużeniem możliwego czasu działania robota. 4.1.1 Zasilanie silników Silniki zasilane są napięciem 24 V podawanym z przetwornicy step-up opartej o układ XL60098. Przy pracy pobierają 1 - 1.2 A. 4.1.2 Zasilanie logiki Wszystkie układy logiczne zasilane są napięciem 5 V uzyskiwanym z przetwornicy step-down D24V6F5. Powodem zastosowania przetwornicy zamiast stabilizatora liniowego jest różnica napięć na wejściu i wyjściu układu. Występuje tu obniżenie napięcia z ~16 V do 5 V, co przy stabilizatorze liniowym generowałoby bardzo duże ilości ciepła i mogłoby prowadzić do jego uszkodzenia lub poparzenia użytkownika podczas obsługi robota. 4.2 Procesor Jednostką sterująca całego robota jest ośmiobitowy procesor AVR Atmega 128 firmy Atmel, taktowany zewnętrznym kwarcem 16 Mhz. Procesor zasilany jest napięciem 5 V. W celu zmniejszenia rozmiarów robota, zastosowano procesor w obudowie TQFP64. 4.3 Czujniki odległości Jako czujniki odległości zastosowano diodę LED SFH4550 działającą w paśmie podczerwieni. W robocie umieszczono 6 takich zestawów. Dwa skierowane w przód, dwa na boki oraz dwa odchylone od diametralnej robota o 45°. Prąd płynący przez diody IR to 95 mA, co daje wystarczające natężenie światła do dokładnego odczytywania odległości przy jednoczesnym braku konieczności uważania na przepalenie się diody spowodowane długim świeceniem przy zbyt dużym prądzie. 4.4 Sterowniki silników Zastosowano sterowniki firmy Pololu oparte na modula A4988. Sterowniki pozwalają na pracę w trybach: pełnokrokowym, półkrokowym, ćwierćkrokowym, 1/8 oraz 1/16 kroku. Funkcja ograniczania prądu (chopper) pozwala sterować silniki wyższym napięciem bez ryzyka uszkodzenia cewek silnika. Kolejną zaletą zastosowania sterowników silników krokowych jest możliwość sterowania silnika za pomocą tylko jednego pinu (tylko jeden pin mikrokontrolera podaje sygnał częstotliwościowy odpowiedzialny za taktowanie silnika). W celu umożliwienia generowania sygnałów o różnej częstotliwości, każdy ze sterowników obsługiwany jest przez inny timer. Obydwa szesnastobitowe timery sterujące działają w sprzętowym trybie Clear on Compare Match. Pozwala to na automatyczne generowanie sygnału o zadanej częstotliwości bez udziału samej jednostki obliczeniowej. 4.5 Interfejs komunikacyjny Jako interfejs komunikacyjny robota służą dwie diody LED, buzzer, interfejs UART wraz z modułem bluetooth HC-05 oraz dwa przyciski. Programowanie robota realizowane jest poprzez interfejs SPI. 4.6 Płytka PCB Płytka PCB na której zostały umieszczone wszystkie elementy robota została zaprojektowana za pomocą programuy CadSoft Eagle. Długość: 101 mm Szerokość: 94 mm Płytka pełni jednocześnie funkcję podwozia robota. Takie wymiary pozwalają na swobodny obrót robota w miejscu między ścianami, oraz jazdę po skosie w labiryncie. Płytka w swoim kształcie jest symetryczna, lecz główna masa elementów skupiona została przy tylnej części. Powoduje to brak efektu kołysania się robota ze względu na dociśnięcie tyłu do podłoża. Płytka została stworzona metodą fototransferu oraz wytrawiona w warunkach domowych. Otwory wykonano na wiertarce stołowej. Prostokątny otwór na środku płytki jest miejscem na wystające elementy silników, w których znajdują się gniazda przewodów zasilających. Warstwa Top zawiera wszystkie układy scalone, czujniki, silniki, akumulatory i złącza. W przedniej części robota znajdują się czujniki, mikrokontroler, układ ULN2003 (sterowanie diodami LED) oraz jeden z akumulatorów. Z tyłu umieszczono sterowniki silników krokowych, obydwie przetwornice, moduł bluetooth, drugi akumulator oraz buzzer. Silniki znajdują się w osi symetrii robota Na dolnej stronie płytki umieszczono jedynie kilka rezystorów oraz slizgacz, znajdujący się w diametralnej robota, w jego tylnej części. Zdjęcie poniżej pokazuje stopień upakowania elementów i modułów w robocie. 5 Oprogramowanie Główną częścią projektu było rozwinięcie oprogramowania związanego z obsługą peryferii oraz algorytmem rozwiązującym labirynt. Program napisany został w języku C. 5.1 Pomiary odległości Pomiar z każdego z czujników dokonywany jest z częstotliwością 200 Hz. Zastosowano pomiar różnicowy z uśrednianiem wyników. 5.2 Sterowanie prędkością robota Prędkość robota sterowana jest częstotliwością sygnału podawanego na sterowniki silników. 5.3 Algorytm Zaimplementowany algorytm opiera się na algorytmie Dijkstry, służącym do znajdywania najkrótszej drogi w grafie. 6 Podsumowanie Projektowanie, budowa oraz zaprogramowanie robota zostały zrealizowane zgodnie z założeniami. Robot dobrze radzi sobie w labiryncie. 6.1 Sprawność silników krokowych w robocie mobilnym Podczas jazdy kroki są gubione dość rzadko, co pozwala na wystarczająco dokładne wysterowanie robota w otwartej pętli sterowania z kompensacją pozycji od czujników odbiciowych. Osiągane maksymalne prędkości podczas testów (oczywiście poza labiryntem i po prostej) sięgają 2 m/s. Głównymi wadami tych silników w robocie są ich masa, wielkość, konieczność stosowania sterowników silników krokowych oraz wyższego napięcia. Kolejną wadą jest konieczność ograniczania przyspieczeń, w celu zminimalizowania gubionych kroków. Zaletą stosowania silników krokowych jest brak konieczności stosowania sprzężenia zwrotnego w postaci enkoderów obrotowych. Sterowanie robotem klasy (2.0) w otwartej pętli regulacji Sterowanie w otwartej pętli regulacji z wykorzystaniem silników krokowych jest możliwe. Rozwiązanie to jest wygodniejsze i prostsze do zrealizowania, aczkolwiek posiada bardzo dużą wadę, w postaci braku informacji o gubionych ktokach. Cała kalibracja pozycji opierać musi się na odczytach z czujników odbiciowych. Budowa tego robota z pewnością przyczyniła się do znacznego poszerzenia mojej wiedzy na temat budowy robotów mobilnych, projektowaniu schematów elektronicznych oraz płytek PCB, kategorii micromouse oraz silników krokowych. Niestety nie miałem dostępu do pełnowymiarowego labiryntu, dlatego filmiki z testów są tylko na ćwiartce labiryntu. Robot jeździ wolno, bo w momencie kiedy zaczął działać i poprawnie rozwiązywać labirynt, semestr zaczął być tak gorący że musiałem porzucić prace nad jego rozwojem i zająć się studiami. Na pewno może jeździć o wiele szybciej - pozostaje tylko kwestia gubienia kroków. Zeby pokazać w sumie clue sprawy związanej z zastosowaniem silników krokowych, poniżej filmik na którym robot jedzie z wyłączonymi czujnikami, z wgraną na stałe sekwencją (prosto, prawo, lewo, prosto itp.) Widać jak dokładne może być pozycjonowanie się na silnikach krokowych (które i tak dobierane było "na oko"). Jazda bez sprzężenia od czujników A tutaj testy na labiryncie. Robot rozwiązujący labirynt Nie chcę się już bardziej szczegółowo rozpisywać na poszczególne tematy, żeby artykuł nie rozrósł się do rozmiarów nieczytelnych. Jeśli kogoś interesują detale budowy tego robota i używania tego napędu, zapraszam do dołączonej w załącznikach prezentacji oraz raportu z budowy robota. Jeśli jesteś zainteresowany schematami elektronicznymi tego robota - napisz w komentarzu. KoNaR - Bartlomiej Kurosz - Micromouse Let Me Out.pdf Zastosowanie silnikow krokowych w robotach mobilnych.pdf

Vampire2 to moja druga konstrukcja micromouse. W porównaniu z pierwszą konstrukcją (Vampire) wprowadzono pewne zmiany mechaniczne jak dodanie żyroskopu, zmiana enkoderów oraz zmniejszenie wymiarów płyty PCB. Konstrukcja mechaniczna i zasilanie Podwoziem robota jest płyta PCB wykonana w firmie Satland Prototype. Napędem są silniki Pololu 30:1 sterowane za pośrednictwem mostka TB6612. Koła standardowe Pololu. Ostatecznie udało się uzyskać myszkę o wymiarach maksymalnych 95x75mm, co pozwala poruszanie się po skosie. Prześwit robota został ustawiony dla bezpieczeństwa na 4mm. Maksymalna prędkość jaką udało mi się uzyskać na tych silnikach to 1.6m/s. Robot zasilany jest z akumulatora litowo-polimerowego. W tej chwili jest to Pakiet LiPol Dualsky 150mAh 7.4V. Pakiet spokojnie wystarcza na wykonanie przejazdów podczas zawodów. Elektronika Mózgiem robota jest mikrokontroler STM32F407VGT6. Głównymi cechami są: taktowanie 168 MHz, 192kB RAM, 1MB flash, duża liczba peryferii z czego wiele ze wsparciem DMA, sprzętowa obsługa wejść kwadraturowych, wiele dostępnych interfejsów komunikacyjnych. Model ten stosowany jest w płytce ewaluacyjnej Discovery, dzięki czemu po testach z płytką ewaluacyjną kod nie wymagał żadnych zmian aby przenieść go na robota. W konstrukcji użyto enkodery magnetyczne AS5306 oraz magnesy zamocowane na obręcze kół z 72 polami magnetycznymi. W rezultacie z enkoderów otrzymujemy 5700 imp/obrót co daje dokładność 0,017 mm/imp. Jako dalmierzy użyto diod podczerwieni SFH4511 w parze z fototranzystorami TEFT4300. Diody sterowane są poprzez układ ULN2003, każda osobno. Dalmierze zapewniają dość dobrą charakterystykę w zakresie 0-20 cm. Robot wyposażony jest w żyroskop cyfrowy L3GD20. Posiada on bardzo mały dryf, zakres do +-2000st/s oraz interfejs SPI. Interfejs użytkownika Do wybierania trybów pracy wykorzystano 4 przyciski. Na płycie są również 4 diody. Płyta posiada wyprowadzenie dla wyświetlacza z telefonu Nokia 3310, który obecnie nie jest zamontowany. Wyprowadzony został również interfejs UART do komunikacji z PC. Oprogramowanie Oprogramowanie w dalszym ciągu jest rozwijane. W aktualnej wersji uzyskano stabilną jazdę w labiryncie. Algorytm pozwala na przeszukiwanie labiryntu pole po polu z zatrzymywaniem się na każdym polu. Wyszukiwanie trasy przy użyciu algorytmu floodfill z dodanymi różnymi wagami dla prostych i zakrętów, odpowiednio 1 i 3. Sterowanie dynamiką bazuje na pomyśle opisanym w [Programowanie] Sterowanie robotem mobilnym klasy (2,0) . Podsumowanie Robot spełnił moje oczekiwania. Pierwszy cel, czyli stabilne i przewidywalne zachowanie w labiryncie, został osiągnięty. Trwają prace nad rozwojem algorytmu przeszukiwania aby możliwe było przeszukiwanie bez zatrzymywania się, a w przyszłości również wymiana i przystosowanie robota do silników z przekładnią 10:1. Galeria Osiągnięcia I miejsce w kategorii MicroMouse na zawodach Robomaticon 2013 w Warszawie Pozdrawiam 😃

Speedy jest moim pierwszym robotem. Postanowiłem zrobić micromouse'a ze względu na dość prostą konstrukcję mechaniczną. Mechanika Podwoziem robota jest płytka PCB. Napęd stanowią dwa silniki pololu 10:1 HP z kołami 36mm. Całość zasila akumulator li-po 550mAh 2S. Jako trzeci punkt podparcia użyłem LEDów. Elektronika Jako mikrokontrolera użyłem atmegi168 z wewnętrznym taktowaniem 8MHz. Rolę mostka H pełni układ TB6612. Jako dalmierzy użyłem fototranzystorów l53p3c i diod tsal6400. Chciałem jeszcze użyć enkoderów as5040, jednak z powodu błędów konstrukcyjnych nie zostały zamontowane. Oprogramowanie Na początku chciałem użyć algorytmu flood-fill, jednak z powodu braku enkoderów musiałem wykorzystać regułę prawej dłoni. Program nie jest jeszcze do końca dopracowany i robot cały czas uderza w ściany (czasami się blokuje), ale po kilku popchnięciach dojedzie do celu 😋. Podsumowanie Robot spełnia moje oczekiwania, czyli jeździ 😋. Dużo się na nim nauczyłem, wiem jakich błędów unikać w przyszłości. Osiągnięcia I miejsce w kategorii MicroMouse na zawodach Robocomp 2013 w Krakowie

Tematyką micromouse interesowałem się od dawna, jednak dopiero w czerwcu tego roku postanowiłem spróbować swoich sił w tej właśnie kategorii. Devil jest moim pierwszym robotem tego typu, konstruując go, chciałem wypróbować parę pomysłów oraz nauczyć się o co tak naprawdę chodzi w micromouse... Konstrukcja i napęd Tutaj liczyła się przede wszystkim masa i wymiary, dlatego zrezygnowałem z obudowy. Rolę konstrukcji nośnej pełni główny obwód PCB na laminacie 1,5mm wykonany w firmie Satland Prototype. Jako napęd wybrałem mikrosilniki Pololu HP z przekładnią 50:1 i podwójną osią. Na osiach silników zamontowano tarczki z trackballa, które wraz z czujnikami optycznymi z myszy kulkowej pełnią rolę enkoderów. Napędy pracują w zamkniętej pętli sprzężenia zwrotnego z rozdzielczością 4800 impulsów/obrót koła. Przy zastosowanych kołach Pololu o średnicy 32mm daje to 0,0209 mm/impuls 🙂 Trzeci punkt podparcia stanowi ball caster Pololu umieszczony na przodzie. Elektronika Mikrokontroler - wybór padł na 16-bitowy dsPIC33FJ64MC204. Posiada dużą liczbę peryferiów wspierających tego typu aplikacje, między innymi dwa sprzętowe interfejsy do obsługi enkoderów inkrementalnych, 6-kanałowy generator PWM z regulowanym dead-time, szybki przetwornik ADC z 4 układami Sample&Hold, DMA, a dzięki pętli PLL może pracować z częstotliwością 80MHz wykorzystując wewnętrzny oscylator. Przy tym zegarze ma wydajność 40 MIPS. Czujniki - rolę dalmierzy pełnią diody nadawcze sparowane z fototranzystorami pracujące w paśmie podczerwieni (odpowiednio L-53F3C i L-53P3BC). Światło dzienne eliminowane jest poprzez sprzętowy filtr górnoprzepustowy. Mostek H - tutaj nie ma niespodzianki, tak jak w większości konstrukcji tak i tutaj siedzi TB6612 firmy Toshiba 🙂 Jeden układ spokojnie wystarcza do sterowania dwoma silnikami. Zasilanie - źródłem energii dla robota jest litowo-polimerowy pakiet modelarski 2s 500mAh. Mostek H zasilany jest bezpośrednio z niego, cała reszta elektroniki poprzez przetwornicę opartą na układzie MC34063A. Przewody zasilające pełnią dodatkowo rolę "uszka" koniecznego do awaryjnego wyciągnięcia robota z labiryntu. W załączniku zamieszczam schemat ideowy. Interfejs użytkownika Do komunikacji pomiędzy robotem a użytkownikiem służą 3 przyciski, buzzer oraz graficzny wyświetlacz z telefonu Nokia 3410 o rozdzielczości 96x65 pikseli. Wyświetlane na nim menu pozwala na kalibrację czujników, zmianę nastaw prędkości, wybór trybu działania, a w trakcie mapowania i jazdy po labiryncie rysowany jest rozkład ścianek z zaznaczeniem odwiedzonych komórek oraz planowanej ścieżki przejazdu. Oprogramowanie W związku z ciągłym rozwojem, wersji oprogramowania było kilka. Najistotniejsze zmiany zostały wprowadzone przed zawodami we Wrocławiu, mianowicie udało się "nauczyć" Devila przeszukiwania labiryntu bez postojów co komórkę. Do algorytmu floodfill, odpowiedzialnego za rozwiązywanie labiryntu, został wprowadzony system wag, dzięki czemu robot analizuje ścieżkę nie pod względem długości ale pod względem prędkości przejazdu. Podsumowanie Konstrukcja w pełni spełniła moje oczekiwania i udało mi się dzięki niej osiągnąć więcej niż przypuszczałem 🙂 Przede wszystkim dała mi pojęcie na co trzeba zwracać uwagę w robotach tego typu, a wyniesioną naukę postaram się przełożyć na jeszcze lepszą konstrukcję nowej myszy 😉 Galeria Osiągnięcia I miejsce w kategorii MicroMouse na zawodach Sumo Challenge 2011 w Łodzi I miejsce w kategorii MicroMouse na zawodach Robotic Arena 2011 we Wrocławiu Pozdrawiam, Grabo 🙂 Devil_sch.pdf

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!

Witajcie, postanowiłem opublikować moją pierwszą konstrukcję jaką jest robot "Bunio". W sumie nie wiedziałem w jakiej kategorii go sklasyfikować, ale jako że na zawodach wziął udział w kategorii "MicroMouse" to taką też wybrałem, choć robot ten to bardziej moja "platforma testowa" do różnych zabaw z robotyką, zanim zbuduję coś poważnego. Parę tygodni temu rozpocząłem swoją przygodę z robotyką od kupienia platformy miniQ z trobota. Zastanawiałem się, co kupić na początek, by nie utknąć już na wstępie na problemach natury mechanicznej. Uznałem, że ta platforma ma dobrą cenę w stosunku do możliwości - na dzień dzisiejszy kosztuje 89zł, a zestaw zawiera podróbki silników pololu 1:50 (zwykłe, nie HP), których cena jest wyższa niż cena całej platformy (podwozie, silniki, mocowania silników, metalowa kulka podporowa). Silniki mają parametry: - 13000 rpm @ No load - 50:1 Gear ratio - 260 rpm @ 6V - 40mA @ 6V - 360mA stall current @ 6V - 10 oz inches torque @ 6V Są więc nawet teoretycznie trochę lepsze niż pololu 1:50, ale oczywiście zdaję sobie sprawę, że pololu są bardziej trwałe niż podróbki. Jako zasilania robota użyłem 6 akumulatorków AA, co daje łączne napięcie około 7 - 8,4V, w zależności od naładowania. Mostek H to oklepany L293D - jako, że silniki nie są HP, to mogłem zastosować jeden, bez obaw o wysoki prąd zwarcia obu silników. Silniki zasilam bezpośrednio z baterii, bo biorąc pod uwage bardzo wysoki spadek napięcia na tym mostku, to akurat zasilanie jest odpowiednie przy 100% PWM. Proszę się nie śmiać z tych baterii - wiem, że to kiepski pomysł i że zajmują 3/4 całej objętości robota - w planach miałem użycie lipola 2S, ale w Polsce są wysokie ceny, a na HK przesyłka długo idzie, więc czekam na razie.. Tak więc paluszki to tylko zastępcze zasilanie. Swoją drogą, mogłem użyć AAA (tak jak w robocie 3pi), ale akurat miałem dużo w domu AA, a zmieściły się na robota 😉 Jako mikrokontrolera użyłem Atmegi8 (zamiennie z 328P, bo taką też mam, a jest kompatybilna) taktowaną 16 Mhz z wgranym bootloaderem arduino - od arduino zacząłem swoją przygodę z elektroniką, więc już z przyzwyczajenia najłatwiej mi się pisze w tym środowisku, z użyciem bilbiotek wiring. Atmega jest zasilana z tych samych paluszków co silniki, tylko że przez również oklepany regulator 7805. Kod (napisany w C++/arduino) wrzucam po UART do atmegi poprzez ft232rl. Tydzień po kupieniu platformy miniQ, zauważyłem, że na zawodach Robotic Tournament w Rybniku (do którego mam dość blisko) będzie rozgrywana konkurencja MicroMouse. W szczególności zainteresował mnie fakt, że można dotykać ścianek (rzadko spotykane w tej konkurencji), oraz, że labirynt będzie można przejść regułą lewej/prawej dłoni. Pomyślałem, że spróbuję zbudować prostego robota "wall-follower" który będzie używał czujników dotykowych (krańcówek) do wykrywania ścian. Kupiłem parę krańcówek i na 3 dni przed zawodami (!) zacząłem budowę i pisanie programu. Zastosowałem 3 krańcówki (pololu, długie)- jedną z przodu do wykrywania przedniej ściany, oraz dwie z lewej strony do kontrolowania dystansu od lewej ściany. Nie śmiać się, że są poklejone taśmą - były za krótkie i przedłużałem je jakimś drutem czy kawałkiem metalu który miałem pod ręką i kleiłem taśmą klejącą. W moim założeniach było, by robot w ogóle dojechał do mety, więc po prostu przechodziłem labirynt metodą lewej dłoni, tzn zawsze dotykając lewej ściany. 2 lewe czujniki miały pewną różnicę pomiędzy sobą w wychyleniu, zatem zasada poruszania się była bardzo prosta: - jeśli bardziej wysunięta krańcówka dotyka ściany, a mniej wysunięta nie, to jedź prosto - jeśli obydwie dotykają ściany, to odjedź trochę w prawo - jeśli tylko mniej wysunięta krańcówka dotyka ściany, to ostro kontruj w prawo (teoretycznie sytuacja ta nie powinna mieć miejsca) - jeśli żadna nie dotyka ściany, to skręcaj w lewo (albo za bardzo robot odjechał w prawo, albo skończyła się ściana - bez znaczenia) Oraz oczywiście: - jeśli przednia krańcówka dotyka ściany to się zatrzymaj i odwracaj w miejscu w prawo aż krańcówka przestanie dotykać ściany. Te parę prostych "IFów" w programie pozwoliło mi przejechać labirynt - niestety całego robota złożyłem i napisałem do niego program na dzień przed zawodami (chyba w okolicy godziny 21), więc praktycznie nie było czasu na testy różnych ustawień krańcówek, odgięcia ich w odpowiedni sposób, oraz na regulację PWM lewego i prawego silnika w zależności od rodzaju skrętu (skręt w lewo ma inne ustawienia PWM niz w prawo). No trudno, cieszyłem się, że w ogóle działa. Niestety na zawodach okazało się, że krańcówki są źle umiejscowione i robot ciągle się zacina w labiryncie, przez co musiałem go dotykać (jest to dozwolone w regulaminie - każde dotknięcie robota to 5sekund kary do końcowego czasu). Nie mniej jednak, udało się przejechać cały labirynt (2-krotnie, bo 2 rundy były) uzyskując czas 5 minut i 15 sekund za pierwszym razem i poniżej 5 minut za drugim razem (nie pamiętam dokładnie) dotykając robota (aż!) 5 razy (co ciekawe, blokował się zwykle w tych samych 5 miejscach w labiryncie, niezależnie skąd był start). 5 minut to dość wolno - był to najwolniejszy robot z wszystkich które wystartowały (zgłoszonych było 6, ale 1 nie dojechał, 1 się zepsuł zanim postawiono go w labiryncie, więc w praktyce były 4 roboty), ale zajął na zawodach 3 miejsce , pokonując robota Stuart, który był szybszy w drugiej rundzie od Bunia, jednak w pierwszej rundzie pogubił się w labiryncie (bo raz zahaczył o scianę) i nie udało mu się dojechać do mety. To po prostu pech Harnasia - szkoda, bo jego robot był zdecydowanie lepszy oczywiście, no ale przez to potknięcie, mój robot nie był najgorszy, a nawet dostał medal (oraz parę nagród) za zaszczytne 3 miejsce 😉 Podsumowując (dla tych co nie lubą dużo czytać 😉 ): Podwozie: DFRobot miniQ (trobot.pl) - silniki 1:50 (260rpm) (klon pololu) - koła 42mm (klon pololu) - podstawa 12x12cm (klon pololu) - metalowa kulka podporowa Elektronika: - Atmega8/328P (z bootloaderem Arduino), 16Mhz, 5V - Stabilizator 7805 - Mostek H L293D Czujniki: - 3 krańcówki pololu Zasilanie: - 6 x AA 1,2V Schemat: Zdjęcia: filmiki: Pierwsza jazda robota, po złożeniu i napisaniu programu: Podczas pierwszych testów na zawodach RT2012 w Rybniku (niestety filmiku z przejazdu eliminacyjnego/finałowego nie mam): P.S: Miałem dylemat czy umieszczać opis w "nasze sukcesy", czy w "konstrukcje początkujących", bo z jednej strony robot z bateriami AA zamiast lipolów, z prostymi krańcówkami, oraz płytką uniwersalną polutowaną na szybko średnio pasuje do profesionalnych konstrukcji w tym dziale, ale z drugiej strony w konstrukcjach początkujących 3/4 robotów to beam, często bez mikrokontrolera. Decyzję o "nasze sukcesy" podjąłem na podstawie argumentu, że robot wystartował w zawodach i nawet przejechał labirynt;) (P.S2: Wiem wiem, brakuje kondensatorów 100nF na silnikach, oraz między AVCC i AGND. Nie ma też dławika. )

W końcu mamy chwilę czasu na opisanie robota:) Robot stworzony wspólnie z użytkownikiem Maszto. Najpierw zastrzeżenie - więcej zdjęć dołożymy jak będę miał do nich dostęp, teraz wrzucam tylko te, które mam przy sobie (niestety większość słabej jakości). A więc, jak można się domyślić, robot powstawał jako projekt inżynierski. We wrześniu byliśmy pewni, że będziemy go mogli robić. Tak więc od października projekt ruszył pełną parą. Zbieraliśmy informacje, porównywaliśmy datasheety różnych elementów, sprawdzaliśmy różne diody nadawcze i fototranzystory w paśmie IR. W listopadzie powstał pierwszy proto-prototyp:) W sumie w segmencie mieścił się na styk, ale był stworzony do celów testowych -> współpraca silnik - enkoder - czujniki - ATmega32A. Testy przyniosły nową wiedzę, potwierdziły pewne przypuszczenia, pewnych nie. Tak więc bogatsi o nowe doświadczenia rozpoczęliśmy pracę nad prototypem właściwym. Zdjęcie z 17 listopada: Ta masa kolorowych kabelków z tyłu służyła do tymczasowego podłączenia mostka L293D w zastępstwie TB6612 z pololu, który uległ uszkodzeniu. Po małym zwarciu:D. Na tym prototypie widać początkowe ułożenie sensorów z przodu, które nie okazało się optymalne. Nie mam teraz zdjęć, ale została zmieniona strona, na którą pary nadajnik-odbiornik wskazują. (Czyli te dwie pary z przodu zostały przekręcone na boki, a te boczne do przodu) A po dodaniu pięterka, głównie dla celów diagnostyki przez LCD: Jedna rzecz, która na pewno musi się znaleźć w następnej myszy, to wyświetlacz graficzny. Jak widziałem jak to u Graba działało, to mi się odechciało już wyświetlania na LCD 2x16 🙂. Wypisywanie 256 elementowej macierzy trochę trwa... No właśnie, skoro już jesteśmy przy konstruktorze Devila, to muszę mu bardzo podziękować za pomoc przy ogarnianiu zespołu enkoder-silnikDC. Gdyby nie on, pewnie by tak ładnie nie jeździła:). Sensoryka: - 2 Sharpy 5 cm; - 4 diody SFH4550; - 4 fototranzystory BPW77; - 2 czujniki Halla AS5145B (enkodery). Z enkoderów jestem zadowolony, diody i fototranzystory IR również doskonale spełniają swoje zadanie. Na początku nie używałem w ogóle Sharpów, ale później zostały użyte do dodatkowego wspomagania kalibracji ruchu. Mechanika: Laminat jednostronny kupiony w pobliskim sklepie, trawiony w domu. 2 silniczki z pololu 50:1 HP. Jako podpory - 2 diody. Elektronika: - ATmega32A; - 2x ATtiny13A (do obsługi enkodera - dorabiane na szybko i elegancko;-) ); - TB6612 z Robodudes (dzięki, MirekCz, za szybką pomoc); - stabilizator L7805 dla elektroniki; - stabilizator L7809/L7808/L7806/L7805 dla zasilania silników(wymienne); - stabilizator L7808/L7806/L7805 dla zasilania diod IR(wymienne). Zasilanie: Li-pol 1000 mAh 3S... Tak, zdecydowanie przesadziliśmy. Wnioski: - Po zamianie li-pola na 2S i mniejszej pojemności, jednym potrzebnym stabilizatorem (lub przetwornicą) będzie ten dla elektroniki. Diody i silniki polecą prosto z baterii. - Gotowy moduł z mostkiem TB6612 jest dużo wygodniejszy jeśli chodzi o wymianę w razie awarii; - Diody najlepiej jeśli mają malutki kąt świecenia i dużą moc. Fototranzystory jak najmniejszy kąt widzenia; - Jeśli robot na początku jeździ szybko i nie wpada na ścianki, to prawdopodobnie w labiryncie jest za dużo ścian:> Na zawodach może tak różowo nie być. Historia rozwoju: 22 listopad: Pierwszy filmik 29 listopad: Zamknięte sprzężenie zwrotne 30 listopad: Bez korekcji 5 grudnia: Korekcja 9 grudnia: Przed zawodami RA2011 Filmik z zawodów, dzięki uprzejmości Grabo: W sumie był to pierwszy (i na razie jedyny) występ Inżyniera, ale zajęcie II miejsca nas bardzo ucieszyło. Jest to nasz drugi robot, pierwszym był ALF. No trochę przeskok to był 😉 Jesteśmy zdecydowanie zadowolenie, zwłaszcza, że np. programować mikrokontrolery tak naprawdę zacząłem we wrześniu;-). Trzeba przyznać, że bardzo dużo się przy tej myszy nauczyliśmy. Jeśli o czymś zapomniałem lub macie pytania, walcie śmiało 😉 Edit: Dodatkowa atrakcja: 3d Model z RA2011

Z przyjemnością przedstawiam wam pierwszego robota typu micromouse na forum dioda! Jest to konstrukcja niezwykle prosta, uprościłem ją do niezbędnego minimum co w tym przypadku naprawdę nieźle się sprawdza. Mechaniki praktycznie nie ma...Dwa silniki krokowe na stalowych kątownikach i trzecie koło z kulki. Niestety te silniki są największą wadą tej konstrukcji...Jeżeli ktoś był na zawodach Robomaticon to z pewnością zapamiętał zabójczą prędkość rozwijaną przez mojego micromose'a:) problem tkwi w przekładniach założonych na te silniki, zbyt duże przełożenie. Zwiększenie częstotliwości zasilania powodowało rezonans silników i gubienie kroku... Jednym słowem, do poprawy. Cała elektronika to atmega32 z kwarcem 4MHz oraz ULN2803 do sterowania silnikami krokowymi. Czujniki to sharpy GP2Y0D805Z0F (0,5 - 5 cm cyfrowe), jest ich sześć sztuk. Bardzo jestem zadowolony z ich działania. Takie ustawienie i ilość spowodowało, że mysz nigdy jeszcze nie dotknęła żadnej ścianki. Program napisany w C, algorytm wlewania wody, zeczerpnięty oczywiście z diody. Bardzo dobrze się sprawdza jak na mój gust. P.S. Micromouse nie miałby sensu istnienia bez swojego naturalnego środowiska, czyli labiryntu. Labirynt na zawodach Robomaticon został wykonany przezemnie. Z tego co mi wiadomo jest to jedyny w Polsce pełnowymiarowy labirynt do tej konkurencji. Jeżeli ktoś byłby zainteresowany tego typu labiryntem proszę o informację na maila: rutkowski.konrad@avargo.pl