[LF][C] Kąty ostre

[BmpPmB]

Witam wszystkich!

Mam problem w moim linefollowerze z pokonywaniem kątów ostrych. Nie mam problemów z kątami prostymi, wtedy zapamiętuję po prostu ostatnią pozycję względem linii i robot na nią wraca. W przypadku najazdu na kąt ostry jednak metoda ta nie chce działać, bo ostatni stan jaki robot widzi to jazda na wprost (zamiast skręcić jedzie prosto). Proszę o pomoc, wskazówki jak się do tego zabrać. Poniższy rysunek obrazuje problem na trasie:

Z góry dziękuję za pomoc!

[marek1707]

Na pewno jest wiele rozwiązań tego problemu i Koledzy wkrótce podrzucą coś interesującego. Tak na szybko przychodzą mi do głowy dwa pomysły:

1. Naiwny, ale prosty w realizacji: patrzysz na trasę wyścigu i sprawdzasz jakie ostre zakręty na niej ułożono. Zwykle na zawodach nie ma tego dużo (jeśli w ogóle) a przy odrobinie szczęścia wszystkie będą w tę samą stronę. Wtedy po nagłym zgubieniu linii (na prostej) zawracasz zawsze w poprawną, ustawioną (przed startem) stronę i znajdujesz dalszy ciąg trasy.

1a. Rozbudową tego jest pamiętanie sekwencji takich zakrętów, tj. pierwsze zgubienie na prostej to kręcę się w lewo, drugie zgubienie na prostej to w prawo itd.. To nie wymaga wielkiej inteligencji od programu a może zadziałać. Wbudowany prosty sekwencer zliczający wydarzenia w czasie jazdy i "podpowiadający" zachowanie się robota w czasie napotkania kolejnego ostrego końca linii załatwi sprawę.

2. Inteligentne reagowanie na ostre kąty wymaga przede wszystkim ich wykrywania. Jak już sam zauważyłeś nie wystarczy pamiętanie ostatniego poprawnie rozpoznanego stanu trasy przed jej zgubieniem jak to ma miejsce w przypadku kątów prostych. Tu musisz wprowadzić jednocześnie:

a. Lepszą analizę tego co widzą czujniki. Jeśli do tej pory szukałeś jednego miejsca/czujnika najlepiej widzącego linię to teraz musisz umieć wykrywać dwa takie miejsca. To wymaga innego podejścia do analizy sygnałów z czujników i być może większej ich liczby. Teraz raczej nie wystarczą typowe trzy lub pięć elementów bo masz wykrywać dwa osobne cele i ich trendy (kierunki ruchu z ramki na ramkę danych) a nie tylko ich obecność. Co więcej - musisz rozumieć co widzisz. Znaczy procesor i jego program, oczywiście. Będziesz musiał napisać funkcję, która śledzi położenie linii po której jedziesz i odczyt po odczycie śledzi jej przesuwanie się pod czujnikami a jednocześnie detektor będzie musiał rozpoznawać "obcą" linię, która pojawia się gdzieś z boku i zdąża do tej właściwej.

b. Mając takie informacje od funkcji obsługujących czujniki będziesz musiał napisać zupełnie nowy automat sterujący taktyką jazdy. Dane o położeniu naszej linii i ew. tej nowej będziesz musiał pamiętać dłużej - czy to w postaci historii z której w krytycznym momencie wywnioskujesz skąd "nadjechała" nowa trasa, czy w postaci stanu automatu, który będzie na bieżąco śledził odczyty. Strona z której pojawiła się pod czujnikami obca linia będzie podstawą decyzji o kierunku obrotu, ale będzie to potrzebne wiele cykli później niż fakt wykrycia tego zdarzenia. Właśnie po to by tę stronę znać musisz odróżniać "swoją", dotychczasową linię od tej "nowej".

Zwykle kąty ostre pojawiają się na prostej więc pozycja robota jest stabilna a napędy nie są w dynamicznym zakręcie, gdzie regulatory rozpaczliwie próbują nadążać za uciekającą na boki trasą. To upraszcza zadanie, choć trywialne ono nigdy nie będzie. Nawet jeśli do tej pory zachowania robota można było wnioskować tylko na podstawie ostatniego kompletu danych i zrobić to na prostych if-ach bez żadnych refleksji z przeszłości, teraz to będzie raczej niemożliwe. Istnieje co prawda szansa, że w megaprostym algorytmie np. zaczniesz zakręcać natychmiast w odpowiednią stronę po wykryciu obcego odczytu gdzieś na skraju listwy czujników (bo to zwiastuje nową linię), ale takie zachowanie jest niebezpieczne bo wymusza paniczne zachowanie przy pierwszym błędnym odczycie np. cienia na podłodze. Tak czy tak wypadałoby porównywać ze sobą kolejne odczyty i upewniać się co do trwałości "zakłócenia", ale to sprowadza się właśnie dośledzenia własnej linii (która jest aktualnym celem) i odróżniania jej od nowego obiektu na skraju. Bardzo przyda się tutaj umiejętność rozpisywania pracy robota na stany automatu, tworzenia takich automatów w C i projektowania sensownych przejść między stanami. Jeśli nigdy tego nie robiłeś, poszukaj haseł typu "maszyna stanów w C", "Finite State Machines" itp. Nie jest to trudne - w końcu to prosta idea przeniesiona do języka programowania a jak się to już raz opanuje, okazuje się fajnym wytrychem do wielu problemów 🙂

[Treker (Damian Szymański)]

BmpPmB, z ciekawości dopytam - skąd zainteresowanie taką tematyką? Kąty ostre raczej nie występują na zawodach. Jeśli chodzi o rozwiązanie tego problemu, to mając dużo czasu na testy i odpowiednią ilość czujników poszedłbym w stronę rozwiązania opisanego przez Marka, konkretnie 2a.

Jeśli miałbym rozwiązać ten problem "na szybko", to pozostałbym przy aktualnym podejściu, które działa przy kątach prostych. Tylko zamiast ostatniego stanu zapamiętywałbym średnią pozycję robota względem linii z kilku ostatnich centymetrów. Jeśli pozycja robota względem trasy liczona jest jako średnia z czujników numerowanych np. w taki sposób: -4 -3 -2 -1 +1 +2 +3 +4, to jadąc po prostej (dwa środkowe na linii) otrzymujemy średnią 0. Zbliżając się do zakrętu ostrego linia zostanie wykryta np. przez dwa środkowe czujniki oraz skrajny prawy. Wtedy ze średniej otrzymasz (-1 + 1 + 4) / 3, co jest wartością większą od 0, więc będzie wiadome, że ostry zakręt był z prawej strony. Tyle w teorii, w praktyce będzie z tym sporo problemów 😉

Zupełnie inne podeście do tematu, to zmniejszenie linijki czujników, do bardzo, bardzo wąskiej - to również rozwiąże problem, ale pokonywanie całej trasy będzie znacznie trudniejsze 😉

[BmpPmB]

Niestety teraz na zawodach coraz częściej się pojawią kąty ostre, np ostatnio w niedzielę w Poznaniu było ich chyba z 5 na trasie, ale już rok temu w Białymstoku też się pojawiły. Dzięki za odpowiedzi, muszę coś szybko wymyślić, bo robot jedzie szybko, a jedynym problemem są kąty ostre właśnie.. Podoba mi się ten pomysł ze średnią, spróbuję to zrobić 🙂

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[marek1707]

Tak czy tak, nie można ograniczyć się do analizowania tylko ostatniej ramki danych. Przecież jeśli będziesz stany czujników obrabiał typowo tj. celował w środek ich wskazań nie rozumiejąc, że oto pojawiły się dwie prawie równoległe taśmy, to w chwili wjechania bocznego odejścia w zakres widzenia czujników Twój "cel" nagle się przesuwa. Robot jeszcze nie stracił trasy więc regulacja położenia skręca podwozie tak, by mieć obie linie mniej więcej po środku. Jeśli robot jest szybki (a jak wiemy jest) i zareaguje na tę zmianę - wydawałoby się - prawidłowo czyli wycentruje się na dwóch liniach (de facto na białym między nimi), to gdy straci trasę będzie dokładnie na środku "dziubka". Wszystko zależy od dynamiki bo może np. okazać się, że przeregulowanie po skokowej zmianie będzie na tyle duże, że wręcz wyjedziemy po drugiej stronie ostrego końca i decyzja o skręcie na podstawie średniej będzie błędna.

Już ten przykład pokazuje, że konieczna jest lepsza analiza i śledzenie aktualnie docelowej trasy bez gwałtownego rzucania się na boki. Do tego potrzebna jest funkcja która rozumie gdzie obecnie jest nasza trasa (tj. który obraz - z max. 2 widzianych - jest taśmą do której się centrujemy), śledzi jej odchyłki i na podstawie historii wyznacza obraz który jest najbardziej prawdopodobnym obecnym położeniem celu. Już nie wystarczy sumować wag czujników które coś widzą, bo to właśnie spowoduje wycentrowanie na przerwie między dwoma liniami.

Mając takie inteligentne śledzenie dwóch obrazów: naszego aktualnego celu i obcej, nowej trasy wystarczy poczekać aż nasz zniknie, wtedy odwołać się do historii i sprawdzić czy jest w niej ślad aktywności funkcji wykrywającej drugą taśmę. Jeśli tak, jesteśmy na kącie ostrym i skręcamy. Jeśli nie, jest to pewnie przerwa w trasie (LF enhanced) - jedziemy w miarę prosto i czekamy na pojawienie się wyniku z funkcji wykrywającej cel podstawowy. Przy braku takowego po jakimś czasie - stop żeby nie uciec z planszy.

[Treker (Damian Szymański)]

Niestety teraz na zawodach coraz częściej się pojawią kąty ostre, np ostatnio w niedzielę w Poznaniu było ich chyba z 5 na trasie, ale już rok temu w Białymstoku też się pojawiły.

Pojawiają się "przypadkiem", czy faktycznie jest to wpisane w regulaminach?

[BmpPmB]

Treker, jest to zapisane w regulaminie. Cytat z regulaminu Cyberbot 2017 (Poznań):

Minimalny kąt skrętu o promieniu 0 mm wynosi 45 stopni.

Będę w najbliższym czasie pracował nad rozwiązaniem problemu, jeżeli się uda, dam znać jak to zrobić. Pozdrawiam i dziękuję za dotychczasowe odpowiedzi!