H ROS kiskáté

Tartalom

• ROS workspace felépítése
• Munkaterületek source fájljainak hanszálata
  • Belépési útvonalak problémájának feloldása

ROS workspace felépítése (#ros-ws-structure)

Fő forrás: http://wiki.ros.org/catkin/Tutorials/create_a_workspace

Workspace-ek és ROS fájlstruktúra: http://wiki.ros.org/catkin/workspaces

Specifikáció az elnevezésekre (REP 128): https://www.ros.org/reps/rep-0128.html

A workspace (munkaterület) alapvetően az a fájlstruktúra, amelyben a szoftver fejlesztését végezzük. Általánosan elmondható, hogy a következő fájlstruktúrát szeretnénk tartani (mappák elrendezése):

• src : Forrásfájlok, szkriptek és indítófájlok. Amellett, hogy a programok forrásfájljait tartalmazza, jellemzően itt szoktuk tárolni a kiegészítő forrásokat (launch, YAML paraméter fájlok).
  • A csomagok tartalmaznak csomópontokat (futtatható állományok) és (statikus/dinamikus) könyvtárakat. Új csomagokat célszerű a választott toolchain eszközével létrehozni.
• build: a fordítás során keletkező köztes fájlok. Ez alapvetően egy nagyon változó mappa, explicit nem szerencsés semmit sem itt egyénileg elhelyezni.
• devel vagy install: a lefordított fájlok és az egyéb telepítendő fájlok. Jellemzően válotzó mappa, explicit nem szerencsés itt tárolni saját fájlokat. A lefordított csomópontok (programok), könyvtárak ebben a mappában tárolandók.
  • A könyvtárak a devel/lib mappában.
  • A csomópontok a csomópontot tartalmazó csomag mappájában találhatók.

Az ROS a következő toolchaineket alkalmazza az aktuális munkaterület lefordításához:

• catkin (kifejlett, ROS 1 toolchain). Célszerű a catkin_tools használata a beépített catkin_make helyett (fleixibilisebb fordítás, dependenciák felismerése, stb.)
• colcon (jellemzően ROS 2-höz alkalmazott toolchain).

Példa: munkaterület létrehozása

Ez gyakorlatilag csak egy új mappa létrehozását jelenti. Például ha a munkaterületünket a catkin_ws mappában szeretnénk elhelyezni (a névválasztás egyéni):

mkdir -p ~/catkin_ws/src

A munkaterület gyökérmappája a következő paranccsal érhető el:

cd ~/catkin_ws

A gyökérmappában fordítható újra a munkaterület csomagjai és alapvetően a belépési pontokat is itt tároljuk, határozzuk meg.

Példa: csomag létrehozása (catkin)

Váltsunk a munkaterület forrásmappájába:

cd ~/catkin_ws/src

Catkin toolchain segítségével hozzuk létre az új csomagot. Szisztematika: csomag elnevezése és a csomag (futás- és fordításidejű) dependenciái.

Például az uj_csomag csomag dependenciái a roscpp rospy és std_msgs:

catkin_create_pkg uj_csomag roscpp rospy std_msgs

A parancs létrehozza a csomagot az src mappában, minimális esetben egy package.xml és CMakeLists.txt hozzáadásával. Természetesen a csomag dependenciái tovább bővíthetők a package.xml és CMakeLists.txt módosításával.

Munkaterület (workspace) lefordítása

A munkaterület gyökér mappájában adjuk ki a követekző parancsot:

catkin build

Megadható az is hogy hány szálon szeretnénk az adott munkaterületet lefordítani. Ez célszerű nagyméretű csomagok esetén - például PCL alapú csomagok. Ha például csak 4 szálon szeretnénk futtatni a fordítást, akkor a --jobs flaget alkalmazzuk:

catkin build -j4

Ha csak a csomagok egy részhalmazát szeretnénk lefordítani, akkor a catkin parancs után lista szerűen kell ezeket a csomagokat felsorolni (a következő lefordítja a csomagom_1 és a csomagom_2 csomagokat):

catkin build csomagom_1 csomagom_2

Egy munkaterületet meg lehet tisztítani úgy, hogy a forrásfájlok megmaradjanak, de a lefordított fájlok és a fordításidejű fájlok törlődjenek. Ez gyakorlatban a devel és build mappa eltávolítását jelenti. Használata indokolt lehet például hibás belépési pontok vagy más konfigurációs problémák esetén. Használata:

catkin clean

Munkaterületek source fájljai

Forrás: http://wiki.ros.org/ROS/Tutorials/InstallingandConfiguringROSEnvironment

Kissé nehezebben megfogható fogalom az elérési útvonalak meghatározása munkaterületenként. A munkaterületek fordítást követően egy setup.bash szkriptfájlt hoznak létre a devel v. install mappában. A szkriptfájl megfelelő meghívása beállít egy terminált a következő paranccsal:

source ~/catkin_ws/devel/setup.bash

A setup.bash a következőket tartalmazza:

• Munkaterülethez köthető környezeti változók
• Munkaterület egyes csomagjainak elérési útvonala és belépési pontok.
  • Ez értelemszerűen azt jelenti, hogy ha a fordítást követően egy új csomagot adunk a munkaterülethez, akkor annak lefordítása szükséges és a szkriptfájlok újboli betöltése szükséges.

Amennyiben egy munkaterület sokszor használatos, a .bashrc fájlba exportálható a futtatást eszközölő parancs. Ez megtehető egy szövegszerkesztő használatával, vagy a következő parancs meghívásával:

echo "source ~/catkin_ws/devel/setup.bash" >> ~/.bashrc

Ez a ~/.bashrc fájl végére fogja szúrni a megfelelő sort. Ez azért hasznos, mert így minden új terminál megnyitásakor végrehajtódik a .bashrc tartalma, így meghívódik a jelzett parancs is.

Probléma a munkaterületek beállításával

Alapvetően egy munkaterület fordításakor az éppen használt elérési útvonalakat és belépési pontokat használja fel. Ez egyetlen munkaterület esetén az alap ROS környezet elérési útvonalait és belépési pontjait jelenti (vagyis az /opt/ros/melodic/share/ és /opt/ros/melodic/lib/ mappa tartalmát, amit az /opt/ros/melodic/setup.bash meghívásával aktiválhatunk).

Amennyiben egyszerre több workspace-t használunk előfordulhat, hogy egy csomagot nem érünk el. Ennek feloldására több stratégia használható:

• Értsük meg miről szól a szisztematika: a beállító fájlok meghívása sorrendhez kötött, ad-hoc nem felcserélhető meghívásuk (nem kommutatív művelet). Egy beállító fájl meghívása egy korábbi munkakörnyezet összes elérési útvonalát és belépési pontját tartalmazhatja.
• Minimalizáljuk a használandó munkaterületek számát. Személyes tapasztalatom szerint (@kyberszittya) legfeljebb 3 munkaterület használata igazán indokolt:
  • Az eredeti ROS környezet
  • Az a munkakörnyezet, amiben külső lefordítandó ROS csomagok találhatók (pl. gazebo_ros csomag, ha a Gazebo-t forrásból telepítettük, gazebo plugin-ek). Igazából ez összevonható a fő munkaterülettel.
  • Kiegészítésként az olyan nagy keretrendszerek, mint az Autoware.AI.
  • A fő munkaterület, ahol a szoftverfejlesztést végezzük.
• Ha úgy véljük bizonyos csomagok nem találhatók, gondoljuk végig, melyik csoamg melyik munkaterületben van. Ezután képzeljünk el egy munkaterületi függési kapcsolatot és ennek megfelelően hívjuk meg a beállító fájlokat.
• Alapbeállításokat kezelve fordítsuk újra a munkaterületeket megtisztítást követően.

Példa: Autoware.AI, Gazebo és saját munkaterület

Tegyük fel, hogy elromlott az elérési útvonalak kezelése. Az eredeti ROS-en kívül három munkaterületet használunk:

• Egy munkaterület a külső gazebo plugineknek (~/gazebo_ws)
• Egy munkaterület az Autoware.AI-nak (~/autoware.ai)
• Egy munkaterület, ahol a tényleges munkát végezzük (~/catkin_ws)

Először kezdjük az alapértékekre való visszaállítást:

source /opt/ros/melodic/setup.bash

Ezután tisztítsuk és fordítsuk le újra a gazebo_ws munkaterületet:

cd ~/gazebo_ws
catkin clean
catkin build
source ~/gazebo_ws/devel/setup.bash

Autoware.AI esetén töröljük az install, build és logs mappákat. Fordítsuk újra az Autoware.AI-t. Miután ez megtörtént, hívjuk meg ennek a beállító fájlját:

source ~/autoware.ai/install/setup.bash

A saját munkaterületünket tisztítsuk meg és fordítsuk újra. Ezután használhatjuk a beállítófájlt. Vagyis adjuk ki a következő parancsokat:

catkin clean
catkin build
source ~/jkk_ws/devel/setup.bash

A beállítófájlokat ezt követően eltárolhatjuk a .bashrc fájlunkban. Hasonlítsuk össze a saját fájlunkat:

source /opt/ros/melodic/setup.bash
source ~/autoware.ai/install/setup.bash
source ~/gazebo_ws/devel/setup.bash
source ~/catkin_ws/devel/setup.bash