diff --git a/lab04/README.md b/lab04/README.md index 6c5f90e1768114bcf48bf0e910205145d76b545c..7f5a788eaed3fc0dd267a1f703ff3eae98c21061 100644 --- a/lab04/README.md +++ b/lab04/README.md @@ -1,75 +1,149 @@ # Przygotowanie przestrzeni roboczej PoĹÄ cz siÄ ze zdalnym Ĺrodowiskiem i ĹciÄ gnij swoje repozytorium do przestrzeni roboczej catkin_ws. - - + + # Transformacje pomiÄdzy ukĹadami wspĂłĹrzÄdnych -Przed przystapieniem do omawiania nawigacji waĹźnym jest aby rozumieÄ jak wiele ukĹadĂłw wspĂłĹrzÄdnych znajduje siÄ w platformie robotycznej, jak sÄ one ze sobÄ poĹÄ czone oraz jak okreĹlaÄ poĹoĹźenie i orientacje wzglÄdem poszczegĂłlnych ukĹadĂłw wspĂłĹrzÄdnych. - +Przed przystÄ pieniem do omawiania nawigacji waĹźnym jest aby rozumieÄ jak wiele ukĹadĂłw wspĂłĹrzÄdnych znajduje siÄ w platformie robotycznej, jak sÄ one ze sobÄ poĹÄ czone oraz jak okreĹlaÄ poĹoĹźenie i orientacjÄ wzglÄdem poszczegĂłlnych ukĹadĂłw wspĂłĹrzÄdnych. + DziaĹanie zaleĹźnoĹci pomiÄdzy ukĹadami wspĂłĹrzÄdnych zostanie zwizualizowane na przykĹadzie manipulatora o 5 stopniach swobody. - +  - + W systemie ROS moĹźemy wizualizowaÄ roboty i elementy Ĺrodowiska przy pomocy opisu URDF. Na niniejszym laboratorium jednak nie zostanie on wyjaĹniony. JeĹli chcesz dowiedzieÄ jak tworzy siÄ pliki URDF i jak stworzyÄ model wĹasnego robota, to tu znajdziesz wiÄcej informacji [link](http://wiki.ros.org/urdf/Tutorials) (tutorial opisuje jak stworzyÄ prosty model robota R2D2). - + W skrĂłcie pliki URDF pozwalajÄ opisaÄ jak zĹoĹźony jest robot. Z jakich zĹoĹźony jest elementĂłw i jak sÄ one poĹÄ czone ze sobÄ . - + Aby uruchomiÄ naszÄ wizualizacjÄ potrzebujemy pliku launch. - + ```xml <launch> <param name="robot_description" command="$(find xacro)/xacro.py '$(find katana_description)/urdf/katana_300_6m180.urdf.xacro'" /> <node pkg="joint_state_publisher_gui" type="joint_state_publisher_gui" name="joint_state_publisher"> </node> - + <node pkg="robot_state_publisher" type="robot_state_publisher" name="robot_state_publisher"> <param name="ignore_timestamp" value="false"/> </node> - + <node pkg="tf" type="static_transform_publisher" name="katana_base_link_to_box" args="0 0.5 0 0 0 0 /katana_base_link /box 100"/> </launch> ``` ZostaĹ on juĹź stworzony w pakiecie "laboratorium_pliki_dodatkowe". - + Po pierwsze musimy zaĹadowaÄ opis naszego robota jako parametr pod nazwÄ **robot_description**. - -NastÄpnie uruchamiamy trzy node'y. Pierwszy odpowaiada za publikowanie stanu poszczegĂłlnych przegubĂłw robota. Po uruchomieniu zobaczysz okno z interfejsem, ktĂłry pozwoli na zmianÄ pozycji poszczegĂłlnych przegubĂłw robota. JeĹli posiadalibyĹmy prawdziwego robota, ktĂłrego chcielibyĹmy wizualizowaÄ, wtedy jego sterownik publikowaĹby aktualne stany poszczegĂłlnych przegubĂłw. - + +NastÄpnie uruchamiamy trzy node'y. Pierwszy odpowiada za publikowanie stanu poszczegĂłlnych przegubĂłw robota. Po uruchomieniu zobaczysz okno z interfejsem, ktĂłry pozwoli na zmianÄ pozycji poszczegĂłlnych przegubĂłw robota. JeĹli posiadalibyĹmy prawdziwego robota, ktĂłrego chcielibyĹmy wizualizowaÄ, wtedy jego sterownik publikowaĹby aktualne stany poszczegĂłlnych przegubĂłw. + Kolejny node na podstawie pliku urdf oraz danych publikowanych przez **joint_state_publisher** uaktualnia pozycje wizualizowanych elementĂłw robota. - + Ostatni node **static_transform_publisher** publikuje staĹe przeksztaĹcenie (odsuniÄcie o 0.5 m w osi y) pomiÄdzy ukĹadem wspĂłĹrzÄdnych **katana_base_link**, a **box**. Ma on symulowaÄ poĹoĹźenie przykĹadowego elementu i posĹuĹźy do lepszego wyjaĹnienia omawianego zagadnienia. - + Uruchom plik launch **wizualizacja_urdf** z paketu **laboratorium_pliki_dodatkowe**. NastÄpnie uruchom program RVIZ i dodaj wizualizacje modelu robota, tf oraz zmieĹ staĹy ukĹad wspĂłĹrzÄdnych na **katana_base_link**. - + @@@@@@ - - + + **Zadanie 1:** Przy pomocy **joint_state_publisher** obrĂłÄ poszczegĂłlne przeguby robota i zobacz jak zmienia siÄ wizualizacja. ZmieĹ staĹy ukĹad wspĂłĹrzÄdnych (Fixed frame) na wybrany ukĹad zaczynajÄ cy siÄ od nazwy **katana_motor**. SprawdĹş jak teraz zmienia siÄ wizualizacja przy ruchach przegubĂłw. - - + +  - -Jak widaÄ robot zĹoĹźony jest z wielu ukĹadĂłw wspĂłĹrzÄdnych poĹÄ czonych ze sobÄ . KaĹźdy kolejny ukĹad wspĂłĹrzÄdnych jest zaczepiony w poprzednim i wzglÄdem niego jest ukreĹlana jego pozycja. Taki sposĂłb organizacji wszystkich ukĹadĂłw wspĂłĹrzÄdnych pozwala nam w Ĺatwy sposĂłb wyliczyÄ, gdzie np. znajduje siÄ koĹcĂłwka robota wzglÄdem podstawy lub dowolnego innego obiektu np. pudeĹka o ukĹadnie wspĂłĹrzÄdnych **box**. Wszystkie poĹÄ czenia pomiÄdzy ukĹadami wspĂłĹrzÄdnych sÄ zorganizowane w postaci struktury drzewa. AktualnÄ strukturÄ moĹźemy zobaczyÄ przy pomocy narzÄdzia rqt i TF Tree. - + +Jak widaÄ robot zĹoĹźony jest z wielu ukĹadĂłw wspĂłĹrzÄdnych poĹÄ czonych ze sobÄ . KaĹźdy kolejny ukĹad wspĂłĹrzÄdnych jest zaczepiony w poprzednim i wzglÄdem niego jest okreĹlana jego pozycja. Taki sposĂłb organizacji wszystkich ukĹadĂłw wspĂłĹrzÄdnych pozwala nam w Ĺatwy sposĂłb wyliczyÄ, gdzie np. znajduje siÄ koĹcĂłwka robota wzglÄdem podstawy lub dowolnego innego obiektu np. pudeĹka o ukĹadzie wspĂłĹrzÄdnych **box**. Wszystkie poĹÄ czenia pomiÄdzy ukĹadami wspĂłĹrzÄdnych sÄ zorganizowane w postaci struktury drzewa. AktualnÄ strukturÄ moĹźemy zobaczyÄ przy pomocy narzÄdzia rqt i TF Tree. + **Zadanie 2:** Uruchom program rqt przy pomocy komendy ``` rqt ``` w terminalu. NastÄpnie wĹÄ cz wizualizacje TF Tree (Plugins -> Visualization -> TF Tree). - -Po uruchomieniu TF Tree moĹźesz zobaczyÄ jak caĹa struktura jest zorgranizowana. Dodatkowo, dziÄki temu narzÄdziu moĹźemy sprawdziÄ czy na pewno wszystko jest ze sobÄ poĹÄ czone. JeĹli ktĂłryĹ z elementĂłw nie bÄdzie poĹÄ czony z resztÄ to dane z takiego elementu nie mogÄ byÄ odniesione do innych np. jeĹli nie wprowadzimy jak zamontowany jest lidar na robocie to bÄdziemy wiedzieÄ jak dalego znajduje siÄ przeszkoda od lidaru, ale nie bÄdziemy wiedzieÄ jak blisko znajduje siÄ od np. przedniego zderzaka robota. - + +Po uruchomieniu TF Tree moĹźesz zobaczyÄ jak caĹa struktura jest zorganizowana. Dodatkowo, dziÄki temu narzÄdziu moĹźemy sprawdziÄ czy na pewno wszystko jest ze sobÄ poĹÄ czone. JeĹli ktĂłryĹ z elementĂłw nie bÄdzie poĹÄ czony z resztÄ to dane z takiego elementu nie mogÄ byÄ odniesione do innych np. jeĹli nie wprowadzimy jak zamontowany jest lidar na robocie to bÄdziemy wiedzieÄ jak daleko znajduje siÄ przeszkoda od lidaru, ale nie bÄdziemy wiedzieÄ jak blisko znajduje siÄ od np. przedniego zderzaka robota. +  - -W dowolnej chwili moĹźemy sprawdziÄ aktualne przesuniÄcie (transformacje) pomiÄdzy dwoma dowolnymi ukĹadami wspĂłĹrzÄdnych. MoĹźomy to zrobiÄ przy pomocy komendy: + +W dowolnej chwili moĹźemy sprawdziÄ aktualne przesuniÄcie (transformacje) pomiÄdzy dwoma dowolnymi ukĹadami wspĂłĹrzÄdnych. MoĹźemy to zrobiÄ przy pomocy komendy: ```bash rosrun tf tf_echo <nazwa ukĹadu wspĂłĹrzÄdnych> <nazwa ukĹadu wspĂłĹrzÄdnych> ``` - + @@@@@@@@@@ - +  - -Program tf co sekundÄ pokazuje nam odlegĹoĹÄ i zmianÄ orinetacji pomiÄdzy dwoma ukĹadami wspĂłĹrzÄdnych. PrzesuniÄcie okreĹlone jest kolejno w osiach X,Y,Z. Natomiast zmiana orientacji podana jest w trzech róşnych jednostkach. - - + +Program tf co sekundÄ pokazuje nam odlegĹoĹÄ i zmianÄ orientacji pomiÄdzy dwoma ukĹadami wspĂłĹrzÄdnych. PrzesuniÄcie okreĹlone jest kolejno w osiach X,Y,Z. Natomiast zmiana orientacji podana jest w trzech róşnych jednostkach. + + **Zadanie 3:** Uruchom tf_echo pomiÄdzy ukĹadami wspĂłĹrzÄdnych **katana_gripper_tool_frame** i **box**, a nastÄpnie ustaw koĹcĂłwkÄ robota na tyle blisko ukĹadu wspĂłĹrzÄdnych **box**, aby odlegĹoĹÄ w Ĺźadnej osi nie przekraczaĹa 0.2 m. - - - +----------- + +PrzechodzÄ c do pojazdĂłw, standardowa struktura ukĹadĂłw wspĂłĹrzÄdnych i ich nazewnictwo przedstawia siÄ nastÄpujÄ co: + + + +Standardowo wszystkie elementy umieszczone na robocie sÄ ostatecznie poĹÄ czone z ukĹadem **base_link**. NastÄpnie ukĹad **base_link** jest poĹÄ czony z ukĹadem **base_footprint**, ktĂłry jest rzutem na pĹaszczyznÄ ukĹadu **base_stabilized**, ale zwykle pomija siÄ ukĹad **base_stabilized** i zwykle siÄ go nie tworzy. + +Kolejne poĹÄ czenie jest tworzone pomiÄdzy **base_footprint**, a **odom**. Tym razem jest to juĹź poĹÄ czenie odpowiedzialne za lokalizacjÄ. Tak jak poprzednie ukĹady wspĂłĹrzÄdnych byĹy raczej statyczne wzglÄdem siebie, tak **base_footprint** i **odom** juĹź nie. Transformacja ta obrazuje przesuniÄcie robota wzglÄdem punktu poczÄ tkowego (poczÄ tkiem ukĹadu wspĂłĹrzÄdnych odom) i zwykle wykorzystywane sÄ do tego metody przyrostowe. Co waĹźne w systemie ROS przyjÄte jest, Ĺźe w tej transformacji nie mogÄ wystÄpowaÄ przeskoki w pozycji (pozycja musi zmieniaÄ siÄ w sposĂłb ciÄ gĹy). + +Ostatnim zaprezentowanym poĹÄ czeniem jest pomiÄdzy **odom** i **map**. To poĹÄ czenie pozwala pokazaÄ, gdzie robot znajduje siÄ na mapie. Tu mogÄ juĹź wystÄpowaÄ przeskoki w pozycji tzn. transformacja pomiÄdzy **map** i **odom** jest tak dobierana aby koĹcowa pozycja robota wzglÄdem mapy byĹa zgodna z rzeczywistoĹciÄ (dokonuje tego zwykle algorytm SLAM). + +Czasami stosuje siÄ jeszcze ukĹad wspĂłĹrzÄdnych **earth**, ktĂłra jest juĹź ostatecznym ukĹadem wspĂłĹrzÄdnych i zwykle odnosi siÄ do koordynatĂłw GPS. Ten ukĹad wspĂłĹrzÄdnych pozwala nam na odniesienie wzglÄdem siebie kilku map i przypisaÄ im rzeczywistÄ pozycjÄ na "Ĺwiecie" + +------ + +JeĹli znamy juĹź caĹÄ konwencjÄ tworzenia i nazewnictwa ukĹadĂłw wspĂłĹrzÄdnych, moĹźemy przejĹÄ do nawigacji zliczeniowej. +Zwykle pozycja w nawigacji zliczeniowej robotĂłw mobilnych jest okreĹlana na podstawie enkoderĂłw umieszczonych na koĹach. WiedzÄ c jak obrĂłciĹy siÄ koĹa moĹźemy obliczyÄ pozycjÄ robota na podstawie poniĹźszych wzorĂłw: + + + + +W systemie ROS obliczaniem odometri zakmuje siÄ program obsĹugujÄ cy fizyczne enkodery, natomiast juĹź w systemie posĹugujemy siÄ wadomoĹciÄ Odometry ([dokumnetacja](http://docs.ros.org/en/melodic/api/nav_msgs/html/msg/Odometry.html)). Zawiera ona zarĂłwno aktualnÄ pozycjÄ jak i prÄdkoĹÄ. Dodatkowo oba parametry sÄ opatrzone macierzÄ kowariancji, ktĂłra reprezentuje niepewnoĹÄ kaĹźdego z pomiarĂłw. + +Uruchom symulacjÄ robota turtlebot: +```bash +export TURTLEBOT3_MODEL=waffle +roslaunch turtlebot3_gazebo turtlebot3_world.launch +``` + +Uruchom RVIZ +```bash +export TURTLEBOT3_MODEL=waffle +roslaunch turtlebot3_gazebo turtlebot3_gazebo_rviz.launch +``` + +Uruchom program sterujÄ cy robotem +```bash +export TURTLEBOT3_MODEL=waffle +roslaunch turtlebot3_teleop turtlebot3_teleop_key.launch +``` + +**Zadanie 4:** Uruchom program rqt i zobacz jak wyglÄ dajÄ zaleĹźnoĹci pomiÄdzy ukĹadami wspĂłĹrzÄdnych w tym robocie. + +PrzejdĹş do programu RVIZ, zmieĹ ustawienie widoku na **ThirdPersonFollower**, zbliĹź kamerÄ do robota. WĹÄ cz wizualizacjÄ TF i wĹÄ cz widocznoĹÄ tylko nastÄpujÄ cych ukĹadĂłw **base_link**, **base_scan**, **base_link**, **wheel_right_link**, **wheel_left_link**, **odom**. Zmniejsz rozmiar zwizualizowanych ukĹadĂłw wspĂłĹrzÄdnych "Marker scale", tak aby nie przysĹaniaĹy modelu robota. + +@@@@@@@@@ + +**Zadanie 5:** Podejrzyj co dzieje siÄ na topicu **/odom**. ObserwujÄ c robota jak i topic **/odom** przejedĹş okoĹo 1 m do przodu symulowanym robotem. + +**Zadanie 6:** ZmieĹ staĹy ukĹad wspĂłĹrzÄdnych "Fixed Frame" z **odom** na **base_scan**. PrzejedĹş ponownie robotem jakÄ Ĺ odlegĹoĹÄ w dowolnym kierunku. Jak teraz prezentowane sÄ dane w programie RVIZ? + +@@@@ TU jeszcze pokazaÄ jak ukĹady przeskakujÄ @@@@@ + +------ + + +OprĂłcz pozycji czÄsto potrzebujemy rĂłwnieĹź orientacji robota. OrientacjÄ w trzech osiach moĹźemy uzyskaÄ dziÄki Ĺźyroskopowi, akcelerometrowi i magnetometrowi. Magnetometr jest bardzo podatny na zakĹĂłcenia, szczegĂłlnie w pomieszczeniach i wymaga dobrej kalibracji, aby dziaĹaĹ poprawnie. Z tego powodu zwykle uĹźywa siÄ jedynie Ĺźyroskopu i akcelerometru. Akcelerometr pozwala nam wyliczyÄ dokĹadny kÄ t Pitch i Roll na podstawie wektora grawitacji jednak tylko przy wolniejszych zmianach. DziÄki Ĺźyroskopowi jesteĹmy w stanie natomiast nadÄ ĹźaÄ, za szybkimi zmianami jednak wyliczanie orientacji na jego podstawie polega na caĹkowaniu prÄdkoĹci kÄ towych w kaĹźdej osi, co skutkuje ciÄ gle narastajÄ cym bĹÄdem. ĹÄ czÄ c dane z akcelerometru i Ĺźyroskopu moĹźemy ĹledziÄ szybkie zmiany orientacji, a zarazem zniwelowaÄ narastajÄ ce bĹÄdy dziÄki wektorowi grawitacji, ale niestety odnosi siÄ to tylko do kÄ tĂłw Roll i Pitch, poniewaĹź obrĂłt w osi Z (kÄ t Yaw) nie wpĹywa na odczyt wektora grawitacji. Z tego powodu kÄ t Yaw uzyskuje siÄ jedynie z Ĺźyroskopu i jest on obarczony narastajÄ cym bĹÄdem. Aby zniwelowaÄ ten bĹÄ d uĹźywa siÄ magnetometru, ktĂłry wskazuje biegun magnetyczny ziemi. MoĹźna rĂłwnieĹź wykorzystaÄ inne metody okreĹlania kÄ ta Yaw, jak np. uĹźycie dwĂłch odbiornikĂłw GPS zamontowanych na dwĂłch kraĹcach pojazdu. + +W nastÄpnym Äwiczeniu posĹuĹźymy siÄ sterownikiem pixhawk, ktĂłry zostaĹ podĹÄ czony do komputera przewodem USB. + + + +Na kontrolerze pixhawk zainstalowane jest oprogramowanie Ardupilot, pozwalajÄ ce na sterowanie pojazdami autonomicznymi ([dokumentacja](https://ardupilot.org/ardupilot/)). + +Istnieje wiele akcesoriĂłw do ukĹadu pixhawk, ktĂłre zwiÄkszajÄ jego moĹźliwoĹci jak: +- odbiornik RC +- GPS +- ZewnÄtrzny magnetometr +- Radiokomunikacja +- ... + +Na pokĹadzie pixhawka mamy do dyspozycji Ĺźyroskop, akcelerometr, magnetometr oraz barometr. Na potrzeby tego Äwiczenia wykorzystamy akcelerometr i Ĺźyroskop, aby okreĹliÄ orientacjÄ kontrolera. + +Aby odczytaÄ dane z kontrolera moĹźemy wykorzystaÄ dwie metody: +- program stacji bazowej np. [QGroundControl](http://qgroundcontrol.com/) czy [Mission Planner](https://ardupilot.org/planner/). W przypadku systemu Windows zalecam uĹźywanie programu Mission Planner, poniewaĹź posiada on duĹźo uĹźytecznych funkcjonalnoĹci. Niestety jest on dostÄpny jedynie na systemy Windows, dlatego na potrzeby laboratorium uĹźyjemy QGroundControl. Nie mniej jednak program QGroundControl jest rĂłwnieĹź bardzo uĹźytecznym programem, a zainstalowaÄ moĹźemy go nawet na telefonie z systemem Android. +- bezpoĹrednio przy pomocy protokoĹu mavlink. TÄ metodÄ stosuje siÄ gdy do sterownika podĹÄ czamy komputer, ktĂłry ma nadzorowaÄ jego pracÄ i wydawaÄ mu komendy, tak jak w naszym przypadku. diff --git a/lab04/img/mobile_robot_standard_tf.png b/lab04/img/mobile_robot_standard_tf.png new file mode 100644 index 0000000000000000000000000000000000000000..0b688fc5bea614150dc6b9cbaced8b5009939dcd Binary files /dev/null and b/lab04/img/mobile_robot_standard_tf.png differ diff --git a/lab04/img/odom_wzor.png b/lab04/img/odom_wzor.png new file mode 100644 index 0000000000000000000000000000000000000000..3a6630744a3fc4abd03b463bbc3e5ddf8eb7cfe7 Binary files /dev/null and b/lab04/img/odom_wzor.png differ diff --git a/lab04/img/orientation.png b/lab04/img/orientation.png new file mode 100644 index 0000000000000000000000000000000000000000..3ba49ec695abd7bac15344c3aa862e6728a38623 Binary files /dev/null and b/lab04/img/orientation.png differ diff --git a/lab04/img/pixhawk.png b/lab04/img/pixhawk.png new file mode 100644 index 0000000000000000000000000000000000000000..3d015f09a7f67f3df6fa906040b5fe54c894a280 Binary files /dev/null and b/lab04/img/pixhawk.png differ