Skocz do zawartości

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

Udostępnij ten post


Link to post
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

Udostępnij ten post


Link to post
Share on other sites
(edytowany)

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

Udostępnij ten post


Link to post
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!

Gość
Napisz odpowiedź...

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