Une introduction au système d'exploitation robotique : le cadre d'application robotique ultime

Le système d'exploitation du robot (ROS) n'est pas un système d'exploitation réel, mais un cadre et un ensemble d'outils qui fournissent les fonctionnalités d'un système d'exploitation sur un cluster informatique hétérogène. Son utilité ne se limite pas aux robots, mais la majorité des outils fournis sont axés sur le travail avec du matériel périphérique.

ROS est divisé en plus de 2000 packages, chaque package fournissant des fonctionnalités spécialisées. Le nombre d'outils connectés au framework est probablement sa plus grande puissance.

Pourquoi devrais-je utiliser Robot OS ?

ROS fournit des fonctionnalités pour l'abstraction matérielle, les pilotes de périphériques, la communication entre les processus sur plusieurs machines, les outils de test et de visualisation, et bien plus encore.

La caractéristique clé de ROS est la façon dont le logiciel est exécuté et la façon dont il communique, vous permettant de concevoir des logiciels complexes sans savoir comment fonctionne certains matériels. ROS fournit un moyen de connecter un réseau de processus (nœuds) à un hub central. Les nœuds peuvent être exécutés sur plusieurs appareils et ils se connectent à ce concentrateur de différentes manières.

Les principaux moyens de créer le réseau consistent à fournir des services à la demande ou à définir des connexions éditeur/abonné avec d'autres nœuds. Les deux méthodes communiquent via des types de messages spécifiés. Certains types sont fournis par les packages principaux, mais les types de message peuvent être définis par des packages individuels.

Les développeurs peuvent assembler un système complexe en connectant des solutions existantes pour de petits problèmes. La façon dont le système est mis en œuvre nous permet de :

• Remplacer les composants par des interfaces similaires à la volée, éliminant ainsi la nécessité d'arrêter le système pour diverses modifications

• Multiplexage des sorties de plusieurs composants en une entrée pour un autre composant, permettant la résolution parallèle de divers problèmes

• Connectez des composants créés dans différents langages de programmation en implémentant simplement les connecteurs appropriés au système de messagerie, ce qui facilite le développement de logiciels en connectant des modules existants de différents développeurs

• Créez des nœuds sur un réseau d'appareils, sans vous soucier de l'endroit où le code est exécuté et implémentez des systèmes de communication interprocessus (IPC) et d'appel de procédure à distance (RPC)

• Connectez-vous directement aux flux à la demande à partir d'un matériel distant sans écrire de code supplémentaire, en utilisant les deux points précédents

Nous prévoyons de démontrer à quel point cela est utile en développant de manière itérative une solution simple. Il y a plusieurs avantages clés par rapport aux autres approches. ROS prend en charge plusieurs plates-formes et permet des connexions entre des processus sur plusieurs appareils via des connexions peer-to-peer qui sont gérées en arrière-plan. La conception permet la prise en charge de n'importe quel langage en enveloppant les classes de communication C++ ou en développant manuellement des classes pour l'interface du langage.

ROS est fait par sa propre communauté, destiné à sa communauté. Après plusieurs années, cela s'est traduit par une grande quantité de packages réutilisables et simples à intégrer, grâce à l'architecture du système.

Des approches alternatives telles que MRPT, CARMEN, LCM, Player, Microsoft RDS et d'autres fournissent certaines de ces fonctionnalités, mais pas toutes. La plupart du temps, les inconvénients de la conception sont les limitations de la prise en charge de la langue, une communication non optimisée entre les processus ou le manque de prise en charge de divers appareils, ce qui est sans doute le problème le plus difficile à résoudre.

Qu'allons-nous construire ?

Étant donné que nous nous concentrons sur le cadre et non sur les algorithmes réels pour des problèmes particuliers, le problème donné sera assez simple. Notre objectif est de créer un logiciel pour un ordinateur de bord qui nous permet de contrôler et de surveiller à distance un robot, connecté à nous via Wi-Fi, en utilisant une manette de jeu sur notre ordinateur et un flux de la caméra montée sur le robot.

Tout d'abord, nous allons connecter un programme simple à une simulation simple, juste pour démontrer les principes de base de ROS. Nous allons attacher une manette de jeu à un ordinateur et essayer de concevoir un bon schéma de contrôle pour transformer l'entrée de la manette de jeu en signaux de contrôle pour un robot.

Les principaux langages d'écriture de code ROS sont C++ et Python, C++ étant préféré en raison de meilleures performances. Nous expliquerons nos exemples en Python en raison de moins de passe-partout dans le code et de la nécessité d'une construction explicite.

Installation et configuration

Les versions ROS sont désignées par leur nom. À ce jour, la dernière version est Jade Turtle , et la dernière version LTS Indigo Igloo . Opter pour la version LTS est préférable, et la rétrocompatibilité n'est pas garantie dans ROS, donc tous les exemples seront écrits pour Indigo .

ROS est disponible sur diverses plates-formes *NIX. La version officiellement prise en charge est sur Ubuntu. Les versions OS X, Arch Linux, Debian, Raspbian et Android sont supportées par la communauté.

Nous allons passer par le processus d'installation d'Ubuntu 14.04 sur le bureau. Les processus pour toutes les versions et plateformes prises en charge sont disponibles sur le site officiel. Des machines virtuelles avec ROS installé sont également disponibles.

L'installation dépend de la plate-forme (et la plupart des plates-formes ont des packages fournis), mais la configuration de l'espace de travail est la même pour toutes les plates-formes.

Installation sur Ubuntu

ROS fournit ses propres référentiels. La première étape consiste à les ajouter.

 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

Après cela, vous aurez tous les packages hébergés pour toutes les versions ROS disponibles pour votre version Ubuntu. Par exemple, Ubuntu 14.04 prend en charge indigo et jade .

L'installation des packages de base sur le bureau comporte l'une des trois options suivantes :

• sudo apt-get install ros-indigo-ros-base pour une installation minimale

• sudo apt-get install ros-indigo-desktop pour avoir les outils graphiques supplémentaires de base

• sudo apt-get install ros-indigo-desktop-full pour avoir toutes les fonctionnalités officielles, y compris divers simulateurs et bibliothèques pour la navigation et la perception

Pour une expérience de travail optimale, l'option complète est recommandée. Pour une installation sur des appareils qui ne serviront qu'à exécuter des nœuds, la version de base est suffisante. Quelle que soit l'option que vous choisissez, vous pouvez installer n'importe quel package nécessaire nommé package_name en exécutant :

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

Les traits de soulignement sont remplacés par des traits d'union dans le nom final, donc stage_ros sera dans le package ros-indigo-stage-ros .

L'étape suivante consiste à initialiser rosdep . Les packages dans ROS peuvent déclarer les composants dont ils dépendent. rosdep vous permet de compiler ces packages sans trop de gestion manuelle des dépendances. Pour l'initialiser, appelez :

 sudo rosdep init rosdep update

ROS a plusieurs variables d'environnement utilisées par ses outils. Avec l'installation par défaut, le script bash pour les initialiser se trouve dans /opt/ros/indigo/setup.bash . Les variables doivent être initialisées dans chaque session bash, donc la meilleure solution est de les ajouter à ~/.bashrc .

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

Certains packages installent des dépendances externes via rosinstall , qui est disponible sous forme de package et installé via sudo apt-get install python-rosinstall .

C'est la fin de l'installation sur Ubuntu. Ce qui suit est une brève introduction à l'installation des espaces de travail.

Configuration

Depuis Groovy Galapagos , les espaces de travail ROS sont gérés via catkin . Nous devons définir un répertoire pour tous les packages que nous hébergeons. Dans le répertoire, nous créons un dossier src et appelons le formulaire catkin_init_workspace à l'intérieur. Cela créera divers liens symboliques vers la version ROS actuellement source. L'étape suivante consiste à ajouter également cet espace de travail aux variables d'environnement.

Pour effectuer cette configuration complète de l'espace de travail, choisissez un répertoire vide et exécutez les commandes suivantes :

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

Vous avez maintenant créé un espace de travail dans lequel vous pouvez créer vos propres packages ROS.

Se familiariser avec les outils

Créer n'importe quel code est un grand saut. Familiarisons-nous d'abord avec certains des systèmes fonctionnant en arrière-plan. Notre première étape consistera à exécuter l'interface graphique de base et à voir les messages qu'elle génère.

Pour exécuter quoi que ce soit dans ROS, un processus principal doit être lancé. C'est aussi simple que d'ouvrir une nouvelle fenêtre de terminal et de taper :

 roscore

Dans l'ensemble de votre réseau d'appareils connectés, roscore doit être lancé qu'une seule fois, sur l'appareil qui hébergera le hub central pour la répartition des communications.

Le rôle principal de roscore est d'indiquer aux nœuds à quels autres nœuds ils doivent se connecter et de quelle manière (que ce soit via un port réseau ou une mémoire partagée). L'objectif est de permettre aux nœuds de se soucier uniquement des données qu'ils veulent connaître, plutôt que du nœud auquel ils veulent se connecter, tout en minimisant le temps et la bande passante nécessaires pour effectuer toutes les communications.

rqt

Après avoir exécuté roscore , nous pouvons lancer l'outil graphique principal pour ROS : rqt . Ce que nous voyons est très décevant - une fenêtre vide. rqt héberge une grande variété de plugins qui peuvent être configurés dans n'importe quelle configuration visuelle et n'importe quel nombre de vues prédéfinies.

Pour commencer, exécutons le plugin Robot Steering , en le choisissant dans Plugins > Robot Tools > Robot Steering . Ce que nous obtenons, ce sont deux curseurs, représentant le mouvement linéaire et de rotation que nous voulons que notre robot ait. En haut du plugin, nous voyons une zone de texte contenant /cmd_vel . Nous pouvons le renommer comme nous voulons. Il représente le nom du sujet sur lequel le pilotage publie. Les outils du terminal sont le meilleur endroit pour voir ce qui se passe en arrière-plan.

Outils terminaux

ROS dispose de plusieurs outils puissants pour inspecter ce qui se passe dans le système. Le premier outil que nous présenterons est rostopic . Cela nous permet d'inspecter les sujets auxquels les nœuds peuvent s'abonner et publier. L' rostopic list donnera :

 /cmd_vel /rosout /rosout_agg

Les 2 derniers sujets sont toujours en cours d'exécution et sont liés aux systèmes ROS centraux. Le sujet /cmd_vel est en cours de publication par notre direction. Renommer le sujet dans la direction le renommera également ici. Maintenant, nous nous intéressons à ce qui se passe dans le sujet. L'exécution rostopic echo /cmd_vel ne nous montrera rien (à moins que vous n'ayez modifié les curseurs). Le processus s'exécute jusqu'à ce que nous l'annulions. Déplaçons maintenant le curseur vertical à 20 m/s. En regardant l'écho, nous pouvons voir ce qui suit répété encore et encore :

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

À quelle fréquence spamme-t-il ce message ? rostopic hz /cmd_vel dit à une fréquence moyenne de 10 Hz. Eh bien, combien de sujets comme celui-ci puis-je traiter via ma connexion Wi-Fi lente ? rostopic bw /cmd_vel détecte une moyenne de 480 B/s.

C'est bien beau, mais nous avons parlé des types de messages. Ces données sont bonnes pour un humain, mais une application aura besoin des données brutes et devra connaître le type de message pour pouvoir interpréter les données. Le type peut être déterminé avec rostopic type /cmd_vel , nous indiquant qu'il s'agit d'un geometry_msgs/Twist . Tous les outils de terminal ROS appelés sans aucun argument renvoient un message d'aide standard.

Le ROS Wiki est assez bon pour qu'une recherche sur le Web pour cette chaîne aboutisse à une explication Wiki de ce qu'elle contient et de la façon dont elle est structurée. Mais nous ne devons pas compter dessus. rosmsg est l'outil général pour les types de messages. L'exécution rosmsg show geometry_msgs/Twist renverra :

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

Le message se compose de deux vecteurs 3D, représentant la vitesse linéaire et angulaire dans l'espace 3D.

Si nous voulons à quels sujets un nœud est connecté, rosnode info <node-name> nous donnera des données détaillées sur le nœud. Les outils rostopic , rosmsg et rosnode sont les principaux outils d'inspection des fonctionnalités ROS brutes. ROS a beaucoup plus d'outils d'interface graphique et de terminal, mais ceux-ci sont hors de notre portée pour cette introduction.

Les principaux outils d'exécution des nœuds ROS sont rusrun et roslaunch . rosrun peut exécuter des nœuds via rosrun <package_name> <node_name> , et roslaunch exécute des nœuds basés sur des fichiers de lancement, avec lesquels nous nous familiariserons dans une toute petite mesure car ils constituent l'élément le plus complexe de l'automatisation ROS.

Nous pouvons arrêter tout ce que nous avons exécuté pour commencer à travailler sur notre premier code. Pour référence future, il va sans dire que l'exécution de tout ce qui concerne ROS nécessite une instance active de roscore . De nombreux problèmes que vous rencontrez peuvent être résolus en fermant la fenêtre du terminal dans laquelle roscore est exécuté et en en ouvrant une nouvelle pour la relancer. Cela met à jour toutes les dépendances qui devaient être rechargées, à la fois dans bash et dans roscore .

Création d'une téléopération avec manette de jeu

Notre premier objectif est d'imiter la fonctionnalité de Robot Steering en créant un nœud qui publie les données geometry_msgs/Twist sur /cmd_vel en fonction de l'entrée de la manette. Notre premier arrêt est le forfait joy .

Le forfait joy

Le package joy fournit des pilotes ROS génériques pour les joysticks et les manettes de jeu. Il n'est pas inclus dans l'installation par défaut, il doit donc être installé via :

 sudo apt-get install ros-indigo-joy

Après l'installation, nous pouvons exécuter rosrun joy joy_node . Cela nous connectera au joystick ou au gamepad par défaut. L'exécution rostopic list nous montre que nous avons un sujet appelé /joy . L'écouter via rostopic echo nous montre des messages au format suivant (notez qu'il faut interagir avec la manette ou le joystick pour que les messages soient publiés).

 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]

Vous pouvez ignorer les en-têtes pour le moment. En dehors de cela, nous avons des axes et des buttons , expliquant bien ce qu'ils représentent. Le déplacement des axes et l'appui sur les boutons du contrôleur entraîneront la modification de ces chiffres. À l'aide de nos outils, nous pouvons déterminer que le type de message est sensor_msgs/Joy et que le format est :

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

Créer notre téléopération

La première étape pour écrire du code consiste à créer un paquet. Dans le dossier src de l'espace de travail, exécutez :

 catkin_create_pkg toptal_tutorial rospy joy geometry_msgs sensor_msgs

Ici, nous indiquons le nom du package que nous créons, suivi des packages dont nous prévoyons de dépendre. Pas de soucis, les dépendances peuvent être mises à jour manuellement plus tard.

Nous avons maintenant un dossier toptal_tutorial . Dans le dossier, créez un dossier de scripts qui contiendra tous nos scripts Python.

Créons un fichier appelé teleop.py , et dans celui-ci nous définirons :

 #!/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()

Nous devrons également définir chmod +x teleop.py pour que le script devienne exécutable. En rosrun joy joy_node dans un terminal et rosrun toptal_tutorial teleop.py dans un autre, la sortie du terminal de teleop.py sera remplie de messages Joy.

Examinons ce que fait le code.

Tout d'abord, nous importons rospy, qui héberge la bibliothèque pour interagir avec le framework ROS. Chaque package qui définit des messages possède un sous-package msg contenant des définitions de message. Nous importons Joy pour gérer l'entrée. Il n'est pas nécessaire d'importer des types de messages intégrés (comme l'en- Header de std_msgs.msg qui se trouve dans le message Joy ) à moins que nous ne souhaitions les mentionner explicitement.

Notre première étape consiste à initialiser un nœud avec un nom spécifique (dans ce cas, nous l'appelons "teleop"). Après cela, nous créons un abonné qui s'abonne au sujet "joy" de type sensor_msgs.msg.Joy , et qui gère chaque message en appelant la fonction joy_callback . Les rappels reçoivent un paramètre, les données du message. L'accès aux membres des données est simple. Si nous voulions imprimer l'état du premier axe, si nous rappelions le type de message, nous appellerions print data.axes[0] , et ce sera un flottant. La boucle à la fin boucle jusqu'à ce que ROS soit arrêté.

Notre prochaine étape serait de gérer nos données d'une manière ou d'une autre. Nous devrions créer un message Twist qui change en fonction de l'entrée, puis nous le publierions dans le sujet 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()

Tout d'abord, nous ajoutons le message Twist et nous ajoutons la prise en charge des arguments de fonction de liaison via functools.partial . Nous créons un éditeur, pub , qui publie sur cmd_vel un message de type Twist . Nous lions cet éditeur au rappel et lui faisons publier un message Twist sur chaque entrée avec les vitesses représentées par les deux premiers axes. Ce code fait ce que nous attendons de lui, et nous pouvons voir la sortie résultante via rostopic echo /cmd_vel .

Nous avons encore un problème. Le sujet /joy peut être publié à des tarifs avantageux. Si nous surveillons le rostopic hz /cmd_vel et déplaçons le stick analogique en cercles, nous pouvons voir un grand nombre de messages. Non seulement cela entraîne une grande quantité de communication, mais les processus qui reçoivent ces messages doivent traiter chacun d'eux. Il n'est pas nécessaire de publier ces données si fréquemment, et nous ferions mieux de publier simplement à un rythme stable de 10 Hz. Nous pouvons accomplir cela avec le code suivant.

 #!/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()

Nous avons modifié le rappel pour recevoir l'objet Twist mutable et le modifier dans la boucle. La fonction de sleep de rospy.Rate maintient une fréquence de sortie stable.

Le code final donnera au sujet /cmd_vel des commandes de vitesse à 10 Hz, imitant la sortie du plugin Robot Steering rqt .

Exécution d'un système simulé

Simuler le monde

Notre premier objectif est de créer un environnement dans lequel nous pouvons simuler un scénario que nous voulons réaliser. Le nœud stageros dans le package stage_ros nous permet d'exécuter un robot dans une scène 2D définie via une image. Il existe toute une syntaxe, décrite dans le package stage_ros pour les fichiers du monde et comment les générer. C'est assez simple, mais hors de notre portée. Heureusement, le package est livré avec plusieurs mondes de démonstration. Tout d'abord, allons dans le répertoire des fichiers en exécutant :

 roscd stage_ros cd world

Dans le dossier, il y a plusieurs fichiers. Exécutons-en un.

 rosrun stage_ros stageros willow-erratic.world

Cela a créé plusieurs sujets. La signification de chacun d'eux est également documentée avec le package. La partie importante est qu'il a cmd_vel .

Dans la scène affichée, il y a un carré bleu, représentant le robot que vous contrôlez. En utilisant soit notre code, soit Robot Steering , nous pouvons contrôler ce robot. Essaye le.

Configuration de notre système via des fichiers de lancement

créons un dossier de launch dans notre package, et dans celui-ci, créons un fichier appelé teleop.launch . La structure finale du dossier devrait ressembler à ceci :

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

Dans le fichier teleop.launch , nous définirons un ensemble de nœuds et leurs interconnexions.

 <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>

Le nouveau monde se compose de quatre robots, et chacun de leurs sujets a un préfixe de robot_<n> . Ainsi, le robot numéro 0 a un sujet de commande de vitesse appelé robot_0/cmd_vel . C'est pourquoi nous plaçons notre contrôle dans un espace de noms appelé robot_0 , pour ajuster leurs noms au nouveau formulaire. En ce sens, vous pouvez considérer les noms de sujet comme des dossiers dans un système de fichiers.

Pour exécuter les fichiers de lancement, aucun roscore n'est nécessaire. Dans un sens, roscore n'est qu'un cas particulier d'un fichier de lancement qui ne fait rien. S'il manque un roscore , seul le premier fichier de lancement lancé exécutera un noyau, tandis que les autres s'y connecteront. Maintenant, nous lançons le lancement avec :

 roslaunch toptal_tutorial teleop.launch

Si tout est correct, cela se traduira par un simulateur avec 4 robots, dont l'un est contrôlé avec notre gamepad ou joystick. Ce monde a beaucoup plus sous le capot que le précédent. Chacun des quatre robots possède :

 /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

Nous remplaçons <n> par 0, 1, 2 ou 3. Cela nous amène à notre dernier sujet.

Affichage de nos données avec rqt

Nous ne sommes pas allés trop loin dans rqt , mais c'est l'outil parfait pour visualiser des données plus complexes. Vous pouvez tester tous les sujets, mais nous nous concentrerons sur les image_0 , image_1 , depth_0 et depth_1 .

rqt et supprimons tous les plugins ouverts. Nous allons maintenant ouvrir 4 visualiseurs d'images ( Plugins > Visualization > Image View ) et les placer dans une formation de grille 2x2. Enfin, dans le coin supérieur gauche de chacune des vues, choisissons l'un des quatre sujets indiqués pour robot_0 .

Ce que nous obtenons est une vision stéréo avec perception de la profondeur, avec des caméras à faible résolution. Gardez à l'esprit que nous aurions même pu obtenir ce résultat sans notre système de saisie. Si nous exécutons simplement ceci (depuis le dossier stage_ros/world ):

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

et ajoutez le plugin Robot Steering avec un sujet appelé /robot_0/cmd_vel , nous aurions obtenu les mêmes résultats avec les contrôles étant des curseurs à l'écran.

Application des résultats à un système réel

De nombreux matériels prennent entièrement en charge ROS, très souvent fournis par des bénévoles tiers. De nombreuses plates-formes de robots ont des pilotes qui génèrent ces types de messages, et ROS a des nœuds qui prennent une webcam et publient un flux d'images.

Alors que le dernier résultat était une simulation de ce que nous voulons réaliser, la même chose peut être obtenue avec les modifications suivantes :

• Installez ROS sur l'ordinateur de bord de votre robot
• Créez un fichier de lancement pour l'ordinateur de bord qui connecte ROS à la plate-forme sous-jacente et à tous les capteurs de haut niveau tels que les caméras, les télémètres laser et autres. Les nœuds nécessaires peuvent déjà exister ou peuvent être implémentés en créant un éditeur/abonné à ROS d'un côté et un pilote pour les communications série de l'autre
• Faire exécuter le fichier de lancement au démarrage
• Sur votre ordinateur distant, ajoutez export ROS_MASTER_URI=http://<robot_hostname>:11311/ à votre démarrage bash, ce qui oblige l'ordinateur distant à rechercher roscore sur ce nom d'hôte et ce port.
• Lancer rqt et/ou tout script pour surveiller et contrôler le robot

Cela se résume en fait à exporter la variable d'environnement appropriée sur le périphérique distant, et le reste se gère tout seul. L'exécution de ROS sur un cluster d'ordinateurs ne nécessite qu'une seule étape pour chaque machine.

Conclusion

Nous avons démontré comment, avec très peu de codage, vous pouvez avoir un système complexe de variables que vous pouvez manipuler à votre guise. Le système simple éditeur/abonné vous permet de développer rapidement un pipeline logiciel qui traite les données dans un cluster d'ordinateurs, sans vous soucier de l'implémentation sous-jacente de certains éléments.

Alors que nous avons utilisé un simulateur simple, des simulateurs plus complexes comme gazebo (également inclus dans la version de bureau complète) vous permettent de créer des mondes 3D avec de la physique et des capteurs complexes, et peuvent vous donner une expérience des résultats finaux et du produit bien avant qu'il ne soit développé.

Cette introduction était très basique, mais j'espère que vous êtes devenu plus intéressé à travailler avec ce framework polyvalent.