HekSiipod – czy łatwo zbudować robota?

Rozwijasz kompetencje techniczne w ramach własnych projektów i chcesz mieć z tego rozrywkę? Zrealizuj projekt z zakresu robotyki, a uzyskasz efekt „wow” już na starcie. Choć zagłębienie się w tę dziedzinę na pierwszy rzut oka może wydawać się kosmicznie trudne, na pewno jest ekscytujące i warte uwagi.

Wiedza i umiejętności z różnych zakamarków inżynierii będą Twoimi sprzymierzeńcami – musisz tylko odpowiednio je wykorzystać. Ważne jest także rozbicie problemu na mniejsze, łatwiejsze do zarządzania elementy. Dzięki temu przestaną one być przerażające i powoli – od zadania do zadania – osiągniesz sukces.

W tym artykule pokażemy Ci, jak my realizujemy się w ramach wewnętrznego projektu robota pająka.

Cztery nogi czy sześć?

Projekt HekSiipod realizowany jest w lubelskim oddziale Sii przez pracowników Embedded Competency Center. Sama idea, jaka nam przyświecała, to spędzenie wolnego czasu w ciekawy sposób, ale też integracja członków zespołu. Pomysłów na wykonanie „czegoś” było kilka, jednak finalnie zdecydowaliśmy się właśnie na robotyczną wersję „pająka”.

W sieci możemy natknąć się na wszelakie konstrukcje, którym towarzyszyło zróżnicowane podejście zarówno do kinematyki urządzenia jak i oprogramowania. Najbardziej pospolitym rozwiązaniem jest zastosowanie czterech bądź sześciu nóg symetrycznie rozłożonych dookoła ciała.

Oba podejścia wiążą się oczywiście z pewnymi konsekwencjami. O ile wersja sześcionożna (hexapod) kinematycznie jest stabilniejsza, to na pewno generuje większe koszty budowy. Z drugiej strony opcja czterech nóg (quadropod) kusi mniejszą liczbą serw, ale wymaga większego nakładu pracy na algorytmikę. Każde uniesienie kończyny wiąże się z przesunięciem środka ciężkości robota pomiędzy pozostałe trzy punkty podparcia.

My w swojej konstrukcji skupiliśmy się na wersji drugiej i ją omówimy w dalszej części tekstu.

Projektowanie robota

Czy to w wersji heksapod, czy quadropod, urządzenie z poprawnym oprogramowaniem potrafi nacieszyć oko oraz wywołać zadumę nad kunsztem obecnej technologii. Najprostsze wersje robota mają po trzy serwomechanizmy na nogę, co w szybkim przeliczeniu daje nam 12 bądź 18 mechanizmów do kontroli oraz synchronizacji (nie wspominając już o dodatkowych czujnikach takich jak akcelerometr, żyroskop czy chociażby kontrola sekcji zasilania).

Pozornie wydawać by się mogło, że zaprojektowanie działającego pająka jest zadaniem nie do wykonania. Cała zabawa jednak zaczyna się, gdy zaczniemy analizować problem pod różnymi kątami, m.in.:

• Jak sterować serwomechanizmem?
• Jak zsynchronizować/uzależnić 3 serwa w jednej nodze?
• Jak zarządzać nogami – w jakiej kolejności je podnosić?
• Co z balansem całej konstrukcji?

Celem dzielenia projektu na wspomniane etapy jest skupienie się tylko na jednym problemie w danej chwili oraz zamknięcie rozwiązania konkretnego problemu w postaci jednej prostej funkcjonalności. Taki moduł możemy wykorzystać w kolejnym kroku jako tzw. „black box”, który nieważne jak działa – ważne, że działa. Kolejna warstwa aplikacji zbierze razem kilka małych „skrzyneczek”, tworząc następnie moduł wyższego poziomu, służący jako półfabrykat systemu gdzieś wyżej. Pozwala nam to skupić się wyłącznie na małym elemencie układanki, a nie na całym systemie naraz.

Podział architektury na moduły na przykładzie StaSii

Tak naprawdę nie ma jednego słusznego podziału architektury na moduły. W takiej sytuacji każdy projektant na pewno miałby swoje podejście i własną koncepcję. Oczywiście – nie ma w tym nic złego. Jedyne, o czym musimy pamiętać to fakt, żeby każdy taki mały „klocek” posiadał funkcjonalność unikalną dla samego siebie oraz aby nie wchodził w kompetencje swoich „kolegów”. Dla lepszego zobrazowania sytuacji zobaczmy, jak to wygląda w naszym przypadku.

Pozycja serwomechanizmu

Zacznijmy od najniższego poziomu. Podstawowym elementem wykonawczym używanym do takich konstrukcji są serwomechanizmy modelarskie. Te najprostsze do kontroli pozycji orczyka wykorzystują sygnał PWM.

W prostym tłumaczeniu szerokość impulsu (współczynnik wypełnienia) jest wprost proporcjonalna do oczekiwanej pozycji osi serwa lub, innymi słowy, kąta obrotu. Większość popularnych obecnie mikrokontrolerów ma odpowiednie peryferia do generowania takiego sygnału i tak naprawdę sterowanie pozycją serwomechanizmu sprowadza się do zmiany wartości odpowiedniego rejestru. Wartość XX będzie odpowiadać pozycji 0st, YY to 180st itp.

Konkretne liczby będą uzależnione od wielu czynników takich jak:

• częstotliwość taktowania układu,
• zastosowany mikrokontroler,
• model serwa.

Te wartości można wyznaczyć empirycznie, jednak niestety będą one mało czytelne i trudne do użycia w dalszej części kodu. Rozwiązaniem jest napisanie prostego sterownika, do którego będziemy podawali żądaną wartość kąta, a on zrobi już resztę. Jeżeli wiemy, że wartość naszego rejestru to XX dla 0st, a YY dla 180st, to przy liniowej charakterystyce dla wartość np. 46st wartość naszego rejestru powinna wynosić coś pomiędzy XX a YY. Dokładną wartość można łatwo wyliczyć z równania funkcji liniowej bądź proporcji, jednak na potrzeby tego artykułu, pomińmy te wzory.

Gdy uda nam się już przeliczyć kąt, to w razie potrzeby zmiany pozycji serwa będziemy mogli używać wartości podanej w stopniach, czyli w jednostkach układu SI.

Uczenie sterowania nogą

Kolejnym krokiem w realizacji projektu jest nauczenie się sterowania jedną nogą. W naszym przypadku założyliśmy, że na tym etapie będziemy kontrolować wirtualny punkt umiejscowiony na styku odnóża z podłożem. W tym miejscu chcemy zapomnieć o serwach i kątach, a podawać od razu współrzędne tego punktu w postaci koordynat (x,y,z). Układ współrzędnych niech umieszczony będzie w miejscu zamontowania nogi do całej konstrukcji. Płaszczyzna XY będzie równoległa do podłoża, oś Z skierowana ku górze, a X wskazuje kierunek „do przodu”.

Konstrukcyjnie taka noga składa się z trzech połączonych ze sobą serw. O ile w pierwszym kroku zależało nam na konwersji kąta obrotu na dane wypełnienie sygnału PWM, tak na tym etapie podajemy już punkt przestrzenny w przyjętym układzie odniesienia, oczekując trzech wartości kątów dla naszych serwomechanizmów.

Tylko jak się do tego zabrać? Z pomocą przychodzi nam kinematyka odwrotna. Rozpisanie tego etapu na czynniki pierwsze i poszczególne wzory pozwolimy sobie zostawić na oddzielny artykuł, gdyż dziedzina sama w sobie jest bardzo ciekawa. Na potrzeby obecnego teksu wystarczy streszczenie, że po zebraniu pewnych pomiarów konstrukcji (długości poszczególnych członów kończyny), zastosowaniu twierdzenia cosinusów i szczypty trygonometrii, wyliczenie kątów dla naszych przegubów nie jest problemem.

Operowanie punktami w przestrzeni

Ostatnim etapem jest operowanie punktami w przestrzeni. Podniesienie jednej nogi do góry to nic innego, jak zmiana współrzędnej „z”. A jak podnieść całe ciało? Zmieniamy koordynaty „z” dla wszystkich nóg. Pozostaje nam sama zabawa z mechaniką ruchów. Co zrobić z robotem podczas kroku? Jak utrzymać równowagę, balansując środkiem ciężkości? Można powiedzieć, że otworzyliśmy sobie drzwi do jednego z najciekawszych obszarów, zapominając jednocześnie o detalach konstrukcyjnych.

Pozornie skomplikowane zagadnienie, jakim jest synchronizacja wszystkich mechanizmów, staje o wiele prostsze, gdy odpowiednio opiszemy problem i rozłożymy go na czynniki pierwsze. Jest to szczególnie istotne przy modyfikacjach projektu.

Wyobraźcie sobie sytuację, gdy po wielu testach dochodzimy do wniosku, że ograniczeniem są zastosowane serwomechanizmy. Po przeszukaniu rynku znajdujemy nasz „Święty Gral”, czyli serwomechanizmy robotyczne, które do kontroli wykorzystują magistralę szeregową (ang. Serial Bus Servo). Zmiana sposobu komunikacji z serwami pozornie może wydawać się mocno ingerująca w cały projekt, wręcz podważająca sens całej zmiany.

Jednak, gdy przyjrzymy się naszej architekturze systemu, szybko zobaczymy, że tak naprawdę do podmiany mamy tylko nasz „klocek” odpowiadający za konwersję kąta na wartość wychylenia serwa. Jeżeli wymienimy nasz driver, zachowując dokładnie takie samo API, czyli sposób w jakim rozmawiamy z modułem (innymi słowy garść funkcji), to reszta systemu nawet nie zauważy różnicy.

Podobnie sytuacja będzie wyglądać z urządzeniami do sterowania naszym robotem. Czy to aplikacja na telefon wykorzystująca bluetooth, czy pad od PS2 komunikujący się po magistrali SPI, nie ma to dla nas znaczenia tak długo, jak będziemy w stanie napisać moduł tłumaczący sygnał z zewnątrz na coś, co będziemy rozumieć. Daje nam to swobodę rozwijania takiego projektu, wykorzystując podzespoły, które może nie są najlepsze w danej aplikacji, ale po prostu „są” (może zostały w spadku po innych projektach), pozwalając nam kontynuować pracę i cieszyć się z tego, co robimy, a w przyszłości ulepszyć o komponenty wyższej klasy.

Podsumowanie

W artykule przedstawiliśmy sposób podejścia do złożonego zagadnienia, jakim jest proces zbudowania systemu kontroli robota kroczącego. Nie jest to gotowa instrukcja, jak wykonać takie urządzenie, a jedynie przedstawienie sposobu myślenia oraz prezentacja podejścia wybranego przez nasz zespół.

Warto zaznaczyć, że jedną z miar poprawnie zaprojektowanej architektury każdego systemu jest tak naprawdę nakład pracy, jaki musimy włożyć, aby zmodyfikować ją pod nowe wymagania projektowe.

Pamiętajcie, że każdy projekt to unikalna podróż, a kluczem do sukcesu są nie tylko gotowe rozwiązania, ale również umiejętność elastycznego myślenia i znajdowania własnych dróg. Dzięki odpowiedniemu podzieleniu projektu na etapy oraz skupieniu się na poszczególnych warstwach, nawet najbardziej złożone przedsięwzięcia stają się bardziej przystępne. Finalnie, projekt staje się łatwiejszy do zarządzania, a wyzwania są rozwiązywane po kolei, eliminując przytłaczające uczucie złożoności.

***

A jeśli ciekawią Cię inne projekty zrealizowane przez naszych inżynierów „po godzinach”, zajrzyj koniecznie do artykułów: Sii to the sky – how to launch your device at 24 km high! oraz Smart contract i IoT: oświadczyny w blockchainie