ROS2 + DDS :rejouer

Les tests en conditions réelles sont nécessaires – et souvent coûteux - partie de la création de systèmes distribués et autonomes. Les tests sont conçus pour soumettre le système à de nombreux scénarios différents et la collecte de données en temps réel peut créer une valeur durable à partir de ces tests.

Pensez à tester sur route un véhicule (semi-)autonome comprenant GPS, caméras, LiDAR, RADAR, accéléromètres, gyroscopes, boussole, compteur de vitesse, signaux de contrôle, ainsi que cartographie et environnement Les données. C'est *beaucoup* de données… et très cher à obtenir. Ne serait-il pas bien que toutes ces données puissent être enregistrées pour une relecture à la demande, comme si un test réel était en cours ? Et si vous pouviez créer une bibliothèque numérique de chaque session de test et pouvoir la modifier lors de la lecture, créant ainsi des scénarios de test encore plus reproductibles ?

Saviez-vous que l'enregistrement et la lecture à large bande passante/haute capacité sont disponibles pour les utilisateurs de DDS depuis de nombreuses années avec le service d'enregistrement RTI ? Un exemple de cas d'utilisation du service d'enregistrement RTI serait l'enregistrement continu (24h/24 et 7j/7) de toutes les données du système lors d'un déploiement étendu sur le terrain, tel qu'un essai en mer d'un navire de la Marine. La bande passante et la capacité d'enregistrement sont presque illimitées en raison de la nature distribuée du DDS :plusieurs instances du service d'enregistrement peuvent être lancées pour suivre le rythme du flot de données.

L'écosystème ROS a son propre service d'enregistrement appelé Rosbag, mais au moment d'écrire ces lignes, Rosbag n'était sorti que récemment pour ROS2. Heureusement, ROS2 utilise DDS comme cadre de connectivité sous-jacent, il devrait donc être simple d'utiliser le service d'enregistrement RTI éprouvé sur le terrain pour enregistrer des données à large bande passante à partir de ROS2 pour une relecture à tout moment.

Faisons en sorte que cela se produise...

Configuration de l'enregistreur

Le service d'enregistrement RTI peut être configuré par un fichier XML pour enregistrer tous les sujets ou certains sujets, avec tous les paramètres de QoS nécessaires. Dans cet exemple, je vais configurer pour enregistrer un sujet à bande passante modérée (données ROS2 LiDAR), puis le relire dans ROS2 - le tout à partir d'un ensemble d'outils DDS pur.

Le service d'enregistrement RTI désérialisera normalement les données pour l'enregistrement dans les colonnes d'une base de données conventionnelle. Les données LiDAR ROS2 ont un grand nombre de points par échantillon, donc dans ce cas, je demanderai à l'enregistreur de ne pas désérialiser les données et de les enregistrer comme une seule colonne dans la base de données. Le reste du fichier XML indique à l'enregistreur quel sujet et type de données enregistrer, et où stocker les données.

Ceci est contenu dans un fichier XML que j'ai créé, nommé "ros2_record.xml":

 xsi:noNamespaceSchemaLocation="http://community.rti.com/schema/5.3.1/rti_record.xsd"> 
 
  
  
  
 vrai 
 0 
  
 
  
  
 ros2_replay_example.dat 
 vrai 
  
 
  
  
 0 
  
 RTIDDS_DESERIALIZEMODE_NEVER 
  
 
  
  
 rt/velodyne_points 
 * 
 
 
 
  
  
  
 domain0 
 
  
 ros-rt 
 
 
 
  
  
  
 <élément> 
  
 domain0 
  
  
  
  
 <élément> 
  
 PointCloud2.xml 
  
  
 <élément> 
 faux 
 sensor_msgs::msg::dds_::PointCloud2_ 
  
 sensor_msgs::msg::dds_::PointCloud2_ 
  
  
 rt/velodyne_points 
  
  
  
 2147483647 
  
 
 
  
 . 
  
  
  
  
 
 
  
  
 

Pour lancer le service d'enregistrement RTI à l'aide du fichier XML ci-dessus, j'utilise la commande suivante (exécutée à partir du même répertoire que le fichier XML ci-dessus) :

rtirecord -cfgFile ros2_record.xml -cfgName simple_example

Ceci lance le service d'enregistrement qui s'abonnera aux données LiDAR et les enregistrera en continu jusqu'à ce que je ferme le programme. Le résultat final est un fichier de base de données SQLite nommé "ros2_replay_example.dat_0_0"

Des nombres sont ajoutés au nom du fichier pour différencier les sessions d'enregistrement (le premier nombre) et le fichier de base de données dans lequel il se trouve dans une séquence (les fichiers sont automatiquement limités à un fichier sélectionnable par l'utilisateur taille ; une fois qu'ils deviennent trop volumineux, ils sont fermés et un autre fichier est ouvert pour contenir la prochaine période de données. Cela empêche les fichiers de la base de données de devenir trop volumineux).

Configuration du lecteur

Maintenant que j'ai enregistré les données LiDAR ROS2, voyons si elles peuvent être lues dans ROS2.

Comme mentionné dans les articles de blog précédents (A Field Guide to Interoperability et When Ecosystems Merge), ROS2 nécessite quelques paramètres pour assurer la compatibilité. Dans cet exemple, l'envoi des informations du code de type lors de la découverte a été supprimé pour être compatible avec la configuration par défaut de la version ROS2 « Bouncy Bolson », mais cet ajustement peut également être effectué dans ROS2 si vous exécutez rmw_connext_cpp comme couche RMW.

Ces paramètres, ainsi que les informations sur le sujet, le domaine et le fichier, sont placés dans un autre fichier XML :

 
  xsi:noNamespaceSchemaLocation="http://community.rti.com/schema/5.3.1/rti_replay.xsd"> 
 
  
  
  
  
  
 annotation> 
 Exemple de service de relecture 
  
  
 1  
 AUTO 
 5 
  
 
  
  
 ros2_replay_example.dat_0_0 
 faux 
 
  
  
 0 
  
  
 0 
 0 
  
  
  
 
  
  
  
  
 <élément> 
  
 PointCloud2.xml 
  
  
 <élément> 
 faux 
 sensor_msgs::msg::dds_::
[1] [2] 下一页 
            


            

               Présentation de l'IIC, maintenant avec OpenFog !         
                Plongez dans notre meilleur contenu pour réussir dans l'IoT industriel (en 2019 et au-delà)