Embedded Processing

While turning my focus to available robotic platforms and the development tools currently available to designers for my just-published hands-on project (see "Robots on the march"), I quickly noticed parallels between what issues designers have to address regardless of whether they are working on robotic designs or semi-autonomous subsystems.

An example from my own personal experience is the autonomous vehicles I worked on in the early 1990s. They sensed the world inertially and visually, had a set of goals they tried to accomplish, had a means to move around, interact with, and affect the world around them, and were "smart enough" to be able to adjust their behavior based on how the environment changed. We never referred to these as robots, and I never thought to apply the word robot to them until I started this project.

The first thing I discovered is that defining what makes something a robot is not clearly established. I found a description for robots from the Robot Institute of America (1979) that says a robot is "A reprogrammable, multifunctional manipulator designed to move material, parts, tools, or specialized devices through various programmed motions for the performance of a variety of tasks." Our autonomous vehicles met that description. They were reprogrammable and they could manipulate the system through six degrees of freedom to accomplish a variety of tasks. Despite this, I think it would still be difficult to get people to call them robots.

Additionally, it seems there are many embedded subsystems, such as the braking systems or stability-control systems resident in many high-end automobiles, that might also fit this description—but we do not call them robots either. Even my clothes-washing machine can sense and change its behavior based on how the cleaning cycle is or is not proceeding according to a predicted plan; the system can compensate for many anomalous behaviors. These systems can sense the world in multiple ways, they make increasingly complex decisions as their designs continue to mature, they meaningfully interact with the physical world, and they adjust their behavior based on split-second changes in the environment.

Webster's definition for robot, "a machine that looks like a human being and performs various complex acts (as walking or talking) of a human being" offers some insight into why we did not call these vehicles robots. It seems that the term robot best applies to the description and behavior of the end-application rather than to an embedded subsystem. The parts of these systems that meet the first presented definition of robot are embedded in the system and not necessarily obviously apparent in the description of the end behavior.

Mechatronics is a candidate term to describe the development of these types of subsystems. The term emphasizes the cross-discipline combination of mechanical, electronic, and software engineering within a single module, subsystem, or system. Even though the term was introduced in 1969, it is only now resurfacing as a common description for these types of systems.

Why is a common and accepted term important? If there is a common design and engineering thread among all these systems, from explicit end-applications to deeply embedded control systems, how, as an industry, are we able to better amortize the development efforts from any one of these system designs to another? It seems that much of the current robotic and embedded robotic development is stand-alone—it does not build on the efforts of the entire industry in the way that allowed the electronics and software industries to grow at the phenomenal rates we've seen in the past few decades.

By using words that help clearly identify the commonality of these different systems, we as an industry can refine and expand that description to steer development-tool design, interface specifications, and third-party intellectual property certification to better accommodate the evolving needs of a maturing multidisciplinary design abstraction. I believe this design abstraction may represent an important and necessary step to maintain the growth in design productivity of these increasingly complex systems.