W poprzednim wpisie tylko ogólnie napisałem o projekcie. Teraz przyszła pora na więcej szczegółów technicznych. Opiszę więc na czym polegają zawody Micromouse, sformułuję wymagania i przedstawię koncepcję robota.

Opis konkurencji Micromouse

Micromouse to jedna z konkurencji odbywających się podczas zawodów robotów. Jej celem jest jak najszybsze przejechanie robota z rogu labiryntu do mety znajdującej się najczęściej w środku labiryntu. Każdy ze startujących robotów ma określony czas, jaki może spędzić w labiryncie. Robot zaczyna od przejazdu eksploracyjnego podczas którego poznaje ułożenie ścian. Następnie wraca na start i rozpoczyna speed run, czyli jak najszybszy przejazd od startu do mety. Jeśli czas na to pozwala, robot może wykonać więcej niż jeden speed run. Podczas przejazdu możliwa jest interwencja zawodnika np. jeżeli robot się zablokuje. W takim wypadku dodawana jest kara czasowa do wyniku przejazdu. Końcowy wynik to najczęściej czas najszybszego przejazdu + kary. Na niektórych zawodach dodawany jest również całkowity czas spędzony w labiryncie podzielony przez jakiś przelicznik.

Labirynt składa się z pól o wymiarach 180 x 180 mm. Ściany labiryntu mają wysokość 50mm i grubość 12mm. Podłoże labiryntu jest koloru czarnego, ściany koloru białego po bokach, od góry koloru czerwonego. Boczne pola labiryntu zawsze posiadają ściany zewnętrzne, dzięki czemu robot nie może wyjechać poza labirynt. Pole startowe znajduje się w jednym z rogów i jest otoczone ścianami z trzech stron. Pełnowymiarowy labirynt ma wymiary 16 x 16 pól, a meta składa się z 4 pól na środku labiryntu nieprzedzielonych ścianami i posiadających tylko jedno wejście. Często spotyka się również labirynty 9 x 9 pól, gdzie meta znajduje się na przeciwległym rogu od startu. Jest on wycinkiem pełnowymiarowego labiryntu, dzięki czemu do zawodów na takim torze nie trzeba zmieniać algorytmu robota.

Konkursowy przejazd robota micromouse może wyglądać tak:

Wymagania

Znając dokładne zasady konkurencji Micromouse możemy przejść do sformułowania podstawowych wymagań:

• Poruszanie się po labiryncie – jazda do przodu, skręcanie, jazda na skos, zawracanie w miejscu.
• Określanie pozycji robota w labiryncie.
• Wykrywanie ścian labiryntu i określanie odległości od nich.
• Zapamiętywanie pozycji ścian w labiryncie.
• Wyznaczanie drogi w labiryncie na podstawie zapamiętanego rozkładu ścian.

Dodatkowo będę się starał osiągnąć następujące cele:

• Płynna eksploracja labiryntu bez zatrzymywania się w każdej komórce.
• Premiowanie jazdy po prostej w algorytmie wyszukiwania drogi.
• Wykorzystanie zaawansowanych algorytmów estymacji pozycji w labiryncie.
• Wykorzystanie zaawansowanych algorytmów sterowania.

W następnych rozdziałach opiszę koncepcję robota, która będzie realizować te wymagania. Podzielę ją na trzy kategorie:

• Konstrukcja mechaniczna
• Elektronika
• Oprogramowanie

Konstrukcja mechaniczna

Wymagania mechaniczne dotyczą głównie rozmiarów robota i zastosowanego układu napędowego:

• Płytka PCB służy jako podstawa konstrukcji. Do niej zamontowane są mocowania silników i pozostałe elementy konstrukcyjne.
• Rozmiary robota około 100 x 80 mm. Aby możliwa była jazda na skos, szerokość robota nie może być większa niż połowa przekątnej pola, czyli 118 mm. Ideę jazdy po skosie obrazuje rysunek.

• Pojazd czterokołowy, gdzie koła są jedynymi punktami podparcia.
• Napęd za pomocą dwóch silników – po jednym na każdą stronę. Napęd na cztery koła przenoszony za pomocą przekładni zębatych. Do tego wykorzystam mocowania silników i felgi z drukarki 3D, które opisywałem ostatnio.
• Skręcanie poprzez kręcenie kołami po obu stronach z różną prędkością – łagodny skręt, albo w odwrotnym kierunku – ostry skręt np. przy zawracaniu.
• Wykorzystane silniki – Faluhaber 1717T006SR z enkoderem IE2-16 – enkoder kwadraturowy dwukanałowy o rozdzielczości 16 impulsów na obrót.

Elektronika

W tej sekcji opiszę elementy elektroniczne jakie mam zamiar wykorzystać.

• Zasilanie – pakiet Li-Po 130mAh 2S. Układ zasilania przewiduje napięcie z baterii bezpośrednio do sterowania silnikami, przetwornicę step-down ST1S10PHR obniżającą napięcie do 5V podawane na diody IR i stabilizator 3.3V, z którego zasilana jest logika.
• 6 czujników odległości – zadaniem tych czujników jest wykrywanie ścian labiryntu. Przewiduję po dwa czujniki patrzące do przodu, dwa w bok pod kątem i dwa na skos pod kątem . Czujniki skierowane na skos są niezbędne podczas jazdy na skos po labiryncie. Podobno robot może obyć się z czterema czujnikami – bez tych patrzących w bok, ale postanowiłem ułatwić sobie trochę życie i uwzględnić te czujniki. Pojedynczy czujnik będzie się składać z pary dioda IR i fototranzystor. Przy wyborze elementów bardzo ważne jest, żeby oba elementy działały na tej samej długości fali (w moim przypadku 940nm).
• Układ Darlingtona ULN2003. do sterowania diodami IR.
• Mostek H TB6612 do sterowania silnikami.
• Moduł MinIMU-v5 z akcelerometrem i żyroskopem – dzięki użyciu gotowego modułu mocowanego na goldpiny odpada mi lutowanie małego układu w niewygodnej obudowie. Żyroskop będzie wykorzystany do określania kąta podczas określania pozycji robota. Możliwe, że będę próbował jakiś bardziej zaawansowanych sposobów pozycjonowania, wtedy odczyt z akcelerometru i żyroskopu przyda się do Filtru Kalmana.
• Procesor STM32F401RB – wybrałem procesor z rodziny F4 ze względu na wsparcie operacji zmiennoprzecinkowych. Jeżeli będę się bawił Filtrem Kalmana, czy sterowaniem predykcyjnym na pewno przyda się FPU.
• Debugowe złącze UART umożliwiające podłączenie modułu Bluetooth. Komunikacja z robotem podczas przejazdu jest zabroniona przez regulamin konkurencji, dlatego moduł Bluetooth musi być zdejmowany. Podczas developmentu informacje debugowe na pewno będą bardzo przydatne.
• Interfejs użytkownika składający się z dwóch przycisków i 2 diod LED. Do tego dioda PWR i przełącznik zasilania.

Oprogramowanie

W tej sekcji opiszę biblioteki, frameworki i algorytmy, jakie planuję wykorzystać.

• Nie używam bibliotek od ST do obsługi peryferiów SPL ani HAL, warstwę sprzętową będę robić bezpośrednio na rejestrach.
• Program na STM32 oparty na FreeRTOS.
• Regulatory PID do zadawania ruchu postępowego i obrotowego.
• Pozycjonowanie w układzie kartezjańskim (x,y) – Filtr Kalmana.
• Algorytm znajdowania drogi w labiryncie – Floodfill.
• Profilowanie prędkości – temat do wybadania. Najpierw pewnie będzie prosty profiler, później może pobawie się sterowaniem predykcyjnym.
• System logowania zdarzeń przez UART – różne poziomy logów wybierane podczas kompilacji, asserty, dostęp do danych na rządanie, możliwość zrobienia aplikacji na PC lub telefon wizualizującej aktualny stan robota na podstawie logów.
• Unit testy – framework CppUTest w C++ – do tej pory używałem frameworka Unity napisanego w C. CppUTest daje więcej możliwości i integruje się z Eclipse. Poza tym będę miał możliwość poćwiczyć trochę C++.
• Operacje matematyczne – z biblioteki matematycznej na pewno użyję funkcji trygonometrycznych. Możliwe, że do zaawansowanych algorytmów będę też potrzebował jakiejś biblioteki do obliczeń macierzowych.

Podsumowanie

Spisane tutaj wymagania bazują głównie na moich przemyśleniach z wcześniejszych prób zrobienia robota Micromouse opisanych tutaj i tutaj. Początkowo zamysł był taki, żeby najpierw stworzyć robota, który po prostu jest w stanie przejechać labirynt, a później dopiero zająć się bardziej zaawansowanymi algorytmami i optymalizowaniem czasu przejazdu. Jednak potem stwierdziłem, że PIDy i Filtr Kalmana będę chciał zaimplementować od razu, więc ta prosta wersja nie będzie się dużo różnić od zaawansowanej. Podczas poprzedniej próby ugrzązłem na sterowaniu silnikami i nie miałem nawet okazji zaimplementować dalszych funkcjonalności. Zobaczymy jak pójdzie teraz.

W najbliższym czasie ruszę z projektem elektroniki. Chcę jak najszybciej zrobić schemat ideowy i projekt PCB, żeby złożyć zamówienie na płytkę. Czas oczekiwania na realizację to dwa tygodnie i przez ten czas podłubię coś przy sofcie nie wymagającego ostatecznego sprzętu. Niedługo też wrzucę pierwsze commity na GitHuba. Program Eagle, w którym będę robić schematy przechowuje zapisane pliki w formacie tekstowym, więc bardzo dobrze poddają się kontroli wersji.