ROS2 + DDS:speel het opnieuw

Tests in de echte wereld zijn noodzakelijk – en vaak duur - onderdeel van het creëren van gedistribueerde en autonome systemen. Tests zijn ontworpen om het systeem door veel verschillende scenario's te laten gaan en realtime gegevensverzameling kan blijvende waarde creëren uit deze tests.

Denk aan het testen op de weg van een (semi-)autonoom voertuig met GPS, camera's, LiDAR, RADAR, versnellingsmeters, gyroscopen, kompas, snelheidsmeter, controlesignalen, plus kaarten en omgevingsfactoren gegevens. Dat is een *veel* data... en erg duur om te verkrijgen. Zou het niet mooi zijn als al deze gegevens kunnen worden vastgelegd voor on-demand herhaling, alsof er een echte test wordt uitgevoerd? Wat als u een digitale bibliotheek van elke testsessie zou kunnen bouwen en deze tijdens het afspelen zou kunnen wijzigen, waardoor u nog meer herhaalbare testscenario's zou creëren?

Wist u dat opnemen en afspelen met hoge bandbreedte/hoge capaciteit al vele jaren beschikbaar is voor DDS-gebruikers met RTI Recording Service? Een voorbeeld van een use case voor RTI Recording Service is het continu (24/7) vastleggen van alle systeemgegevens tijdens een uitgebreide veldinzet, zoals een proefvaart op zee van een marineschip. De opnamebandbreedte en -capaciteit zijn bijna onbeperkt vanwege het gedistribueerde karakter van DDS - er kunnen meerdere instances van Recording Service worden gestart om gelijke tred te houden met de stroom aan gegevens.

Het ROS-ecosysteem heeft zijn eigen opnameservice genaamd Rosbag, maar op het moment van schrijven was Rosbag pas onlangs uitgebracht voor ROS2. Gelukkig gebruikt ROS2 DDS als het onderliggende connectiviteitsraamwerk, dus het zou eenvoudig moeten zijn om de in de praktijk bewezen RTI Recording Service te gebruiken om gegevens met hoge bandbreedte van ROS2 op te nemen om ze op elk moment opnieuw af te spelen.

Laten we dat laten gebeuren...

Recorderconfiguratie

RTI Recording Service kan worden geconfigureerd door een XML-bestand om alle of geselecteerde onderwerpen op te nemen, met alle QoS-instellingen die nodig zijn. In dit voorbeeld zal ik een onderwerp met gemiddelde bandbreedte opnemen (ROS2 LiDAR-gegevens) en het vervolgens opnieuw afspelen in ROS2 - allemaal vanuit een pure DDS-toolset.

RTI Recording Service deserialiseert normaal gesproken de gegevens voor opname in de kolommen van een conventionele database. De ROS2 LiDAR-gegevens hebben een groot aantal punten per monster, dus in dit geval zal ik de recorder instrueren om de gegevens niet te deserialiseren en als een enkele kolom in de database op te nemen. De rest van het XML-bestand vertelt de recorder welk onderwerp en gegevenstype moet worden vastgelegd en waar de gegevens moeten worden opgeslagen.

Dit staat in een XML-bestand dat ik heb gemaakt, genaamd "ros2_record.xml":

 xsi:noNamespaceSchemaLocation="http://community.rti.com/schema/5.3.1/rti_record.xsd"> 
 
  
  
  
 true 
 0 
  
 
  
  
 ros2_replay_example.dat 
 true 
  
 
  
  
 0 
  
 RTIDDS_DESERIALIZEMODE_NEVER 
  
 
  
  
 rt/velodyne_points 
 * 
 
 
 
  
  
  
 domain0 
 
  
 ros-rt 
 
 
 
  
  
 
 
  
  
 domein0 
  
  
  
 
 
  
  
 PointCloud2.xml 
  
  
  
 false 
 sensor_msgs::msg::dds_::PointCloud2_ 
  
 sensor_msgs::msg::dds_::PointCloud2_ 
  
  
 rt/velodyne_points 
  
  
  
 2147483647 
  
 
 
  
 . 
  
  
  
  
 
 
  
  
 

Om RTI Recording Service te starten met het bovenstaande XML-bestand, gebruik ik de volgende opdracht (uitgevoerd vanuit dezelfde map als het bovenstaande XML-bestand):

rtirecord -cfgFile ros2_record.xml -cfgName simple_example

Hiermee wordt de opnameservice gestart die zich abonneert op de LiDAR-gegevens en deze continu opneemt totdat ik het programma sluit. Het eindresultaat is een SQLite-databasebestand met de naam "ros2_replay_example.dat_0_0"

Aan de bestandsnaam worden getallen toegevoegd om onderscheid te maken tussen opnamesessies (het eerste nummer) en welk databasebestand dit in een reeks is (de bestanden zijn automatisch beperkt tot een door de gebruiker te selecteren grootte; zodra ze te groot worden, worden ze gesloten en wordt een ander bestand geopend om de volgende periode met gegevens te bewaren. Dit voorkomt dat de databasebestanden te groot worden).

Replayer-configuratie

Nu ik de ROS2 LiDAR-gegevens heb opgenomen, gaan we kijken of deze kunnen worden afgespeeld in ROS2.

Zoals vermeld in eerdere blogartikelen (A Field Guide to Interoperability and When Ecosystems Merge), vereist ROS2 enkele instellingen om compatibiliteit te garanderen. In dit voorbeeld is het verzenden van de typecode-informatie tijdens de ontdekking onderdrukt om compatibel te zijn met de standaardconfiguratie van de ROS2 "Bouncy Bolson"-release, maar deze aanpassing kan ook worden gemaakt in ROS2 als rmw_connext_cpp wordt uitgevoerd als de RMW-laag.

Deze instellingen – samen met onderwerp-, domein- en bestandsinformatie – worden in een ander XML-bestand geplaatst:

 
  xsi:noNamespaceSchemaLocation="http://community.rti.com/schema/5.3.1/rti_replay.xsd"> 
 
  
  
  
  
  
 annotatie> 
 Replay-servicevoorbeeld 
  
  
 1  
 AUTO 
 5 
  
 
  
  
 ros2_replay_example.dat_0_0 
 false 
 
  
  
 0 
  
  
 0 
 0 
  
  
  
 
  
  
  
 
 
  
  
 PointCloud2.xml 
  
  
  
 false 
 sensor_msgs::msg::dds_::PointCloud2_ 
  
 sensor_msgs::msg::dds_::PointCloud2_ 
  
 rt/velodyne_points 
  
  
 2147483647 
  
 
 
 . 
  
  
 
  
  
 
[1] [2] 下一页