29-01-2013, 02:53 PM
Implementing distributed control system for intelligent mobile robot
1Implementing distributed.pdf (Size: 264.79 KB / Downloads: 26)
Abstract
The control system of a mobile robot has a number
of issues to deal with in real time, including motion
control, mapping, localization, path planning, and sensor
processing. Intelligent reasoning, task-oriented behaviors,
human–robot interfaces, and communications add more
tasks to be solved. This naturally leads to a complex hierarchical
control system where various tasks have to be processed
concurrently. Many low-level tasks can be handled
by a robot’s onboard (host) computer. However, other
tasks, such as speech recognition or vision processing, are
too computationally intensive for one computer to process.
In this case, it is better to consider a distributed design for
the control system in networked environments. In order to
achieve maximum use of the distributed environment, it is
important to design and implement the distributed system
and its communication mechanisms in an effective and flexible
way.
Introduction and discussion
Mobile robot controllers are rather complex systems that
have to deal in real time with a number of tasks in order
to allow the robot to operate autonomously. These tasks
include motion control, sensing, planning, navigation, etc.
Robot controllers are usually designed as modular and hierarchical
systems. This makes it easier to realize complex
system functions using a composition of more simple taskoriented
modules. There are numerous works on designing
mobile robot control architectures.1–4 A number of mobile
robot controllers were successfully implemented using proposed
architectures.4,5
If mobile robots are to perform useful tasks in open
environments, their control systems should be provided
with high-level intelligent features like natural human–
machine interfaces: speech recognition, face and sign recognition,
and other ways of human–robot interaction. The
problem here is that algorithms which may provide these
features are usually very computationally intensive. If these
high-level programs use the same computer which also
handles low-level control and sensing then this will affect
the system performance and worsen the response time of
run-time system components.
Control system architecture
From a general point of view, our system architecture follows
a well-established structure.4,5 There are two levels of
control built one on the top of the other: the hardware
control level and the robot control level (Fig. 1). The
hardware control level includes a set of procedures for
controlling robot hardware: motors, encoders, sensors,
pan-tilt-zoom cameras, etc. On this level, all hardwarespecific
control issues are resolved and presented to the
higher level in an abstract robot state. Motor input voltages
are represented by desired velocities, encoder pulses are
processed to reflect current robot velocity and odometry
status, ultrasonic sensor readings are filtered, and so on.
Communication mechanisms
In this section we discuss the communication mechanisms
we use to implement the distributed system. We used
CORBA architecture and infrastructure to link distributed
modules of the control system together. This architecture is
vendor and platform independent and can be used in a
variety of areas including real-time applications. We used
the omniORB-free implementation of CORBA.
Robot control with distributed components
Components in the distributed system can operate with
little or no supervision from outside. Nevertheless, in order
to operate as a complete control system, the collection of
distributed modules needs to be integrated together. Coordinating,
directing, and overseeing the operation of distributed
components in order to achieve control goals requires
some form of central management. In our system, this
management was provided by the so-called executive
component.
The executive component task is to coordinate the work
of other components. The executive communicates with
other modules on the messaging communication level.
Its scripting engine allows the programming of new robot
actions and behaviors (we call them “activities”), and
executes these programmed activities in real time. Robot
activity scripts follow finite state automaton (FSA) semantics
and use executive kernel, threading, message processing,
and event processing libraries to perform their
functions and state transitions.
Conclusions
In this article, we presented our implementation of a distributed
control system. The distributed design provides open
and dynamic framework for realizing mobile robot control.
The distributed design enables sharing of computational
load between available computers to achieve maximum system
performance when using computationally demanding
control algorithms and intelligent robot–human interfaces.
The system consists of collection of separate executable
task-specific components that communicate between each
other over the network. CORBA-based communication
mechanisms that allow the linkage of system components
together using different communication strategies were
considered. The structure and implementation details of the
executive component, the task of which is to integrate and
coordinate the operation of distributed components, were
discussed.