![](bg2.png)
particular model of a certain device, and associates
all of them to a same interface. In that way the
control programs can interact with a device, using
their interfaces, without having to know the
particular characteristics of its driver. For instance:
there is only one interface ‘position’ that allows to
control the movement devices of any robot, and it is
implemented by some drivers (one by each concrete
device that allows to control) adjusted to this
interface.
Player provides already implemented a set of
drivers that allows to control commercial devices of
some robots (Pioneer 1, Pioneer 2, AmigoBot, RWI
B-series robots...). But if you want to use it to
control robots of own creation, or other ones that are
not between the implemented ones, it is necessary to
develop and implement a new specific driver for
each device of the robot, as each robot has its own
characteristics of hardware (microcontroller), system
media, etc.
Player can be executed in the most of the
UNIX/LINUX systems. It allows controlling
multiples devices and it offers the possibility of
modifies its code to add news drivers and/or device
interfaces.
Control programs (clients) communicate with
Player across a socket TCP, asking for data of the
sensor devices, sending command to actuators and
configuring devices. Player server admits multiples
clients connected at the same time, one by socket,
and these don’t have to be in the same machine,
simply they should be executed on a computer
located in the same network that the server. As well
as client programs can be written in any language of
programming that provides socket.
A very interesting aspect is the control of
multiple robots using TCP/IP wireless connections,
because they offer a greater operational range and
allow to control from an only PC (or robot), that is
in the same network, all robots. The problem is that
to do this with Player, we would have to execute an
instance of Player in each robot, something that in
most of robots is not possible (because they need to
have installed an operating system type
UNIX/LINUX). The reason is that drivers of Player
access, normally through serial connections, directly
to the devices and that is not possible using TCP/IP
connections. The software platform that we propose
allows to control multiple robots using only an
instance of Player, that can be executed in a PC of
the network or in a robot, and it does not need that
robots has a great capacity of processing: it can be
minirobots like K-team robots (Khepera robots).
In the following sections of this article the
proposed software platform is described, its
architecture, and conclusions.
2 PROPOSED SOFTWARE
PLATFORM
The software platform that we propose uses Player
as its intermediate layer and is thought to control
multiple robots of any type, through wireless
connections and without needing to modify its code
to control each particular robot.
It tries to facilitate complex aspects such as the
necessity to create a new driver for each device that
you want to control. Also it allows to control the
devices through TCP/IP connections.
In order to avoid having to create a new driver in
Player for each new device that we want to control,
we have developed a generic driver for each generic
type of device (one to sonar, other to IR, another one
for position, another one for battery...). These
generic drivers don’t have access directly to the
devices, it is done through a server application, that
is executed in the robot control module. The
communication between generic drivers and the
server application makes use of an own protocol and
it is possible to be made through wireless
connections.
This way to work is going to allow us to control,
without needing to add new exclusive drivers to
Player, any type of robot that incorporates the server
application model that we propose. In this way, it is
the robot that has to adapt to the software platform
and not this one to each particular robot.
The platform allows to control multiple robots
from an only PC (or robot), through a wireless
network, being able to execute the control programs
in any PC of the network.
2.1 Platform Architecture
It is an architecture in three layers (see figure 1).
The top layer is composed by the control
applications elaborated in any high-level language.
These applications communicate, making use of the
interfaces and through TCP socket, with the
intermediate layer (Player).
The lowest layer is composed by a server
application which is executed in the control module
of the robot, and has access to the robot devices. The
communication between the server application and
Player is made by TCP socket, following an own
protocol (see figure 3).
Both Player and server application of the robot
support multiple connections, so a control
application can work on several robots
simultaneously.
ICINCO 2005 - ROBOTICS AND AUTOMATION
436