Designing your Scenario - nps-ros2/mininet_testbed GitHub Wiki
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:
-
Start the
miniedit
GUI network editor:~/gits/mininet/examples/miniedit.py
or if using mininet-wifi:
~/gits/mininet-wifi/examples/miniedit.py
-
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/. -
Save the network configuration as a Python script by opening the
File
menu and selectingExport level 2 script
. -
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 whereodometry
messages are simulated by transmitting at 10 Hz 500 bytes of collective odometry information using a QoS policy ofkeep_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 receivingodometry
data using a QoS policy ofkeep_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 theGS
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.