Download Report - Image Group

2.3 Drivers
Player/Stage
2 PLAYER/STAGE DETAILS
to commands the actuators of a robot at a time, while the rest of the user programs may subscribe to sensor data message. In other words, each user program can only control devices
on its own robot but is allowed to snoop on its neighbors’ devices.
2.3 Drivers
Player is distributed with a rich set of drivers for commonly used robots and robotics related
hardware. However, not all robots and hardware are supported “out of the box”. In this
case, Player has a rich framework for writing drivers for new hardware. Two methods exists
for extending Player with new drivers. A driver may either be built-in at compile time
or plugged-in at runtime. The choice of whether to implement a built-in or plugin driver
mainly depends on whether the driver is going to be submitted for inclusion in the coming
version of Player. Drivers that are going to be maintained out-of-tree as a separate package,
must be plugins. The ability to extend Player by dynamically load drivers into a running
Player server offers a great level of flexibility when developing and using drivers.
2.3.1
Virtuel Drivers
In the above, we describe drivers as a method for providing access to sensors or actuators,
but in Player it is also possible to expose algorithms through virtual drivers. This driver type
offer a powerful way to extend Player with advanced and reusable features.
A virtual driver implements special purpose functionality in Player through one or more
interfaces. Instead of deriving input from real hardware, they usually build upon the interfaces provided by one or more other drivers. A virtual driver can get data from other
drivers, process and use advanced algorithms on the data, and finally output the result to
the interfaces it provides. Besides the interfaces, usually targeted for hardware drivers, a set
of interfaces exist purely for these virtual drivers. There are no restrictions regarding which
interfaces they can provide, i.e. a virtual driver can also provide interfaces normally associated with hardware, such as an odometry interface. Using this approach, virtual drivers can
be used to apply error correction to hardware derived data considered prone to errors.
A good example of a virtual driver is the acml-driver based on the Adaptive MonteCarlo Localization algorithm. This virtual driver takes as input odometry and laser data,
and provides two new interfaces that estimates the robot’s position based on the algorithm’s
computation on the input data.
2.4 Devices and Device Addressing
The Player server makes it possible for drivers to provide multiple devices all using the same
interface. For example, a driver can provide two position2d devices, each with different
origin of data, or two separate drivers can each provide a position2d that originates from
two different robots. To allow drivers and clients to easily distinguish between devices, each
device that is provided by a Player server must be given a unique device address. This is
usually done in a configuration file passed to the Player server when starting up.
The fully-qualified device address consists of 5 parts: key:host:robot:interface:index. Broken down, the key is a unique name, the host and robot fields are usually the host name and
port number on which the Player server listens but may vary on the context[4], the interface is
the interface name of the device, and the index is a interface specific sequence number. In the
Bue Petersen & Jonas Fonseca
13