Steropes
Witam, chciałem przedstawić robota klasy linefolower. Pracowałem nad nim w wolnym czasie około roku wliczając różne wersje. Jak zwykle chciałem odejść od stereotypów i głównego nurtu linefolowerów. Głównym celem było, aby robot mógł widzieć linie przed nim, by mieć trochę więcej czasu na reakcję. Za podstawę jezdną wykorzystałem używany model samochodu RC w skali 1/24 Sarpent S240. Ograniczyło to trochę zwrotność robota, ale ułatwiło kontrolę i dało jakąś szansę na realne wykorzystanie pomysłu w większej skali poza zawodami.
Kamera
Sprawnie poruszanie się po torze wymaga szybkiej kamery, aby obraz się nie rozmywał i by posiadać w miarę świeże dane o położeniu. Niestety kamery o dużej liczbie klatek na sekundę są drogie, a prędkość danych wypluwanych przez matrycę jest prawie niemożliwa do obrobienia w czasie rzeczywistym na pokładzie małego robota. Jedyną możliwością jest ograniczenie liczby pikseli. Po długich poszukiwaniach znalazłem matrycę, która spełniała moje wymagania. TSL1401R jest prostą w obsłudze matrycą posiadającą 128 pikseli ułożonych w jednej linii. Maksymalna prędkość tej matrycy mocno przerosła moje zapotrzebowanie, ale szybkie sczytywanie zmniejsza poziom sygnału na wyjściu, przez co byłem zmuszony do ograniczenia prędkości do 1000fps. Jednym z problemów, jakie napotkałem była zmiana natężenia światła padającego na matrycę. Wieczorami natężenia jest tak małe, że musiałem doświetlać obszar przed robotem LEDami na podczerwień (w podczerwieni wypada maksymalna czułość matrycy), a w słoneczny dzień robot był wręcz oślepiony światłem, odczytując maksymalne naświetlenie dla wszystkich pikseli. Rozwiązałem to czymś na kształt PWM, w czasie każdej 1ms mikrokontroler wykonuje dwa sczytywania jedno właściwe o regulowanej długości naświetlania i drugie dopełniające, z którego wartości są pomijane. Co gwarantuje stała częstotliwość 1000fps? Przy takim rozwiązaniu w słoneczny dzień jestem w stanie skrócić czas naświetlania do 40us i otrzymać poprawne wyniki, a w nocy wydłużyć czas naświetlania do 960us i też zobaczyć linie. Obudowę do matrycy zrobiłem samemu razem z obiektywem składającym się z jednej soczewki. Matrycą steruje mikrokontroler Atmega1284 ze względu na dużo SRAMu. Atmega taktuje matrycę z częstotliwością 5MHz wygenerowaną przez jeden z timerów. Sygnał analogowy z matrycy jest przesłany przez wzmacniacz operacyjny do ADC1175CIJM, który jest podpięty do jednego z portów równolegle i taktowany tym samym sygnałem zegarowym. Atmega po wczytaniu wartości z ADC zajmuje się obróbką obrazu. Nie będę tu opisywał wszystkich szczegółów obróbki obrazu, bo nie chcę się rozpisywać. Jednak nie są one tajemnicą i jak ktoś bardzo chce je poznać, to proszę o kontakt, to opiszę. Mogę powiedzieć, że zajmują one ok. 60% mocy obliczeniowej i na końcu generują pozycje linii w postaci jednego byte'a lub zero, które oznacza brak linii w zasięgu. Ponieważ robot jest mało zwrotny, a pole widzenia kamery to tylko 10cm szerokości, wpadłem na pomysł zamontowania kamery na obrotowej platformie. Komplikuje to trochę budowę, lecz w rezultacie poprawia dużo czynników. Po pierwsze - robot nie zawsze musi znajdować się w kierunku linii. Poruszyć kamerą można dużo szybciej i sprawniej niż całym robotem. Przy dobrym algorytmie linia znajduje się zawsze w polu widzenia. Kamerą porusza silnik za pomocą paska zębatego. Przełożenie jest bardzo małe - ok. 1:4. Na osi platformy znajduje się potencjometr, który czyta pozycję kamery względem robota.
Tył robota z widocznym układem obróbki obrazu:
Podczas tworzenia robota wiele razy zdarzyło się, że warto by było zobaczyć, co robot widzi. Przy pomocy drugiego uartu w Atmedze i przejściówki na USB stworzyłem taką możliwość pisząc program w WinApi do wizualizacji. Prędkość uart nie pozwoliła na wysyłanie każdej ramki, więc częstotliwość odświeżania na komputerze to tylko 10fps. Oto przykładowy obraz (na górze wykres naświetlenia, na dole pasek odcieni szarości):
Podstawa Jezdna
Jak już wcześniej wspominałem - robot porusza się na podwoziu samochodzika RC Serpent S240. Do oryginalnej konstrukcji wprowadziłem tylko niezbędne zmiany. Uciąłem i nagwintowałem słupki podtrzymujące karoserię, aby podtrzymywały one kolejną warstwę. Przednie koła wysunąłem po 1cm na boki, przez co zwiększyłem maksymalny skręt kół. Ponieważ podwozie oryginalnie było zrobione z włókna węglowego, postanowiłem zachować je w tej konwencji. Warstwę, którą dobudowałem zrobiłem też z włókna węglowego, co przysporzyło mi trochę kłopotów, ale jestem zadowolony z końcowego efektu. Dwie ogniwa Li-pol po 800mAh mieszczą się w przewidzianym przez producenta uchwycie.
Silnik główny
Do napędu wykorzystałem oryginalny silnik szczotkowy. Do sterowania tym silnikiem użyłem 30-amperowego sterownika do modelarskich siników bezszczotkowych. Było taniej i prościej przerobić taki sterownik niż kupować część od zera. W sterowniku został mi jeden kanał, z którego wykorzystałem mosfety do włączania reszty elektroniki. Na początku planowałem zamontować na silniku napędowym enkoder, aby można było utrzymywać stałą prędkość bez względu na zmianę napięcia akumulatorów, jednak okazało się to niewykonalne ze względu na brak miejsca. Zastosowałem alternatywny sposób tzw. Back EMF. Dokładniejszy opis po angielsku tutaj: url=http://www.acroname.com/robotics/info/articles/back-emf/back-emf.html]Link[/url]. Polega on na tym, że podczas normalnej operacji silnika odłącza się na chwilę zasilanie i mierzy napięcie generowane przez silnik, które po ustabilizowaniu jest proporcjonalne do prędkości obrotowej. Pomiary te wykonuje Atmega8 oryginalnie zainstalowana w sterowniku zmieniłem tylko soft i kilka połączeń. Atmega odbiera po uart-cie żądanie uzyskania odpowiedniej prędkości i dzięki sprzężeniu zwrotnemu z back EMF i kontrolerowi PID uzyskuje żądaną prędkość. Płytka regulatora pełni równocześnie rolę rozdzielacza zasilania i kontrolowania baterii. Atmega8 jest na stałe podłączona przez oszczędny regulator do baterii i wprowadzona w tryb uśpienia. Wciśnięcie przycisku z boku robota budzi Atmegę, ona włącza resztę elektroniki przez mosfety i czeka na pierwsze rozkazy odnośnie sterowania silnikiem. Ponowne wciśnięcie przycisku lub spadek napięcia baterii poniżej 6 Voltów powoduje wyłączenie robota i przejście Atmegi w tryb uśpienia.
Sterownik głównego silnika:
Serwo kierunku
Z początku wykorzystałem serwo HS-82mg, jednak szybko okazało się, że jest za wolne i nie nadążało ze skręcaniem. Niestety powszechnie produkowane serwa nie są dużo szybsze, więc byłem zmuszony do przeróbek. Ponieważ moment mojego serwa był o wiele za duży, postanowiłem skrócić przekładnie. W efekcie uzyskałem bardzo szybkie serwo, ale niestety oryginalny układ sprzężenia zwrotnego nie poradził sobie z tą zmianą, musiałem zrobić własny. Atmega8 w wersji SMD i Si9986 (1Amperowy mostek H) stworzyła nowy sterownik serwa. Zaimplementowałem PID i przyspieszyłem uaktualnianie pozycji z oryginalnego 50Hz do 200Hz.
Główna płyta
Mikrokontroler odpowiedzialny za zbieranie informacji i rozdzielanie rozkazów to Atmega168. Odbiera ona rozkazy od mikrokontrolera obrazu i wysyła rozkazy odnośnie prędkości i kierunku. Atmega168 jest też odpowiedzialna za sterowanie silnikiem obrotu kamery i badania jej pozycji. Główny Algorytm to utrzymać linie w środku pola widzenia. Kołami sterować w kierunku linii. Osiągać maksymalną prędkość na prostej i zmniejszać ją proporcjonalnie do kąta skrętu, nie schodząc poniżej ustalonej granicy. W algorytmie występuje kilka wyjątków odnośnie zakrętów ostrych lub chwilowych utrat linii z zasięgu wzroku. Większość współczynników i parametrów jazdy można zmienić przez uart. Zapisane są one w EEPROMie Atmegi168. Takie jak zakresy skrętu, granice maksymalne i minimalne prędkości, współczynniki dohamowywania do zakrętów i inne. W sumie jest ich ok. 12 plus są jeszcze inne parametry zapisane na stałe w innych mikrokontrolerach. Dobranie wszystkich parametrów zabrało mi sporo czasu i myślę, że dalej jest pole do ulepszeń. Największym problemem są nieliniowe zależności pomiędzy prędkością, dohamowywaniem i wchodzeniem w zakręty i innymi. Jest po prostu tyle możliwości ustawień, że nie sposób tego czasami ogarnąć. Nawet gdybym zaczął wszystkie zależności starać się opisać w funkcje, to jest za dużo niewiadomych i mikrokontroler nie byłby wstanie tego przetworzyć. Trzeba by się odwoływać do czegoś o większych zdolnościach obliczeniowych.
Niektórzy mogą stwierdzić, że bez sensu wykorzystałem 4 mikrokontrolery, mogłem dać jeden o większej mocy obliczeniowej. Jak dla mnie napisanie krótkiego programu do każdego mikrokontrolera jest łatwiejsze i czas reakcji jest też krótszy. Odnośnie płytek: ja wiem, że to jest nie profesjonalne, ale trudno by było zaprojektować taką płytkę. Ponadto jestem wstanie w każdej chwili zmienić każde połączenie, co też często robiłem podczas testów, z czego wynika, że schemat nigdy nie powstał. Odnośnie programów - jeśli ktoś jest chętny, to mogę je udostępnić, choć nie są one bogate w komentarze i napisane w Assemblerze.
Link
Fajne!
Możesz mi wyjaśnić pojęcie styropes ?
dość ciekawa technika wykonywania prototypow, nie spotkałem się z czymś takim wcześniej. Trochę przeraża mnie wizja możliwych zwarć. Rozumiem, że pola lutownicze z płytki prototypowej będące na linii wyprowadzeń z mikrokontrolerów musiały być wydłubane? Wydaje mi się, że przy prototypowaniu wygodniejsze jest użycie płytek stykowych, odpada przelutowywanie drucików a przerobienie układu jest bajecznie proste i szybkie 
Niemniej jednak podziwiam za cierpliwość przy tworzeniu tych pajęczynek.