Install ROS2, mininet, and this repository:

Install ROS2 Crystal:

sudo apt update && sudo apt install curl gnupg2 lsb-release
curl http://repo.ros2.org/repos.key | sudo apt-key add -
sudo sh -c 'echo "deb [arch=amd64,arm64] http://packages.ros.org/ros2/ubuntu `lsb_release -cs` main" > /etc/apt/sources.list.d/ros2-latest.list'
sudo apt update
sudo apt install ros-crystal-desktop

Also, source the ROS2 Crystal setup script in order to set up environment variables required for working with ROS2 as described in https://github.com/nps-ros2/nps-ros2-examples/wiki/Installing-the-ROS2-Environment#set-global-variables. Specifically, add this line near the bottom of your ~/.bashrc file:

source /opt/ros/crystal/setup.bash

Install Mininet. First, determine whether you want mininet or mininet-wifi.:

Please see About Mininet and About Mininet Wifi. Either may be used, but mininet-wifi is difficult to configure. To install mininet:

sudo apt install mininet

Clone this repository:

mkdir ~/gits
cd ~/gits
git clone https://github.com/nps-ros2/mininet_testbed.git

Developers who use RSA keys to authenticate may prefer to clone using git instead of https:

git clone [email protected]:nps-ros2/mininet_testbed.git

Build mininet_testbed:

cd ~/gits/mininet_testbed/testbed_ws
colcon build

Add this line to your .bashrc file to make this project visible:

source ~/gits/mininet_testbed/testbed_ws/install/local_setup.bash

and open a new command window.

Set up the robot roles and the network topology for your swarm, see Designing your Scenario.

Once you have defined your swarm scenario, run your simulation by typing: ./mininet_runner.bash <Python network setup file> <CSV communication setup file> <Log output file>. The <Python network setup file> configures the scenario's network. The <CSV communication setup file> configures the scenario's communication. The <log output file> names the log output file. The mininet_runner tool uses Sudo so that Mininet can configure the virtual network devices required by your scenario.

For example type this to run the example1.csv scenario, saving the output log to file _mininet_test_outfile:

cd ~/gits/mininet_testbed
./mininet_runner.bash ~/gits/mininet_testbed/scenarios/example1_mod.py ~/gits/mininet_testbed/scenarios/example1.csv _mininet_test_outfile

Once you have collected enough log data, type exit or press Ctrl-D to cleanly stop the simulation. If the Mininet configuration gets broken because a previous run did not end cleanly, type this to clean up:

sudo mn -c

The mininet runner logs information that flows between robots. In the example run above we generated data in output log file _mininet_test_outfile. This log file contains CSV entries for each message transmitted and each message received. Here are the transmit and receive fields that get written to the log:

• Transmit:

  from, to, topic, tx index, timestamp
  

• Receive:

  from, to, topic, tx index, rx index, message size, timestamp
  

To manage logging for analysis, transmitted data includes the publisher name and the transmit index. As a result, the actual payload size is the requested size plus the length of the publisher name plus four bytes for the transmit index. Here is the TestbedMessage.msg file that defines the message content that is transferred from publishers to subscribers:

string publisher_name
uint32 tx_index
string message

Once the mininet runner has configured the network and started the robots in their respective network namespaces, it opens the Mininet command line interface (CLI). From here you can spawn commands that run on specific stations, where station names are robot names. This allows experimentation on nodes while the simulation is running. Here are some example commands run at the station assigned to robot R1:

• Batch-open an xterm window in R1's network namespace where you can for example enter Ping commands to other stations (default IP addresses start at 10.0.0.1):

  R1 xterm &
  

• Open Wireshark in R1's network namespace:

  R1 wireshark
  

Post-process the mininet_runner log file using the plot_analytics.py tool, specifying the output log filename, the plot name, and any optional parameters. Use -m <max latency> to bound the maximum latency, in ms, to plot, default 20 ms. Use -b <bar period> to set the time period for the bar plots, default 5 seconds. Use -w <plot filename prefix> to write plots to filenames using the given prefix, default is to plot directly to the screen.

For example to plot the latency and loss characteristics captured in the example log file _mininet_test_outfile, above, labeling the plot test, type:

cd ~/gits/mininet_testbed
./plot_analytics.py _mininet_test_outfile test

• Use Wireshark to observe network traffic. This will show if or when traffic starts at a node.
• Check for log messages from individual robots in file _log_<robot name>. For example if ROS2 environment variables are not set, it will read: bash: ros2: command not found.
• Check the contents of your log output file to see what messages are being sent or received. Or just run plot_analytics.py to inspect the plots.

There are inherent limitations in modeling network behavior. These limitations can impact test results when attempting to scale up to large network sizes, resulting in unrealistic measurements and inconsistent communication failure. Limitations include:

• Modeling the whole network within operating system's networking system.
• How the WiFi devices are simulated.
• Demands of the DDS and ad-hoc network protocols.
• Limitations of modeling all this on one computer.
• Undue congestion when transmit times are not randomly staggered.

An approach for working alongside these limitations might be to start small and increase network size and load, being alert to limitations of the modeled network and the network modeler.