Ramię robota: Jensen: 4 kroki

2024 Autor: John Day | [email protected]. Ostatnio zmodyfikowany: 2024-01-30 11:31

Jensen to ramię robota zbudowane na platformie Arduino z naciskiem na intuicyjne planowanie ruchu, wykonane jako niezależny projekt o wartości 1 kredytu pod opieką dr Charlesa B. Mallocha. Może replikować serię zaprogramowanych ruchów, ręcznie przesuwając ramię. Inspirację do jej zbudowania czerpałem z obejrzenia innych ramion robotycznych zbudowanych w przestrzeni produkcyjnej UMass Amherst M5. Ponadto chciałem nauczyć się obsługi oprogramowania CAD i chciałem wykonać zaawansowany projekt Arduino. Postrzegałem to jako okazję do zrobienia wszystkich tych rzeczy.

Krok 1: Oryginalny projekt i zakres

Oprogramowanie CAD, które wybrałem do nauki w tym projekcie, to OnShape, a pierwszą rzeczą, którą wymodelowałem, było analogowe serwo HiTec HS-422. Wybrałem serwo, ponieważ był dla mnie dostępny lokalnie i miał rozsądną cenę. Służyła również jako dobra praktyka do nauki OnShape przed przejściem do projektowania własnych części. Na tym wczesnym etapie projektu miałem ogólne pojęcie o tym, do czego chciałem, aby ramię było zdolne. Chciałem, żeby miał przyzwoity zakres ruchu i chwytak do podnoszenia rzeczy. Te ogólne specyfikacje wpłynęły na projekt, gdy kontynuowałem modelowanie go w CAD. Kolejnym ograniczeniem projektowym, które miałem w tym momencie, był rozmiar stołu roboczego w mojej drukarce 3D. Dlatego podstawa, którą widzisz na powyższym zdjęciu, jest stosunkowo prymitywnym kwadratem.

Na tym etapie projektu robiłem też burzę mózgów, jak chcę kontrolować ramię. Jedno ramię robota, które zainspirowałem się w makerspace, używało ramienia kukiełkowego do sterowania. Inny wykorzystał intuicyjną metodę programowania ścieżki, w której ramię było ustawiane przez użytkownika w różnych pozycjach. Ramię następnie przechodziło z powrotem przez te pozycje.

Moim pierwotnym planem było dokończenie budowy ramienia, a następnie wdrożenie obu tych metod sterowania. Chciałem też w pewnym momencie stworzyć aplikację komputerową do kontrolowania tego. Jak zapewne wiesz, skończyło się na ograniczeniu zakresu tego aspektu projektu. Kiedy zacząłem pracować nad tymi dwoma pierwszymi metodami sterowania, szybko odkryłem, że intuicyjne programowanie ścieżek jest bardziej skomplikowane niż myślałem. Wtedy postanowiłem skupić się na tym i odłożyć inne metody kontroli na czas nieokreślony.

Krok 2: Kontrola

Wybrana przeze mnie metoda sterowania działa w ten sposób: przesuwasz ramię rękoma w różne pozycje i „zapisujesz” te pozycje. Każda pozycja zawiera informacje o kącie między każdym ogniwem ramienia. Po zakończeniu zapisywania pozycji naciskasz przycisk odtwarzania, a ramię powraca do każdej z tych pozycji po kolei.

W tej metodzie kontroli było wiele rzeczy do ustalenia. Aby każdy serwo wracał do zapisanego kąta, musiałem jakoś „zapisać” te kąty w pierwszej kolejności. Wymagało to Arduino Uno, którego używałem, aby móc odbierać aktualny kąt każdego serwomechanizmu. Mój przyjaciel Jeremy Paradie, który stworzył ramię robota wykorzystujące tę metodę sterowania, podpowiedział mi, jak używać wewnętrznego potencjometru każdego serwomechanizmu hobbystycznego. Jest to potencjometr, którego serwo używa do zakodowania swojego kąta. Wybrałem serwo testowe, przylutowałem przewód do środkowego pinu wewnętrznego potencjometru i wywierciłem otwór w obudowie, aby wyprowadzić przewód na zewnątrz.

Mogłem teraz otrzymać aktualny kąt odczytując napięcie na środkowym styku potencjometru. Pojawiły się jednak dwa nowe problemy. Po pierwsze pojawiły się szumy w postaci skoków napięcia na sygnale dochodzącym ze środkowego pinu. Ten problem stał się później prawdziwym problemem. Po drugie, zakresy wartości dla wysyłania kąta i odbierania kąta były różne.

Powiedzenie serwonapędom hobbystycznym, aby przesunęły się pod pewnym kątem między 0 a 180 stopni, wiąże się z wysłaniem im sygnału PWM o wysokim czasie odpowiadającym kątowi. Przeciwnie, użycie analogowego pinu wejściowego Arduino do odczytu napięcia na środkowym pinie potencjometru podczas przesuwania tuby serwomechanizmu między 0 a 180 stopni zwraca oddzielny zakres wartości. Dlatego potrzebne było trochę matematyki, aby przetłumaczyć zapisaną wartość wejściową na odpowiednią wartość wyjściową PWM potrzebną do przywrócenia serwomechanizmu pod tym samym kątem.

Moją pierwszą myślą było użycie prostej mapy zasięgu, aby znaleźć odpowiedni wyjściowy PWM dla każdego zapisanego kąta. To zadziałało, ale nie było zbyt precyzyjne. W przypadku mojego projektu zakres wysokich wartości czasu PWM odpowiadający zakresowi kąta 180 stopni był znacznie większy niż zakres wartości wejść analogowych. Dodatkowo oba te przedziały nie były ciągłe i składały się wyłącznie z liczb całkowitych. Dlatego kiedy zmapowałem zapisaną wartość wejściową do wartości wyjściowej, dokładność została utracona. W tym momencie pomyślałem, że potrzebuję pętli sterowania, aby ustawić serwa tam, gdzie powinny.

Napisałem kod dla pętli sterowania PID, w której wejście było napięciem środkowego pinu, a wyjściem było wyjście PWM, ale szybko odkryłem, że potrzebuję tylko zintegrowanego sterowania. W tym scenariuszu dane wyjściowe i wejściowe reprezentowały kąty, więc dodanie sterowania proporcjonalnego i różniczkowego powodowało, że przewyższanie lub miało niepożądane zachowanie. Po dostrojeniu sterowania integralnego były jeszcze dwa problemy. Po pierwsze, gdyby początkowy błąd między aktualnym a pożądanym kątem był duży, serwo przyspieszałoby zbyt szybko. Mogłem zmniejszyć stałą dla integralnej kontroli, ale to spowodowało, że ogólny ruch był zbyt wolny. Po drugie, ruch był roztrzęsiony. Było to wynikiem szumu na analogowym sygnale wejściowym. Pętla kontrolna w sposób ciągły odczytywała ten sygnał, więc skoki napięcia powodowały drgający ruch. (W tym momencie przeniosłem się również z mojego jednego serwa testowego do zespołu pokazanego powyżej. Zrobiłem również obiekt pętli sterującej dla każdego serwa w oprogramowaniu.)

Rozwiązałem problem zbyt szybkiego przyspieszania, umieszczając na wyjściu filtr wykładniczo ważonej średniej ruchomej (EWMA). Uśredniając moc wyjściową, zmniejszono duże skoki w ruchu (w tym drgania spowodowane hałasem). Jednak szum na sygnale wejściowym nadal stanowił problem, więc kolejnym etapem mojego projektu było rozwiązanie tego problemu.

Krok 3: Hałas

Na zdjęciu powyżej

Na czerwono: oryginalny sygnał wejściowy

Na niebiesko: sygnał wejściowy po przetworzeniu

Pierwszym krokiem w redukcji szumów w sygnale wejściowym było zrozumienie jego przyczyny. Sondowanie sygnału na oscyloskopie wykazało, że skoki napięcia zachodziły z częstotliwością 50 Hz. Zdarzyło mi się wiedzieć, że sygnał PWM wysyłany do serw również ma częstotliwość 50 Hz, więc domyśliłem się, że skoki napięcia mają z tym coś wspólnego. Postawiłem hipotezę, że ruch serw w jakiś sposób powodował skoki napięcia na pinie V+ potencjometrów, co z kolei zakłócało odczyt na środkowym pinie.

Tutaj podjąłem pierwszą próbę zmniejszenia hałasu. Ponownie otworzyłem każde serwo i dodałem przewód wychodzący z pinu V+ na potencjometrze. Potrzebowałem więcej wejść analogowych, aby je odczytać, niż miało Arduino Uno, więc w tym momencie przeniosłem się również na Arduino Mega. W moim kodzie zmieniłem wejście kątowe z analogowego odczytu napięcia na środkowym pinie na stosunek napięcia na środkowym pinie do napięcia na pinie V+. Miałem nadzieję, że jeśli na pinach pojawi się skok napięcia, zniknie to w stosunku.

Złożyłem wszystko z powrotem i przetestowałem, ale skoki nadal się pojawiały. To, co powinienem zrobić w tym momencie, to zbadać mój grunt. Zamiast tego moim kolejnym pomysłem było umieszczenie potencjometrów w całości na osobnym zasilaniu. Odłączyłem przewody V+ od wejść analogowych Arduino i podłączyłem je do osobnego zasilacza. Wcześniej sondowałem piny, więc wiedziałem, przy jakim napięciu je zasilać. Odciąłem też połączenie między płytą sterującą a pinem V+ w każdym serwo. Połączyłem wszystko z powrotem, przywróciłem kod wprowadzania kąta do poprzedniego stanu, a następnie przetestowałem. Zgodnie z oczekiwaniami na pinie wejściowym nie było już skoków napięcia. Pojawił się jednak nowy problem – podłączenie potencjometrów do osobnego zasilacza kompletnie popsuło wewnętrzne pętle sterujące serw. Mimo że piny V+ otrzymywały takie samo napięcie jak poprzednio, ruch serwomechanizmów był nieregularny i niestabilny.

Nie rozumiałem, dlaczego tak się dzieje, więc w końcu sprawdziłem połączenie z masą w serwach. Spadek napięcia na ziemi wynosił średnio około 0,3 V, a jego skok był jeszcze wyższy, gdy serwa pobierały prąd. Było dla mnie jasne, że te szpilki nie mogą już być uważane za „uziemiające” i lepiej można je opisać jako szpilki „odniesienia”. Płyty sterujące w serwomechanizmach musiały mierzyć napięcie na środkowym pinie potencjometru w stosunku do napięcia na pinach V+ i odniesienia. Zasilanie potencjometrów osobno zepsuło ten względny pomiar, ponieważ teraz zamiast skoku napięcia na wszystkich pinach, nastąpiło to tylko na pinie odniesienia.

Mój mentor, dr Malloch, pomógł mi debugować to wszystko i zasugerował, abym również zmierzył napięcie na środkowym pinie w stosunku do innych pinów. To właśnie zrobiłem w mojej trzeciej i ostatniej próbie zmniejszenia szumu wejściowego kąta. Otworzyłem każde serwo, ponownie podłączyłem przewód, który odciąłem, i dodałem trzeci przewód wychodzący z bolca odniesienia na potencjometrze. W moim kodzie uczyniłem wejście kątowe równoważne następującemu wyrażeniu: (środkowy pin - pin referencyjny) / (V+pin - pin referencyjny). Przetestowałem go i skutecznie zredukował skutki skoków napięcia. Dodatkowo na to wejście założyłem też filtr EWMA. Ten przetworzony sygnał i oryginalny sygnał pokazano powyżej.

Krok 4: Zawijanie rzeczy

Po rozwiązaniu problemu hałasu najlepiej jak potrafię, zabrałem się za naprawę i wykonanie końcowych części projektu. Ramię zbyt mocno obciążało serwo w podstawie, więc zrobiłem nową podstawę, która podtrzymuje ciężar ramienia za pomocą dużego łożyska. Wydrukowałem również chwytak i trochę go szlifowałem, aby działał.

Jestem bardzo zadowolona z efektu końcowego. Intuicyjne planowanie ruchu działa konsekwentnie, a ruch jest płynny i dokładny, biorąc pod uwagę wszystko. Jeśli ktoś inny chciałby zrobić ten projekt, najpierw gorąco zachęcam go do zrobienia prostszej wersji. Z perspektywy czasu, zrobienie czegoś takiego za pomocą hobbystycznych serwomotorów było bardzo naiwne, a trudność, jaką miałem, aby to zadziałało, pokazuje to. Uważam za cud, że ramię działa tak samo dobrze. Nadal chcę tworzyć ramię robota, które może łączyć się z komputerem, uruchamiać bardziej złożone programy i poruszać się z większą precyzją, więc zrobię to w następnym projekcie. Będę używał wysokiej jakości cyfrowych serw robotów i mam nadzieję, że pozwoli mi to uniknąć wielu problemów, które napotkałem w tym projekcie.

Dokument CAD:

cad.onshape.com/documents/818ea878dda7ca2f…