Designing your Robot Scenario - nps-ros2/ns3_testbed GitHub Wiki

Define the communication flows for your robot scenario using a spreadsheet, then export it to CSV format so that your robots can access it when they start up.

The spreadsheet defines publications and subscriptions for various nodes along with their transmission rate, size, and QoS settings.

Here is the example1.csv file exported from the demo spreadsheet:

Publish,,,,,,,
Node,Subscription,Frequency,Size,History,Depth,Reliability,Durability
R2,odometry,10,500,keep_last,0,reliable,volatile
R2,image,10,2500,keep_last,0,reliable,volatile
,,,,,,,
R3-29,odometry,10,500,keep_last,0,reliable,volatile
R3-29,image,10,2500,keep_last,0,reliable,volatile
,,,,,,,
,,,,,,,
Subscribe,,,,,,,
Node,Subscription,History,Depth,Reliability,Durability,,
R1,odometry,keep_last,0,reliable,volatile,,
R1,image,keep_last,0,reliable,volatile,,

where:

  • Publish starts the publish section. Rows in this section define publishers. node.create_publisher is called to instantiate each publisher.

  • Subscribe starts the subscribe section. Rows in this section define subscriptions. node.create_publisher is called to instantiate each subscription.

  • Column Node identifies the robot node name, starting with R, and one of R1, R2, R3, etc. The number of R* nodes is set using the count parameter you provide when running setup scripts. Note that you may provide an inclusive range for robots, for example R2-R29 for 28 robots from R2 to R29.

  • Column Subscription is the name of the subscription.

  • Publisher column Frequency is the publication frequency, in Hz.

  • Publisher column Size is the "payload" size. The actual size may be twenty bytes larger.

  • Columns History, Depth, Reliability, and Durability define QoS parameters. For a description of these (and many other QoS parameters likely not supported by ROS2) please see the RTI Connext DDS Comprehensive Summary of QoS Policies at https://community.rti.com/static/documentation/connext-dds/5.2.0/doc/manuals/connext_dds/RTI_ConnextDDS_CoreLibraries_QoS_Reference_Guide.pdf.

    Specifically:

    • History controls history depth. Modes are keep_all and keep_last. For keep_last, use Depth.
    • Depth defines history depth when History mode is keep_last.
    • Reliability regulates reliability of data received. Modes are reliable and best_effort. For reliable, DDS will track transmissions and attempt to repair lost transmissions. For best_effort, DDS will not track transmissions and will not attempt to repair lost transmissions.
    • Durability provides durability by transmitting previously transmitted data to readers that join late. Modes are transient_local and volatile.

    On the ROS2 side, QoS parameters are set on a per-topic basis for publishers and subscribers, see rclcpp Node API interfaces create_publisher and create_subscription at http://docs.ros2.org/beta3/api/rclcpp/classrclcpp_1_1node_1_1Node.html. The ROS2 QoS profile structure is defined at http://docs.ros2.org/latest/api/rmw/structrmw__qos__profile__t.html. A ROS2 QoS discussion is here: https://design.ros2.org/articles/qos.html.