Micromouse Stuart

[grabo]

Owszem, można zapisywać do Flasha.

[Harnas]

Więc tak. W Rybniku zwracałem się do organizatorów z prośbą o umieszczenie w regulaminie specyfikacji labiryntu. Dostałem jedynie informacje gdzie będzie start i meta a w finale start będzie z innego pola które będzie podane tuż przed finałem, więc mogłem odpowiednio ustawić floodfill. Labirynt był praktycznie cały czas odkryty i można było wklepać sobie do programu mapę labiryntu.

W Stuarcie jest miejsce na eeprom, był nawet przez jakiś czas wlutowany, jednak nie miałem okazji go uruchamiać a po pewnym czasie uszkodziłem w procesorze nóżkę z I2C.

Pozatym chyba łatwo zobaczyć że ktoś puszcza robota, a on od razu, bez mapowania jedzie po najkrótszej trasie, i chociaż regulamin tego nie zabrania można uczestnika zdyskwalifikować za niezbyt uczciwe praktyki.

Algorytm licznie ile razy było się w danej uliczce i znaczenie ślepych uliczek pozwala przejechać labirynt który posiada pętle których zwykły wallfollower nie przejedzie.

[MatManiak]

Zgodzę się, że powinno być zabronione ręczne modyfikowanie zapisanej trasy w robocie, bądź też wpisywanie jej ręcznie. Jeśli są 2 etapy konkursu (eliminacje i finał) i w każdym etapie są np 2 przejazdy (bądź dowolna ilość przejazdów w ciągu X minut), to układ labiryntu powinien się różnić w finale w stosunku do tego z eliminacji. W labiryncie z wyciąganymi ściankami to nie problem (a w Rybniku poradzono sobie właśnie z tym problem zmieniając pole startowe, bo ścianek tam nie można przestawiać bo są przykręcone). Masz rację, że powinna być dyskwalifikacja, gdy robot pierwszy raz wjeżdża do labiryntu o danym układzie i jedzie odrazu optymalną trasą - to akurat może być łatwo dostrzeżone przez sędziego. Idealnie byłoby w ogole nie doprowadzać do takiej sytuacji, tzn robić tak jak w Japonii - przychodzisz z robotem na zawody, to labirynt jest zasłonięty i albo jest odsłonięty tylko fragmencik na ktorym można przetestować/skalibrować czujniki, albo jest w strefie serwisowej/obok identycznie wykonany malutki testowy labirynt. Po testach, każdy z zawodników oddaje robota organizatorom i od tamtej pory nie może go dotykać. Wtedy odsłaniany jest labirynt i po kolei są wywoływani zawodnicy którzy biorą swojego robota, umieszczają na starcie i mają np 10 minut na ile przejazdów chcą, a liczy się najszybszy (bądź też całkowity czas + najszybszy z odpowiednimi wagami oczywiście). Po przejeździe, odkładają robota. Jeśli przejdą do finału (o ile w ogóle jest runda finałowa), to labirynt jest zmieniany (przestawianie ścianek) i cała sytuacja się powtarza. No ale zdaję sobię sprawę, że to może potrwać zanim takie idealne rozwiązanie zostanie wdrożone - narazie MM jest mało popularne, więc priorytetem są falstarty w sumo, brudne/pofałdowane trasy w LF itp itd;)

P.S: żeby nie robić całkowitego offtopu (przepraszam), to pytanie do Harnasa - jaką szerokość ma Stuart? Jak słusznie zauważył Grabo, niepotrzebnie robot jest taki szeroki - jakby był bardziej wąski, to istaniała by mniejsza szansa na uderzenie w ściankę.

[Harnas]

Szerokość to 11 cm a długość jedynie 8 cm, i to prawda że jest zbyt szeroki. Aktualnie priorytetem jest załatwienie do końca sprawy korekcji, tak aby jak najbardziej zmniejszyć szanse na uderzenie w ścianę. O jechaniu na skos nawet nie myślę, a przynajmniej narazie

[MatManiak]

Dla labiryntu który ma szerokość korytarza 168mm (czyli 99% labiryntow do micromouse na swiecie), by robot zmieścił się po przekątnej (tzn by jechał na wprost przez "schody", czyli pod kątem 45 stopni w stosunku do ścian) maksymalna szerokość robota to:

168*sqrt(2)/2 >118,8 mm

Zatem Twój robot się mieści, ale by nie zahaczył o róg musiałby jeździć bardzo precyzyjnie, bo z każdej strony będziesz miał mniej niż 5mm zapasu między bokiem robota, a kątem łączącym 2 ściany. W teorii możliwe, ale w praktyce moim zdaniem to nie wykonalne. Chyba, że co innego masz na myśli pisząc o jeździe na ukoś, bo jeśli chodzi o branie zakrętów po łuku to jak najbardziej możliwe w Twoim robocie.

[electrik_eye]

O.o

Kolega też był w Rybniku? To miło... ;D

Akurat tego micromouse'a nie widziałem bo skupiałem się na linefollowerach ale świetny robot

[wn2001]

algorytm odcinania ślepych dróg jest równie dobry jak floodfill (bo zwróci optymalną, jedyną trasę start-meta, w której robot nie będzie wjeżdżał 2x na to samo pole). W floodfill trzeba znać rozmiar labiryntu, punkt startowy, metę (tzn gdy nie jest znany można go wyliczyć po zmapowaniu całego labiryntu oczywiście, ale to dodatkowe utrudnienie), trzeba przechowywać informację o strukturze labiryntu co zajmuje pamięć, no i trzeba wykonać algorytm rozlewania wody a później wybrania najlepszej trasy. W algorytmie odcinania ślepych dróg, wystarczy zapamiętywać pokonywane skrzyżowania, co zajmuje mniej pamięci i nie wymaga nawet użycia enkoderów, nie trzeba znać rozmiaru labiryntu, podobnie miejsce startu i mety jest bez znaczenia, a sam algorytm eliminacji jest prostrzy do wykonania, bo to zwykłe szukanie i usuwanie konkretnych podciągów w ciągu zakrętów

W robocie jest zaimplementowanie liczenie ile razy był w danej komórce jak i zaznaczanie ślepych uliczek.

Na początku przepraszam od odkopanie tematu Tak się składa, że buduję swojego MM i choć jestem w powijakach, to już zastanawiam się nad wyglądem programu, w tym algorytmu rozwiązywania labiryntu Będzie miał dwa silniki krokowe NEMA11, które powinny mi dać odpowiednią precyzję pozycjonowania. Chodzi jednak, jak mógłby w najprostszej postaci wyglądać zacytowany algorytm? Wiem, że labirynt będzie można przejechać prawą i lewą ręką, więc ten algorytm wydaje mi się optymalny. Czy to miałaby być tablica do której wpisuję sekwencje i punkty w których jestem (np. KOMÓRKA 5,5 > skręć w prawo > prosto 3 >komórka 8,5 > zawróć o 180 stopni >prosto 3 > KOMÓRKA 5,5 i zastępuje to tylko 5,5 > prosto)? Chodzi mi o jak najprostszą implementację tego algorytmu, gdyż jest lepszy niż lewa/prawa ręka ale prostszy niż flood-fill. Mam nadzieję, że Atmega328 sprosta temu zadaniu (będą 2 Arduino Nano połączone TX-RX (UART), drugi do reszty zadań). Ktoś ma jakieś pomysły na jak najprostsze urzeczywistnienie tego algorytmu? Z góry dziękuję za wszelkie odpowiedzi

[Harnas]

Wiem, że labirynt będzie można przejechać prawą i lewą ręką

Nie każdy, a jeszcze rzadziej bedzie to droga optymalna.

Ja bardzo wzorowałem się tym artykułem: https://forbot.pl/blog/artykuly/programowanie/roboty-micromouse-5-metod-przeszukiwania-labiryntu-id17354 . Używałem 2 wymiarowej tablicy (mapa[16][16]) gdzie każdy element odpowiadał pojedynczej komórce labiryntu. Oprócz tego w pamięci były 3 zmienne (x, y, z). Samo odcinanie ślepych uliczek było już realizowane przez floodfill.

Jeżeli chciałbyś to zrobić bez floodfillu, to w momencie kiedy będziesz zawracał z ślepej uliczki, postawić sobie w pamięci wirtualną ścianę w polu najbliższego skrzyżowania tak aby nie dało się tam ponownie wjechać, i za każdym razem porównywać odczyty czujników ze ścianami w pamięci.

[wn2001]

Bardzo dziękuję Czy te zmienne x,y to pozycja w labiryncie, a z to kierunek w którym robot jest zwrócony? I wtedy "wlewając wodę" widać, które odcinki są ślepe i na pewno nie prowadzą do celu drogą optymalną (albo nie prowadzą nigdzie)?

Natomiast jeżeli chciałbym bez floodfillu, to tworzę mapę 16x16 i wówczas jeżeli będzie ślepy zaułek, to stawiam tam wirtualną ścianę, tak? I wtedy jadę, korzystając z tej mapy i śledzę prawą ścianę, ale tak, jakby w wjeździe do zaułku stała ściana, tak? Chyba rozumiem, ale chciałem się upewnić