Your scenario model consists of your network topology and the messages that communicate across it:

• Network topology
• Network flows

To define your scenario, identify the network configuration and the ROS2 messages that flow between robots. Construct your scenario model by creating your communication and network components.

Network topology

Build your network topology using the miniedit GUI:

1. Start the miniedit GUI network editor:

    ~/gits/mininet/examples/miniedit.py
   

   or if using mininet-wifi:

    ~/gits/mininet-wifi/examples/miniedit.py
   

2. Build your scenario's network configuration using the miniedit GUI. A reference for using this GUI is at http://www.brianlinkletter.com/how-to-use-miniedit-mininets-graphical-user-interface/.

3. Save the network configuration as a Python script by opening the File menu and selecting Export level 2 script.

4. Edit the saved Python script to make it compatible with the mininet_runner tool:

   • Open the script with an editor.

   • Comment out the lines at the bottom of function myNetwork which start the command line interpreter and then stop the network:

     # CLI(net)
     # net.stop()
     

     and add this line in its place to return the network object that gets created:

     return net
     

   • You may also wish to adjust QoS properties or rename hosts.

Network flows

Messages relating to varying topics pass between publishing and subscribing robots. ROS2 communicates messages between robots using the DDS communication protocol. A publication consists of the publication topic name, the size and frequency of the publication, and QoS properties for the publication. A subscription consists of the topic name and QoS properties for the subscription. Security policies may also be set for robots and topics. See QoS and Security for information on setting QoS and Security policies.

We manage topic flows by robot role. First we define publication and subscription topics and assign them to roles. Then we define robots by name and assign roles to them.

Publisher, subscriber, and robot properties are defined using comma-separated value (CSV) entries in Scenario files as follows, where properties consist of role-based definitions for publication and subscription topics and the names of robots and their role:

• Publisher - Define publisher topics by role. Also defines the QoS policy for publishing the topic. Publisher entries have this format:

  Publisher, Role, Topic, Frequency, Size, History, Depth, Reliability, Durability
  

  This example defines a publisher role for a red_team robot where odometry messages are simulated by transmitting at 10 Hz 500 bytes of collective odometry information using a QoS policy of keep_last, 0, reliable, volatile:

  Publisher, red_team, odometry, 10, 500, keep_last, 0, reliable, volatile
  

• Subscriber - Define subscriber topics by role. Also defines the QoS policy for the topic. Subscriber entries have this format:

  Subscriber, Role, Topic, History, Depth, Reliability, Durability
  

  This example defines a subscriber role for Ground Station GS "robots" for receiving odometry data using a QoS policy of keep_last, 0, reliable, volatile:

  Subscriber, GS, odometry, keep_last, 0, reliable, volatile
  

• Robot - Define robot names and the role the robots will take:

  Robot, Name, Role
  

  This example assigns robot R1 to the GS role:

  Robot, R1, GS
  

Example

Please see Example 1 mininet which describes the steps for defining a 5-robot swarm scenario, simulating it, and then plotting network traffic results.