# Plexe

The Platooning Extension for Veins.

# Plexe Examples - Extending Plexe

Note: This tutorial assumes you already cloned the git repositories for running Example 1.

## Step 0. Building Plexe with sample changes

To switch to the code for this example and build the source, simply do the following (you can do this on your Instant Plexe VM as well):

## Description

The second example shows how Plexe can be extended to implement a user-defined control model to be tested against the others. The control law of the custom controller is defined as

The controller tries to maintain a fixed distance of 25 m, and has two gains that acts on the speed ($k_s$) and the distance ($k_d$) error components. In this example we set $k_d = 0.2$ and $k_s = 0.4$.

## Running the example

This example is the same as Example 1, but this time we have the new user-defined controller as well. Assuming you already run Example 1 and you did not delete the results, you can just run the two new simulations:

## Plotting the results

When the simulation terminates, go into the analysis folder and type

By typing make the Makefile you already generated for Example 1 parses the result files and merges them into the merged .Rdata files. The older results are untouched, so they are not re-processed. The script generates plots similar to the ones of the first example, but this time they include the user-defined controller. The plots clearly show the instability of the controller (it even leads to a collision in the braking scenario), which could be expected since this is a toy example. This shows, however, how easily Plexe can be extended to test new control algorithms.

## Changes to the source code

This example requires changes to both Plexe-Veins and Plexe-SUMO. As the tutorial adds a new controller, the main changes are made in Plexe-SUMO, while the changes in Plexe-Veins are only needed to tell the simulator to use this new controller. We thus start describing the changes to Plexe-SUMO. In particular:

• CC_Const.h: we change this file in SUMO (and in Veins as well) to add some constants about the new controller we add to the simulator. In this file we find an enumeration with the list of all available controllers. We add the new one by defining the enum as

According to the control law shown above, the controller has two parameters, $k_d$ and $k_s$, so we create two constants for setting the value of those parameters via the TraCI interface, and we do so by adding the following two lines

The value of the two constants should clearly be unique within this file.

• CC_VehicleVariables.h: as this class maintains the state and the variables of a vehicle using automated controller, we add two variables for storing the values of $k_d$ and $k_s$. In particular we declare them as

and we initialize them in the constructor initialization list (CC_VehicleVariables.cpp):

• MSCFModel_CC.h: as described in the documentation, the MSCFModel_CC class is the core of the Plexe-SUMO extension. If you want to introduce a new CACC, you will need to make changes to this file. With respect to the header file, the only thing that we need to do is to define the prototype of the function for our controller, i.e.,

where veh is a pointer to the vehicle using the controller, egoSpeed is its current speed, predSpeed is the speed of the vehicle in front, and gap2pred is the distance to the front vehicle.

• MSCFModel_CC.cpp: the actual implementation goes into the C++ file. First, we edit the _v() function, where the model computes the speed of the vehicle at the next simulation step depending on the current vehicle state and the chosen controller. In the switch statement, we add

The model first checks whether it has received at least one beacon from the vehicle in front. If that is the case, the model computes the acceleration using our new CACC algorithm. If no front beacon has been received so far, the model cannot compute a valid acceleration value, so the car keeps cruising with a constant speed.

Next, we add the actual implementation of our controller:

Finally, we need to handle the passing of the $k_d$ and $k_s$ parameters via the TraCI interface. To do so, we edit the setParameter() function. This function handles data coming from Plexe-Veins and has the following prototype:

The veh variable is the vehicle for which this method has been called, key is the parameter to be set, while value is the value for that parameter.

To handle value passing for our parameters we add two new if statements.

The two constants we are handling are the ones we defined in the CC_Const.h file. Please notice that this example does not change SUMO to parse the parameters of our controller from the vehicle type XML definition. The reason is that this requires to modify the SUMOXMLDefinitions.h file, which causes an almost complete rebuild of SUMO. Without this changes, switching branch and recompiling is a matter of a few seconds.

Concerning changes from the Plexe-Veins side, we simply need to edit the simulation to use the new controller available in Plexe-SUMO. The first step is to copy-paste the CC_Const.h we edited in Plexe-SUMO. Then we perform the following changes:

• BaseScenario.ned: we add the two parameters of our controller to be able to set them within the omnetpp.ini file. To do so we simply add
• BBaseScenario.ned: to reflect the changes into BaseScenario.ned, we add the same parameters to the module defining the default values
• BaseScenario.h: we create two class variable to store the parameters in the C++ implementation:
• BaseScenario.cc: we change the implementation to load the value of such parameters in the initialize method:

and to pass their value to Plexe-SUMO in the initializeControllers() function:

Finally, we need to enable the use of our new controller when requested, so in the initialize method we add the following lines:

• omnetpp.ini: the next step is to change the configuration of the simulation in examples/platooning. First, we set the values for our controller parameters:

Then, we need to add a new simulation run that uses our new controller:

The first two lines add a numeric ID to our controller (which adds an additional simulation run) and pass the MYCC string as the controller to be used associated with such ID. The headway parameter is only needed by the ACC, but we need to add a value to respect the cardinality of the controller variable. Any number can be used here. Finally, we need to modify two parameters of the PlatoonsTrafficManager class. As the class inserts platoons at steady state, we need to tell it at which distance vehicles should be inserted for each controller. In our case, we have a fixed distance of 25 m (first line) and there is no headway time (second line).

• plot-sinusoidal.R and plot-braking.R: finally, we change the plot scripts to plot the behavior of our controller. We change both files and add

## Diff

To show you all the changes made in this example, in the following we show the full diff between the plexe-2.1 and the plexe-2.1-mycc-example git branches.