Skip to content

VREP Simulation

Jump to bottom Edit New page
Devon Ash edited this page Feb 5, 2019 · 1 revision

Prerequisites

GAMS must be compiled with V-REP support.

Introduction

This tutorial covers the V-REP simulations included with GAMS and design of custom simulations. V-REP is a 3-D simulator for robotics which provides support for controlling quadrotor UAVs and ground-based robots using Lua scripts, remote API calls, and ROS nodes. Of those interaction options only the remote API is used. Each implemented area coverage algorithm has an associated simulation script included in the repository in the scripts/simulation directory along with MADARA variable initialization files. A simulation manager called dynamic_simulation was written to support creating simulation environments on demand. The GAMS executable, called gams_controller, is also used for simulations.

Table of Contents

Setup

The remoteApiConnections.txt file in $VREP_ROOT must be modified to tell the VREP remote API which ports to listen on. On Linux and Windows machines, this file is located in the root of the unzipped folder. On Mac machines, this file is in vrep.app/Contents/MacOS. A script has been created to modify this file. Run the script remoteApiConnnectsionGen.pl with two arguments. The first argument is the first port for V-REP to listen on and the second argument is the number of ports to open. One port is needed for the simulation controller (dynamic_simulation) and an additional port is needed for each agent that will be simulated, i.e. for n agents, n+1 ports are needed. All of the simulation scripts are designed to start at 19905 and at most require 11 ports (i.e., running remoteApiConnectionsGen.pl 19905 11 is suitable for all current simulations).

For a two agent example (which could be generated using remoteApiConnectionsGen.pl 19905 3), the file contents should look like the following :

portIndex1_port 		= 19905
portIndex1_debug 		= false
portIndex1_syncSimTrigger 	= true

portIndex2_port 		= 19906
portIndex2_debug 		= false
portIndex2_syncSimTrigger 	= true

portIndex3_port 		= 19907
portIndex3_debug 		= false
portIndex3_syncSimTrigger 	= true

This can be continued for as many agents as required for the simulation.

Simulations also require that V-REP be running before any GAMS code is executed. On Linux, launch V-REP by executing vrep.sh (in $VREP_ROOT) from a terminal. On Windows and Mac, launch V-REP as you would any other application. On Linux and Windows, the ports listed in remoteApiConnections.txt should be marked as starting in the script output:

Starting a remote API server on port 19905
Starting a remote API server on port 19906
Starting a remote API server on port 19907

When the simulation starts, set the simulation to run in real-time in the v-rep window (the clock button next to the tortoise and hare).

The script also requires that the terminal commands be set for launching each gams_controller instance. In simulation.pm, change $term_prefix and $term_suffix to what you want to use. If $term_prefix is not empty string, then "$term_prefix <cmd> $term_suffix" is executed as a system command. If they are left as an empty string, then OS specific launch conditions are used. On Linux, this is a new xterm instance with the "-hold" option. On Windows, this is a new command terminal with realtime precedence named Device<id> with the id of the agent being simulated in the terminal. On Mac, a new Terminal instance is launched. Alternatively, the environment variables $GAMS_TERM_PREFIX and $GAMS_TERM_SUFFIX can be used to set $term_prefix and $term_suffix without changing simulation.pm. For example to override the OS Specific launch conditions and simply run the gams_controller in the background under linux for the zone_coverage simulation do the following:

export GAMS_TERM_PREFIX="sh -c"
export GAMS_TERM_SUFFIX="&"
./zone_coverage_simulation.pl

Running a Uniform Random Edge Coverage Simulation

The Uniform Random Edge Coverage simulation simulates three quadrotor UAVs executing the Uniform Random Edge Coverage algorithm over a convex polygon. To launch it, run the urec_simulation.pl script. This script does two things:

  1. Launches an instance of gams_controller for each simulated agent
  2. Launches dynamic_simulation to produce the simulation environment in V-REP

During initialization, objects will be added to the V-REP environment. dynamic_simulation places floor tiles to provide a bigger area for the simulation and each gams_controller instance creates its representative quadrotor. When dynamic_simulation is done creating the environment, it starts the simulation and signals each gams_controller to begin executing.

dynamic_simulation listens to the updated MADARA variables to collect information about the simulation such as how long it takes to completely cover the area. The gams_controller also prints its knowledge base every 15 iterations of the MAPE loop. The quadrotors will move about the simulation environment in V-REP controlled by their respective gams_controller.

To quit the simulation, stop the simulation in V-REP, kill each gams_controller instance and kill dynamic_simulation. All objects added in the V-REP environment by the simulation must be removed before the next simulation is started.

Creating Custom Simulations

Simple modifications to the Uniform Random Edge Coverage simulation can be accomplished by adding or modifying MADARA initialization files and updating the simulation launch script.

Adding an Agent

Using madara_init_2.mf as an example:

.vrep_port=19908;

.initial_x=20;
.initial_y=20;

These three variables control how the drone is initialized in V-REP. .vrep_port is the port the simulated agent uses to connect to V-REP. .initial_x and .initial_y are the initial coordinates of the quadrotor in V-REP.

device.2.command="cover";
device.2.command.size=2;
device.2.command.0="urec";
device.2.command.1="region.0";

The next set of variables are the commands to be executed. See Area Coverage for an explanation of these lines.

Using this as an example, a simulated fourth agent would be described with madara_init_3.mf:

.vrep_port=19909;

.initial_x=22;
.initial_y=22;

device.3.command="cover";
device.3.command.size=2;
device.3.command.0="urec";
device.3.command.1="region.0";

Note that the port is changed, the initial location is changed to a new unique location, and the device command variables are updated with the correct id.

The next file to change is urec_simulation.pl:

#!/usr/bin/perl
use lib "$ENV{GAMS_ROOT}/scripts/simulation";
use simulation;

$gams_root = $ENV{GAMS_ROOT};
$time = 3600;
$madara_debug = 0;
$period = 0.5;
$num = 3;
$sim = "urec";
$area = "small";
$plants = "region.0";

simulation::run($num, $time, $period, $sim, $area, $madara_debug, $plants);

$time is the time in seconds to run the simulation, $madara_debug is the level to use for MADARA debug output, $period is the time between MAPE loop executions, $num is the number of agents in the simulation, $sim is location of the simulation files relative to ./scripts/simulation, $area is the simulation environment description file found in ./scripts/simulation/areas with ".mf" being appended automatically, and $plants is the region or search area to outline in plant models. Multiple regions or search areas can be specified in $plants by using a comma separated list. For this change to using four agents, simply update $num to 4.

$num=4;

By changing the madara_init_<integer>.mf files and the simulation specific launch file, any combination of agents and algorithms can be created.

Changing the Simulation Environment

Simulation environments are defined in the scripts/simulation/areas folder. Using the CMU athletics area as an example:

// cmu athletics area
.vrep_sw_position="40.442832,-79.940941";
.vrep_ne_position="40.443501,-79.939573";

// cmu football field
region.0.type=0;
region.0.size=4;
region.0.0="40.443501,-79.940802";
region.0.1="40.443257,-79.939573";
region.0.2="40.442832,-79.939734";
region.0.3="40.443110,-79.940941";

Area description files are MADARA variable initialization files. .vrep_sw_position and .vrep_ne_position are <lat,long> coordinates that define the southwest and northeast corners of the simulation environment. dynamic_simulation uses these values to determine the size of the created environment with .vrep_sw_position being mapped to (0,0) in the V-REP coordinate system. The VREP_UAV class of objects uses .vrep_sw_position to translate between GPS coordinates and the V-REP cartesian coordinate system. With this mapping and translation, all algorithms continue to work on GPS coordinates while simulation platforms can use their own coordinate systems.

A region is also defined. region.0 is defined to be a convex polygon (region.0.type=0) defined by four GPS coordinates (region.0.size=4). The four coordinates are then specified by region.0.0 through region.0.3.

A second area, this time the CMU parking garage, can be added to the file to create a second region:

// cmu east parking garage
region.1.type=0;
region.1.size=4;
region.1.0="40.444179,-79.941016";
region.1.1="40.443718,-79.938951";
region.1.2="40.443444,-79.939053";
region.1.3="40.443893,-79.941113";

The east parking garage at CMU is now defined as region.1. Because an additional region was added, the .vrep_sw_position and .vrep_ne_position variables should be changed to reflect this.

.vrep_sw_position="40.442832,-79.941113";
.vrep_ne_position="40.444179,-79.938951";

Both regions will now fit in the environment that is created by dynamic_simulation. Now that an additional region has been defined, it can be used in the previously modified madara initialization files.

Further Reading

Search Areas are defined as a collection of regions and some area coverage algorithms only accept search areas. For defining those, see the articles on MadaraVariables and AreaCoverage.

Add a custom footer
Add a custom sidebar

Clone this wiki locally