Lab 05 - Laboratoria problemowe 1

Lab. 05 - Laboratorium problemowe 1 - “Robot poszukujący”

Robot TurtleBot3 patrzący kamerą na kostkę z ArucoTagiem.

1. Laboratoria problemowe

W ramach laboratorium problemowego stawiany jest przed Państwem problem, zagadnienie, które wymaga pracy własnej, szukania rozwiązań, kreatywnego podejścia.

Efektem tego laboratorium nie musi być rozwiązanie problemu. Skupiamy się tutaj na możliwych podejściach, rozważaniu co może zadziałać a co nie zadziała, jakie potencjalne problemy możemy napotkać.

Wynikiem końcowym ma być krótki raport (wiecej na dole instrukcji) oraz ewentualnie program realizujący rozwiązanie problemu. Raport będzie oceniany jak standardowe zadanie domowe, natomiast za implementację możliwe jest do uzyskania dodatkowo do 5 punktów.

2. Problem

Dany jest robot TurtleBot3 typu waffle. Robot funkcjonuje w środowisku z gotową mapą, jest się w stanie w nim lokalizować. Jest wyposażony w skaner laserowy o zasięgu 3,5 metra oraz kamerę RGB.

W środowisku, po uruchomieniu, umieszczane są w 5 losowych punktach kostki z tagami ArUco (ze słownika ARUCO_ORIGINAL). Punkty są losowane spośród wolnych miejsc na mapie, z odstępem od ścian, mebli i pozostałych kostek. Zakładamy, że robot nie zna przybliżonych położeń kostek.

Robot ma autonomicznie przeszukiwać środowisko i lokalizować położenie wszystkich 5 kostek wraz z ich ID.

Zadanie powinno być realizowane jako akcja, gdzie wynikiem jest pozycja wszystkich kostek.

3. Przygotowanie środowiska

Przed przystąpieniem do pracy należy przygotować środowisko: Instrukcja przygotowania środowiska do zajęć. Obraz bazuje na osrf/ros:jazzy-desktop-full (ROS 2 Jazzy Jalisco) z symulatorem Gazebo Harmonic.

Domyślnie kontener nosi nazwę ARM_05.

UWAGA! Skrypty po uruchomieniu usuwają kontener o takiej nazwie przed utworzeniem nowego.

Korzystanie z kontenera

Po każdym ponownym uruchomieniu komputera, proszę pamiętać o wywoływaniu:

xhost +local:root

Nowy terminal można dołączyć do kontenera korzystając z polecenia:

docker exec -it ARM_05 bash

ROS_DOMAIN_ID

W przypadku pracy na wielu komputerach w tej samej sieci lokalnej (eduroam też może tego wymagać), konieczne może być ustawienie zmiennej środowiskowej ROS_DOMAIN_ID na różnych wartościach. Należy wybrać dowolną liczbę całkowitą z zakresu 0-100. Wartość tę należy ustawić w pliku ~/.bashrc:

export ROS_DOMAIN_ID=10  # przykładowa wartość

lub bezpośrednio w terminalu (wtedy będzie obowiązywać tylko w tym terminalu):

export ROS_DOMAIN_ID=10  # przykładowa wartość

Sugerowane jest użycie dwóch ostatnich cyfr numeru IP komputera jako wartości ROS_DOMAIN_ID, aby uniknąć konfliktów z innymi użytkownikami w sieci. Aby sprawdzić swój adres IP, można użyć polecenia:

ip addr show

adres IP będzie widoczny przy interfejsie sieciowym, np. wlan0 lub eth0.

Wygodne może być dodanie tego exportu do bashrc:

echo 'export ROS_DOMAIN_ID=<wybrana_wartość>' >> ~/.bashrc

Gazebo: GZ_IP i GZ_PARTITION

Gazebo komunikuje się niezależnie od ROS 2 (biblioteka gz-transport), więc ROS_DOMAIN_ID nie rozdziela symulacji. Domyślnie Gazebo łączy ze sobą symulacje uruchomione przez tego samego użytkownika na komputerach o tej samej nazwie (hostname), a kontener uruchomiony z --network=host przejmuje nazwę komputera i działa jako root. Jeżeli komputery w sieci mają takie same nazwy, symulacje różnych osób mogą się wzajemnie zakłócać.

Dlatego w obrazie, w pliku ~/.bashrc, ustawiona jest zmienna GZ_IP=127.0.0.1, dzięki której Gazebo komunikuje się tylko w obrębie jednego komputera. W kontenerach utworzonych ze starszej wersji obrazu (polecenie echo $GZ_IP nic nie wypisuje) należy ją dopisać samodzielnie:

echo 'export GZ_IP=127.0.0.1' >> ~/.bashrc

Jeżeli na jednym komputerze działa kilka symulacji (np. w kilku kontenerach), można je dodatkowo rozdzielić, ustawiając w każdym kontenerze inną wartość zmiennej GZ_PARTITION (węzły Gazebo widzą się nawzajem tylko w obrębie tej samej partycji):

echo 'export GZ_PARTITION=<wybrana_nazwa>' >> ~/.bashrc  # np. arm_10

Wartość GZ_PARTITION musi być taka sama we wszystkich terminalach, w których korzysta się z Gazebo (uruchomienie symulacji, polecenia gz), dlatego lepiej ustawić ją w ~/.bashrc niż w pojedynczym terminalu. Zmiany w ~/.bashrc obowiązują w nowo otwartych terminalach, więc po ich wprowadzeniu należy ponownie uruchomić symulację.

4. Uruchomienie symulacji

W tej instrukcji będziemy ponownie wykorzystywać robota TurtleBot3 (waffle), tym razem w świecie arm_house.world z paczki arm05_sim. Można ją uruchomić poleceniem

cd /arm_ws
source install/setup.bash
ros2 launch arm05_sim world.launch.py

Pierwsze uruchomienie może trochę potrwać, wymagana jest odrobina cierpliwości.

Razem z symulacją uruchamiany jest stos nawigacyjny Nav2 z gotową mapą środowiska. AMCL startuje z pozycją początkową robota (0, 0), więc od razu można wysyłać cele nawigacyjne, np. akcją /navigate_to_pose albo przyciskiem Nav2 Goal w RViz. RViz z konfiguracją Nav2 można uruchomić w osobnym terminalu:

ros2 launch nav2_bringup rviz_launch.py use_sim_time:=true

Obraz z kamery publikowany jest na topicu /camera/image_raw. TurtleBot3 w ROS 2 Jazzy przyjmuje na topicu /cmd_vel wiadomości geometry_msgs/msg/TwistStamped.

Podczas uruchamiania w losowych miejscach są spawnowane kostki ArUco (pokazane poniżej). Za każdym razem będą one w innym położeniu. Kostka jest sześcianem o boku 9 cm.

Po uruchomieniu symulacji, pozycje kostek są zapisywane w folderze /root/.ros/arm05_sim/logs. Nazwy plików to sygnatury czasowe, ale zawsze ostatnie uruchomienie jest zapisywane w pliku latest.txt. W ten sposób można sprawdzić dokładność działania proponowanego systemu.

5. Zadanie do samodzielnej realizacji

W ramach zajęć należy zaproponować sposób rozwiązania problemu postawionego w punkcie 2.

Efektem ma być przygotowanie raportu, który będzie zawierał proponowaną strukturę programu (wraz z node’ami i topicami, które będą one wymieniać), paczki z sieci, które można wykorzystać do realizacji zadania oraz opis potencjalnych problemów, na które można napotkać.

Raport powinien mieć następujące elementy:

Cel i założenia – krótki opis problemu oraz przyjętych ograniczeń.
Strategia działania – najważniejsze kroki algorytmu oraz podział odpowiedzialności między node’ami.
Schematy i diagramy – diagramy blokowe, diagramy przepływu danych między node’ami itp.
Wykorzystane narzędzia – biblioteki, paczki ROS2 i inne zasoby zewnętrzne.
Potencjalne ryzyka – spodziewane trudności, sposoby ich weryfikacji lub obejścia.
Wnioski – podsumowanie, możliwe kierunki dalszego rozwoju.

Program

Opcjonalnie, można również przygotować program realizujący postawione zadanie (wraz z jego opisem w ramach raportu). Za implementację można otrzymać dodatkowo do 5 punktów.

_{Autor: Kamil Młodzikowski}