Autor: Dondu
Artykuł jest częścią cyklu: Robotyka - Teoria oraz kurs budowy robotów.
Ponieważ projekt dopiero rusza (2013.08.12), to wszyscy czytelnicy mają wpływ na jego efekt końcowy. Dlatego zachęcam do pisania uwag i zadawania pytań w poszczególnych artykułach.
Konstrukcja mechaniczna
Założenia nasze nie będą dotyczyć części mechanicznej, której rozwiązanie pozostawiam Waszej inwencji.
Założenia nadrzędne
- cel stricte edukacyjny,
- minimalizowanie ilości elementów zewnętrznych,
- minimalizowanie poboru energii,
- minimalizowanie kosztów,
- konstrukcja modułowa w celu łatwiejszej modyfikacji,
- wykonanie części mechanicznej z elementów dostępnych "w szufladach" lub gotowych podwoziach lub z kupionych elementów jeśli ktoś woli :-)
Założenia dot. elektroniki
- konstrukcja oparta o mikrokontroler ATmega8 (patrz wyjaśnienie w dalszej części artykułu),
- projekty płytek PCB dla metody "żelazkowej",
- ... czekam na dalsze propozycje.
Założenia dot. programu
- nie stosowanie funkcji opóźnień programowych i pętli oczekujących,
- stosowanie programowych regulatorów prędkości robota oraz wykrywania i reagowania na przesuwającą się linię,
- używanie wskaźników i struktur,
- opracowanie bibliotek poszczególnych funkcjonalności,
- ... czekam na dalsze propozycje.
Funkcjonalności robota
- podążanie za linią z możliwie największą prędkością,
- odszukanie linii po wypadnięciu z trasy,
- zapisywanie w czasie jazdy parametrów (prędkość, nastawy silników, stan czujników, itp) do pamięci, w celu ich późniejszej analizy,
- określanie kierunku i prędkości obrotu kół,
- dostosowywanie poziomu oświetlenia czujników linii do jakości podłoża,
- autokalibracja czujników linii,
- reagowanie na komendy wydawane pilotem podczerwieni RC-5,
- kontrola źródła zasilania,
- zapamiętywanie trasy w celu dokonania szybszego drugiego przejazdu (w miarę wolnej pamięci lub jako osobny temat),
- ... czekam na dalsze propozycje.
Funkcjonalności analizy zebranych danych
Funkcjonalności te dotyczą narzędzi, które pomogą nam analizować pozyskane wyniki pomiarów w celu modyfikacji algorytmów zachowań robota. W tym zakresie należy opracować:
- format zapisu danych do pamięci,
- funkcjonalności bloga (niniejszej strony) w zakresie automatyzacji generowania tabel i wykresów na podstawie przesłanych danych.
Dodatkowe urządzenia pomiarowe
W celu testowania i maksymalizowania osiągów, w ramach niniejszego cyklu wykonamy w dalszej kolejności:
- hamownię silników,
- bramki pomiaru czasu przejazdu,
- własny pilot podczerwieni RC-5 (o ile będzie takie zapotrzebowanie),
- ... czekam na dalsze propozycje.
Dlaczego ATmega8?
Uprzedzając ewentualne pytania wyjaśniam, że ATmega8 to świadomy i celowy wybór ze względu na to, iż ten mikrokontroler stosujemy w przypadku artykułów dla początkujących. Dlatego też naturalnym jest iż pierwszy robot, będzie oparty o ten właśnie mikrokontroler.
Drugim powodem i celem jest pokazanie, jak w przypadku ograniczonych możliwości sprzętowych (tego mikrokontrolera) kombinować w celu osiągnięcia założonych celów.
Kolejne roboty na XMega
Drugim robotem prezentowanym w tym cyklu artykułów będzie RoDonXM, czyli konstrukcja oparta o znacznie bardziej zaawansowany mikrokontroler, którym będzie jeden z rodziny XMega. W tym robocie położymy szczególnie nacisk na zwiększanie osiągów pokazując jednocześnie kierunki i możliwości modyfikacji.
Jeżeli cykl dot. robotów będzie się cieszył dużym zainteresowaniem, to zajmiemy się kolejnymi, nie tylko linefollower-ami.
Propozycje i pytania
Jeżeli masz propozycje lub uwagi dot. założeń to zapraszam do dyskusji w komentarzach do niniejszego artykułu.
No wreszcie! Mnie najbardziej interesować będzie hamownia, aczkolwiek algorytmy także.
OdpowiedzUsuńCałkiem sporo tych funkcjonalności jak na Mega8. Ciekawi mnie ile zostanie pinów na czujniki linii. Wiadomo, że nie powinno ich być mniej niż 5.
OdpowiedzUsuńNie wspomniałeś nic o źródle zasilania. To także traktujesz jak część mechaniczną?
Wstępne zestawienie funkcjonalności i wykorzystanych pinów jest przygotowane. Jednak zanim je zaprezentuję, poczekam na Wasze uwagi dot. funkcjonalności.
UsuńFaktycznie pominąłem źródło zasilania (wybór akumulatora) i traktuję go jak część mechaniczną - każdy dobierze to, co ma pod ręką.
Bardzo ważnym elementem jest też dostępność elementów, głownie czujników itp. Natomiast wybór Atmegi8 jest jak najbardziej trafny, można ją kupić już za 5 Pln a w wersji SMD za 3,5 PLN :) Bo wiadomo każdy(albo większość) początkujący ma okrojony budżet ;)
OdpowiedzUsuńO budżet pytałem pod koniec maja, stąd znam możliwości czytelników - kto nie udzielił odpowiedzi, może jeszcze to zrobić. Koszty były jednym z kilku argumentów, by pierwszy robot powstał jako możliwie najtańszy i dlatego jest to jedno z założeń nadrzędnych.
UsuńCo do czujników, to w artykule ich dotyczącym jak zwykle weźmiemy pod uwagę ich parametry z datasheet, by czytelnik sam mógł dokonać wyboru w przypadku braku w sklepach tych, które ja zastosuję.
Za wiele to na ATmega8 nie zrobisz, a przy tych założeniach, to nawet braknie pinów. Będziesz musiał jakieś kombinacje robić. Pamięci też za wiele nie ma, więc algorytm skomplikowany nie będzie. No ale rozumiem założenie, że XMega będzie następnym krokiem. Szczerze mówić bardzo jestem ciekaw co z ATmega8 wyciągniesz :P
OdpowiedzUsuńTe jak to piszesz "kombinacje" są celowe, by pokazać, że do każdego problemu można podchodzić na różne sposoby :)
UsuńSkoro robot ma zapamiętywać parametry trasy to może w funkcjonalności dodałbym poszukiwanie trasy po wypadnięciu z toru.
OdpowiedzUsuńWitam!
OdpowiedzUsuńJuż nie mogłem się doczekać, ale widzę, że chyba warto było. Piszesz o zapamiętywaniu parametrów w czasie jazdy. Czy masz na myśli kształt trasy, czy parametry typu prędkość, stan czujników, itp.
Pozdrawia Arek.
Odpowiadając na oba posty powyżej wyjaśniam, że pisząc o zapamiętywaniu parametrów mam na myśli parametry takie jak wspomniał Arek, czyli prędkości kół, stan czujników, podejmowane decyzje, itp. w miarę możliwości jak najwięcej, po to by później był materiał do analizy.
OdpowiedzUsuńCo do zapamiętywania trasy i ewentualnego szybszego drugiego przejazdu, to o ile będzie to możliwe równolegle do zapamiętywania podstawowych parametrów, oczywiście zrealizujemy. Jeżeli nie, to zrealizujemy to jako osobny temat. Dopiszę więc do listy powyżej.
Algorytm poszukiwania linii po wypadnięciu z trasy, jest na tyle oczywisty, że zapomniałem go dopisać. Naprawię zaraz ten błąd :)
Jeżeli dobrze rozumiem, nie przewidujesz w robocie żadnych przycisków?
OdpowiedzUsuńZgadza się, przyciski zostaną zastąpione pilotem RC-5, dlatego też ostatnio ten standard opisałem.
UsuńMoim zdaniem nie ma na co czekać. Ująłeś chyba wszystko co powinien mieć nieskomplikowany linefollower. Czekamy na dalsze artykuły.
OdpowiedzUsuńZ zapamiętywaniem kształtu trasy będzie problem, bo wystarczy że robot wpadnie w poślizg i pomiar jest niedokładny. Do tego jeszcze dochodzi możliwość poślizgu podczas wykonywania zapisanej trasy. O ile z poślizgiem przy zapisywaniu można sobie poradzić np. linią w paski, to z poślizgiem przy wykonywaniu będzie gorzej. Co do robienia linefollowera na XMega to totalna głupota i przerost formy nad treścią, idąc tym tokiem rozumowania to może lepiej od razu przykręcić kółka do PC i z niego zrobić linefollowera. Szkoda też że kosztem robota zrezygnowano z ciekawszego moim zdaniem SmartPIPa i sterowania silnikami BLDC.
OdpowiedzUsuńMasz rację, zapamiętywanie trasy, to tylko w teorii sprawa prosta. Ten temat będzie liźnięty w RoDonM8, a rozwinięty jako jeden z ostatnich w robocie z XMega, w którym będzie akcelerometr i żyroskop.
UsuńNie uważam, żeby XMega była zbyt silna dla robota, a do PC'ta jest jej daleko. Poza tym, celem użycia XMega jest także pokazanie praktycznych przykładów na ten mikrokontroler oraz jego możliwości.
Co do SmartPIP'a i BLDC, to dokończę je po skończeniu RoDonM8, a przed rozpoczęciem RoDoXM. Niestety zainteresowanie SmartPIP'em i BLDC nie było zbyt duże.
A na koniec serdeczna prośba, byś niepotrzebnych epitetów i przymiotników nie stosował do określania swojego zdania. Staramy się trzymać odpowiedni poziom, a Twój post jest blisko krawędzi którą sobie wyznaczyliśmy.
Odnośnie ATmegi8, proponowałbym zastosowanie megi16 (cenowo w wersji smd to różnica rzędu 1zł a daje nam większe możliwości pamięci RAM :) ) Skoro mowa o rejestracji trasy i konkretnych parametrów/osiągów to wypadało by to zapisywać na pamięci nieulotnej więc w celu minimalizacji kosztów karta SD wydawałaby się najrozsądniejszym rozwiązaniem (można by zastosować fat16/32 albo dopisać protokół transmisji po RS232 aby te dane wyciągać bezpośrednio z sektorów z pominięciem struktury plików)
OdpowiedzUsuńW artykule dokładnie wyjaśniłem dlaczego zastosujemy ATmega8. Karty SD nie będzie także z innych względów - spory pobór prądu. O tym już w najbliższym artykule.
UsuńPytanie z innej beczki:
OdpowiedzUsuńCzy ten robot już jest wykonany, czy będzie tworzony "na gorąco" podczas pisania artykułu?
Tworzony wraz z każdym artykułem. Taki jest cel tego cyklu, w którym będę krok po kroku pokazywał jak zmienia się konstrukcja od strony elektronicznej i programowej w trakcie tworzenia robota rozpoczynając od w miarę prostego, dokładając mu kolejne funkcjonalności.
UsuńAktualnie powstaje PCB modułu głównego (CPU, SRAM + odbiornik RC-5). W stosunku do powyższych założeń, już nastąpią pewne zmiany, które opiszę. I tu wracam do tego o co pytałeś i celu tego cyklu.
Zdradzę niespodziankę, że Tomek Francuz równolegle będzie przedstawiał rozwiązanie na XMegaE5 (RoDonXM) pokazując, jak to samo i więcej można osiągnąć na tej rodzinie. Jego artykuły będą zawsze nieco opóźnione do tych o RoDonM8.
Fajny pomysł z równoległym tworzeniem jak rozumiem odpowiednika na XMega, tylko pewnie to spowolni cały cykl. Chociaż z drugiej strony skoro pisać będzie dwóch autorów, to nie powinno to wpłynąć na terminy?
UsuńNiestety jednak lekkie opóźnienie będzie, ponieważ podczas redagowania i publikacji nie wszystko jeszcze jest zautomatyzowane, stąd nieco mojego czasu wymaga proces redagowania i publikacji każdego artykułu innego autora. Ale oczywiście czas ten jest znaczne krótszy, niż czas potrzebny na tworzenie artykułu.
Usuń