Wirgiliusz

Jako, że jestem wielkim fanem gier komputerowych to nieuniknione było to, że w pewnym momencie spróbuję w jakiś sposób połączyć swoje zainteresowanie elektroniką oraz grami. W taki sposób narodził się pomysł na projekt, który przyjął nazwę "Fly And Shoot". Projekt złożony jest z dwóch części: Programistyczna - stworzenie samej aplikacji oraz gry. Postawiłem tutaj na prostotę i postanowiłem zrobić grę, w której lecąc statkiem kosmicznym musimy omijać/zestrzeliwać nadlatujące asteroidy. Taki typ gry wydał mi się idealny aby można było z nią połączyć drugą część projektu czyli część: Elektroniczna - polegająca na stworzeniu pada dzięki któremu będzie można sterować statkiem. W tym przypadku aby sterowanie nie okazało się banalne, postanowiłem, że pad będzie opierał się na akcelerometrze, a sterować będzie można wychylając go w odpowiednie strony. Tak o to prezentowała się koncepcja mojej gry: PAD DO GRY Do stworzenia pada postanowiłem użyć dwóch głównych komponentów: akcelerometru MMA7660FC oraz mikrokontrolera Arduino Nano v3. Założenie było proste: akcelerometr analizuje swoje wychylenie i przesyła zebrane dane do Arduino poprzez protokół I2C, następnie Arduino serializuje dane w odpowiedni format i przesyła je poprzez UART do komputera, w którym to dalsze działanie przejmuje aplikacja. Dodatkowym elementem, który postanowiłem jeszcze dodać był zwykły przycisk, który potem mógłbym wykorzystać np. do odczytu strzału. Na podstawie powyższych założeń stworzyłem schemat elektroniczny pada: Na podstawie schematu złożyłem układ na płytce stykowej: Na początku miał to być tylko prototyp, jednak okazał się on na tyle wygodny do trzymania, iż uznałem że nie ma sensu specjalnie lutować tych kilku komponentów. Osobiście uznałem, że kanciasty prostokątny kształt nadaje padowi trochę retro stylu, w szczególności jeśli ktoś kiedyś miał styczność z NESem : Oczywiście można było wszystko schować w jakąś kanciastą obudowę, jednak nie mam jeszcze doświadczenia z takimi rzeczami, więc stworzenie ślicznych obudów do wszystkich moich projektów zostawiam na przyszłość. Na podstawie dokumentacji akcelerometru oraz biblioteki Wire.h dla Arduino napisałem mały program, który łączył się z modułem, a następnie odczytywał zwracane dane i konwertował je na stopnie. Na jego podstawie mogłem potwierdzić działanie modułu: Kolejnym krokiem stało się przesłanie danych do komputera. Uznałem, że najlepszym sposobem będzie połączenie wszystkich danych w tzw. "ramkę" i przesłanie jej w całości do komputera. Moja ramka przyjęła następującą postać: Tworząc ramkę na początku umieszcza się nagłówek, który pozwala aplikacji odbierającej dane rozpoznać, że to właśnie z nią ma do czynienia. W kolejnych polach umieściłem dane, które chciałem przesłać: 'accX' i 'accY' oznaczające wychylenie akcelerometru/pada w osi X oraz Y (pominąłem Z, ponieważ było one zbędne w przypadku mojej gry) oraz 's' mówiące o tym czy wciśnięty został przycisk. Na końcu ramki umieszczone zostało pole na sumę kontrolną CRC8. Po co? W moim przypadku głównie w celu edukacyjnym, jednak na pewno jest ono przydatne w bardziej krytycznych węzłach komunikacyjnych, gdyż zapewnia integralność danych. W skrócie działa to tak, że na podstawie wszystkich wysyłanych danych mikrokontroler oblicza sumę kontrolną i przesyła ją razem z danymi. Następnie program, który odbiera dane ponownie na ich podstawie oblicza sumę kontrolną takim samym algorytmem i porównuje ją z sumą kontrolną, którą uzyskał razem z danymi - jeśli się zgadzają oznacza to, że przesłane dane nie zostały zakłamane i są prawdziwe. W tym momencie konieczne stało się przejście do drugiego etapu projektu, czyli aplikacji. APLIKACJA Z GRĄ Na początku postanowiłem stworzyć graficzny projekt aplikacji oraz gry. Poszczególne elementy, które sobie wymyśliłem wyglądają następująco: Do stworzenia aplikacji z grą postanowiłem użyć środowiska Qt: czemu akurat Qt? Bo nigdy wcześniej nie miałem z nim styczności, a chciałem je poznać . Na początku bardzo pomocny okazał się Kurs Qt z Forbota - to właśnie on pomógł mi stworzyć pierwsze okna i zaimplementować połączenie i komunikację z Arduino: W dalszej części postanowiłem najpierw zająć się oknem z wykresami, aby mieć pewność, że dane które odczytuje mają sens. W tym celu musiałem zaimplementować funkcje, które odczytywały moją ramkę danych i sprawdzały ich integralność. Następnie stworzyłem wykresy za pomocą narzędzi udostępnianych przez Qt: Po potwierdzeniu, że wszystkie dane są odczytywane poprawnie przyszedł czas na stworzenie gry. W pierwszej kolejności stworzyłem scenę, na której umieściłem obrazek gracza i stworzyłem możliwość jego poruszania. Uzyskanie satysfakcjonującego efektu nie było zbyt proste. Testowałem różne rozwiązania, aż w końcu mój wybór stanął na funkcji y = 2*sqrt(x) [y - prędkość gracza, x - wychylenie akcelerometru]. Użycie takiej funkcji do konwersji wychyleń akcelerometru na prędkość gracza pozwoliło mi uzyskać szybką reakcję w przypadku małych wychyleń przy jednoczesnym ograniczeniu maksymalnej prędkości w przypadku dużych wychyleń. W kolejnym kroku stworzyłem kilka obrazków dla przeszkód (aby miały różne wielkości) i napisałem funkcję, która tworzyła je w losowych miejscach ponad górną krawędzią ekranu. Nadanie im prędkości w dół wywołało iluzję poruszania się statku gracza. Następnie zaimplementowałem wykrywanie kolizji obiektów i tym samym dodałem system żyć oraz punktów dla gracza: Przy okazji stworzyłem jeszcze obiekt odpowiadający za pocisk, który potrafił niszczyć nadlatujące przeszkody. Na końcu dodałem okienko końca gry w przypadku utraty wszystkich żyć, które pozwalało na jej restart: Po stwierdzeniu, że wszystko działa jak należy nadszedł czas na ostatni krok: upiększenia graficzne. Do tej pory wszystkie elementy były tylko prowizorycznymi kształtami. Jako, że nie mam wielkiego talentu artystycznego, to postanowiłem poszukać darmowych paczek obrazków w internecie. Po znalezieniu zestawu obrazków użyłem ich do stworzenia prostych animacji, które zaimplementowałem w grze. Efekt końcowy wygląda następująco: PODSUMOWANIE Projekt nauczył mnie sporo o tworzeniu aplikacji z użyciem Qt. Wykorzystanie elektroniki do stworzenia kontrolera do gry dodatkowo umiliło naukę - w szczególności, że efekt końcowy wyszedł całkiem nieźle. Nie jest to gra na długie godziny, ale potrafiła zatrzymać na odrobinę czasu wszystkich, którym dałem wypróbować swój kontroler. Na koniec dorzucam link do repozytorium: https://github.com/Wirgiliusz/FlyAndShoot oraz filmik prezentujący działanie gry wraz z padem:

Szczerze mówiąc nie jestem do końca pewny, ale wydaje mi się, że użyłem po prostu biblioteki BSP, którą można zainstalować bezpośrednio z CubeIDE dla tej płytki. Jednak to co wysłałeś wygląda bardzo podobnie, obstawiam, że też będzie działało. Wydaje mi się że dużo osób tworzy jakieś pochodne biblioteki dla tego wyświetlacza ale działają one na tej samej zasadzie. Projekt miał głównie charakter edukacyjny i jak na razie nie zamierzam go rozwijać. Jeśli chodzi o labirynt to tak, jest on wgrany "z góry" - na początku miałem plan aby rysował się on na podstawie odczytów z robota, jednak samo nauczenie się zrobienia czegokolwiek w ROSie i RViZie zajęło o wiele więcej czasu i wysiłku niż się spodziewałem, więc potem zacząłem upraszczać wizualizację. Nie zmienia to faktu, że jest to możliwe i pewnie nie aż tak bardzo trudne w porównaniu do tego co zrobiłem, jednak mi po prostu zabrakło już sił

Od siebie dorzucam 2 opisy projektów, które napisałem:

Zgodnie z zapowiedzią tutaj link do projektu, który wykorzystuje LCD oraz wizualizację:

W trakcie budowy ostatniego robota zdałem sobie sprawę jak bardzo przydałoby mi się coś, co pozwalałoby wizualizować to co dzieje się w robocie w trakcie jego testowania. Ze względu, że mój robot Micromouse (którego budowę opisałem tutaj: Micromouse Robot - robot typu micromouse) wyposażony był w wyświetlacz LCD oraz moduł Bluetooth to był to idealny powód aby ich użyć. W taki sposób zrodził się pomysł na drugi projekt, który nazwałem "Robot Wizualizer - wizualizacja robota Micromouse". Projekt składa się z 2 części: Wyświetlacz LCD - na wyświetlaczu chciałem ukazać aktualne parametry robota takie jak: ustawiona prędkość na silnikach, pozycja w labiryncie i odczyty z czujników. Dodatkowo chciałem aby wyświetlacz wizualizował labirynt, który poznaje i przeszukuje robot. Wizualizacja komputerowa z środowiskiem ROS i RViZ - na podstawie danych przesyłanych przez robota do komputera miała powstać 3-wymiarowa wizualizacja labiryntu wraz z aktualnym położeniem robota. WYŚWIETLACZ LCD Ze względu, że płytką którą użyłem przy konstrukcji robota było STM32F429I-DISC1 to użytym wyświetlaczem był QVGA TFT LCD wbudowany w płytkę. Schemat elektroniczny projektu wygląda następująco: Jak widać, jeśli chodzi o wyświetlacz LCD to jest on podpięty w płytce wewnętrznie, jedyne co należy zrobić to użyć odpowiednich pinów. Reszta zadania polegała na podpięciu modułu bluetooth (HC-06) oraz w moim przypadku użycia prostego stabilizatora L7805 aby zasilić płytkę 5V. Interfejsy, które wykorzystałem do obsługi wyświetlacza to: DMA2D z Color Mode ustawionym na RGB565 w celu komunikacji pomiędzy mikrokontrolerem a wyświetlaczem, LTDC z rozdzielczością ustawioną na 320x240 do obsługi wyświetlacza i SPI do jego konfiguracji. Wszystkie elementy skonfigurowałem w środowisku STM32CubeIDE. Biblioteką, którą użyłem do sterowania wyświetlaczem jest sterownik STM32F429I_DISCOVERY_LCD dostarczany przez ST, który działa na podstawie sterownika wyświetlacza ILI9341. Użycie powyższej biblioteki sprawia, że praca z wyświetlaczem LCD staje się prosta, gdyż do dyspozycji mamy wiele funkcji, którymi możemy obsługiwać wyświetlacz. Po wykonaniu inicjalizacji oraz włączeniu wyświetlacza: wyświetlacz obsługujemy funkcjami typu: Pierwsze z nich pozwalają na rysowanie prostych kształtów o wybranym kolorze, w tym przypadku białego prostokąta w pozycji 0,0 i wielkości 239x239. Natomiast drugi zestaw odpowiada za wybranie białego koloru czcionki i wyświetleniu napisu w zadanej pozycji (70,260) wyrównanego do lewej. Niestety nie udało mi się znaleźć dokumentacji, która opisywałaby wszystkie funkcje. Osobiście znalazłem przydatne dla siebie funkcje przeszukując plik nagłówkowy biblioteki i testując ich działanie. Ich nazwy są całkiem adekwatne do tego co robią, więc nie było to niemożliwe zadanie. Po przetestowaniu działania wyświetlacza przyszedł czas na zaplanowanie elementów graficznych, które zostaną przedstawione na wyświetlaczu. Ze względu, że nie jestem wyrafinowanym grafikiem to zdecydowałem się na schematyczne ukazanie pożądanych informacji: Kolejne pola labiryntu zostały oznaczone kwadratami a możliwe ścieżki pomiędzy nimi to po prostu linie łączące kolejne pola. Dodatkowo pole, w którym aktualnie znajduje się robot miało być zaznaczane innym kolorem. Po podziale wyświetlacza na równe części i zastosowaniu odrobiny matematyki udało mi się napisać następujące funkcje: Pierwsza z nich rysuje bezbarwne pole dla zadanego położenia robota, natomiast druga pole kolorowe. Położenie robota zdefiniowałem jako 2 współrzędne (x,y) gdzie kolejne wartości całkowite (0, 1, .., n-1; gdzie nxn to rozmiar labiryntu) wskazują na pola labiryntu. Układ współrzędnych umieszczony jest w lewym górnym rogu, więc jeśli z tego punktu robot zacznie swoją trasę i przemieści się dwa razy na wschód, a potem raz na południe to jego współrzędne będą wynosiły (2,1). Zastosowanie współczynnika wielkości (WSP_WIELKOSCI) pozwala wykorzystać moje funkcje rysujące dla labiryntu dowolnej wielkości - podczas zwiększania się wymiarów labiryntu, rysowane pola są mniejsze, jednak nadal mieszczą się na wyświetlaczu. Następnie zaimplementowałem funkcję rysującą istniejące połączenia dla danego pola, dzięki czemu robot wraz z przejeżdżaniem labiryntu może od razu wizualizować, które ścieżki odkrył: W tym przypadku elementy także są skalowane w zależności od wielkości labiryntu. W tym momencie zauważyłem, że kwadratowa plansza labiryntu wykorzystuje tylko część prostokątnego wyświetlacza i nadal pozostaje na nim wolne miejsce - dlatego postanowiłem je wykorzystać. Stworzyłem kolejne funkcje, tym razem działające na tekście, które wypisywały informacje o robocie (prędkość, pozycja, czujniki). Implementacja przykładowej z nich wygląda następująco: Jak widać cały czas posługuje się funkcjami, które przytoczyłem wcześniej i które zapewnia użyta biblioteka do wyświetlacza. Na końcu dodałem jeszcze ramkę aby oddzielić część wizualną labiryntu od reszty danych i o to efekt (zdjęcie 1: labirynt 4x4, zdjęcie 2: labirynt 16x16): WIZUALIZACJA RVIZ Ta sekcja będzie mocno programistyczna i składać się będzie z 3 głównych programów: robota, skryptu w Pythonie oraz programu w C++. Jeśli ktoś jest zainteresowany dokładniejszym zrozumieniem działania każdego z nich, to polecam w trakcie czytania śledzenia poniższego diagramu, na którym przedstawione zostały schematy blokowe właśnie tych programów oraz relacje między nimi: ROBOT - wysyłanie danych Drugą część projektu rozpocząłem od skonfigurowania interfejsu USART w celu komunikacji mikrokontrolera z modułem bluetooth. Na podstawie skonfigurowanego interfejsu napisałem funkcje przesyłające przez niego dane do modułu: Dodatkowo użyłem przerwania wywoływanego przez interfejs w przypadku otrzymania informacji. W ten sposób jeśli otrzymaną informacją była np. komenda stopu to robot mógł zareagować natychmiastowo, bez potrzeby kończenia aktualnie wykonywanej akcji. Kolejnym krokiem była instalacja środowiska ROS oraz RViZ na moim laptopie. Wszystko odbyło się przy pomocy instrukcji ze strony producenta: https://www.ros.org/. W pierwszej kolejności moją uwagę poświęciłem stworzeniu prostego modelu robota. Do tego celu potrzebna okazała się wiedza o budowie plików .urdf wykorzystywanych w środowisku. Po zebraniu wiedzy z kilku poradników powstał pierwszy model: PYTHON - przekonwertowanie i przekazanie danych Następnym krokiem było wyrysowanie wszystkich elementów graficznych na scenie. W tym celu pierwszym krokiem stało się odebranie danych od robota przez komputer. Aby spełnić to zadanie posłużyłem się językiem Python i biblioteką pybluez, która umożliwia komunikację przez bluetooth. Napisany skrypt, w pierwszej kolejności tworzy wydawcę (publishera), który pozwala przesyłać dane do oprogramowania ROS. Następnie pyta użytkownika o tryb pracy: manualny czy zdalny. Tryb manualny polega na ciągłym odczycie komend wpisanych przez użytkownika, natomiast tryb zdalny łączy się z modułem bluetooth i cyklicznie odczytuje otrzymane dane z modułu. Niezależnie od wybranego trybu skrypt przesyła otrzymane dane do środowiska ROS. Wycinki skryptu, które realizują powyższe zadania wyglądają następująco: C++ - odebranie i wykorzystanie danych Kolejnym ogniwem był program napisany w języku C++, który pozwalałby wizualizować otrzymane dane w programie RViZ. W związku z tym tworzy on subskrybenta (subscribera), który łączy się z publisherem wcześniej stworzonym w skrypcie tworząc węzeł komunikacyjny. Następnie program tworzy znaczniki (markery) umożliwiające wizualizację w RViZie. Postanowiłem użyć dwóch rodzajów markerów: linii do rysowania ścian labiryntu oraz sześcianu do reprezentowania robota. Końcowo program w pętli oczekuje na odbiór danych, jeśli to się stanie to następuje przerwanie i w zależności od rodzaju danych wykonywane są odpowiednie funkcje aktualizujące pozycję lub orientację modeli. Wycinek opisanych funkcji wygląda następująco: Końcowy efekt prezentuje się następująco (na zdjęciu widoczne użycie w trybie manualnym): PODSUMOWANIE Myślę, że projekt ten wyszedł całkiem nieźle, w szczególności, że była to moja pierwsza styczność z wyświetlaczem LCD oraz oprogramowaniem ROS. Spora jego część jest czysto programistyczna, jednak mam nadzieję, że i tak kogoś zaciekawił. Jeśli kogoś interesują szczegóły to zapraszam do repozytorium https://github.com/Wirgiliusz/Micromouse-Robot-Wizualizer, w którym można znaleźć wszystkie wspomniane przeze mnie pliki oraz projekt w STM32CubeIDE, który zawiera zarówno konfiguracje samego robota Micromouse jak i wyświetlacza LCD. Na koniec jeszcze filmik pokazujący działanie wszystkich elementów w czasie rzeczywistym:

Mam pytanie techniczne: czy jeśli napisałem opis projektu w jednym z wymienionych działów i został on zatwierdzony i upubliczniony to jest on automatycznie kwalifikowany do konkursu, czy powinienem go gdzieś jeszcze zgłosić?

Niedługo mam zamiar napisać kolejny opis projektu, który tym razem skupi się właśnie na wykorzystaniu tego wyświetlacza (+ jeszcze bonus ). Podlinkuje tutaj gdy będzie gotowy.

Cześć, systemami wbudowanymi interesuję się od jakiegoś roku. Spodobała mi się zarówno warstwa elektroniczna (projektowanie układów, lutowanie itp.) jak i programistyczna. Jak na razie nie mam zbyt wielkiego doświadczenia, jednak staram się je zdobywać tworząc coraz to nowe projekty. Zawsze szukam nowych źródeł wiedzy i wiem, że tutaj na pewno takie znajdę, dlatego postanowiłem dołączyć do 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: