Test napędu cięgnowego typu capstan drive

napęd capstanowy / BLDC / ODrive / Python

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ę.

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.

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.

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.

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.

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.