Sur le mélange d’ament et de chaton (catment)

Tout ce qui suit est expérimental et spéculatif.

Fond

Il était une fois une chose appelée rosbuild. Puis vint une chose appelée catkin, qui remplaça largement rosbuild. Récemment introduit est une chose appelée ament, qui pourrait un jour remplacer catkin.

Les trois outils peuvent être considérés comme des « systèmes de méta-construction ». Ils reposent sur d’autres systèmes de construction (par exemple, CMake, Python setuptools) et fournissent des fonctionnalités supplémentaires destinées à faciliter l’utilisation de ces systèmes de construction, en particulier lors de la gestion des dépendances entre plusieurs packages et lors de la création de plusieurs packages dans un seul espace de travail.

Chacun de ces systèmes de méta-construction fait deux choses :

  1. Ajoutez une API au système de construction sous-jacent (par exemple, CMake) qui peut être utilisée pour simplifier les tâches courantes (par exemple, fournir tous les indicateurs exportés par les packages dépendants lors de la construction d’un exécutable). Il existe généralement des crochets pour permettre l’injection d’API supplémentaires par des packages en dehors du système de méta-construction principal.

    • rosbuild : mk/cmake.mk, rosbuild_init(), rosbuild_add_executable(), etc.

    • catkin : catkin_package(), catkin_install_python(), etc.

    • ``ament”” : ``ament_target_dependencies()””, ``ament_export_dependencies()””, ``ament_package()””, etc.

  2. Fournir un outil qui peut être utilisé pour itérer dans l’ordre des dépendances sur un espace de travail rempli de packages, en créant et peut-être en installant chacun d’eux.

    • rosbuild : rosmake

    • catkin : catkin build, catkin_make, catkin_make_isolated, etc.

    • ``ament”” : ``ament build””

Le fil conducteur qui relie tous ces systèmes est la division du code en packages, chaque paquet contenant un fichier manifeste (manifest.xml ou package.xml). Ce manifeste est requis (à quelques exceptions près) pour que les deux parties du système de méta-construction (API et outil de construction) fonctionnent.

Postulats

  1. Alors que nous considérons généralement que les deux aspects d’un système de méta-construction sont couplés, ils ne doivent pas l’être. L’API utilisée à l’intérieur d’un package et l’outil qui itère sur les packages peuvent être considérés comme largement indépendants, avec le package manifeste formant l’interface entre eux. Il n’y a aucune raison en principe pour laquelle, par exemple, rosmake ne pourrait pas être modifié pour itérer sur un espace de travail rempli de packages catkin, en y entrant dans l’ordre des dépendances et en faisant l’habituel mkdir build ; construction de cd ; cmake ..; make install routine pour chacun (avec les drapeaux appropriés passés à cmake et make).

  2. L’effort requis pour migrer d’un système de méta-construction à un autre doit être minimisé. La migration massive de rosbuild à catkin a été difficile et reste un point sensible pour de nombreux membres de la communauté. Bien qu’il soit raisonnable de demander aux développeurs d’apporter des modifications en échange de l’accès à de nouvelles fonctionnalités, les modifications requises doivent être aussi minimes que possible sans sacrifier l’efficacité du nouveau système. Cela est particulièrement vrai lorsque l’ancien système est largement utilisé.

    1. Corollaire : La migration vers un nouveau système de méta-construction ne devrait pas être requise sans une très bonne raison. Si un développeur ne souhaite pas les fonctionnalités offertes par le nouveau système, il ne doit pas être contraint de migrer depuis le ancien système à moins qu’il y ait quelque chose de irrévocablement cassé sur l’ancien système (par exemple, le modèle de construction dans la source de rosbuildet l’absence d’une étape « d’installation »).

  3. L’interopérabilité est une bonne chose. Dans la mesure du possible (toutes les combinaisons ne seront pas pratiques), les développeurs doivent pouvoir mélanger et assortir les systèmes de méta-construction, y compris en mélangeant leurs différents aspects (c’est-à-dire utiliser l’outil de construction d’un système et l’API d’un autre). Un tel mélange et correspondance est particulièrement important lorsque les développeurs veulent combiner une grande base de code existante en utilisant un système de méta-construction (par exemple, ROS avec catkin) avec de nouvelles bibliothèques et outils offerts par une base de code en utilisant un autre système de méta-construction (par exemple, ROS 2 avec ament). Idéalement, ce type de combinaison peut être effectué sans nécessiter de modifications de l’API utilisée par l’une ou l’autre des bases de code et sans dire au développeur quel outil de création utiliser.

    1. Corollaire : Les espaces de travail n’ont pas besoin d’être homogènes. Il n’y a aucune raison pour que nous ne soyons pas en mesure de mélanger librement, disons, les packages catkin et ament dans un espace de travail, avec des dépendances dans les deux directions, tant que l’outil de construction utilisé sait comment les construire tous les deux. L’interface principale entre les packages (au moins, les packages contrôlés par CMake) est leur fichier de configuration CMake. Tant que ce fichier de configuration suit le protocole standard (configuration foo_LIBRARIES, etc.), alors peu importe qui a écrit le fichier. Il peut être généré automatiquement par catkin ou ament, ou même créé manuellement par un développeur qui souhaite utiliser CMake dans son package, mais dont le package dépend toujours de catkin ou ament packages.

Cas d’utilisation, avec implémentations expérimentales

Ajout de packages ROS à un espace de travail ROS 2 et construction avec ament build

Supposons que vous souhaitiez ajouter des packages ROS existants à votre espace de travail ROS 2 et que vous ne souhaitiez pas migrer les packages ROS de catkin vers ament (ou vice versa). Voici deux patchs qui vous permettent de faire cela :

  • ament_package : ajout de la prise en charge des manifestes de package de format 1, au lieu d’exiger le format 2. Cette modification n’est pas strictement liée à `` catkin`` contre ament, car le format 2 existe depuis un certain temps et catkin le prend en charge, donc les développeurs pourraient déjà mettre à jour leurs manifestes au format 2. Mais il y a une tonne de code ROS là-bas qui utilise le format 1, nous devons donc le prendre en charge. Cette implémentation pourrait être améliorée, par exemple, en raisonnant sur les différentes saveurs des balises depend et comment elles diffèrent entre les formats 1 et 2.

  • ament_tools : ajoutez un nouveau type de construction catkin à ament. Cette implémentation traite simplement les packages catkin de la même manière que les packages cmake simples, ce qui semble fonctionner correctement. Il pourrait être rendu plus sophistiqué.

Example usage:

  1. Obtenez le code ROS 2 comme d’habitude, en utilisant les branches mentionnées ci-dessus.

  2. Ajoutez à votre espace de travail des packages catkin ROS, en vous assurant que toutes leurs dépendances sont satisfaites (soit également présentes dans l’espace de travail, soit installées ailleurs avec les fichiers shell de configuration appropriés).

  3. Construisez comme d’habitude (par exemple, ./src/ament/ament_tools/scripts/ament.by build).

Voila : votre code existant n’est pas soudainement cassé simplement parce qu’un nouvel outil de création est utilisé.

Variante : Construire des packages ROS avec ament build

Disons que vous aimez le nouvel outil ament et que vous souhaitez l’utiliser pour construire vos packages ROS existants qui utilisent catkin en interne. Voici un exemple de la façon de procéder, en effectuant une installation minimale de ament, puis en l’utilisant pour créer un espace de travail rempli de packages ROS catkin :

mkdir -p ~/ament_ws/src
cd ~/ament_ws/src
git clone https://github.com/osrf/osrf_pycommon.git
git clone https://github.com/ament/ament_package.git
cd ament_package
git checkout catkin
cd ..
git clone https://github.com/ament/ament_tools.git
cd ament_tools
git checkout catkin
cd ../..
 ./src/ament_tools/scripts/ament.py build

Construisez maintenant les packages ROS :

. $HOME/ament_ws/install/setup.bash
cd ~/ros_catkin_ws
ament build

Voilà : vous avez utilisé l’outil de compilation ament pour créer vos packages catkin, sans avoir à les migrer.

Variante : Utilisation de l’API catkin dans un package ROS 2

Supposons que vous construisiez au-dessus de ROS 2, qui utilise en interne l’API ament, et que vous souhaitiez ajouter un nouveau package à l’aide de l’API catkin.

Pour que cela fonctionne, nous avons besoin d’une installation Python3 de catkin (les binaires debian utilisent Python2.7). Voici un exemple d’installation dans $HOME/catkin :

# install catkin_pkg
git clone https://github.com/ros-infrastructure/catkin_pkg.git
cd catkin_pkg
git checkout ament
python3 setup.py install --prefix $HOME/catkin --single-version-externally-managed --record foo --install-layout deb
# install catkin
git clone https://github.com/ros/catkin.git
cd catkin
git checkout ament
mkdir build
cd build
PYTHONPATH=$HOME/catkin/lib/python3/dist-packages/ cmake .. -DCMAKE_INSTALL_PREFIX=$HOME/catkin -DPYTHON_EXECUTABLE=/usr/bin/python3
make install

Pour utiliser cette version de catkin, il vous suffit de sourcer le fichier $HOME/catkin/setup.bash.

Supposons que vous ayez l’espace de travail habituel de ROS 2 dans ~/ros2_ws, et que vous soyez sur les branches catkin dans ament_package et ament_tools. Ajoutez à cet espace de travail le package image_tools_catkin de https://github.com/gerkey/catment. C’est un simple portage du package image_tools de ROS 2, le prenant de l’API ament à l’API catkin. Pour le construire :

cd ~/ros2_ws
. $HOME/catkin/setup.bash
./src/ament/ament_tools/scripts/ament.py build

Voilà : lors de l’ajout de nouveaux packages sur ROS 2, vous êtes libre de choisir l’API CMake que vous préférez dans votre package.

  • Mise en garde : Nécessite de commenter l’utilisation de CATKIN_DEPENDS dans catkin_package(), car quelque part quelqu’un s’énervait que des choses comme rclcpp ne soient pas des packages catkin. Cette contrainte doit être assouplie d’une manière ou d’une autre.

  • TODO : La même démo mais avec un package ament qui dépend d’un package catkin (c’est facile).

  • TODO : La même démo mais avec un paquet qui a un CMakeLists.txt vanille qui n’utilise ni ament ni catkin, et fournit un ``fooConfig.cmake` généré manuellement ` qui exporte les bons éléments pour les rendre identiques aux étrangers.

Construire des packages ROS 2 avec catkin_make_isolated

Disons que vous connaissez déjà ROS et catkin et que vous êtes impatient d’essayer ROS 2, mais que vous n’êtes pas d’humeur à en savoir plus sur ament. Vous préférez vous en tenir à ce que vous savez, comme utiliser catkin_make_isolated pour tout construire. Voici un patch qui vous permet de faire cela :

  • catkin : ajout de la prise en charge des packages qui se déclarent avoir un type de construction ament_*. Cette implémentation appelle ament pour construire chacun de ces packages. Alors que les packages ament_cmake peuvent être traités comme des packages cmake simples (comme nous l’avons fait lors de l’ajout de la prise en charge de catkin à ament), les packages ament_python nécessitent des invocations gnarly de Python . Au lieu d’essayer de reproduire cette logique dans catkin, il est plus simple de laisser ament s’en occuper. Toujours dans ce patch, nous ajoutons les packages buildtool_export_depend à l’ensemble qui sont pris en compte lors de la construction.

  • catkin_pkg : également dans ce correctif, nous ajoutons les packages buildtool_export_depend à l’ensemble qui sont pris en compte lors du calcul l’ordre topologique.

Comme nous allons appeler ament build, nous aurons également besoin d’une installation minimale de ament, comme dans un exemple précédent :

mkdir -p ~/ament_ws/src
cd ~/ament_ws/src
git clone https://github.com/osrf/osrf_pycommon.git
git clone https://github.com/ament/ament_package.git
cd ament_package
git checkout catkin
cd ..
git clone https://github.com/ament/ament_tools.git
cd ament_tools
git checkout catkin
cd ../..
 ./src/ament_tools/scripts/ament.py build

Ensuite, nous devons installer la version modifiée de catkin quelque part :

# install catkin_pkg
git clone https://github.com/ros-infrastructure/catkin_pkg.git
cd catkin_pkg
git checkout ament
python3 setup.py install --prefix $HOME/catkin --single-version-externally-managed --record foo --install-layout deb
# install catkin
git clone https://github.com/ros/catkin.git
cd catkin
git checkout ament
mkdir build
cd build
PYTHONPATH=$HOME/catkin/lib/python3/dist-packages/ cmake .. -DCMAKE_INSTALL_PREFIX=$HOME/catkin -DPYTHON_EXECUTABLE=/usr/bin/python3
make install

Compilez maintenant les packages ROS 2 :

. $HOME/catkin/setup.bash
. $HOME/ament_ws/install/setup.bash
cd ~/ros2_ws
touch src/eProsima/AMENT_IGNORE
PYTHONPATH=$PYTHONPATH:/home/gerkey/ros2_ws_catkin/install_isolated/lib/python3.5/site-packages catkin_make_isolated --install

Voilà : vous avez créé ROS 2 à l’aide des outils que vous connaissez bien.

  • Mise en garde : nous ignorons les packages eProsima dans l’espace de travail car ils manquent de fichiers package.xml, ce qui signifie que catkin ne peut pas les voir. ament a quelques heuristiques pour gérer de tels paquets. Options : rétroportez ces heuristiques vers catkin ; passer à l’installation de packages ne contenant pas package.xml en dehors de l’espace de travail ; ou ajoutez simplement un package.xml à chacun de ces packages (par exemple, dans notre propre fork).

Combiner tout ROS et ROS 2 dans un seul espace de travail et le construire (TODO)

Cette étape nécessitera de trier certaines choses, y compris au moins :

  • Conflits de nom de package. Nous avons actuellement des versions ROS 2 des packages de messages ROS, ainsi que des éléments dans geometry2. Soit la fonctionnalité doit être fusionnée dans un package qui peut prendre en charge les deux systèmes, soit les nouvelles versions nécessitent des noms différents.

  • Génération de messages. ROS et ROS 2 ont des étapes de génération de message différentes, dont la sortie peut ou non entrer en conflit. Quelque chose de sophistiqué doit être fait pour permettre la génération de tous les bons artefacts à partir d’un seul paquet de messages (ou, comme indiqué ci-dessus, les nouveaux paquets de messages ont besoin d’un nom différent).

Utiliser bloom pour publier les packages ament (TODO)

Il semble que bloom devrait pouvoir publier des packages qui utilisent l’API CMake ament, et que les versions résultantes devraient pouvoir être construites sur la ferme. Nous pouvons apporter des modifications à bloom et ros_buildfarm selon les besoins pour activer ce cas d’utilisation.