Recent Changes - Search:

Research

Notes

Architecture

Faults

System

Planning

Background

OS

Misc

edit SideBar

PlayerStage

Player / Stage

The Player project is the precursor to ROS. It was developed at USC in the early 2000's, with version 2 released in 2005. It is similar in design to the slightly earlier CARMEN; both rely on a client / server architecture for modules with well defined interfaces.

Stage is a 2D simulator designed along side Player (the 3D simulator is Gazebo). Stage provides devices and a Player plugin so that Player can seamlessly switch between running in the real world and a simulated environment.

I use Player / Stage for the basis of my Framework.

Player

source paper

Brief summary slides that I made for a research group presentation.

The architecture of Player sets control programs as clients, which communicate with drivers maintained by the Player server. These drivers are initialized through a configuration file, and they can communicate with each other as well as with clients.

This Communication is transparent; TCP sockets are typically used, and marshaling is handled by code automatically generated from an interface definition language. This allows drivers and control programs to potentially be written in a variety of languages. However, in practice c/c++ is the preferred language although python is relatively easy to use for control programs.

The driver abstraction is not what one may immediately expect: it is a threaded node which processes and/or publishes messages. It started out as representing hardware components such as actuators and sensors, but it was found to be extremely convenient to create drivers for easily decomposeable tasks such as local navigation. As long as the task has a well defined interface, then it is suitable to encapsulate as a driver. This can make for sparse control programs that merely send commands to sophisticated drivers and thus greatly eases the programmer's burden.

Stage

Stage is a low-fidelity 2D simulator which provides virtual devices for robot motors and sensors. Although it was designed to complement Player, the two can be run independently. A common use-case is to develop robotic software using Player with Stage in place of hardware for testing, and then move to actual hardware that is just running Player.

Stage is executed with a configuration files of it's own. The master file has a .world extension, and this file can include similar files (with a .inc extension, but the format is the same). This allows one to define robotic models and objects as .inc files, and the scenario setting as a .world.

Edit - History - Print - Recent Changes - Search
Page last modified on August 13, 2014, at 08:49 AM