Stanowisko testowe napędu, czyli zanim noga zacznie naprawdę pracować
Ten wpis opisuje etap budowy stanowiska testowego dla napędu capstanowego Zervidjanny. W praktyce był to pierwszy większy krok w stronę docelowych nóg: zamiast od razu montować silnik, linkę i bęben w kompletnej kończynie, powstał osobny moduł, na którym można bezpiecznie sprawdzić mechanikę, elektronikę, enkoder, sterowanie ODrive oraz programy testowe pisane w Pythonie.
Na zdjęciach z tego etapu widać kilka warstw pracy: projektowanie obudowy i uchwytów, druk 3D, składanie mechaniki, pierwsze prowadzenie linki, konfigurację sterownika, kalibrację enkodera oraz pisanie skryptów do ruchu cyklicznego. To nie był jeszcze gotowy staw robota, tylko stanowisko do odpowiedzi na ważniejsze pytanie: czy taki sposób przeniesienia napędu ma sens, zanim zacznie się budować większą i droższą wersję.
Cel tego etapu
Celem nie było zbudowanie finalnej nogi, tylko osobnego stanowiska, które pozwala szybko i bezpiecznie sprawdzić najważniejsze założenia napędu: przełożenie, prowadzenie linki, zachowanie bębna, reakcję sterownika i sposób sterowania ruchem z poziomu programu.
- sprawdzić, czy napęd BLDC z ODrive nadaje się do dynamicznej pracy stawu;
- przetestować przeniesienie capstanowe oparte na lince i bębnie;
- zobaczyć, jak duże znaczenie mają naciąg, prowadzenie linki i geometria bębna;
- przygotować pierwsze skrypty Pythona do konfiguracji, kalibracji i ruchu testowego;
- wyciągnąć błędy konstrukcyjne na stanowisku, a nie dopiero w gotowej nodze robota.
Dlaczego capstan, a nie zwykła przekładnia?
W klasycznym robocie najprościej byłoby dać silnik, przekładnię planetarną albo pasową i podłączyć wszystko bezpośrednio do stawu. W Zervidjannie zależy mi jednak na konstrukcji możliwie lekkiej, sprężystej i bardziej zbliżonej do układów biologicznych. Napęd capstanowy pozwala odsunąć silnik od osi stawu, przenieść moment przez linkę oraz uzyskać przełożenie bez klasycznych zębów, luzów przekładniowych i dużej masy w samej kończynie.
Taki napęd ma jednak własne wymagania. Linka musi być dobrze napięta, bęben musi mieć odpowiednią średnicę i powierzchnię, a prowadzenie nie może pozwalać na zsuwanie się cięgna. W CAD wygląda to bardzo elegancko, ale w praktyce wystarczy kilka milimetrów złego ustawienia albo zbyt mały naciąg, żeby zamiast precyzyjnego stawu dostać warsztatową wersję szpulki z sznurkiem.
Założenia techniczne stanowiska
Stanowisko zostało zbudowane wokół silnika BLDC sterowanego przez ODrive. W testach chodziło przede wszystkim o ocenę zachowania napędu przy niskich i średnich prędkościach, sprawdzenie reakcji na zmianę pozycji oraz przygotowanie bezpiecznego środowiska do dalszych prób. Do sprzężenia zwrotnego przewidziany został enkoder inkrementalny AMT102-V, a przełożenie mechaniczne oparte było na bębnie i lince pracującej w układzie capstanowym.
W praktyce taki prototyp jest kompromisem między docelową konstrukcją a tym, co da się szybko wydrukować, skręcić i poprawić. Dlatego część elementów powstała jako wydruki 3D. To pozwoliło szybko przetestować rozstawy, średnice, punkty mocowania i dostęp serwisowy, bez czekania na obróbkę metalu albo wykonywanie drogich części w pierwszej wersji.
Główne elementy stanowiska
| Obszar | Rozwiązanie w prototypie |
|---|---|
| Napęd | Silnik BLDC Multistar 9235-100KV użyty jako źródło momentu obrotowego dla stanowiska testowego. |
| Sterownik | ODrive v3.6-56V, konfiguracja osi, ograniczeń prądowych, rezystora hamowania i trybów pracy. |
| Sprzężenie zwrotne | Enkoder inkrementalny AMT102-V do pomiaru pozycji i prędkości wału. |
| Przeniesienie | Układ capstanowy: bęben, linka, wstępny naciąg i test geometrii prowadzenia cięgna. |
| Mechanika | Obudowa, uchwyty i elementy pomocnicze wykonane jako prototypy z druku 3D. |
| Oprogramowanie | Skrypty w Pythonie do konfiguracji ODrive, kalibracji i wykonywania ruchów testowych. |
Projekt obudowy: najpierw trzeba dać mechanice szansę działać
Projekt obudowy nie był tylko pudełkiem na silnik. Musiał utrzymać osiowość, nie uginać się nadmiernie, zapewnić miejsce na bęben i pozwolić na regulację albo przynajmniej łatwą korektę prowadzenia linki. Przy napędzie cięgnowym geometria jest bardzo ważna, bo błąd ustawienia nie zawsze widać od razu. Czasem dopiero po uruchomieniu okazuje się, że linka zaczyna pracować po krawędzi albo chce iść własną drogą.
W CAD dopracowałem więc rozmieszczenie mocowań, dostęp do śrub, miejsce na przewody i układ elementów tak, aby stanowisko dało się złożyć bez gimnastyki narzędziowej. To mało widowiskowa część projektu, ale bardzo ważna. Roboty najczęściej nie przegrywają z wielkimi teoriami, tylko z nakrętką, do której nie da się później dojść.
Druk 3D: szybka droga od pomysłu do części, która czasem mówi „popraw mnie”
Kiedy model był gotowy, przyszedł czas na druk 3D. To idealna metoda na taki etap, bo pozwala sprawdzić kształt, tolerancje i wygodę montażu bez udawania, że pierwsza wersja musi być finalna. Wydruki nie są oczywiście tak sztywne jak elementy metalowe, ale do sprawdzenia koncepcji stanowiska sprawdzają się bardzo dobrze.
Najbardziej wartościowe w druku 3D jest to, że błędy szybko stają się fizyczne. Na ekranie wszystko wygląda równo, a na stole od razu widać, czy śruba ma miejsce, czy kabel się mieści, czy bęben nie ociera i czy element da się skręcić bez użycia zaklęć. Ten etap pozwolił wyłapać kilka rzeczy, które w samym CAD-zie łatwo byłoby zignorować.
Montaż: bęben, linka i tolerancje po wydruku
Po wydrukowaniu elementów zaczął się montaż mechaniczny. Silnik, bęben, mocowania, przewody i linka musiały zacząć pracować jako jeden układ. Szczególną uwagę trzeba było poświęcić prowadzeniu cięgna i jego wstępnemu napięciu. Przy capstanie linka nie jest tylko dodatkiem. To właściwy element przenoszący moment, więc jej zachowanie decyduje o jakości całego napędu.
Ten etap szybko pokazał, że w prototypie drukowanym 3D tolerancje nie są detalem. Wymiary z modelu CAD nie zawsze idealnie przenoszą się na gotowy element, ponieważ dochodzi skurcz materiału, dokładność drukarki, sposób chłodzenia oraz kierunek ułożenia warstw. Otwory, gniazda i miejsca pasowania trzeba więc traktować z pewnym zapasem, a czasem po prostu dopasować ręcznie po wydruku.
Pierwszy montaż ujawnił typowe rzeczy: coś trzeba było podszlifować, coś dokręcić, coś ustawić ponownie, a część założeń z ekranu skonfrontować z rzeczywistą sztywnością wydruku. To normalny etap prototypowania. Dobra wiadomość była taka, że podstawowa koncepcja zaczęła działać i można było przejść z pytania „czy to w ogóle się złoży?” do pytania „jak tym teraz dobrze sterować?”.
ODrive: moc jest przyjemna, ale najpierw bezpieczeństwo
Sterowanie silnikiem BLDC przejął ODrive. Zanim stanowisko mogło wykonać pierwszy sensowny ruch, trzeba było przejść przez konfigurację osi, ustawienie typu silnika, liczby par biegunów, ograniczeń prądowych, progów napięcia oraz rezystora hamowania. To mniej efektowne niż film z obracającym się bębnem, ale bez tego bardzo łatwo zrobić z testu krótką i kosztowną atrakcję pirotechniczną.
Wstępne ograniczenia prądu i prędkości były celowo zachowawcze. Na takim etapie nie chodzi o pokazanie maksymalnej siły, tylko o zrozumienie zachowania układu. Dopiero gdy kalibracja, enkoder i ruch w obie strony zaczynają działać przewidywalnie, można stopniowo zwiększać parametry. W robotyce cierpliwość bywa tańsza niż nowy sterownik.
Najważniejsza zasada przy pierwszym uruchomieniu
Najpierw stabilna konfiguracja i diagnostyka, dopiero później moc. Napęd stawu robota ma być szybki i silny, ale na stanowisku testowym ważniejsze jest to, żeby każdy ruch był powtarzalny, zrozumiały i możliwy do zatrzymania.
- ograniczenie prądu na czas testów;
- kontrola napięcia zasilania i rezystora hamowania;
- sprawdzenie poprawności enkodera przed ruchem dynamicznym;
- osobne skrypty do konfiguracji, kalibracji i testów ruchu;
- małe kroki zamiast jednego „zobaczmy, co się stanie”.
Python jako panel testowy
Do obsługi stanowiska powstały skrypty w Pythonie. Ich rola była prosta: nie klikać wszystkiego ręcznie, tylko mieć powtarzalny sposób konfiguracji, kalibracji i uruchamiania testów. Osobne programy pozwalały sprawdzić połączenie z ODrive, ustawić parametry osi, wykonać kalibrację enkodera, zapisać konfigurację i uruchomić ruchy przód-tył.
Z czasem skrypty zaczęły dostawać kolejne zabezpieczenia i wygodne funkcje. Pojawiły się limity wychylenia, kontrola prędkości, możliwość zmiany parametrów w trakcie pracy oraz prostsze komunikaty diagnostyczne. To ważne, bo przy stanowisku mechanicznym sama informacja „nie działa” nie wystarcza. Trzeba wiedzieć, czy problem jest w enkoderze, konfiguracji osi, stanie ODrive, zasilaniu, limicie prądu czy w mechanice, która właśnie postanowiła zostać hamulcem.
Co robiły pierwsze skrypty testowe
| Skrypt / etap | Zadanie |
|---|---|
| Wykrycie ODrive | Sprawdzenie komunikacji z urządzeniem, odczyt podstawowych informacji i błędów. |
| Konfiguracja osi | Ustawienie typu silnika, par biegunów, ograniczeń prądu, limitów napięcia i parametrów pracy. |
| Kalibracja | Uruchomienie procedur kalibracji silnika i enkodera oraz kontrola stanu osi. |
| Test ruchu | Cykliczne ruchy przód-tył, najpierw wolne i krótkie, później szybsze oraz z większym wychyleniem. |
| Diagnostyka | Odczyt pozycji, prędkości, błędów oraz obserwacja reakcji mechaniki na zadany ruch. |
| Bezpieczeństwo | Limity wychylenia, ostrożne ograniczenia prądu i możliwość szybkiego zatrzymania testu. |
Pierwsze testy: działa, ale pokazuje, gdzie będzie walka
Najważniejszy wynik pierwszych prób był pozytywny: napęd można uruchomić, sterować ruchem i obserwować reakcję mechaniki. Stanowisko pozwoliło zobaczyć, jak linka zachowuje się na bębnie, jak układ reaguje na zmianę kierunku i gdzie pojawiają się potencjalne problemy z naciągiem albo prowadzeniem.
Jednocześnie ten etap jasno pokazał, że capstan nie wybacza niedbałości. Przy docelowej nodze trzeba będzie bardzo dobrze rozwiązać regulację naciągu, stabilność bębna, prowadnice i ograniczenia mechaniczne. Sam silnik i sterownik to tylko połowa historii. Druga połowa to geometria, tarcie, sprężystość linki i sztywność konstrukcji.
Diagnostyka enkodera i kalibracji
Osobnym tematem była diagnostyka enkodera i procedur kalibracyjnych. W takim układzie nie wystarczy, że silnik „jakoś się kręci”. Sterownik musi wiedzieć, gdzie jest wał, w którą stronę się porusza i czy odczyt pozycji ma sens. Dlatego część pracy polegała na sprawdzaniu sygnałów, stanów osi, odczytów pozycji i zachowania ODrive podczas kalibracji.
Nie rozpisuję się tu zbyt mocno, bo nie jest to najbardziej widowiskowy etap devloga, ale był bardzo potrzebny. Napęd robota nie może bazować na domysłach. Jeśli staw ma później utrzymywać równowagę, reagować na uderzenia i pracować dynamicznie, to pętla sprzężenia zwrotnego musi być pewna. Ten prototyp pomógł oddzielić problemy mechaniczne od problemów konfiguracyjnych i programowych.
Wniosek po tym etapie
Stanowisko potwierdziło, że kierunek z napędem capstanowym jest wart dalszego rozwijania. Największą wartością nie jest samo to, że silnik poruszył bębnem, ale to, że powstał kompletny tor testowy: mechanika, elektronika, enkoder, ODrive i oprogramowanie. Dzięki temu kolejne wersje można już poprawiać metodycznie, a nie na zasadzie zgadywania.
To nadal prototyp warsztatowy, ale właśnie taka była jego rola. Miał szybko pokazać, co działa, co wymaga wzmocnienia, gdzie potrzebna jest regulacja i które elementy muszą być zaprojektowane dokładniej przed przejściem do pełnej nogi Zervidjanny.
Najważniejsze wnioski techniczne
| Obszar | Wniosek |
|---|---|
| Mechanika | Konstrukcja stanowiska spełniła rolę testową, ale docelowa wersja będzie wymagała większej sztywności i lepszej regulacji naciągu linki. |
| Capstan | Przeniesienie przez linkę działa, ale bardzo zależy od geometrii bębna, prowadzenia cięgna, tarcia i wstępnego napięcia. |
| Sterowanie | ODrive pozwala wygodnie testować BLDC, ale wymaga starannej konfiguracji i ostrożnego zwiększania parametrów. |
| Enkoder | Diagnostyka pozycji i poprawność kalibracji są kluczowe, zanim zacznie się wykonywać szybkie ruchy. |
| Oprogramowanie | Skrypty Pythona dobrze sprawdziły się jako panel testowy i narzędzie diagnostyczne, ale są zbyt wolne do docelowego sterowania napędem. W przyszłości kontrola układu ma zostać przeniesiona na szybszą komunikację przez magistralę CAN. |
| Następny etap | Trzeba przejść od stanowiska demonstracyjnego do bardziej dopracowanego modułu stawu z ogranicznikami, lepszym prowadzeniem linki i kontrolą obciążeń. |
Co dalej?
Kolejny krok to przeniesienie doświadczeń z pojedynczego napędu do większego fragmentu konstrukcji. W planie jest prototyp miednicy Zervidjanny z co najmniej dwoma, a docelowo trzema silnikami BLDC. Najważniejsze będzie zmieszczenie całego układu możliwie kompaktowo, ponieważ tylna część robota nie daje zbyt dużo miejsca na silniki, bębny, mocowania i prowadzenie cięgien.
Głównym wyzwaniem będzie więc mechanika: rozmieszczenie napędów, sztywność korpusu, prowadzenie linek, regulacja ich naciągu oraz takie ułożenie cięgien, aby nie kolidowały ze sobą podczas ruchu. Ten etap ma pokazać nie tylko, czy pojedynczy napęd działa, ale czy da się zbudować z niego powtarzalny moduł dla nóg robota.
Od strony sterowania kierunek również jest jasny. Skrypty Pythona zostaną głównie jako narzędzie testowe i diagnostyczne, natomiast docelowa kontrola napędów ma zostać przeniesiona na STM32 oraz komunikację przez magistralę CAN. W planie jest także wizualizacja danych z ODrive, lepsze logowanie parametrów oraz zwiększenie napięcia zasilania z 24 V do 48 V, aby uzyskać szybszą i bardziej dynamiczną pracę silników.
ZERVI LABS