3.2) Development Environment
Overview
This page is intended to provide an overview of the AERPAW development environment. The figure above (corresponding to the scenario on the right) shows an example experiment in development mode with one portable node (on a vehicle) and one fixed node. In development mode, the Experimenter gains access to the two Experimenter VMs (E-VMs), as well as to the Operator Experiment Oversight Console (OEO-Console). In other words, the Experimenter plays both the roles of the Experimenter (by editing experiment software in the two E-VMs), as well as that of an Operator, issuing system commands through the OEO-Console.
In addition to the parts of the system the Experimenter can access directly, every experiment in development mode also has support for a vehicle simulator (Software in the Loop - SITL), as well as a wireless channel emulator. The Emulation Overview page provides more details about the two emulation components in AERPAW.
Planning the Experimenter Code
We expect that the main activity of the Experimenter in development mode is going to be the development of the experiment code. Details on developing the wireless and vehicle applications are in the wireless and vehicle software page. Before the Experimenter starts developing the experiment we advise the experimenter to make an experiment plan similar to the one shown in the table included in the sample experiment page. The Experimenter should first answer these questions (indicated as question marks in the table on the right):
What type of radio software is needed for the experiment?
Which nodes will run which radio software?
If the radio software needs a traffic source, what type of traffic source? Where will the client and server be? (if a client-server traffic source is used)
Are there portable nodes? Then a vehicle control application is very likely needed.
Using the Sample Applications
The simplest (and safest way) to start developing experiments in AERPAW is to use the AERPAW provided sample applications. The page on running sample applications provides details on how to choose between the different options for the three components of the Experimenter code: the radio script, the traffic script and the vehicle control application.
The Experimenter should then carefully follow the plan, installing the client server applications in pairs on the different nodes, as well as edit the parameters of the sample applications as required by the experiment.
Using the OEO Console
The OEO console is the user-facing component that allows an operator to monitor the execution of the current experiment. While in testbed mode, the AERPAW Operators will use the OEO console, but in the development environment the Experimenter also wears an Operator hat and thus can use the OEO Console. To use the OEO Console the Experimenter will have to gain access to the OEO Console container. To start the OEO Console, after accessing the OEO Console container, type:
cd; ./startOEOConsole.sh
The complete documentation for the OEO Console is available at this page. In what follows, we only provide a minimum subset of commands that allow an experimenter to start and stop an experiment.
Starting an Experiment
Once the experiment scripts are complete, it is time to test the code. When the experiment is initially deployed in development mode, all the emulation software is ready for the experiment, so the Experimenter should start the experiment. There are at least two ways to start an experiment: manually, or through the OEO.
Manual Start
For starting an experiment manually, execute :
/root/startexperiment.sh
in each of the E-VMs. If the experiment involves TCP servers (e.g., if using an iperf server with a TCP port), please start the servers first, or, alternatively, appropriately delay the connection attempt from the client (e.g., via sleep).
If the experiment involves a vehicle, then the Experimenter will also take the role of the Safety Pilot and will have to manually arm the Vehicle. This can be done either:
through the OEO Console by typing all arm or <node_id> arm (to arm all nodes or a specific node), or
through the MAVProxy on the OEO Console (available in the mavproxy screen) by typing arm throttle at the MAVProxy prompt, or
through the QGroundControl connected to the OEO Console (which also has an ARM button on the GUI).
In the field the Safety Pilot will do the equivalent arming by using the remote control associated with the vehicle carrying the portable node.
OEO Start
To start an experiment from the OEO Console, run in the OEO Console:
<node_id> start_experiment
where <node_id> can be all if you want to start the experiment in all nodes, or a number, to start it in a particular node. The effect is the same as in the manual start case (i.e., the OEO system will execute the same /root/start_experiment.sh script as the Experimenter).
In the best case scenario the experiment will run exactly as the Experimenter desired, and the experiment results will then be available in the /root/Results folder for examination. The Experimenter should then assess the resulting logs, and if they are satisfactory for the purpose of the experiment, then the experiment can be then submitted for testbed.
However, in the case the experiment did not complete as desired, then the experiment should be stopped and reset before implementing the corrections.
Stopping an Experiment
In the likely event in which an Experimenter wishes to modify an experiment and re-run it, the entire system should be first reset. Before a reset, the experiment should be first stopped.
Manual Stop
To stop an experiment manually run:
# /root/stopexperiment.sh
in each of the E-VMs. This should stop all experiment processes in each of the E-VMs (other than bash and the system processes). This can be easily verified either by checking all the screen sessions (see help on screen if needed):
# screen -ls
or by checking the processes:
# ps -aux
OEO Stop
To stop an experiment from the OEO Console, run in the OEO Console:
<node_id> stop_experiment
where <node_id> can be all if you want to stop the experiment in all nodes, or a node _id to stop it in a particular node.
Resetting an Experiment
After all experimenter code has been stopped, the vehicle and wireless channel emulators need to be also reset.
Manual Reset
A manual reset is achieved by running:
/root/reset.sh
on any of the EVMs. This (assuming it completes successfully - please watch the feedback on the console) will reset all the emulation processes on the system and the experimenter can now edit the code and run the experiment again. Each run of the experiment will generate a new log in the /root/Results directory.
OEO Reset
For an OEO Reset, type in the OEO Console:
<node_id> reset_cvm
where <node_id> can be all if you want to reset the experiment in all nodes, or a node _id to reset it in a particular node.