Jakiś czas temu zapowiadałem, że się pochwalę swoją konstrukcją, tak więc robię to
Teraz tylko zdjęcia, bo akurat dorwałem aparat cyfrowy.
Opis co, jak i dlaczego dołączę za kilka dni, dlatego raczej nie pytajcie na razie "a co to", "a po co" (no chyba ze chcecie sobie nabić statystyki ).
Wiem, czytać umiem, chciałem tylko zwrócić uwagę by umieścił najlepiej link nie w nowym temacie a już przez kogoś zapoczątkowanym. Będzie łatwiej porównać różne rozwiązania.
Opis będzie chyba w odcinkach, bo mało mam ostatnio czasu niestety...
Podstawa, czyli BASE Jak widać na zdjęciach, podstawa zrobiona jest z LEGO.
To zadziwiające, jak pasują do tych klocków pewne elementy!!! Do tej pory nie mogę wyjść z podziwu.
Jak widać, serwo typu HS-300 dało się prawie idealnie wpasować.
Również mniejsze serwa, jak HS-81 pasują bez przeróbek.
Ale już prawdziwy majstersztyk to fototranzystor 5mm pasujący do otworów w belkach - to mnie poprostu zabiło!
Oczywiście tak osadzony fototranzystor ma jeszcze bardziej zawężoną charakterystykę kierunkową - to jest minus, ale poza tym jest OK.
Napęd to dwa wspomniane wcześniej serwa po przeróbkach: amputowano elektronikę i przerobiono przekładnię na ciągły obrót.
Sterowanie różnicowe, jak w czołgu.
Zasilanie to dwie baterie 9V (niestety baterie, a nie akumulatory - te będą zapewne w kolejnym robocie).
Jedna bateria do elektroniki, druga do silników - oba obwody połączone masami..
Jako stabilizatory napięcia, użyłem L4940 firmy STMicroelectronics w podstawowej konfiguracji.
Wszystko mieści się w części zaznaczonej na jednym ze zdjęć.
Na wyższym piętrze znajdują się fototranzystory SFH300 firmy Infineon, w wersji pracującej w zakresie światła widzialnego.
Po jednym fototranzystorze na każdą stronę robota - w sumie 4 szt.
Podwozie pozwala na swobodne poruszanie się po płaskim terenie.
Pokonanie fug pomiędzy płytkami w przedpokoju jest czasami problemem, tak jak wjechanie na dywan.
Jest to w zasadzie kwestia kół - zastosowanie nieco większych i przede wszystkim trzeciego koła wleczonego jako punktu podparcia niwelowało te problemy.
Ostatecznie zdecydowałem się jednak na taką konstrukcję jak na zdjęciach.
Orientacyjny koszt całego robota to ~350 - 400zł (pomijam koszt klocków i "robocizny"), a konkretnie:
2x SHARP GP2D12
2x serwo HS-300BB
2x PIC16F877A + 1x PIC16F876A (akurat takie miałem, a AVR nie lubie )
L293D
reszta drobiazgów jak rezystory, kondensatory... sami wiecie
A schemat?... A zobaczymy
Opisu ciąg dalszy: MOBOT, bo to robot z modułów.
Od strony technicznej robot to moduły, które są połaczone ze sobą tylko kilkoma liniami:
1. Zasilanie (GND, +5V)
2. magistrala komunikacyjna (RS232C / RS485)
3. dodatkowe linie sterujące (globalny RESET)
Od strony logicznej robot to zestaw zachowań (konkretnie wykorzystano model subsumption)
Moduły zostały zaprojektowane na wzór klas z obiektowych języków programowania. Każdy ma pewien zbiór metod określających funkcjonalność oraz pól opisujących stan lub konfigurację.
Moim głównym celem było pokazanie jak korzystając z modułów o zestandaryzowanym API można składać roboty o cechach i zachowaniu zależnym od wykorzystanych komponentów.
Moduł BLIR (na wcześniejszych zdjeciach - ten na samym dole)
Z funkcjonalnego punktu widzenia są to dwa niezależne moduły - decyzyjny i sterujący silnikami (napędowy). Ponieważ moduły znajdują się fizycznie na tej samej płytce drukowanej, a od strony programowej są to zestawy funkcji wykonywanych przez ten sam mikrokontroler (PIC16F876A), proces komunikacji pomiędzy nimi ograniczono do zmiany wartości odpowiednich parametrów i wywoływania funkcji.
Sterowanie robotem opiera się na zachowaniach. Hierarchia tych zachowań jest niezwykle prosta i ma na celu głównie pokazanie łatwości, z jaką można modyfikować działanie robota poprzez wymianę modułów. Najprostszy robot składa się tylko z modułu BLIR, w którego części decyzyjnej zaszyte jest zachowanie jedź do przodu. Inne zachowania są realizowane przez inne moduły, które możemy do robota dodawać. Zadaniem modułu decyzyjnego jest okresowe odczytywanie wartości z aktualnie podłączonego modułu dodatkowego i wyznaczenia kierunku jazdy na podstawie poziomów zachowań tam realizowanych. Jeśli poziom wyzwalania zachowań dodatkowych jest wyższy od założonego, zachowania te mają pierwszeństwo przed zachowaniami realizowanymi w module decyzyjnym BLIR.
Moduł napędowy zamienia wartości wyliczane przez moduł decyzyjny na odpowiednie sygnały sterujące silnikami. Do wysterowania silników wykorzystano układ L293D. Jest to podwójny mostek typu H wraz z niezbędnymi diodami ograniczającymi. Sterowanie silnikami odbywa się za pomocą podwójnego generatora PWM zaszytego w mikrokontrolerze. Wartości dla generatora PWM są wyznaczane na podstawie prędkości obliczanej przez moduł decyzyjny. Sygnały odpowiedzialne za kierunek obrotu silników i podawane na odpowiednie wejścia układu L293D, wyznaczane są na podstawie kierunku jazdy obliczanej przez moduł decyzyjny.
Na rysunku jest model modułu, oraz schemat zachowań.
Opis jest mniej techniczny, niż byście pewnie chcieli W razie czego, proszę o pytania, ale inteligentne
Co mnie podkusiło?
Wszystko stanie sie jasne, jak zamieszczę resztę opisu Generalnie 1 Moduł = 1 uC
ale może być i tak, ze 1 uC = M Modułów,
a nawet 1 Moduł = N uC
Wszystko zalezy od funkcji, jaką spełnia moduł.
A modułem może być wszystko: np system stereowizji, który ma zaszyte zachowanie "follow the white rabbit" W tym przypadku jeden uC to za mało na taki moduł.
Wewnątrz modułu są prowadzone skompikowane obliczenia, a na wyjściu masz tylko komendę typu "skręć wolno w lewo"
Podstawową zasadą jest to, ze jak komponuje gotowego robota, nie interesuje mnie, ile jest uC w środku modułów i jak to działa, tylko jakie rozkazy moge do modułów przesłać i jakie dane z nich wyciągnąć.
W ten sposób, dobierając odpowiednią magistralę, która łączy moduły, otrzymuję prawie "dowolnie" skalowalny system.
Jest jeszcze jedna ciekawa właściwość, ale muszę znaleźć jeden rysunek, aby to zobrazować.
Jeśli chodzi o uC, które wykorzystałem, to takie akurat miałem. Po skompilowaniu programów wyszło, że z powodzeniem wystarczyły by mniejsze uC, bo nie wykorzystałem aż tyle zasobów, jakie daję te PIC'e.
Wszystkie programy były pisane w C, bez wstawek w ASM.
Pytanka:
- Co to są te czarne prostokąciki na pierwszym rysunku (mob-all.jpg)?
- Jak w praktyce sprawował się model logiczny? Robot sprawnie omijał przeszkody?
).
