-
Notifications
You must be signed in to change notification settings - Fork 2
Designing your Scenario
Your scenario model consists of your network topology and the messages that communicate across it. To define your scenario, identify the ROS2 messages that flow between robots and the configuration of robot network. Construct your scenario model by creating your communication and network components.
Model communication flows between robots by defining ROS2 messages that flow between network nodes. ROS2 communicates between robots using the DDS communication protocol. Communication is sent from publishers and is received by registered subscribers. A publication consists of the publication topic name, the size and frequency of the publication, and QoS properties set for the publication (see QoS and Security#ROS2 QoS Policy). A subscription consists of the topic name and QoS properties set for the subscription.
Robot swarms are role-based. First we define publication and subscription topics and assign them to roles. Then we define robots by name and assign roles to them.
The publisher, subscriber, and robot properties are defined using comma-separated (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
Several GUI tools are available for defining complex network configurations, https://dl.acm.org/doi/10.5555/2685617.2685639, https://ieeexplore.ieee.org/document/7148414?reload=true&arnumber=7148414. We describe working with the miniedit
tool because it is packaged with mininet-wifi.
Here are the steps for building the network topology for your Scenario using miniedit
:
-
Start the
miniedit
GUI network editor:~/gits/mininet-wifi/examples/miniedit.py
-
Build your scenario's network configuration using the
miniedit
GUI. -
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
-
While here, you might also wish to rename nodes, change node positions, or rearrange lines to make the code more readable.
-
You might also want to make adjustments. See https://usermanual.wiki/Pdf/mininetwifidraftmanual.297704656/view. For example to add mobility, see Section 5.6.
-
Save your modified Python script.
-
Please see Example 1 which describes the steps for defining a 5-robot swarm scenario, simulating it, and then plotting network traffic results.
An alternate workflow is to not provide a network property setup file but to instead put network settings directly into the CSV file (Type none
for the Python filename). This approach only supports ad-hoc network configurations. this workflow is depracated and may be removed.
For ad-hoc networks, we can define stations, links, radio propagation, robot mobility and some other properties directly within the CSV file instead of using miniedit by adding CSV entries. These entries are ignored when using GUI-generated code:
-
Stations - Station definitions for each robot such as location for fixed-location stations:
Station, Name, param=value, ...
For example settings, see
addStation
in the examples in the mininet-wifi repository. -
Links - Radio link information for the network link on each robot:
Link, Name, param=value, ...
For example settings, see
addLink
in the examples in the mininet-wifi repository. -
Propagation Model - The radio signal propagation model:
Propagation Model, param=value, ...
See
setPropagationModel
in the examples in the mininet-wifi repository. -
Mobility Model - The mobility model:
Mobility Model, param=value, ...
See
setMobilityModel
in the examples in the mininet-wifi repository.Alternative to Mobility Model, we can define start and stop points for individual robots using
Start Mobility
,Mobility
, andStop Mobility
, see example usage in the mininet-wifi repository. -
Plot Graph - How to plot the real-time mobility graph:
Plot Graph, param=value, ...
See
plotGraph
in the examples in the mininet-wifi repository.
File scenarios/example10_deprecated.csv
is provided as an example for working with this syntax.