Skocz do zawartości

Quadrupel - robot kroczący


Pomocna odpowiedź

Dzisiaj skończyłem tworzyć model robota w URDF. Mam skrypt, który czyta paramtery w notacji Denavita-Hartenberga i zamienia je na współrzędne używane w URDF. Na razie jest zrobione tak, żeby było i będę musiał jeszcze przysiąść, żeby to "czysto" napisać. Oprócz tego napisałem odwrotną kinematykę, też na razie trochę brzydko, ale chciałem sprawdzić obliczenia i wydają się być dobre. Poniżej wstawiam filmik z działania i moje obliczenia, dość chaotycznie spisane. Wiem, że model nie za piękny, ale na razie mi tyle wystarcza do wizualizacji 😛 
Pozycja końcówki jest zadawana z joysitcka, który był kupowany po taniości i ma bardzo wąski i trudny do wychwycenia zakres "analogowości", przez co ruchy końcówki nie są zbyt płynne. Obsługę joysticka ogarnia węzeł ROSa, który jest dołączany do instalacji.

 

67778908_349375502624894_581094360590843904_n.thumb.jpg.5f62a48e549cffc9635f1801e71605a2.jpg

Przy okazji dowiedziałem się, że mój sterownik serw w przypadku komunikacji po UART ma maksymalny baudrate 9600, co przy formacie komend sterownika daje mi maksymalną częstotliwość odświeżania ~10Hz. Szczerze mówiąc liczyłem na trochę więcej i może kiedyś pokombinuję z USB, bo na tym może już ponoć działać nawet na 115200. Ponadto ten sterownik dość często błędnie odbiera dane i dopiero po wysłaniu po raz któryś komendy ogarnia.

No i przygód z korzystaniem z niedokończonego systemu ciąg dalszy. ROS2 jeszcze nie ma w pełni zaimplementowanego programu do wizualizacji RVIZ (który jest właśnie na filmiku), w związku z czym nie można mu podać modelu robota automatycznie przy jego odpalaniu, ale trzeba ręcznie wprowadzić ścieżkę w programie. Na szczęście ustawienia są zapamiętywane i nie trzeba za każdym razem tego robić.

Teraz planuję nieco "upiększyć" model robota, bo w tym momencie jest to skopiowany 4 razy opis jednej nogi z niewielkimi zmianami, chcę zrobić jedną templatkę na nogę, która będzie automatycznie wklejana do głównego pliku modelu. W ROS1 istniało coś, co się nazywało xacro i robiło to w miarę samo, ale 1) pewnie jeszcze tego nie ma w ROS2 2) i tak potrzebuję programu do konwersji z notacji DH, więc mogę od razu to wpisać do templatki.
Do tego chcę jeszcze "upiększyć" kinematykę odwrotną, bo jest zhardkodowana na przednią lewą nogę. Muszę wymyślić sposób na jakąś generalizację tego.

I wrzuciłem kod na githuba. Jeszcze nie cały, bo większość kodu jest na razie w wersji "żeby się ruszało, potem będę to robił porządnie" i głupio publikować, ale coś już tam jest. Link: https://github.com/Wojcik98/Quadrupel

  • Lubię! 1
Link do komentarza
Share on other sites

Dopracowałem już model i sterowanie serw, żeby obydwa pokazywały to samo i udało mi się zakodzić prosty "chód", a właściwie czołganie się, czym się pochwalę:

 

Na razie to jest bardzo proste, bo od strony implementacyjnej wygląda to tak, że końcówką każdej nogi zakreślam okrąg.

I teraz chciałem zadać pytanie o "poprawne" sterowanie, ale w trakcie jego formułowania przyszło mi do głowy rozwiązanie 😀
Moja definicja poprawnego sterowania: sterowanie pozycją nóg i robota względem otoczenia, zamiast względem robota. Aktualnie w wizualizacji mam nieruchomego robota, który przebiera w powietrzu nogami. Chciałbym mieć nieruchome otoczenie, względem którego przemieszcza się robot i po postawieniu nogi nie przesuwa się ona względem otoczenia. I wcześniej wspomniane rozwiązanie jest takie:

1) ustalam zadaną pozycję nóg względem otoczenia (gdzie je postawić)
2) ustalam zadaną pozycję robota względem otoczenia (gdzie ma być i jak ma być zorientowany)
3) znam pozycję nóg względem otoczenia i robota względem otoczenia, więc mogę przekształcić współrzędne końcówek nóg do układu robota
4) z tego już liczę odwrotną kinematykę i ustawiam serwa według niej

Dzięki temu wiem, że nogi się nie ruszą względem otoczenia , a i robot będzie tam, gdzie będę tego chciał. Teraz pozostaje problem, gdzie w otoczeniu stawiać nogi, ale to brzmi jak problem generowania chodu, którym się zajmę później, na razie zaimplementuję powyższy algorytm.

  • Lubię! 1
Link do komentarza
Share on other sites

Zarejestruj się lub zaloguj, aby ukryć tę reklamę.
Zarejestruj się lub zaloguj, aby ukryć tę reklamę.

jlcpcb.jpg

jlcpcb.jpg

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

Generalnie to się zazwyczaj robi tak, że masz kilka układów odniesienia. Każda noga ma swój, do liczenia kinematyki odwrotnej. Ciało wraz z nogami ma swój, na potrzeby chodu i balansowania. Dalej masz pojazd wirtualny — czyli to czym sterujesz — który nie do końca pokrywa się z ciałem, bo ciało może się przesuwać w celu balansowania, a pojazd wirtualny pozostaje wtedy w miejscu — przesuwa się tylko na komendy użytkownika. No i wreszcie masz układ odniesienia otoczenia, żeby robot wiedział gdzie jest. Przejścia między tymi układami najłatwiej się robi macierzami przejścia między układami współrzędnych.

Edytowano przez deshipu
  • Lubię! 2
Link do komentarza
Share on other sites

Po półtora miesiąca przerwy czas coś napisać. Większość tego czasu spędziłem na ogarnięciu, czemu ROS2 nie działa i to była faktycznie jego, a nie moja wina 😛. Na początku po jakiejś aktualizacji okazało się, że przestała działać główna jego funkcjonalność, czyli protokół porozumiewania się między węzłami (osobnymi programami). Nawet przykładowe programy nie działały, publisher wysyłał wiadomości w eter a do subscribera już nic nie docierało. Nareszcie po kilku dniach przyszła kolejna aktualizacja, która naprawiała ten problem i mogłem pisać dalej, tylko pojawił się kolejny problem. ROS2 nie widział paczek napisanych w Pythonie. W ROS2 struktura prjektu wygląda tak, że jest folder z folderem `src`, w którym w osobnych folderach znajdują się poszczególne paczki. Każda paczka zdefiniowana jest przez plik `package.xml` i do tego paczka C++ wymaga `CMakeList.txt`, a paczka Pythona `setup.py`, więc przy budowaniu projektu faktycznie są inaczej traktowane. Problem był o tyle trudny do zdebugowania, że paczki przy budowaniu się pokazywały, ale ROS2 ich nie widział przy próbie uruchomienia programów z tych paczek, mówił, że nie istnieją. Okazało się, że w pliku `setup.py` należy dołożyć dodatkowy krok budowania, który polega na skopiowaniu pustego pliku o nazwie takiej, jak paczka do folderu, który ROS2 wykorzystuje do indeksowania paczek. Nie wiem, czemu wcześniej działało wszystko bez tego i nagle przestało, ale chwilę na to poświęciłem. Jeśli ktoś byłby zainteresowany, to takie linijki są potrzebne w `setup.py`:

data_files=[
    ('share/ament_index/resource_index/packages',
        ['resource/' + package_name]),
    ('share/' + package_name, ['package.xml']),
],

 

Oprócz tego miałem problem ze stworzeniem własnego typu serwisu, który korzystał z typów wbudowanych w ROS2 (z paczki geometry_msgs), najwyraźniej dlatego, że było coś nie tak w implemetacji tych typów. Tutaj już mi się nie chciało dochodzić do przyczyny w kodzie źródłowym ROSa i po prostu zdefiniowałem własny typ, który miał dokładnie takie same informacje (tj. informacje o pozycji). Po pokonaniu przeciwności ze strony ROSa mogłem nareszcie wziąć się do właściwego kodzenia.

Zaimplemetowałem to, co deklarowałem w poprzednim poście, czyli ustawianie nóg i ciała względem "świata", zamiast względem siebie. Do przejścia między układami bazy nogi i bazy świata używałem serwisu ROSa, który sam się tym zajmuje, a do przejścia z bazy świata do końcówki nogi mnożyłem macierze, bo nie publikowałem ich pozycji, tylko trzymałem je w pamięci programu. Robot teraz potrafi poruszać ciałem względem świata z nogami stojącymi nieruchomo, ogarnia zarówno translację, jak i rotację ciała (choć na filmiku poniżej jest tylko translacja, bo rotację zaimplemetowałem jakieś dwie godziny później).

 

Z rzeczy, których nie ma na filmiku, to zmieniłem nieco ułożenie kolana. Na filmiku robot nie może go zginać mniej niż 90*, bo inaczej dochodzi do kolizji z udem. Wystarczyło przestawić na drugą stronę mocowania, podobnie jak to widać na mocowaniu "biodrowym". Dzięki temu już mu lepiej wychodzi kucanie.

Co chcę zrobić w najbliższym czasie:
1) Umieścić dane o charakterystyce nóg w jednym globalnym pliku, teraz jest to zahardkodowane w kodzie i nie sprzyja zmianom.
2) Poprawić odwrotną kinematykę dla nowych danych i uwzględniać przesunięcie osi w biodrze, bo wcześniej tego nie brałem pod uwagę i niby działało, ale przyda się dokładna pozycja końcówki nogi.
3) Prosty chód w stylu: idź do przodu.

@deshipu czy dobrze rozumiem: przez analogię do regulatorów, pojazd wirtualny to jest pozycja zadana robota, którą rzeczywisty układ powinien osiągnąć? Jeśli tak, to przy zachowywaniu równowagi statycznej (nie ma potrzeby balansowania, robot się nie potyka) te układy powinny się cały czas pokrywać i różnice powinny się pojawić się tylko w przypadku zewnętrznych sił, np. kopiących panów z Boston Dynamics?

  • Lubię! 2
Link do komentarza
Share on other sites

Dnia 23.09.2019 o 10:02, Wojcik98 napisał:

@deshipu czy dobrze rozumiem: przez analogię do regulatorów, pojazd wirtualny to jest pozycja zadana robota, którą rzeczywisty układ powinien osiągnąć? Jeśli tak, to przy zachowywaniu równowagi statycznej (nie ma potrzeby balansowania, robot się nie potyka) te układy powinny się cały czas pokrywać i różnice powinny się pojawić się tylko w przypadku zewnętrznych sił, np. kopiących panów z Boston Dynamics?

Nie do końca. Jeśli robot zostanie kopnięty i musi zrobić te kilka kroków, to pojazd wirtualny też przesuniesz. Ale nie przesuwasz go przy ruchach typu odciążenie nogi przed jej uniesieniem, czy obrócenie ciała żeby lepiej móc sięgnąć. To jest po prostu kwestia wygody osoby sterującej, żeby się nie musiała przejmować dokładną pozycją. Jeśli twój robot nie robi żadnego balansowania ani nic takiego, to to się będzie pokrywać z układem odniesienia ciała, ale moim zdaniem warto i tak wydzielić taki układ, bo nigdy nie wiadomo co w przyszłości dodasz.

Edytowano przez deshipu
  • Lubię! 1
  • Pomogłeś! 1
Link do komentarza
Share on other sites

Dołącz do dyskusji, napisz odpowiedź!

Jeśli masz już konto to zaloguj się teraz, aby opublikować wiadomość jako Ty. Możesz też napisać teraz i zarejestrować się później.
Uwaga: wgrywanie zdjęć i załączników dostępne jest po zalogowaniu!

Anonim
Dołącz do dyskusji! Kliknij i zacznij pisać...

×   Wklejony jako tekst z formatowaniem.   Przywróć formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Twój link będzie automatycznie osadzony.   Wyświetlać jako link

×   Twoja poprzednia zawartość została przywrócona.   Wyczyść edytor

×   Nie możesz wkleić zdjęć bezpośrednio. Prześlij lub wstaw obrazy z adresu URL.

×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.