Wprowadzenie do systemu operacyjnego robota: Ultimate Robot Application Framework

Robot Operating System (ROS) nie jest rzeczywistym systemem operacyjnym, ale strukturą i zestawem narzędzi, które zapewniają funkcjonalność systemu operacyjnego w heterogenicznym klastrze komputerów. Jego użyteczność nie ogranicza się do robotów, ale większość dostarczanych narzędzi skupia się na pracy ze sprzętem peryferyjnym.

ROS jest podzielony na ponad 2000 pakietów, z których każdy zapewnia specjalistyczną funkcjonalność. Liczba narzędzi podłączonych do frameworka to prawdopodobnie jego największa siła.

Dlaczego powinienem używać Robot OS?

ROS zapewnia funkcjonalność abstrakcji sprzętu, sterowników urządzeń, komunikacji między procesami na wielu maszynach, narzędzi do testowania i wizualizacji i wiele więcej.

Kluczową cechą ROS jest sposób działania oprogramowania i sposób, w jaki się ono komunikuje, co pozwala na projektowanie złożonego oprogramowania bez znajomości działania określonego sprzętu. ROS umożliwia połączenie sieci procesów (węzłów) z centralnym hubem. Węzły mogą działać na wielu urządzeniach i łączą się z tym koncentratorem na różne sposoby.

Główne sposoby tworzenia sieci to dostarczanie żądanych usług lub definiowanie połączeń wydawcy/subskrybenta z innymi węzłami. Obie metody komunikują się za pośrednictwem określonych typów wiadomości. Niektóre typy są dostarczane przez pakiety podstawowe, ale typy komunikatów mogą być definiowane przez poszczególne pakiety.

Deweloperzy mogą złożyć złożony system, łącząc istniejące rozwiązania małych problemów. Sposób wdrożenia systemu pozwala nam:

• Wymieniaj komponenty na podobne interfejsy w locie, eliminując potrzebę zatrzymywania systemu dla różnych zmian

• Multipleksowanie wyjść wielu komponentów w jedno wejście dla innego komponentu, umożliwiające równoległe rozwiązywanie różnych problemów

• Połącz komponenty wykonane w różnych językach programowania poprzez implementację odpowiednich złączy do systemu przesyłania wiadomości, co ułatwia tworzenie oprogramowania poprzez łączenie istniejących modułów różnych programistów

• Twórz węzły w sieci urządzeń, nie martwiąc się o to, gdzie jest uruchamiany kod, i wdrażaj systemy komunikacji międzyprocesowej (IPC) i zdalnego wywoływania procedur (RPC)

• Łącz się bezpośrednio z kanałami na żądanie ze zdalnego sprzętu bez pisania dodatkowego kodu, korzystając z dwóch poprzednich punktów

Planujemy zademonstrować, jak przydatne jest to, poprzez iteracyjne opracowywanie prostego rozwiązania. Istnieje kilka kluczowych zalet w porównaniu z innymi podejściami. ROS obsługuje wiele platform i umożliwia połączenia między procesami na wielu urządzeniach za pośrednictwem połączeń peer-to-peer, które są obsługiwane za sceną. Projekt umożliwia obsługę dowolnego języka poprzez owijanie klas komunikacyjnych C++ lub ręczne tworzenie klas dla interfejsu języka.

ROS jest tworzony przez własną społeczność, przeznaczoną dla jej społeczności. Po kilku latach zaowocowało to dużą ilością pakietów wielokrotnego użytku, które dzięki architekturze systemu są łatwe w integracji.

Alternatywne podejścia, takie jak MRPT, CARMEN, LCM, Player, Microsoft RDS i inne, zapewniają niektóre z tych funkcji, ale nie wszystkie. W większości przypadków wadami projektowymi są ograniczenia obsługi języka, niezoptymalizowana komunikacja między procesami lub brak obsługi różnych urządzeń, co jest prawdopodobnie najtrudniejszym problemem do naprawienia.

Co zbudujemy?

Ponieważ skupiamy się na strukturze, a nie na rzeczywistych algorytmach dla poszczególnych problemów, dany problem będzie dość prosty. Naszym celem jest zbudowanie oprogramowania na komputer pokładowy, które pozwoli nam zdalnie sterować i monitorować robota podłączonego do nas przez Wi-Fi, za pomocą gamepada na naszym komputerze i sygnału z kamery zamontowanej na robocie.

Przede wszystkim połączymy prosty program z prostą symulacją, aby zademonstrować podstawowe zasady działania ROS. Podłączymy gamepada do komputera i spróbujemy zaprojektować dobry schemat sterowania, aby zmienić wejście gamepada w sygnały sterujące dla robota.

Główne języki do pisania kodu ROS to C++ i Python, preferowany jest C++ ze względu na lepszą wydajność. Wyjaśnimy nasze przykłady w Pythonie ze względu na mniej schematu w kodzie i brak potrzeby jawnego budowania.

Instalacja i konfiguracja

Wersje ROS są określane po imieniu. Na ten dzień najnowszym wydaniem jest Jade Turtle , a najnowsza wersja LTS Indigo Igloo . Preferowane jest przejście na wersję LTS, a kompatybilność wsteczna nie jest gwarantowana w ROS, więc wszystkie przykłady zostaną napisane dla Indigo .

ROS jest dostępny na różnych platformach *NIX. Oficjalnie obsługiwana wersja znajduje się na Ubuntu. Wersje OS X, Arch Linux, Debian, Raspbian i Android są obsługiwane przez społeczność.

Przejdziemy przez proces instalacji Ubuntu 14.04 na komputerze. Procesy dla wszystkich obsługiwanych wersji i platform są dostępne na oficjalnej stronie internetowej. Dostępne są również maszyny wirtualne z zainstalowanym ROS.

Instalacja jest zależna od platformy (i większość platform ma dostarczone pakiety), ale konfiguracja obszaru roboczego jest taka sama dla wszystkich platform.

Instalacja na Ubuntu

ROS udostępnia własne repozytoria. Pierwszym krokiem jest ich dodanie.

 sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list' sudo apt-key adv --keyserver hkp://pool.sks-keyservers.net --recv-key 0xB01FA116 sudo apt-get update

Następnie będziesz mieć wszystkie hostowane pakiety dla wszystkich wersji ROS dostępne dla Twojej wersji Ubuntu. Na przykład Ubuntu 14.04 obsługuje indigo i jade .

Instalacja pakietów podstawowych na komputerze stacjonarnym ma jedną z trzech opcji:

• sudo apt-get install ros-indigo-ros-base dla minimalnej instalacji

• sudo apt-get install ros-indigo-desktop za posiadanie podstawowych dodatkowych narzędzi GUI

• sudo apt-get install ros-indigo-desktop-full , aby mieć wszystkie oficjalne funkcje, w tym różne symulatory i biblioteki do nawigacji i percepcji

Aby uzyskać najlepsze wrażenia z pracy, zalecana jest pełna opcja. Do instalacji na urządzeniach, które będą używane tylko do uruchamiania węzłów, wystarcza wersja podstawowa. Bez względu na wybraną opcję, możesz zainstalować dowolny potrzebny pakiet o nazwie package_name , uruchamiając:

 sudo apt-get install ros-indigo-<package-name>

Podkreślenia są zastępowane myślnikami w końcowej nazwie, więc stage_ros będzie w pakiecie ros-indigo-stage-ros .

Następnym krokiem jest zainicjowanie rosdep . Pakiety w ROS mogą deklarować, od jakich komponentów zależą. rosdep pozwala skompilować te pakiety bez zbytniej ręcznej obsługi zależności. Aby go zainicjować, zadzwoń:

 sudo rosdep init rosdep update

ROS ma kilka zmiennych środowiskowych używanych przez jego narzędzia. Przy domyślnej instalacji skrypt bash do ich inicjalizacji znajduje się w /opt/ros/indigo/setup.bash . Zmienne muszą być inicjowane w każdej sesji bash, więc najlepszym rozwiązaniem jest dodanie ich do ~/.bashrc .

 echo "source /opt/ros/indigo/setup.bash" >> ~/.bashrc source ~/.bashrc

Niektóre pakiety instalują zewnętrzne zależności za pośrednictwem rosinstall , który jest dostępny jako pakiet i instalowany za pośrednictwem sudo apt-get install python-rosinstall .

To koniec instalacji na Ubuntu. Poniżej znajduje się krótkie wprowadzenie do instalacji obszarów roboczych.

Konfiguracja

Od czasu Groovy Galapagos , przestrzenie robocze ROS są zarządzane przez catkin . Musimy zdefiniować katalog dla wszystkich pakietów, które obsługujemy. Wewnątrz katalogu tworzymy folder src i wywołujemy w nim formularz catkin_init_workspace . Spowoduje to utworzenie różnych dowiązań symbolicznych do aktualnie pobranej wersji ROS. Następnym krokiem jest dodanie tego obszaru roboczego również do zmiennych środowiskowych.

Aby wykonać całą konfigurację obszaru roboczego, wybierz pusty katalog i wykonaj następujące polecenia:

 mkdir src cd src catkin_init_workspace cd .. catkin_make echo "source $(pwd)/devel/setup.bash" >> ~/.bashrc source ~/.bashrc

Utworzyłeś teraz obszar roboczy, w którym możesz tworzyć własne pakiety ROS.

Zapoznanie się z narzędziami

Tworzenie dowolnego kodu to duży skok. Najpierw zapoznajmy się z niektórymi systemami działającymi za kulisami. Naszym pierwszym krokiem będzie uruchomienie podstawowego GUI i sprawdzenie, jakie wiadomości generuje.

Aby uruchomić cokolwiek w ROS, należy uruchomić podstawowy proces. To tak proste, jak otwarcie nowego okna terminala i wpisanie:

 roscore

W całej połączonej sieci urządzeń roscore musi zostać uruchomiony tylko raz, na urządzeniu, które będzie obsługiwać centralny hub do rozsyłania komunikacji.

Główną rolą roscore jest informowanie węzłów, z jakimi innymi węzłami powinni się łączyć iw jaki sposób (przez port sieciowy lub pamięć współdzieloną). Celem jest umożliwienie węzłom dbania tylko o to, jakie dane chcą znać, a nie z jakim węzłem, z którym chcą się połączyć, przy jednoczesnym zminimalizowaniu czasu i przepustowości potrzebnej do przeprowadzenia całej komunikacji.

rqt

Po uruchomieniu roscore możemy uruchomić główne narzędzie GUI dla ROS: rqt . To, co widzimy, jest bardzo rozczarowujące - puste okno. rqt udostępnia szeroką gamę wtyczek, które można skonfigurować w dowolnej konfiguracji wizualnej i dowolnej liczbie predefiniowanych widoków.

Na początek uruchommy wtyczkę Robot Steering , wybierając ją w Plugins > Robot Tools > Robot Steering . To, co otrzymujemy, to dwa suwaki, reprezentujące ruch liniowy i obrotowy, jaki ma mieć nasz robot. W górnej części wtyczki widzimy pole tekstowe z /cmd_vel w nim. Możemy zmienić jego nazwę na cokolwiek zechcemy. Reprezentuje nazwę tematu, w którym publikuje sterowanie. Narzędzia terminala to najlepsze miejsce, aby zobaczyć, co dzieje się w tle.

Narzędzia terminala

ROS ma kilka potężnych narzędzi do sprawdzania tego, co dzieje się w systemie. Pierwszym narzędziem, które wprowadzimy, jest rostopic . Pozwala nam sprawdzać tematy, które węzły mogą subskrybować i publikować. Uruchomienie rostopic list przyniesie:

 /cmd_vel /rosout /rosout_agg

Ostatnie 2 tematy są zawsze aktywne i dotyczą centralnych systemów ROS. Temat /cmd_vel jest publikowany przez nasze sterowanie. Zmiana nazwy tematu w kierownicy spowoduje również zmianę nazwy. Teraz interesuje nas, co się dzieje w tym temacie. Uruchomienie rostopic echo /cmd_vel nie pokaże nam niczego (chyba że majstrowałeś przy suwakach). Proces trwa, dopóki go nie anulujemy. Przesuńmy teraz suwak pionowy na 20 m/s. Patrząc na echo, widzimy powtarzające się w kółko następujące:

 linear: x: 0.2 y: 0.0 z: 0.0 angular: x: 0.0 y: 0.0 z: 0.0

Jak często spamuje tę wiadomość? rostopic hz /cmd_vel mówi ze średnią częstotliwością 10 Hz. Cóż, ile takich tematów mogę uruchomić przez moje wolne połączenie Wi-Fi? rostopic bw /cmd_vel wykrywa średnio 480 B/s.

Teraz wszystko dobrze, ale rozmawialiśmy o typach wiadomości. Te dane są dobre dla człowieka, ale aplikacja będzie potrzebować nieprzetworzonych danych i będzie musiała znać typ wiadomości, aby móc zinterpretować dane. Typ można określić za rostopic type /cmd_vel , co oznacza, że ​​jest to geometry_msgs/Twist . Wszystkie narzędzia terminalowe ROS wywoływane bez żadnych argumentów zwracają standardowy komunikat pomocy.

ROS Wiki jest na tyle dobra, że ​​wyszukiwanie tego ciągu w sieci spowoduje wyjaśnienie na Wiki, co zawiera i jak ma strukturę. Ale nie musimy na tym polegać. rosmsg to ogólne narzędzie dla typów wiadomości. Uruchomienie rosmsg show geometry_msgs/Twist zwróci:

 geometry_msgs/Vector3 linear float64 x float64 y float64 z geometry_msgs/Vector3 angular float64 x float64 y float64 z

Wiadomość składa się z dwóch wektorów 3D, reprezentujących prędkość liniową i kątową w przestrzeni 3D.

Jeśli chcemy, z jakimi tematami jest połączony węzeł, rosnode info <node-name> poda nam szczegółowe dane o węźle. Narzędzia rostopic , rosmsg i rosnode są głównymi narzędziami do sprawdzania funkcjonalności surowego ROS. ROS ma o wiele więcej GUI i narzędzi terminalowych, ale są one poza naszym zakresem tego wprowadzenia.

Główne narzędzia do uruchamiania węzłów ROS to rusrun i roslaunch . rosrun może uruchamiać węzły poprzez rosrun <package_name> <node_name> , a roslaunch uruchamia węzły w oparciu o pliki uruchamiania, z którymi zapoznamy się w niewielkim stopniu, ponieważ są one najbardziej złożonym elementem automatyzacji ROS.

Możemy zamknąć wszystko, co uruchomiliśmy, aby rozpocząć pracę nad naszym pierwszym kodem. Na przyszłość nie trzeba dodawać, że uruchamianie czegokolwiek związanego z ROS wymaga aktywnej instancji roscore . Wiele problemów, które napotkasz, można rozwiązać, zamykając okno terminala, w którym działa roscore , i otwierając nowe, aby je ponownie uruchomić. To aktualizuje wszystkie zależności, które musiały zostać ponownie załadowane, zarówno w bash , jak i roscore .

Tworzenie teleoperacji Gamepad

Naszym pierwszym celem jest naśladowanie funkcjonalności Robot Steering poprzez utworzenie węzła, który publikuje dane geometry_msgs/Twist do /cmd_vel na podstawie danych wejściowych z gamepada. Naszym pierwszym przystankiem jest pakiet joy .

Pakiet joy

Pakiet joy zapewnia ogólne sterowniki ROS dla joysticków i gamepadów. Nie jest zawarty w domyślnej instalacji, więc należy go zainstalować za pomocą:

 sudo apt-get install ros-indigo-joy

Po instalacji możemy uruchomić rosrun joy joy_node . To połączy nas z domyślnym joystickiem lub gamepadem. Uruchomienie rostopic list pokazuje nam, że mamy temat o nazwie /joy . Słuchanie go za rostopic echo pokazuje nam wiadomości w następującym formacie (pamiętaj, że musisz wchodzić w interakcję z gamepadem lub joystickiem, aby wiadomości zostały opublikowane).

 header: seq: 4156 stamp: secs: 1450707466 nsecs: 204517084 frame_id: '' axes: [0.0, 0.0, 0.0, -0.0, 0.0, 0.0, 0.0, 0.0] buttons: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

Na razie możesz zignorować nagłówki. Poza tym mamy axes i buttons , które ładnie wyjaśniają, co reprezentują. Poruszanie osiami i naciskanie przycisków na kontrolerze spowoduje zmianę tych liczb. Korzystając z naszych narzędzi możemy określić, że typ wiadomości to sensor_msgs/Joy , a format to:

 std_msgs/Header header uint32 seq time stamp string frame_id float32[] axes int32[] buttons

Tworzenie naszej teleoperacji

Pierwszym krokiem do napisania kodu jest stworzenie pakietu. W folderze src obszaru roboczego uruchom:

 catkin_create_pkg toptal_tutorial rospy joy geometry_msgs sensor_msgs

Tutaj podajemy nazwę pakietu, który tworzymy, a następnie pakiety, na których planujemy polegać. Bez obaw, zależności można później zaktualizować ręcznie.

Mamy teraz folder toptal_tutorial . W folderze utwórz folder scripts , w którym będą przechowywane wszystkie nasze skrypty Pythona.

Stwórzmy plik o nazwie teleop.py , aw nim ustawimy:

 #!/usr/bin/env python import rospy from sensor_msgs.msg import Joy def joy_callback(data): print data def main(): rospy.init_node('teleop') rospy.Subscriber('joy', Joy, joy_callback) while not rospy.is_shutdown(): pass if __name__ == '__main__': main()

Musimy również ustawić chmod +x teleop.py , aby skrypt mógł działać. Uruchomienie rosrun joy joy_node w jednym terminalu i rosrun toptal_tutorial teleop.py w innym spowoduje, że wyjście terminala teleop.py zostanie wypełnione wiadomościami Joy.

Sprawdźmy, co robi kod.

Najpierw importujemy rospy, który obsługuje bibliotekę do interakcji z frameworkiem ROS. Każdy pakiet definiujący wiadomości ma podpakiet msg z definicjami wiadomości. Importujemy Joy do obsługi danych wejściowych. Nie ma potrzeby importowania osadzonych typów wiadomości (takich jak Header z std_msgs.msg , który znajduje się w wiadomości Joy ), chyba że chcemy je wyraźnie wymienić.

Naszym pierwszym krokiem jest zainicjowanie węzła o określonej nazwie (w tym przypadku nazywamy go „teleop”). Następnie tworzymy subskrybenta, który subskrybuje temat „joy” typu sensor_msgs.msg.Joy , który obsługuje każdą wiadomość przez wywołanie funkcji joy_callback . Callbacki otrzymują jeden parametr, dane z wiadomości. Dostęp do członków danych jest prosty. Gdybyśmy chcieli wydrukować stan pierwszej osi, jeśli przypomnimy sobie typ wiadomości, print data.axes[0] i będzie to zmiennoprzecinkowa. Pętla na końcu zapętla się, dopóki ROS nie zostanie wyłączony.

Naszym następnym krokiem byłoby jakoś obsłużyć nasze dane. Powinniśmy utworzyć wiadomość Twist, która zmienia się w zależności od danych wejściowych, a następnie opublikujemy ją w temacie cmd_vel .

 #!/usr/bin/env python import rospy from sensor_msgs.msg import Joy from geometry_msgs.msg import Twist # new from functools import partial # new def joy_callback(pub, data): # modified cmd_vel = Twist() # new cmd_vel.linear.x = data.axes[1] # new cmd_vel.angular.z = data.axes[0] # new pub.publish(cmd_vel) # new def main(): rospy.init_node('teleop') pub = rospy.Publisher('cmd_vel', Twist, queue_size=1000) # new rospy.Subscriber('joy', Joy, partial(joy_callback, pub)) # modified while not rospy.is_shutdown(): pass if __name__ == '__main__': main()

Najpierw dodajemy komunikat Twist i dodajemy obsługę wiązania argumentów funkcji poprzez functools.partial . Tworzymy wydawcę pub , który publikuje do cmd_vel wiadomość typu Twist . Przywiązujemy tego wydawcę do wywołania zwrotnego i każemy mu publikować komunikat Twist na każdym wejściu, z prędkościami reprezentowanymi przez pierwsze dwie osie. Ten kod robi to, czego oczekujemy, a wynikowe dane wyjściowe możemy zobaczyć za pomocą rostopic echo /cmd_vel .

Nadal mamy jeden problem. Temat /joy może publikować z dużą szybkością. Jeśli monitorujemy rostopic hz /cmd_vel i poruszamy gałką analogową w kółko, możemy zobaczyć dużą liczbę komunikatów. Powoduje to nie tylko dużą ilość komunikacji, ale procesy, które odbierają te wiadomości, muszą przetworzyć każdy z nich. Nie ma potrzeby publikowania tych danych tak często, a lepiej jest publikować je ze stałą częstotliwością 10 Hz. Możemy to osiągnąć za pomocą następującego kodu.

 #!/usr/bin/env python import rospy from sensor_msgs.msg import Joy from geometry_msgs.msg import Twist from functools import partial def joy_callback(cmd_vel, data): # modified cmd_vel.linear.x = data.axes[1] cmd_vel.angular.z = data.axes[0] # moved pub.publish(cmd_vel) to main loop def main(): rospy.init_node('teleop') cmd_vel = Twist() # new pub = rospy.Publisher('cmd_vel', Twist, queue_size=1000) rospy.Subscriber('joy', Joy, partial(joy_callback, cmd_vel)) # modified rate = rospy.Rate(10) # new while not rospy.is_shutdown(): pub.publish(cmd_vel) # new rate.sleep() # new if __name__ == '__main__': main()

Zmodyfikowaliśmy wywołanie zwrotne, aby otrzymać zmienny obiekt Twist i zmodyfikować go w pętli. Funkcja sleep od rospy.Rate utrzymuje stabilną częstotliwość wyjściową.

Ostateczny kod spowoduje, że temat /cmd_vel polecenia prędkości przy 10 Hz, imitując wyjście wtyczki Robot Steering rqt .

Uruchamianie systemu symulowanego

Symulacja świata

Naszym pierwszym celem jest stworzenie środowiska, w którym możemy zasymulować scenariusz, który chcemy osiągnąć. Węzeł stageros w pakiecie stage_ros pozwala nam uruchomić jednego robota na etapie 2D zdefiniowanym za pomocą obrazu. Istnieje cała składnia opisana w pakiecie stage_ros dla plików świata i sposobu ich generowania. To dość proste, ale wykracza poza nasz zakres. Na szczęście pakiet zawiera kilka światów demonstracyjnych. Najpierw przejdźmy do katalogu plików, uruchamiając:

 roscd stage_ros cd world

W folderze znajduje się kilka plików. Przeprowadźmy jeden.

 rosrun stage_ros stageros willow-erratic.world

To stworzyło kilka tematów. Znaczenie każdego z nich jest również udokumentowane w pakiecie. Ważną częścią jest to, że ma cmd_vel .

Na wyświetlonej scenie znajduje się niebieski kwadrat, reprezentujący robota, którym sterujesz. Używając naszego kodu lub Sterowania robotem , możemy sterować tym robotem. Wypróbuj to.

Konfiguracja naszego systemu poprzez pliki startowe

stwórzmy folder launch w naszym pakiecie i utwórzmy w nim plik o nazwie teleop.launch . Ostateczna struktura folderów powinna wyglądać tak:

 toptal_tutorial/ ├── CMakeLists.txt ├── launch │ └── teleop.launch ├── package.xml ├── scripts │ └── teleop.py └── src

W pliku teleop.launch zdefiniujemy zbiór węzłów i ich wzajemne połączenia.

 <launch> <arg name="world_file" default="$(find stage_ros)/world/willow-four-erratics-multisensor.world" /> <node pkg="stage_ros" type="stageros" name="simulated_world" args="$(arg world_file)"></node> <group ns="robot_0"> <node pkg="joy" type="joy_node" name="joy_input"></node> <node pkg="toptal_tutorial" type="teleop.py" name="joy_convert"></node> </group> </launch>

Nowy świat składa się z czterech robotów, a każdy z ich tematów ma przedrostek robot_<n> . Tak więc robot numer 0 ma temat dotyczący komend prędkości o nazwie robot_0/cmd_vel . Dlatego umieszczamy naszą kontrolę w przestrzeni nazw o nazwie robot_0 , aby dostosować ich nazwy do nowej formy. W tym sensie możesz myśleć o nazwach tematów jako folderach w systemie plików.

Aby uruchomić pliki uruchamiania, nie jest potrzebny roscore . W pewnym sensie roscore to tylko specjalny przypadek pliku startowego, który nic nie robi. Jeśli brakuje roscore , tylko pierwszy uruchomiony plik uruchamia rdzeń, podczas gdy reszta połączy się z nim. Teraz uruchamiamy uruchomienie z:

 roslaunch toptal_tutorial teleop.launch

Jeśli wszystko się zgadza, powstanie symulator z 4 robotami, z których jednym sterujemy za pomocą naszego gamepada lub joysticka. Ten świat ma pod maską znacznie więcej niż poprzedni. Każdy z czterech robotów posiada:

 /robot_<n>/base_pose_ground_truth /robot_<n>/base_scan_0 /robot_<n>/base_scan_1 /robot_<n>/camera_info_0 /robot_<n>/camera_info_1 /robot_<n>/cmd_vel /robot_<n>/depth_0 /robot_<n>/depth_1 /robot_<n>/image_0 /robot_<n>/image_1 /robot_<n>/odom

Zamieniamy <n> na 0, 1, 2 lub 3. To prowadzi nas do naszego ostatniego tematu.

Przeglądanie naszych danych za pomocą rqt

Nie zagłębialiśmy się zbytnio w rqt , ale jest to idealne narzędzie do przeglądania bardziej złożonych danych. Możesz eksperymentować ze wszystkimi tematami, ale skupimy się na image_0 , image_1 , depth_0 i depth_1 .

rqt i usuńmy wszystkie otwarte wtyczki. Teraz otworzymy 4 wizualizatory obrazów ( Plugins > Visualization > Image View ) i umieścimy je w formacji siatki 2x2. Na koniec w lewym górnym rogu każdego z widoków wybierzmy jeden z czterech podanych tematów dla robot_0 .

To, co otrzymujemy, to widzenie stereo z percepcją głębi, za pomocą kamer o niskiej rozdzielczości. Pamiętaj, że moglibyśmy nawet uzyskać ten wynik bez naszego systemu wprowadzania danych. Jeśli po prostu uruchomimy to (z folderu stage_ros/world ):

 rosrun stage_ros stageros willow-four-erratics-multisensor.world

i dodaj wtyczkę Robot Steering z tematem o nazwie /robot_0/cmd_vel , otrzymalibyśmy te same wyniki, gdy kontrolki byłyby suwakami na ekranie.

Zastosowanie wyników do rzeczywistego systemu

Wiele sprzętu ma pełne wsparcie dla ROS, bardzo często dostarczane przez wolontariuszy zewnętrznych. Wiele platform robotów ma sterowniki, które generują tego typu wiadomości, a ROS ma węzły, które pobierają kamerę internetową i publikują obraz.

O ile ostatni wynik był symulacją tego, co chcemy osiągnąć, to to samo można osiągnąć z następującymi modyfikacjami:

• Zainstaluj ROS na komputerze pokładowym swojego robota
• Utwórz plik startowy dla komputera pokładowego, który łączy ROS z platformą bazową i wszystkimi czujnikami wysokiego poziomu, takimi jak kamery, dalmierze laserowe i inne. Niezbędne węzły mogą już istnieć lub mogą zostać zaimplementowane poprzez utworzenie wydawcy/subskrybenta ROS z jednej strony i sterownika do komunikacji szeregowej z drugiej
• Uruchom plik startowy podczas uruchamiania
• Na zdalnym komputerze dodaj export ROS_MASTER_URI=http://<robot_hostname>:11311/ do swojego startu bash, dzięki czemu zdalny komputer będzie szukał roscore na tej podanej nazwie hosta i porcie
• Uruchom rqt i/lub dowolne skrypty do monitorowania i sterowania robotem

To, co tak naprawdę sprowadza się do tego, to po prostu wyeksportowanie odpowiedniej zmiennej środowiskowej na zdalnym urządzeniu, a reszta sama się obsługuje. Uruchamianie ROS w klastrze komputerów wymaga tylko wykonania jednego kroku dla każdej maszyny.

Wniosek

Pokazaliśmy, jak przy bardzo niewielkim kodowaniu możesz mieć złożony system zmiennych, którymi możesz manipulować według własnego uznania. Prosty system wydawcy/subskrybenta pozwala szybko opracować potok oprogramowania, który przetwarza dane w klastrze komputerów, nie martwiąc się o podstawową implementację niektórych elementów.

Podczas gdy używaliśmy prostego symulatora, bardziej złożone symulatory, takie jak gazebo (również zawarte w pełnej wersji na komputery stacjonarne), pozwalają tworzyć światy 3D z fizyką i złożonymi czujnikami, a także mogą dać Ci wrażenia z końcowych wyników i produktu na długo przed jego opracowaniem.

To wprowadzenie było bardzo podstawowe, ale mamy nadzieję, że bardziej zainteresowała Cię praca z tym wszechstronnym frameworkiem.