Software
EE
Robotics
Part 1
ngineering
By Fulvio Mastrogiovanni
Ever since Microsoft released
their Robotics Developer
Studio framework [1], Software
Engineering (SE for short)
issues for robotics started to
receive increased attention
by researchers, as well as
engineers, professionals,
and practitioners.
Up to now, software architectures for robots could be
described quite simply: a bunch of software applications
(often called modules) running on the same microprocessor.
They are either on board the robot or on a remote
workstation connected through wireless; each one dealing
with specific aspects of the problem of robot control. In the
case of mobile robots this involves: getting information
from sensors to avoid obstacles; planning a path to reach
a given area in the next few seconds; controlling actuators
to actually follow the planned trajectory; keeping the robot
localized with respect to the surrounding environment;
reasoning about what to do when once arrived in the
desired location; and so on.
Did we miss something? Yeah! Don’t forget real-time
issues! Each module must process the right piece of data at
the right time. Otherwise, delays in the processing chain
will make the robot good only for funny TV shows. I should
mention that software modules must be able to communicate with each other and with the underlying hardware,
and this process must be reliable, efficient, and well under
46 SERVO 09.2009
the communication bandwidth limit. What about faults? Do
you expect your robot to work 24/7 without any trouble?
What if, for instance, the next fancy Mars Rover gets stuck
somewhere in the Red Planet for a bug in a module that is
of secondary importance (I must admit that there are
probably no modules in a Mars Rover that are of secondary
importance)? How can we fix the bug and upload a new
version of the module in time for the next transmission?
Finally, I hope you don’t forget to take care of shared
data structures. These must be maintained, coherent, and
up-to-date for all the modules to use them.
The Emergence of Software
Requirements and Solutions
During the past few years, many important requirements emerged for software applications running on board
real-world robots. Robot software architectures must be:
•Concurrent. Different modules with different
behaviors, input requirements, produced outputs, and
computational loads must share onboard CPU time.
•Distributed. One CPU is not enough anymore to
guarantee real-time requirements; multi-core systems or
even a combination of onboard CPUs and remote
workstations connected through wireless constitute the
next-gen robot infrastructure.
•Embedded. Dedicated microelectronics can be used in
place of low-level software modules in order to speed up
the execution of specific algorithms. Proper interfaces
between hardware (HW) and software (SW) layers must be
found and properly managed.
•Real-time. Coordination among many concurrent
modules must be guaranteed in specific cases under any
condition. For instance, a software module for obstacle
