Grupa NRG

2006-05-21 14:15

Grupa NRG Robotics została formalnie założona 30 listopada 2004 roku, kiedy to na stronach Gildii Nauki Popularnej ukazało się pierwsze ogłoszenie zachęcające do wzięcia w nim udziału. Trzy osoby tj. Grzegorz Musiał, Maciej Kubica i Bogdan Misiewicz postanowiły w ramach swojej pracy naukowej i ciekawego spędzania wolnego czasu stworzyć własnego robota. Maszynę, która będzie potrafiła się poruszać o własnych siłach. Postanowiono zainteresować przedsięwzięciem osoby spoza Akademii Górniczo-Hutniczej, a nawet szeroko rozumianego kręgu naukowego.

Z pomocą przyszedł Jacek "CD Jack" Gdaniec, redaktor naczelny portalu kulturalnego gildia.pl. Umożliwił on stworzenie forum poświęconego temu pomysłowi, a także zatwierdził umieszczanie newsów na podstronach Gildii Nauki Popularnej. W ten sposób w bardzo krótkim czasie zgłosiło się ok. 40 osób chętnych do współpracy. Starszych i młodszych, doświadczonych inżynierów i uczniów liceum, informatyków, elektroników, a także zwykłych podpatrywaczy, którzy zobaczyli w tym coś ciekawego, innego. Projekt zbudowania tak skomplikowanego w gruncie rzeczy mechanizmu przez internet jest pierwszym tego typu w Polsce, a kto wie czy nie na świecie.

Zgłoszeni mieli możliwość określenia swoich umiejętności i chęci współpracy, dokonano podziału na trzy grupy: elektroników, informatyków, mechaników. Wynika on stąd, iż robotyka jest jedną z nauk wykorzystujących większość najnowszych zdobyczy techniki i fizyki i wymaga porozumienia między specjalistami z różnych dziedzin. To też czyni ją niezwykle interesującą i dającą wiele satysfakcji.

Jedynym założeniem, które przyjęto na samym początku było to, że tworzyć będziemy robota mobilnego. Może kłóci się to z typową metodologią naukową, ale by można było wciągnąć sporą grupę ludzi nieobeznanych w temacie, zapewnić im możliwość rozrywki i samodzielnego myślenia, należało zacząć od podstaw. Cel, zastosowanie i sam wygląd powinien wynikać z dyskusji, a osoby zorientowane mają ostateczne prawo głosu - tak pracujemy na forum NRG.

Przyszło więc wybrać obiekt zainteresowań. Resoraki i sterowane konstrukcje z LEGO Mindstorms wydały się grupie mało ambitnymi. Z kolei zasymulowanie ruchu jednej z kończyn człowieka odpadł ze względu na koszt realizacji takiego pomysłu. Zostaliśmy zmuszeni przez nasze własne ograniczenia do wybrania wariantu jeżdżącego/kroczącego lub manipulatora złożonego z 2,3 ramion.

Realne możliwości, które można było wziąć pod uwagę:
- symulujemy ruch zwierzęcia,
- kołowy (2 lub 3 koła napędzane),
- kołowy deluxe (jakiś sześciokołowy łazik z regulowaną geometrią podwozia),
- napęd gąsienicowy,
- nietypowy sposób poruszania się, np. woda, pełzanie itp..

W trakcie rozmów padło wiele interesujących propozycji. Nie ograniczano się w sugestiach. I dobrze, świadczy to o niemałej wyobraźni uczestników. Niektórzy chcieli stworzyć coś na kształt prymitywnie aportującego psa. Odrzuciliśmy, ale tylko ze względu na brak fachowców, pomysł latającego autonomicznego wehikułu. Dalej można wspomnieć o robocie-kuli poruszającego dzięki zmianie położenia środka masy, a także grupie robotów współpracujących ze sobą. Wąż, konik polny, żaba? W końcu uznano, że najambitniejsze, przy uwzględnieniu możliwości ekonomicznych i doświadczenia, będzie zasymulowanie ruchu kraba, pająka albo skorpiona.

Finalnym efektem burzy mózgów stała się następująca koncepcja: stworzenie platformy z sześcioma nogami, dwóch prostopadłych do siebie obrotów na nogę. Na niej dowolny układ działający na otoczenie, nieprzekraczający 40 kilogramów minus masa robota. W wersji pierwszej, tworzonej przez nasz zespół, cały osprzęt to oświetlenie (podczerwień lub halogen) współgrające z kamerą. Cel: patrolowanie i obróbka obrazu. Kiedyś: zadania specjalne.

Ewolucja projektu

Projekt robota NRG-001 "Eihei" zaskakuje nas od samego początku. Clue maszyny -założona na wstępie całkowita masa (40kg) - przysparza kłopotów na każdym etapie prac. Uwidacznia się tu stara inżynierska zasada, mówiąca o tym, że wszystko może pójść źle, a nawet najprostsze kwestie mogą stać się bardzo trudnymi do rozwiązania. Jeżeli projektowanie czegoś miało trwać dwa dni, na pewno potrwa przynajmniej tydzień.

Reguła sprawdziła się już przy wstępnych obliczeniach, kiedy to przy obliczaniu mocy silników obracających nogę w kolanie otrzymaliśmy zawrotne wartości momentu sił utrzymującego mechanizm w zadanym położeniu. Okazało się, że robot musiałby się składać jedynie z napędów. Na nic innego po prostu nie starczyłoby już miejsca. Poza tym umieszczenie takich kolosów w stawie kolanowym oczywiście mijałoby się z celem i z nauką niewiele miałoby wspólnego. Należało diametralnie zmienić podejście do sprawy i szukać rozwiązania-sztuczki.

Po godzinach myślenia przyszedł w końcu dobry pomysł. Postanowiliśmy zmienić rodzaj obciążenia z momentu na siłę. W miejsce zwykłego silnika obracającego nogę wstawiliśmy aktuator liniowy, który to ze względu na specyficzną konstrukcję może wytwarzać znaczny ciąg. Napęd jest przy tym kompaktowy, pobiera niewiele prądu, a jego waga nieznaczna. Same plusy? O nie, teraz kilka słów przestrogi.

Pierwszy raz z pojęciem Polska Rzeczywistość Techniczna spotkaliśmy się właśnie podczas realizacji tego projektu. Niestety, bardzo często jest tak, że sprzedażą urządzeń technicznych zajmują się osoby wywodzące się z kierunków nie mających nic wspólnego z mechaniką, elektroniką, elektrotechniką itp. W związku z tym w kartach katalogowych nie sposób znaleźć najbardziej potrzebnych w konstruowaniu informacji. Nad mocą silnika góruje w nich klasa izolacji przewodów czy opis słowny: silny, niewielki, tani. Rysunki techniczne są często niezgodne z normami, a dane techniczno-geometryczne nieaktualne. Jeśli nie kupi się egzemplarza próbnego, szansa na prawidłowe podłączenie np. silnika do naszego układu są praktycznie zerowe. Sprawdziliśmy na własnej skórze.

Po otworzeniu paczki z aktuatorem wyszło na jaw, że wał z niego wychodzący ma możliwość kątowego odchylania się od osi, wymiary są niezgodne z wcześniej podanymi, a faktycznie rozwijanej siły nie da się określić (tylko doświadczalnie, co może spowodować awarię napędu). Trzeba więc było zastanowić się nad przeprojektowaniem układu. Z niejasnej karty katalogowej wyniknęła potrzeba konstrukcji stabilizatora wału, a także prowadnicy blokującej ruch obrotowy wału. Odnieśliśmy również niejasne wrażenie, że gdy zamówimy pozostałe silniki, każdy z nich będzie wymiarowo podobny, aczkolwiek trochę inny. I to trochę może wystarczyć, by słono dopłacić za przeróbki już wykonanych części, które mają za zadanie współgrać z napędem. Dość powiedzieć, że widzieliśmy też "rysunki techniczne", w których mamy do czynienia z dwoma rzutami niezgadzającymi się ze sobą.

Dlaczego o tym piszę? Chcę przestrzec osoby zaczynające swoją karierę w projektowaniu, głównie studentów i amatorów. Weźcie pod uwagę to, co napisałem wcześniej. Osoby tworzące strony internetowe z danymi i dokumentację niekoniecznie muszą się na tym znać. Do wszystkiego trzeba podchodzić z wyczuciem i dystansem. Najlepiej w ogóle nie wierzyć w pisemne zapewnienia i sprawdzić na własną rękę. Ale czy to jest wyjście? Raczej tylko dla bogatych. Skądinąd wiem, że nasze perypetie z firmami nie są wyjątkiem, a raczej regułą.

Dość jednak narzekań i dociekań. Nie o to w inżynierii chodzi, trzeba efektywnie rozwiązywać problemy.

Samochód zaczyna się projektować od opon. W naszym przypadku należało stworzyć nogę, czyli moduł do podnoszenia i opuszczania robota. Stabilizator, prowadnica, końcówka obrotowa z wyłącznikiem krańcowym. Następnie przyszła kolej na kolej na moduł obracający kończynę. I tu po raz kolejny dał o sobie znać ciężar maszyny. Nie można było pozwolić na jakiekolwiek obciążenie silnika odchylającego. Z warunków równowagi wynikało, że jego wał musiałby przenieść ogromny moment zginający (30Nm) oraz siłę osiową równą 200N. Taka sytuacja nie była oczywiście dopuszczalna. Problem okazał się naprawdę skomplikowany, bardzo ograniczały nas wymiary, masa zespołu, a także specyfika konstrukcji i brak dobrego rozwiązania. Narady z fachowcami i kadrą uczącą nas konstruowania maszyn trwały dobry miesiąc. Rozwiązanie, jak to zwykle bywa w takich przypadkach przyszło znikąd i nagle. Specjalne sprzęgło, trochę mocnego kleju, platformowa konstrukcja, kilka modułów odchylających. Pomysł okazał się na tyle dobry, że osiągnęliśmy stosunek masy robota do całości mniejszy niż 1/2!

Na końcu zajęliśmy się odpowiednim zamontowaniu modułów obracających na jednej płycie korpusu (dawniej planowaliśmy dwie) oraz skonstruowaniu odpowiednio mocnego łącznika noga-korpus. Tu poszło już stosunkowo łatwo. Efekty udało nam się zwizualizować w programie inżynierskim 3D, a są one moim zdaniem piorunujące. Zwłaszcza dla nas, którzy w maszynie znają każdą śrubkę i znaczenie wszystkich części, wymiarów i tolerancji.

Słowem zakończenia, kiedyś na pokazie robotów, który organizowałem razem z moim przyjacielem pisarzem, będącym częścią promocji jego najnowszej książki dla dzieci, jedna z pociech zapytała się mnie bardzo prosto i ciekawie: "A czy takie roboty trzeba też robić w nocy?" Nie wiedziałem, co odpowiedzieć, ale teraz już wiem. Stworzenie takiego kolosa, to kawał dobrej, acz wyczerpującej roboty (psychicznie i fizycznie). Dostarcza niemałej satysfakcji i choć w naszym przypadku to jeszcze nie koniec, już teraz dziękuję wszystkim, którzy przyczynili się do rozwoju projektu NRG.

Zapraszamy na nasze strony internetowe, gdzie znajdziecie dokumentację i trójwymiarową wizualizację robota NRG-001 "Eihei".

P.S. Eihei -z jap. strażnik pałacowy.

Grzegorz "Greg K1ler" Musiał, pomysłodawca projektu

Elektronika - NRG Robotics

Tworzenie elektroniki do robota to skomplikowane zadanie. Szczególnie, jeśli jego ostateczna forma zmienia się z dnia na dzień. W początkowej fazie projektu założenia dotyczące tego działu NRG Robotics były bardzo ogólne. Zakładaliśmy wykorzystanie mocnej jednostki DSP jako głównego CPU, aby zapewnić maszynie pełną możliwość rozbudowy. W grę wchodziła analiza obrazu z kamery prowadzona w czasie rzeczywistym (z tej części pozostała tylko funkcja akwizycji obrazu). Myśleliśmy o skomplikowanej sieci czujników będących "oczami" naszego robota. Przez moment zastanawialiśmy się nawet, czy nie wyposażyć go w magistralę PCI i nie zintegrować z kieszonkową wersją komputera PC. Wraz z upływem czasu i postępem w pracy nad kształtowaniem ostatecznego wyglądu całości trzeba było podjąć ważkie decyzje. Gdy pojawiła się koncepcja robota sześcionożnego, zaczęliśmy wstępne prace.

1.Założenia

System ma być hierarchiczny:
- procesor główny (DSP) koordynujący algorytmy poruszania się i wszelkie procesy decyzyjne,
- układ podprocesorów (słabsze mikrokontrolery Atmela lub Motoroli) - prawdopodobnie jeden na całą nogę (docelowo 6) - każdy sterujący dwoma serwonapędami.

Mikrokontrolery Atmela posiadały istotną zaletę. Jeszcze blisko rok temu planowaliśmy rozwiązanie sterowania za pomocą serwonapędów. Wbudowany w te jednostki sterownik PWM (Puls Width Modulation - modulacja szerokości impulsu) pozwalał na dość proste rozwiązanie problemu pozycjonowania silników. Napędy, którymi się interesowaliśmy posiadały też wbudowane enkodery, co rozwiązywałoby problem sterowania w układzie zamkniętym.

Początkowo zastanawialiśmy się, czy tak podstawowy układ jak ATMega8 ma wystarczającą moc obliczeniową by sprostać naszym wymaganiom. Testy szybko jednak rozwiały nasze wątpliwości.

2. Pierwsze koncepcje

Gdy wstępnie dobraliśmy elementy sterujące, należało się zastanowić nad schematem całego układu. Konieczne było zastosowanie jednej ze standardowych magistral przemysłowych. Myślę, że nie muszę tłumaczyć, dlaczego. Uwagę skupialiśmy głównie na RS-232 i RS-485, ale padły też propozycje zastosowania CAN-a albo ISA. RS był nam dobrze znany, CAN byłby zgodny z najnowszymi trendami w robotyce i automatyce, a ISA dałaby łatwość w podłączeniu do PC. Co z tego wynikło? Wybraliśmy I2C. Standard przyjazny, stosunkowo prosty w obsłudze i niekłopotliwy elektrycznie. Możliwość obsługi dużej ilości masterów/slave'ów, wystarczająca przepustowość i wbudowana w ATMegę obsługa sprzętowa. Czego chcieć więcej?

Oto jak wyglądała pierwsza koncepcja elektroniki:

[rys.1]

Myślę, że nie wymaga dodatkowego komentarza. Uwagę może zwracać dość ogólne wyrażenie "układ mocy". Pod tą tajemniczą nazwą kryć się miał zaproponowany i wykonany przez nas sterownik korzystający z mostka H. W tym momencie podjęliśmy wysiłki właśnie w tym kierunku. Po blisko dwóch tygodniach intensywnej pracy pojawiły się pierwsze wątpliwości. Mechanicy zaczęli coś mówić o silnikach krokowych. Kolejne projekty sterownika okazywały się nieefektywne energetycznie lub zbyt skomplikowane. Po części musimy przyznać, że energoelektronika nie była i nie jest naszą pasją. Prace nad tym elementem zostały zawieszone. Jak się okazało, już na dobre.

Zaczęliśmy rozważać inne napędy. Hydraulika i pneumatyka wydawały się idealne do tego zadania. Niestety koszty całego przedsięwzięcia w przy takim rozwiązaniu stałyby się właściwie nierealne. Trzeba było zejść na ziemię. Przełomem okazała się decyzja o zastosowaniu silników krokowych. Właściwie same zalety:

- Pewność pozycjonowania - w znamionowych warunkach pracy
- Wysoka rozdzielczość - 1.8st na krok
- Małe wymiary oraz niewielka masa
- Odpowiedni stosunek pobieranej mocy do wyjściowego momentu
- Łatwość sterowania i duża dostępność
- Oszczędność finansowa!

3. Czas na decyzję!

Czas uciekał, trzeba było powoli zamykać część projektową. Po dość długich naradach i rozważeniu wszystkich "za" i "przeciw" zdecydowaliśmy, że nie będziemy sami tworzyć sterowników. W ofercie jednej z firm na polskim rynku znaleźliśmy sprzęt, który dokładnie odpowiadał naszym potrzebom. Bipolarne sterowniki silników krokowych w całej gamie obsługiwanych prądów. Wstępne założenia co do elektroniki były gotowe. Wiedzieliśmy, czym sterujemy i jak. Dobór konkretnych modeli był nieistotny. Idea sterowania nie zmieniała się. Finalny efekt naszej pracy przedstawiał się następująco:

[rys.2]


Sygnały CLK - zegarowy, EN -enable - sygnał zezwolenia i DIR - direction -kierunek ruchu to cyfrowe sygnały podawane na sterownik (SMC61/63).

Jednostka DSP to bardzo wydajny procesor firmy Texas Instruments umieszczony na płytce starter kit'a DSK6713. Sprzęt o ogromnych możliwościach, posiadający bogate wyposażenie peryferyjne. Dodatkowo łatwy dostęp do niego pomógł nam w podjęciu tej decyzji.

Jak widać, zrezygnowaliśmy z enkoderów. Przyczyn jest wiele, główna z nich to aspekt finansowy. Zwiększenie kosztów o blisko połowę nie wchodziło w grę. Dlaczego zdecydowaliśmy się na sterowanie w układzie otwartym? Zastosowanie enkoderów zwiększałoby masę nogi, co pociągnęłoby za sobą konieczność zwiększenia mocy silników odpowiadających za ruch postępowy. Dodatkowo, silniki krokowe w odpowiednich warunkach zapewniają pewność pozycjonowania. Aktuator udało się finalnie wyposażyć w krańcówkę, która będzie wykrywała dotknięcie stopy do podłoża. Czy to wystarczy? Wszystko okaże się w testach.


4. Płytka mikrokontrolera.

Kolejny etap to już praktyka. Wykonanie fizycznego egzemplarza płytki drukowanej dla układu ATMegi. Nie chcę was zanudzać szczegółami, przedstawiać kolejnych wersji i usprawnień. Dość powiedzieć, że finalny produkt naszych starań na dzień dzisiejszy przedstawia się następująco:

- Układem steruje mikrokontroler firmy Atmel Atmega8L TQFP32 - wersja energooszczędna, obudowa tiny quad flat package, 32 piny.

- Układ zasilany jest z zewnątrz napięciem 5V, ścieżki zasilania (VCC) i GND, (czyli masa) muszą być grubsze, gdyż płyną nimi dużo wyższe prądy niż przez zwykłe ścieżki sygnałowe.

- Kontroler dla wykorzystania wszystkich pinów wymaga podwójnego zasilania - analogowego i cyfrowego. Oba z nich zostały połączone i zasilone z jednego źródła. Niestety AVCC (analog) wymaga lepszej stabilności, stąd widoczny na rysunku dławik (cewka z zaledwie jednym zwojem - indukcyjność rzędu mikrohenrów), która "wygładza" ewentualne wahania napięcia.

- Wtyczka magistrali I2C - linie SDA i SCL, VCC i masa. Dodatkowo dwa rezystory pull-up wymagane w standardzie I2C.

- Wtyczki D_AKT i D_KROK - sygnały wyjściowe dekoderów obu silników i GND - elementy do zmiany

- Wtyczka interfejsu SPI, który posłużył nam do zaprogramowania całego układu (również określona w standardzie).

- Wtyczki SMC61 i SMC63 - wyjścia cyfrowych sygnałów sterujących driverami obu silników DIR - kierunek, EN -zezwolenie pracy (Enable), CLK -wyjście zegarowe, GND - masa.

- Oscylator i kondensatory C1 i C2 - układ zewnętrznego oscylatora (14Mhz).

- Wtyczka EXT - wyprowadzenie pinów odpowiedzialnych za przerwania zewnętrzne dla kontrolera i masa, dodatkowo PD4 - wolny pin kontrolera wyprowadzony dla możliwości debugowania.

- Kondensatory C3, C4, C5 - umieszczone pomiędzy linią zasilania (VCC/AVCC) i masy (GND) - pozwalają one na uniknięcie zakłóceń, które z pewnością mogłyby być sporym problemem w tym układzie.

- Przycisk S1, rezystor R1 - układ resetu całego układu mikrokontrolera.

- Rezystory R2, R3 - rezystory podciągające (pull-up) linie magistrali i2c do stanu wysokiego (+5V) - wymóg standardu.

- Rezystory R4-R7 - rezystory podciągające (pull-up) linie wyjść cyfrowych dla sterowników do stanu wysokiego (+5V) - zastosowane dla uniknięcia stanów nieokreślonych na wyjściu układu.

- PWR - dioda sygnalizująca obecność zasilania

- D1, D2 - diody kontrolne, służące do debugowania.

- Dławik - dławik o małej indukcyjności rzędu mikrohenrów filtrujący napięcie zasilania części analogowej.

Wykaz komponentów płytki:


IC1 Mikrokontroler Atmega8L TQFP32

Oscylator Oscylator kwarcowy 14 Mhz

C1 Kondensator ceramiczny 22 pF
C2 Kondensator ceramiczny 22 pF
C3 Kondensator ceramiczny 100 pF
C4 Kondensator elektrolityczny 100 pF
C5 Kondensator elektrolityczny 100 pF

R1 Rezystor SMD 10kOm
R2 Rezystor SMD 10kOm
R3 Rezystor SMD 10kOm
R4 Rezystor SMD 10kOm
R5 Rezystor SMD 10kOm
R6 Rezystor SMD 10kOm
R7 Rezystor SMD 10kOm

D1 Dioda SMD
D2 Dioda SMD
PWR Dioda SMD

Dławik Dławik

S1 Przycisk Reset Omron B3F-1020

D_AKT [nazwa do zmiany] goldpin 1 X 03
D_KROK [nazwa do zmiany] goldpin 1 X 03
EXT Przerwania zewnętrzne + debug goldpin 1 X 04
I2C Magistrala i2c (we/wy) goldpin 2 X 04
POWER Zasilanie goldpin 1 X 02
SMC61 Sygnały do sterownika SMC61 goldpin 1 X 04
SMC63 Sygnały do sterownika SMC63 goldpin 1 X 04
SPI Wejscie do programowania uC goldpin 1 X 08


Autor: Maciej "Misha" Kubica

Źródło: http://www.nrgrobotics.gildia.pl