Servo - October 2009

possible not only because the operating environment is assumed (or simply is) static from the robot perspective, but also because all the possible interactions between a robot and its surroundings are static and well-defined. So much so, in fact, that use cases are usually adopted to model these interactions.

In this article, I would like to unleash an onslaught of terror over this idyllic view of robotics as the life of robotics engineers is not so easy. Let’s examine all of our previous assumptions in a more critical way.

— maybe — will be fine. Otherwise, many funny things will happen, but in spite of the laugh, the system is not going to work.

Thinking About

Our Assumptions

All of our assumptions can be summarized by the following two examples:

Static environments. Do we really think that human-populated environments are static? Maybe we are not going to deploy our robots in the middle of New Delhi or at Times Square, but I can assure you that a warehouse is an ever-changing and highly dynamic environment, especially during working days. Other robots, human personnel, boxes, and other objects to stock or transport are nearby, possibly manipulated in ways far independently from the robot’s tasks. At the same time — and also for these reasons — the shape of the environment continuously changes. We are not speaking about obstacles located over pre-programmed robot paths, but about big impacts over the robot operating environment, for instance, the impossibility of following such a path, thereby requiring the robot to think about a detour.

Static interaction with the environment. How do you interact with your environment? Human behavior (which I assume to be highly intelligent, right?) is opportunistic and not programmed in advance; to such an extent that we are not even aware of this. To us, it seems that we perform the same action many times (and we get annoyed by them), but there are slight differences that count — different speed, different trajectories followed by our hands, different precisions, and so on — which ultimately depend on our perceptions, possibly in a way that is not even conscious. To instil these slight differences in robot behavior is the hard task. What if the object the robot is supposed to load from a given place is missing or slightly misplaced? Or, what if it weighs too much for the robotic arm? If I (the robotic engineer) considered these cases during the design phase, everything

If the validity of these two assumptions cannot be guaranteed anymore and if the fundamental requirements that every robotic system must exhibit must still hold, it is immediately evident that such methodologies as domain-engineering are not suited anymore to design and deploy an actual system. In fact, if either the environment or the modalities of interaction between robots and the operating environment (or both) are no longer known or predictable in advance, it is not possible to consider a static domain to analyze.

Every relevant aspect is in question: maps, paths, goals, schedules, operating conditions, just to name a few. As a consequence, the OOP framework cannot help anymore, since its modelling process requires the complete knowledge of the domain to be modelled. In particular, the following aspects of a robotic architecture are affected if we relax the previous assumptions:

Real-time operations. A system able to adapt to its dynamic environment must be extremely versatile. This requirement is usually implemented by providing the robot with many modules that can be activated/deactivated at run-time, since if all of them were scheduled concurrently the required on-board processing power would increase too much (on its turn, imposing impractical restrictions over energy consumption). Scheduling policies able to manage the execution of different modules in different situations are therefore fundamental. This kind of behavior, on its turn, requires the robot to be able to understand different situations, and therefore to be endowed with the necessary sensing and reasoning capabilities. In a sense, such a