Line follower Tsubame

[mskojon]

Byłem na Roboticonie i Tsubame zrobił na mnie naprawdę ogromne wrażenie 🙂 na zdjęciach wydawał się sporo większy, to aż niesamowite że przy takich wymiarach potrafi z taką prędkością jechać po torze. Rozbawiło mnie, gdy po przejeździe Jarek włożył robota do kieszeni 🙂 jest to naprawdę godna konstrukcja, czekam na Tsubame 2 🙂

Oczywiście że możesz udostępnić moje biblioteki, im więcej ludzi z nich skorzysta tym lepiej, miło wiedzieć że ułatwiam forumowiczom projektowanie płytek 🙂

[Sabre]

Bo to taki kieszonkowy robot, mieści się w kieszeni nad portfelem 🙂.

Skoro mam przyzwolenie Kuby to wrzucam spakowane 2 biblioteki.

LM2594_ST1S10PHR_lbr.zip

[ojebejbe]

Dzięki śliczne za biblioteki 🙂

[Sabre]

Takie małe porównanie przejazdów w finale mojego Tsubame i Inferno/Mefisto nagrane w 240fps:

[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

[kamilelektryk]

Widać, że przez to, że Twój robot jest bardzo mały najwięcej straciłeś na tej "pofalowanej" części trasy. Inferno/Mefisto pojechał prosto, a Tsubame kluczył za linią. Gdyby nie ta część trasy najprawdopodobniej byłbyś poważną konkurencją dla Inferno i Mefisto.

[Sabre]

kamilelektryk, kluczenie nie ma nic do rzeczy, a raczej nie aż tak dużo. Mój Tsubame ogólnie jest wolniejszy na tym filmie. Mógłby jechać znacznie szybciej gdyby nie problem z kątami prostymi, który wyraźnie widać w ostatnim filmiku z finałów. Przy zbyt dużej prędkości mój robot za daleko wyjeżdża za linię przez co gdy wraca nie zawsze jedzie tam gdzie powinien. Nie jest to łatwo rozwiązać. Przed zawodami nagrałem bardzo dużo filmów w 240fps i oglądałem reakcję robota na kąt prosty. Prawda jest taka, że ten mikrokontroler ma za wolny przetwornik ADC, po najechaniu na kąt prosty zanim robot przetworzy wszystko jest już około 2-3cm za początkiem kąta prostego, dopiero wtedy zaczyna hamować kołem po wewnętrznej zakrętu, ale jest już za późno. W tym konkretnym przypadku oprócz robota jadącego w stronę linii, linia zakrzywiała się w stronę robota. Efekt końcowy jest taki, że Tsubame wjechał na linię czujnikami równolegle, a nie pod jakimś ostrzejszym kątem, a że był już rozpędzony na zakręcie więc zawrócił.

Oglądanie ruchu w zwolnieniu daje świadomość popełnianych błędów, ale niestety pomimo takiej wiedzy nie zawsze jestem w stanie im zapobiegać.

[Siłak]

Prawda jest taka, że ten mikrokontroler ma za wolny przetwornik ADC

Nie wydaje mi się, że jest to wina wolnego przetwornika ADC. Przy oscylatorze 20MHz przetworzenie 8 kanałów przez ADC trwa bardzo, bardzo krótko.

Hamujesz przeciwprądem?

[Sabre]

Przy oscylatorze 20MHz przetworzenie 8 kanałów przez ADC trwa bardzo, bardzo krótko.

To twoje bardzo, bardzo krótko jest pojęciem bardzo, bardzo względnym, są AVRy, które przetwarzają znacznie szybciej 🙂.

Nie hamuję przeciwprądem bo nie dawało to zamierzonego efektu, a bez enkodera kwadraturowego trudno zapanować nad takim hamowaniem, przynajmniej nie przy takiej przekładni i takiej masie robota.

[Nawyk]

są AVRy, które przetwarzają znacznie szybciej

Sabre, a może warto wreszcie pomyśleć o przesiadce na C ? 🙂

[Siłak]

To twoje bardzo, bardzo krótko jest pojęciem bardzo, bardzo względnym

Nie chciałem podawać konkretnego czasu przetwarzania 8 kanałów przez ADC, ponieważ zależy on w dużej mierze od tego w jaki sposób to robisz. Z moich obliczeń wynika, że przetworzenie 8 kanałów przez ADC w uC, który zastosowałeś w swoim robocie może trwać na przykład 1/1000 sekundy (przy zachowaniu 10cio bitowej rozdzielczości pomiaru). Jeśli robot porusza się z prędkością 1 m/s to w ciągu 1/1000 sekundy przejedzie 1 milimetr. Przetwornik ADC może przetwarzać szybciej (w tym wypadku może zmniejszy się rozdzielczość pomiaru).

[Sabre]

są AVRy, które przetwarzają znacznie szybciej

Sabre, a może warto wreszcie pomyśleć o przesiadce na C ? 🙂

Między innymi dlatego zaczynam się uczyć C, nie dlatego, że Bascom mi nie wystarcza, tylko dlatego, że na chwilę obecną nie obsługuje w pełni xmeg.

Co do czasu przetwarzania to tak powinno być, ale nie wiem dlaczego tak nie jest. Napisałem program, który miał zapalać diodę gdy robot wykryje wysuniętym czujnikiem linię, czyli kąt prosty. O dziwo dioda zapalała się gdy czujniki były prawie za linią. Fakt, że w Striderze2 zrobiłem pomiar czasu przetworzenia 8 kanałów i wynosił on około 1,7ms, dlatego w Tsubame już tego nie robiłem, chociaż zmieniłem preskaler ADC na teoretycznie szybsze przetwarzanie. Jak znajdę jutro chwilę czasu to zmierzę czas w Tsubame bo już dawno powinienem był to zrobić.

[TIMONek]

Każdy współczesny szybki linefollower wyjeżdża na kątach prostych poza linię i trzeba sobie z tym jakoś radzić 😉 między innymi dlatego Inferno posiada regulowaną długość - tak, żeby zdążyć powrócić na trasę. Przejrzałem tak na szybko notę katalogową ATmegi, którą użyłeś w Tsubame i wynika z niej, że przetwornik jest w stanie przetwarzać z prędkością ponad 70 kS/s. W projekcie użyłeś 8 czujników, co daje powiedzmy 8 tysięcy sampli na sekundę na czujnik. Hmm... wniosek jest prosty - problemem nie jest użyty przetwornik ADC. Mikrokontroler też jest względnie szybki, więc albo program jest nieoptymalnie napisany albo problem leży po stronie Bascoma.

Nie wiem też czy porównywanie się z tym filmikiem Inferno ma jakiś cel. Przeważnie na zawodach jeździmy bez stabilizowanego napięcia - więc średnia prędkość robota jest dużo wyższa - można zobaczyć na filmiku z Rybnika. W Warszawie mieliśmy dziwne problemy z robotem.

Jestem też przekonany, że gdyby Inferno miał zastosowaną zwykłą ATmegę też byłby w stanie wykręcać takie czasy 🙂

Nie hamuję przeciwprądem bo nie dawało to zamierzonego efektu, a bez enkodera kwadraturowego trudno zapanować nad takim hamowaniem, przynajmniej nie przy takiej przekładni i takiej masie robota.

Myślę, że wcale nie tak trudno 🙂

Co do czasu przetwarzania to tak powinno być, ale nie wiem dlaczego tak nie jest. Napisałem program, który miał zapalać diodę gdy robot wykryje wysuniętym czujnikiem linię, czyli kąt prosty.

Pewnie pętla programu trwa na tyle długo 😉 chyba, że zapalasz diodę w przerwaniu od ADC - nie wiem jak to w Bascomie wygląda.

[Sabre]

Nie wiem też czy porównywanie się z tym filmikiem Inferno ma jakiś cel.

Celem było pokazanie różnicy w prędkościach. Z moich obliczeń wynika, że wasz robot jechał na tej długiej prostej przed zakrętem z prędkością 1,45m/s.

Przed zawodami w Warszawie nagrałem bardzo dużo filmów z zachowaniem Tsubame na kątach prostych. Próbowałem bardzo wielu ustawień hamowania przeciwprądem i żadne z ustawień nie przyniosło zadowalających rezultatów więc pozostało tak jak było na początku czyli hamowanie mostkiem poprzez zwarcie do Vcc bądź GND obydwu złącz silnika.

Polecenie zapalenia diody było wpisane w pętlę odczytu z czujników, aby rozwiać wszelkie wątpliwości napiszę, że w Striderze2 cała pętla wykonywana była w około 2ms z czego 1,7ms trwało odczytanie danych z czujników (dokładniej pętla odczytująca dane z 8 czujników i wpisująca je do odpowiednich zmiennych). Nie wiem jak jest w Tsubame bo z racji zastosowania tego samego mikrokontrolera tego czasu nie mierzyłem, dziś wieczorem zrobię pomiary.

[Sabre]

Zrobiłem pomiary, przy ustawionym preskalerze na auto, czas przetworzenia napięcia z 8 czujników wynosi 1,6ms, natomiast z preskalerem ustawionym na 4 (przy preskalerze 2 czujniki nie wykrywają już linii) ten sam czas przetworzenia wynosi 230us (prawie 7 razy szybciej) i taki też preskaler był ustawiony podczas zawodów. Ogromna różnica, ale wydaje mi się, że gdy nagrywałem filmiki przed zawodami miałem ustawiony preskaler na auto. Cała pętla programu wykonuje się w 537us więc całkiem szybko. Muszę zrobić nowe analizy na kątach prostych.

[kamilelektryk]

Sabre, mógłbyś napisać jaką metodą wykonujesz takie pomiary czasu?