Software Architecture for Robotics

REPORT FOR “SOFTWARE ARCHITETURE FOR ROBOTICS”, PROF. SUKHAN LEE.

Software Architecture for Robotics
Lorran de Souza Pegoretti
Dept. of Computer Engineering, Sungkyunkwan University
Suwon, South Korea
December 2013
Abstract – Programming a software for robotics is a non-trivial task. The
software must coordinate a countless number of different hardware
elements and software elements and must support some requirements of
heterogeneous systems. In this report, I want to present briefly, some idea
of how should be the software architecture for a robot and in addiction
explain what a middleware is, and how it can help us to develop the
software for a robot.

1 Introduction
Programming a software for robotics is a non-trivial task; it requires a significant iteration and
coordination of hardware and software elements.
The aggregation of a large number of sub-systems must be based on a solid software
architecture, for this way be possible realize the ambitious objectives of robotic research. In
addition, we need to guarantee a certain level of flexibility, performance and reusability of both
hardware and software and support the requirements of heterogeneous modern robotic system that
can be briefly summarized as: hardware abstraction, scalability, modularization, support for
multiple operating systems, extendibility, simplicity, limited runtime, networked computing,
completeness, etc.
Systems for robotics are becoming more and more complex, increasing the number of
constitutional parts that make up current robotic, as multiple sensors for perception, torque, radar,
laser based on sensors or vision systems including cameras as different as low-cost web-cams and
high-dynamic-range cameras.
Moreover, there are required and desired features for a robot software. In an academic
perspective there are required features as; support for multiple components, communication
between components, easy way to write own components, possibility to replace individual
components, easy to extend, means for data logging and debugging and support for decentralized
components. Desired features are; robustness, hardware abstraction, open access (open source
would be the ideal case) and hardware and operating systems independence.

1


Figure 1 - Hardware and software communication

In this scenario, of many hardware and software components needing to communicate
and collaborate to each other to reach a goal, a plenty of required and desired features that need
be covered, is exactly where a middleware can help improving the organization, the
maintainability and the efficiency of the code. In this report I will introduce the meaning of
middleware, what is a middleware, how a middleware can help us in the development of software
for robots, how is the middleware architecture and where we fit the middleware in our system.

2 Middleware
2.1 Middleware Origins
Middleware is a relatively new concept in computer science. It gained popularity in the 1980’s as
solution to wrap legacy system and interface them with newer application. However, the
introduction for the term “Middleware” can be dated of 1968 [1], when d’Agapeyeff used it for
the first time to identify the part of the software that could be shared between different applications.
D’Agapeyeff described an inverse pyramid (Figure 2) that describes a primitive software
architecture in which the high-level applications are build using a set of middle level routines, so
from this description comes the name “middleware”.

Figure 2 - Inverse pyramid of d'Agapeyeff

2


3

2.2 What is a Middleware?
According to Wikipedia, “Middleware is a computer software that provides service to software
applications beyond those available from the operating system. It can be described as “software
glue”. Middleware makes it easier for software developers to perform communications and
input/output, so they can focus just on the specific purpose of their application”.
Generally, a middleware consists of a set of services that allows multiple process running
on one or more machines to interact. This technology evolved to provide interoperability in
support the diffusion of coherent distributed architectures, which are most often used to support
and simplify the development of complex distributed applications. It includes services,
applications servers, and similar tools that support application development and delivery. [2]
Middleware “sits in the middle” between software applications that may run on different
operating system, it is stretched across multiple systems or applications. The middleware cannot
be confused with operating system; however, both are software used to support other software,
such as the application programs. Both provide a similar range of services centered around
controlled interaction. Like and operating system, middleware may enforce rules designed to keep
the computations from interfering with one another. [3]
Middleware is a set of libraries and APIs for specific applications; however, middleware
is not just this, middleware also represent a way of thinking the software, which will be designed
and developed on a specific middleware, so that defines the foundation for a complete application.

2.3 Why use Middleware?
Middleware is useful for a number of reasons when designing large, distributed systems.
Some relevant aspects are:
Portability: middleware offers a common programming model across language and/or platform
boundaries, as well as across distributed end systems. Thanks to this, it is possible to make
cooperative applications developed in different languages (e.g. Java and C++) and executed on
different operating systems (e.g. Windows and Linux) without any specific effort by the programmer.
Reliability: middleware are developed and tested separately from the final application. This allow the
application programmer to abstract low-level aspects and use (and re-use) a well-tested library.
Managing complexity: low-level aspects could be managed by suitable libraries that abstract specific
operating system or hardware aspects. This simplifies development and reduces the probability of
errors. [4]

3 Middleware in Robotics
3.1 Introduction
Robotic systems are usually complex systems built on many different hardware and software
components, as sensors, actuators, cameras, planners and control algorithms.


4

In general, on each robot runs a software that is responsible for reading sensors data,
extracting the needed information from them, computing the sequence of actions to accomplish a
given task and controlling the actuators to execute the actions. In a custom approach, there will
be a single application that will handle all these tasks, making code maintenance, code reuse
extremely hard and preventing any form of code sharing between different projects. In this
scenario, with many hardware and software components that needs to communicate and
collaborate to each other to reach a goal, is exactly where a middleware can help improving the
organization, the maintainability and the efficiency of the code.
Different components can exchange data using a common communication channel
provided by the middleware, using interfaces that are consistent between different applications.
In this way, it becomes easy to share and reuse code among different projects, since is only
necessary to keep the same interface.
As an example, if we need to switch from a proximity sensor to another, it is possible to write
a new component that share the same interface and update it without modifying the rest of the
application. This concept can be extended to large and complex applications, in which using a
middleware can clearly improve the overall code organization and reduce the programming effort.

3.2 Robotics Middleware Projects
There are plenty of robotics middleware projects, now I will present some of them and explain
how they are built, which programming language is used to develop each one and what does it
offer to us.
Player Project: It is an application server with the collection of dynamically loadable device
shared libraries. The main portion of this server is custom communication protocol, which enables
client-server communication model.
Player is implemented in C++ and uses POSIX compliant pthread interface for
multithreaded applications. Player can be viewed as a multithreaded application server providing
applications/services to client programs. For Player application/services are devices that are used
by client programs.
Since applications/services can be loaded dynamically, Player can be considered as "some
way in between monolithic application and modular middleware + services" approach.
Player does not implement any device locking mechanism whenever multiple clients are
connected to a Player server, so one can overwrite the commands of other clients. This applies to
commands and data but not to configuration requests, which can be used to access specific
hardware features.
RT-middleware Project: RT-middleware (Robotics Technology Middleware) is a common
platform standards for Robots based on the distributed object technology. [5] RT-middleware
supports the construction of various networked robotic systems by the integration of various
network enabled robotic elements called RT-Components. The specification and standard of the
RT-component is discussed/defined by the Object Management Group (OMG). [6]
In the RT-middleware, robotics elements, as actuators, are regarded as RT-components,
and the completely robotic system is constructed by connecting those RT-components. Using this


5

distributed architecture developers can re-use the robotic elements, and boosts the reliability of
the robotic system.
RT-middleware is just standard of the Robotics platform software. Therefore, there are
several implementations of RTM. RT-middleware does not assure the communicability between
the RTM implementations, however, the bridging tools that intermediate the communication can
be easily created because the state machines and their programming model is defined.
As example:
 OpenRTM.NET is an implementation of the RT-middleware for the .NET Framework platform.
[7]
 "RTM on Android" is an implementation on Android OS that is communicable with OpenRTMaist. [7]
 "RTC Lite" is a modified RT-middleware for embedded or small-resource systems such as PIC
(Microchip), ARM, H8 (Runesus), etc. [7]
MIRO: MIRO uses an abstract machine model; the system is divided into several distinct layers. The
higher layers can only access the lower layers via their interfaces.
In case of MIRO, these layers are:
 MIRO device layer: this layer provides classes to interface hardware and abstract the lowlevel hardware details, these classes enable access to hardware resources via simple
procedure calls.
 MIRO service layer - this layer provides service abstractions for sensors and actuators by
means of the CORBA interface definition language. These services are implemented as
network transparent objects/CORBA objects. The classes in this layer present the sensors
and actuators as generic services. For example, the RangeSensor class defines functionality
common to the sensors, which return range readings such as sonars, lidars and other type of
range finders.
 MIRO framework layer - on this level functional modules specific to robotics are provided.
Examples are mapping, localization, path planning and similar facilities.
For communication purposes, MIRO relies on a TAO middleware C++ implementation of the
CORBA standard. Subsystems/Objects communicate according to a client-server model, which is an
example for a distribution model. With respect to the time properties, both synchronous and
asynchronous modes of communication are utilized. The system also supports event driven
communication.

4 Middleware for Space Robots
4.1 Problem
Looking to middleware’s potential and what it has to offer us, we can think that using the proper
middleware is the solution to any problem that we may have about projecting and developing a
software for a robot. However, in some cases we cannot use a middleware, so we need to appeal to
other solution. One example that a middleware is not a solution is when we need to develop a software
for space robot. In this situation, we cannot use a middleware because it does not meet the
requirements of flight software and hardware.


6

As requirements that are not meet, we can cite: performance and memory usage, the fact of the
software does not have dynamic memory allocation, does not have callbacks and there is no large
external libraries.

4.2 Solution - CLARaty
A possible solution for software architecture for a space robot is to use approach proposed by
CLARaty (Cloupled Layer Architecture for Robot Autonomy).
One difference between the CLARaty architecture and the conventional three-level
architectures is the explicit distinction between levels of granularity and levels of intelligence. In
conventional architectures, both granularity and intelligence were aligned along one axis. As you
move to higher abstractions of the system, intelligence increases. This is not true for CLARaty, where
intelligence and granularity are on two different axes. In other words, the system decomposition
allows for intelligent behavior at very low levels while still maintaining the structure of the different
abstraction levels.
The CLARaty architecture has two distinct layers: the Functional Layer and the Decision
Layer. The Functional Layer uses an object-oriented system decomposition and employs a number of
known design patterns to achieve reusable and extendible components. These components define an
interface and provide basic system functionality that can be adapted to a variety of real or simulated
robots. It provides both low-level and mid-level autonomy capabilities. The Decision Layer couples
the planning and execution system.

Figure 3 - Two layers of CLARaty approach


7

The Decision Layer uses a declarative-based model while the Functional Layer uses a
procedural-based model. Because the Functional Layer provides an adaptation to a physical or
simulated system, all specific model information is collocated in the system adaptations. The Decision
layer receives this information by querying the Functional Layer for predicted resource usage, state
updates, and model information.
The Decision Layer accesses the Functional Layer at various levels of granularity (Figure 3).
The architecture allows for overlap in the functionality of both layers. This intentional overlap allows
users to elaborate the declarative model to lower levels of granularity. However, is also allows the
Functional Layer to build higher-level abstractions (e.g. navigator) that provide mid-level autonomy
capabilities. In the latter case, the Decision Layer serves as a monitor to the execution of the
Functional Layer behavior, which can be interrupted and preempted depending on mission priorities
and constraints. [8]

5 Conclusion
Having researched about middleware, understood how it works and how it can help us to develop
a robotic software. I can notice that using a proper middleware our work becomes easier, for
controlling all the sensors, for replacement of any sensor in a different one, for sharing code
between different projects and for maintenance of the code. However, we must be sure about what
must be done in the project. As cited, in some situations using a middleware is not the best solution,
so we need appeal to other approach. As in the example of special robot or flying robot, using a
middleware we may not reach the proposed goals, so we can appeal for the usage the CLARaty
approach, which works in a different way, in a double layer and not in a three-level architecture.
I can also notice that this research field is far from state of art, we are just in the beginning,
and there is still a long way to roam when the subject is software architecture for robotics.

References
[1] Report on a conference sponsored by the NATO SCIENCE COMMITTEE. Garmisch, Germany,
7th to 11th October 1968
[2] Simone Ceriani and Martino Migliavacca. Report for “Advanced methods of information
technology for autonomous robotics”, Milan, Italy
[3] Thomson Course. Operating Systems and Middleware: Supporting Controlled Interaction.,
California, USA, October 18, 2005
[4] C.D. Gill and W.D. Smart. Middleware for robots? Proceedings of the AAAI Spring
Symposium on Intelligent Distributed and Embedded Systems, 2002.
[5] Noriaki ANDO, Takashi SUEHIRO, Kosei KITAGAKI, Tetsuo KOTOKU, Woo-Keun Yoon,
"RT-Middleware: Distributed Component Middleware for RT (Robot Technology)", 2005,
Edmonton, Canada
[6] Object Management Group (OMG). “Robotics Technology Component Specification version
1.1”
[7] OpenRTM-aist, [http://openrtm.org/]
[8] I. A. D. Nesnas, A. Wright, M. Bajracharya, R. Simmons, T. Estlin, and W. S. Kim, “Claraty:
an architecture for reusable robotic software,” in Space Robots, vol. 5083 of Proceedings of SPIE,
April 2003.

Software Architecture for Robotics

More Related Content

What's hot (20)

Similar to Software Architecture for Robotics (20)

More from Lorran Pegoretti (6)

Recently uploaded (20)

Software Architecture for Robotics