ROS est la boîte à outils qui est utilisée pour créer toutes les couches d'intelligence du robot. Il existe actuellement 2 versions indépendantes de ce framework :

• ROS (1) : Cette version majeure existe depuis plus de 10 ans (lancée en 2010), c'est elle qui a popularisé le framework, par les bibliothèques fournies adaptées à la recherche dans la robotique, mais surtout par tout l’écosystème qui s’est construit autour grâce à la collaboration de milliers de développeurs partout dans le monde. Bien qu’elle soit entre-temps devenue une usine à gaz, cette version continue d’être maintenue aujourd’hui, mais sans nouvelles améliorations.
• ROS 2 : Suite à l’engouement pour ROS dans le milieu industriel, le collectif Open Robotics gérant le framework a lancé une réécriture totale des outils afin qu’ils reposent sur des bases solides, permettant une meilleur fiabilité et flexibilité pour renforcer son attractivité pour la recherche et le développement dans l’industrie. La première version stable a été publiée en 2017, et la première version avec un support longue durée (LTS) date de 2020. Cette nouvelle version majeure est destinée à long terme à remplacer la première, mais en laissant une période de transition suffisamment longue, car le code pour ROS1 est incompatible avec ROS2.

À chaque version de ROS 1 correspond une version spécifique d’Ubuntu, il est compliqué voire impossible de faire tourner ROS 1 sous d’autres OS. Pour ROS 2 cela reste vrai mais avec en plus le support officiel de MacOS et Windows (tiers 1), et non-officiel de Debian et webOS OSE (tiers 3).

ROS 1 était destinée particulièrement à être utilisée avec du C++03, avec la plupart des fonctionnalités disponible en Python 2 ainsi que Lisp dans une moindre mesure. Pour la sous-version ROS Melodic (2018-2023), elle cible les langages C++14 et Python 2.7 avec une compatibilité fortement recommandée avec Python 3.5. C’est avec cette version qu’est actuellement développée l’architecture d’UTCoupe.

ROS 2 a été conçue pour se détacher d’un langage spécifique en posant une base solide commune à tous les langages : rcl (ROS Common Library); ROS2 Foxy (2020-2023) vient avec rclcpp (C++17) et rclpy (Python 3.8) mais il existe des interfaces pour d’autres langages comme C#, Javascript (NodeJS), Java, Swift…

Les dernières versions de ROS 1 utilisent l’outil Catkin pour gérer l’espace de travail (workspace) contenant tous les packages correspondant à un projet. Il est totalement basé sur CMake, y compris pour des packages contenant uniquement des fichiers Python.

Dans ROS2, cet outil a été remplacé par le duo Ament/Colcon. Ils utilisent toujours CMake, mais il est possible de ne pas utiliser celui-ci pour du code Python.

De plus, le dossier généré devel par cmake est fusionné avec install. Il ne faut donc pas oublier «d’installer» ses bibliothèques et exécutables Python/C++.

ROS1, bien que distribué, requiert la présence d'un nœud central (roscore, accessible via ROS_MASTER_URI) afin de synchroniser tous les autres nœuds. Dans ROS2, il n’y en a plus besoin, chaque nœud s’annonce sur une adresse commune à tous les nœuds, ceux-ci l’enregistrent. De ce fait, les nœud ont un cycle de vie à respecter (voir section ci-dessous).

ROS2 utilise le standard DDS (data distribution service), dont il existe plusieurs implémentations pouvant être utilisées avec ROS2, avec des exigences de rapidité, stabilité et sécurité différentes. Celle venant par défaut lors de l’installation de ROS2 est Fast RTPS (Real Time Publish Subscribe) de eProxima, open-source et adapté à un contexte de laboratoire ; pour un milieu industriel on se tournera plutôt vers Connext de RTI. ROS s’occupe de l’interfaçage par une couche d’abstraction, il n’y a donc pas besoin de savoir quelle implémentation sera utilisée.

Avec le changement du protocole réseau et la disparition du nœud de synchronisation (roscore), il devient nécessaire (mais non-obligatoire) que les nœuds fonctionnent comme un automate à états finis, dont les états et les transitions sont standardisés et rendus publiques aux autres nœuds. Ainsi, il existe 4 états primaires :

• Non-configuré : état dans lequel est le nœud lorsqu’il vient d’être créé ou réinitialisé ;
• Inactif : le nœud est configuré mais ne cherche pas à communiquer avec les autres nœuds (s’il reçoit des messages de services ou topics, leur conservation pour une utilisation ultérieure est définie par la qualité de service lors de la déclaration de ceux-ci) ;
• Actif : état normal de fonctionnement d’un nœud, comparable au concept de nœud de ROS1 ;
• Terminé : état final atteint lorsque le nœud s’est correctement arrêté mais pas encore détruit, utile pour une utilisation dans un débugger (gdb, valgrind…).

Pour plus d’informations, se référer au concept et à l’implémentation.