Skip to content

Designing your Scenario

Jump to bottom
Bruce Allen edited this page Jun 1, 2020 · 33 revisions

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. Then construct your scenario model by creating your communication and network components:

CSV Communication Setup

We model communication flows between robots by composing ROS2 messages that flow between network nodes using the DDS communication protocol. Communication is sent from publishers and is received by registered subscribers. The publications and subscriptions a robot uses depends on its role. We simulate publications by defining publication frequency and publication size in a CSV file. We also define the QoS policy to use for publishers and subscribers. Because robots have roles, we assign specific publications and subscriptions to roles. We then assign these roles to robots. A given robot runs on a specific network node.

Communication properties

We define communication properties in a CSV file. These properties consist of role-based publication definitions, role-based subscription definitions, and the names of robots and their role:

  • Publishers - Defines publisher subscriptions by role. Also defines the QoS policy for publishing the subscription. Publisher entries have this format:

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

  • Subscribers - Defines subscriber subscriptions by role. Also defines the QoS policy for subscribing to the subscription. Subscriber entries have this format:

    Subscriber, Role, Subscription, History, Depth, Reliability, Durability

  • Robots - Defines robot names and the role the robots will take:

    Robot, Name, Role

History, depth, reliability, and durability define the QoS policy, see https://index.ros.org/doc/ros2/Concepts/About-Quality-of-Service-Settings/. Here is the QoS syntax for scenario files:

  • 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.

Network Properties

We define complex networks using miniedit, which is packaged with mininet-wifi. We could also use VDN. For references, please see https://dl.acm.org/doi/10.5555/2685617.2685639, https://ieeexplore.ieee.org/document/7148414?reload=true&arnumber=7148414. We can also define simpler ad-hoc networks directly in the CSV configuration file as described later.

Using miniedit

We can define complex network configurations using the miniedit GUI which is packaged with mininet-wifi. Here we show an example of using miniedit to define the ad-hoc network that is similar to the example at ~/gits/mininet-wifi/examples/adhoc.py:

  • Start miniedit:

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

  • Build the adhoc example:

    • Click the station (laptop) icon
    • Click three places to drop three stations. You may need to adjust their positions later so they are in range of each other.
    • Click the link (line) icon
    • For each station, click down on one station, drag the cursor, and release the click on another station to connect stations with a link.
    • Click the selection (arrow) icon
    • Right click each link to define the connection type as ad-hoc and to set the source and destination properties for wlan0.
    • Save the network as a Python script by selecting the File menu and selecting Export level 2 script.

  • Make the saved script compatible with the mininet_runner tool:

    • Using an editor, comment out the lines near the bottom which start the command line interpreter and then stop the network:

      # CLI_wifi(net)
# net.stop()

      and add this line in its place:

      return net

    • Save this modified file.

Using CSV Rows

For ad-hoc networks, we can define stations, links, radio propagation, robot mobility and some other properties directly within the CSV file using the following entries:

  • 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, and Stop 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.

Examples

ad-hoc network in CSV

Here is the mininet_testbed's example swarm defined at ~/gits/mininet_testbed/scenarios/example1.csv. It defines one ground station that publishes odometry data and four red team robots that subscribe to odometry data:

# Publisher, Role, Subscription, Frequency, Size, History, Depth, Reliability, Durability
Publisher, GS, odometry, 10, 500, keep_last, 0, reliable, volatile

# Subscribers, Role, Subscription, History, Depth, Reliability, Durability
Subscriber, red_team, odometry, keep_last, 0, reliable, volatile

# Robot, Name, Role
Robot, R1, GS
Robot, R2, red_team
Robot, R3, red_team
Robot, R4, red_team
Robot, R5, red_team

# Station, Name, param=value, ...
Station, R1, range=100, position=0;0;0
Station, R2, range=100, position=1;0;0
Station, R3, range=100, position=0;1;0
Station, R4, range=100, position=-1;0;0
Station, R5, range=100, position=0;-1;0

# Link, Name, param=value, ...
Link, R1, cls=adhoc, intf=R1-wlan0, ssid=adhocNet, mode=g, channel=5, ht_cap=HT40+
Link, R2, cls=adhoc, intf=R2-wlan0, ssid=adhocNet, mode=g, channel=5, ht_cap=HT40+
Link, R3, cls=adhoc, intf=R3-wlan0, ssid=adhocNet, mode=g, channel=5, ht_cap=HT40+
Link, R4, cls=adhoc, intf=R4-wlan0, ssid=adhocNet, mode=g, channel=5, ht_cap=HT40+
Link, R5, cls=adhoc, intf=R5-wlan0, ssid=adhocNet, mode=g, channel=5, ht_cap=HT40+

Propagation Model, model=logDistance, exp=4
Plot Graph, min_x=-2, min_y=-2, max_x=2, max_y=2

Scenario File with Coded Topology

The above setup is sufficient for configuring a topology with stations. You may code any network configuration that Mininet-WiFi supports using ROS2 properties in a scenario file and Network properties in a Python code file. The robot names in your scenario file must match names used in the code, for example sta1.

  • ROS2 Properties: Define your publishers, subscribers, and robots using the scenario properties for these, described above.

  • Network Properties: Define your network topology using Python code. As a starting point, please see the examples in the mininet-wifi/examples directory. Here are the steps:

    • Look for examples of configurations similar to your target scenario in the mininet-wifi/examples directory. Network property setup happens in the topology function.

    • Modify the topology or pick an existing topology.

    • Remove the bottom port that starts the command line interpreter (CLI) and stops the network. These lines might look as follows:

      info("*** Running CLI\n")
CLI_wifi(net)
    
info("*** Stopping network\n")
net.stop()

    • Add this line at the bottom of the topology function to return the network object back to mininet_runner so it can start the robots:

      return net

    Once your Python file is set up, invoke mininet_runner.bash passing it the -t "args..." argument indicating that the topology comes from your code.

    An example file is provided at mininet_testbed/scenarios/adhoc.py. Invoke it as follows:

    ./mininet_runner.bash scenarios/adhoc.csv zah -t "scenarios/adhoc.py -a"
Clone this wiki locally