15-05-2013, 04:55 PM
RECIPE – A System for Building Extensible, Run-time Configurable, Image Processing Systems
A System for Building.pdf (Size: 106.27 KB / Downloads: 13)
Abstract
This paper describes the design, and implementation of RECIPE, an extensible, run-time configurable, image capture
and processing system specifically designed for use with robotic systems and currently under active development here at Bonn.
Robotic systems, particularly autonomous robotic systems, present both challenges and opportunities to the implementors of their
vision systems. On the one hand, robotic systems constrain the vision systems in terms of their available resources and in the
specific form of the hardware to be employed. On the other hand, intelligent processes can employ sensory input to modify the
image capture and image processing to fit the current context of the robot.
Introduction
Computer vision, in particular computer vision on robots, is a multidisciplinaryresearch area which presents a different
set of problems and criteria to systems designers than that exhibited by vision and image processing systems to be
run on more general platforms. On the one hand, the robotic nature of the platform itself places many restrictions
on the resources available to a vision system as well as requiring a much closer integration with hardware than is
found generally. On the other hand, the mobile nature of the platform, the additional sensory information available
to the robot and the practical nature of the tasks to be performed by most (if not all) robots, affords opportunities for
optimisation and information integration that would not be generally applicable for desktop systems.
RECIPE Modules
Suppose that we wish to perform an operation such as Canny edge detection on an image. Further suppose that this
operation is defined in an image processing library and that, rather than rewriting the code, we wish to reuse it as a
RECIPE module. This scenario is used to illustrate the concept of RECIPE modules.
In RECIPE, all functionality is provided in the form of these modules. RECIPE modules are dynamically loadable
active objects [10]. They are linked and configured at run-time, have their own thread(s) of control and contain a
message queue as shown in figure 1. All threads have the same function. They are placed in a processing loop which
waits on a condition variable for the arrival of messages fromthe rest of the system. (Message transfer will be explained
later in the paper.) Once a message arrives, one thread awakens, removes the message from the queue, validates it and
parses it. Message parsing is currently rather simple. A command consists of text describing the module to carry out
the operation, the operation to be performed and the arguments to be supplied to the operation. There is currently no
restriction on what may be carried out by the thread. After function execution, the thread returns to waiting.
RECIPE
The design of the RECIPE system is shown in figure 2. RECIPE consists of two main applications – captured and
(possibly multiple copies of) ipd. An application called cook is provided for communication with the ipd process(es)
and for remote testing of modules. In RECIPE, everything is a dynamically loaded active object. All functionality, even
the working parts of the applications, is provided as dynamically loaded and configured, multi-threaded modules. The
RECIPE framework provides facilities for sending messages to other modules, for loading and unloading modules,
and for making large items of information, such as images, available to modules in shared memory. We now describe
each of these applications in more detail with the aim of showing how RECIPE meets the criteria listed in the previous
section and additionally comment on the system’s implementation.
Implementation
RECIPE is implemented using the object oriented, platformand compiler neutral framework ACE, the Adaptive Communications
Environment, under constant development at the University ofWashington [11] and already incorporated
into several mission critical, commercial systems. Many of the framework’s components are repurposed as a result of
the implementation. The run-time dynamic linking is simply a light wrapper around the Service Configurator component
of this framework and the modules are lightly disguised ACE Tasks communicating by way of ACE Message
Blocks. The memory manager is also derived from the ACE Malloc class with a memory mapped file allocation pool.
Here we must mention one of the problems inherent in the RECIPE design and indeed any design that uses
C++ with shared memory. Objects placed in shared memory may not have virtual functions (without trickery or
special techniques). The use of C++ templates is possible (if the compiler you are using can compile them correctly).
Thus RECIPE images and ROI’s are perforce simple objects which act merely as data containers. More complicated
representations may be used in the modules.
Operation and Results
Suppose that a robot is requested to visually verify its location. The robot is given (or has calculated) a reasonably
accurate map of its environment. Verifying its location consists of finding and recognising landmark objects such as
items of furniture known to be in its vicinity. We assume that a remote high level controlling process such as that
found in the FAXBOT system [14] sends control messages to a RECIPE system running on the robot. We illustrate
the sequence of operations involved in figures 3 and 4. (The example refers to version 0.2.0 of the software.)
Conclusions and FutureWork
Our main experience so far with the development of the system has been the value of the platform independence
afforded by the ACE framework. The porting time from Solaris to Linux for the system was measured in hours. The
same cannot be said, however, for porting between compilers. We make an empassioned plea for the C++ standard to
be uniformly implemented by all compiler suppliers.
Concerning operation of the system, we are very encouraged by our early trials. The simplistic tests presented here
represent only a fraction of the system’s potential. The FAXBOT system shows how an image processing system can
become an integral part of a robot control system. More research in this area is worth pursuing. When coupled with
more image processing functionality incorporated from standard libraries or made available as utility modules, we
believe that this system will become a core feature of our vision work on our robot (and hopefully those of others.)