• View
• Edit
• History
• Print

Framework

THIS PAGE IS NOW COMPLETELY OUT OF DATE

I am currently using Player / Stage as my experimental platform, and have augmented it with a good deal of code to facilitate experiments.

Player Stage

The base application. Player follows a client-server architecture to coordinate multiple "drivers." These drivers may represent hardware components in the traditional sense of driver, but may also represent purely software component. For example, a path planner may exist within a driver.

Player coordinates the communication between drivers. So the path planner driver may receive inputs from sensor drivers and send messages to motor control drivers.

Stage is a low-fidelity 2D simulator designed for use with Player (although it is a separate entity). It has emulated device drivers which Player can redirect messages from and to. In this fashion, the control code may does not need to know if it is running on a real or simulated platform.

See the Player Stage page for more information.

My additions

I have forked the Stage GitHub with my additions. Most are contained within the subdirectory experiments which actually has a useful README file.

So far almost all of my additions have been confined to Stage, but I have recently begun to add new interfaces to Player which need to be copied over and compiled into Player for my Stage additions to work correctly. Make sure to make clean, as changes to the client libraries will not be detected by make.

Basic workflow for creating experiments.

As seen above, the process for creating a new experiment consists mainly of setting the parameters through a .conf file. This sets the number of runs to make, the controllers to use, the failure model, and so forth. The environment is defined by a .cfg file and a .world file.

This makes it easy to set up and execute many test runs, but is a bit obfuscated and geared towards the use case of running many python controllers. For more low level control and easy testing, the run_player.py script is more appropriate.

Additional Code

A script to generate the configurations for individual runs as well as a shell script that will execute overload.py. A few short scripts to generate new images to be used as maps.

Fault / Noise Injection

The current fault / noise models supported are limited to player drivers which are interposed between other drivers. In this way it is trivial to distort or lose commands / readings. For example, a noise adding driver can be placed between a range sensor and the control program which uses it.

Currently I am working on ways to model and inject a different type of fault, such as SEUs. This is further explained in the Faults pages.