Figure 1. The Cog—a humanoid robot.

The term "android" better describes a robot with humanoid form and human-like abilities. The construction of an android that comes as close as possible to mimicking human behavior is the goal of The Cog Project (Fig 1), work being done at the Humanoid Robotics Lab at MIT's Artificial Intelligence Laboratory. The group has spent several years trying to build a prototype general-purpose flexible and dexterous autonomous robot while also trying to learn more about human cognition.

Indeed, comments research assistant Bryan Adams, with this robot the group isn't studying functionality; it's studying the interactions of humans and machines. Yet any robot consists of electromechanical parts. So in engineering terms, Cog is a set of sensors and actuators along with a control structure that together try to approximate the sensory and motor dynamics of a human body. Except for legs and a flexible spine, the major degrees of freedom in the trunk, head and arms are all there.

Although Cog's facial structures might not be as fully developed as a human's, his arms are reasonably similar. First of all, they're built to a realistic scale. Note, though, that they're not the pick-and-pace arms you typically associate with a robot; Cog doesn't yet have any hands or fingers. For now, the robot's extremities consist of a metal flipper, and at one time it had claws, while an actuated hand assembly is now under development. These arms supply six degrees of freedom including pitch and roll, thereby providing everything a human has except for lateral (side-to-side) movement in the palm area.

Be gentle

Rather than teaching the robot how to pick up objects, the team is focusing more closely on how the robot interacts with his environment in a natural manner. In this regard, it's first important to note that human arms show a spring-like reaction to resistance by their very nature -- our arms deflect off obstacles due to the way our muscles sense length and apply force.

The response for a mechanical system is generally far different. For instance, when you command an industrial robot to swing its arm to a new position, most models generally do so with considerable force. Often running under control of a proportional-derivative (PD) algorithm, they show some spring-like reactions, except these spring reactions are extremely stiff. Thus, a factory robot generally uses a seemingly unbounded amount of force to move towards its goal, even if another object -- such as an operator's head -- is in the way. Because of the tendency of an industrial robot to push its arm through you, you'd likely get slugged pretty hard. There's a good reason why "Keep Away" signs are posted all around industrial robots.

The important difference between Cog and a typical industrial robot is that for Cog stiffness/compliance is a dynamic operating parameter instead of one an operator tunes and sets permanently. Just like a factory robot, Cog could theoretically belt a person pretty hard if the programmer cranks up its stiffness quotient high enough. The researchers' challenge is figuring out how to implement robotic tasks while having the system maintain a very low level of stiffness. In that way Cog can mimic the response of biological systems, which try to keep stiffness low because that type of reaction uses energy and puts high stress on the skeletal system.

Let's take a closer look at the implementation. Each of Cog's arms is loosely based on the dimensions of its human counterpart. Each arm has six degrees of freedom with a dedicated dc motor. Further, each arm uses two springs: a physical spring, supplemented by a virtual spring in software that adds the low-frequency characteristics. This combination allows the CPUs to control the motors so as to simulate a passive spring-and-damper system.

The physical spring in the actuator doesn't closely emulate natural behavior because, like the electromechanical systems in an ordinary industrial robot, it's far too stiff. It does, however, implement a type of mechanical lowpass filtering that makes controlling the actuator easier. For example, the physical spring prevents chatter when an arm contacts a surface.

The software controller simulates a variable-compliance spring. The end result of this combination is that Cog's overall spring-like property gives each arm natural behavior; if an arm hits an obstacle or is otherwise disturbed, it deflects out of the way. The physical springs take up sudden loads, and the software springs take up "less-sudden" loads. More specifically, the arm compensates for a collision first with the physical springs (before the computation has had a chance to notice) and then by the software springs (to implement the larger "macro" spring behavior).

PC-based data-acq hardware is one element that helps make this virtual spring action possible. The implementation is relatively straightforward. A potentiometer reads the position of the arm, and strain gages measure torque at the joints. A motion-control card digitizes these strain signals and feeds them directly into a DSP that controls the motors so that the force control loop is adequately fast and stable. In addition, analog measurements of joint position and velocity

At this point a PCI-bus board from United Electronic Industries digitizes signals that represent joint position and velocity at six positions on each arm, bringing the total number of channels to 24. The system uses these signals in conjunction with the stiffness and damping of the software spring to determine the output force. The loop for the virtual spring can run at a relatively slow rate, so the card can sample across its channels at 1 kHz, and 12 bits is plenty of resolution for this application. This software-based spring loop sends its torque commands to a motor-controller card that implements the torque control loop independently at a higher frequency.

The RTOS edge

From the standpoint of raw performance, this application isn't exceptional, and almost any data-acq card could handle the job. What gives United Electronic Industries the edge, though, is that firm's range of drivers for realtime operating systems.

Specifically, Cog's computational control consists of a network of processors in a control hierarchy. The current core is a network of a dozen 400-MHz industrial PCs connected with an Ethernet and all running the QNX realtime OS.

The group chose that operating system for several reasons notes Matt Marjanovic, a research assistant at The Cog Shop. Key criteria included: * network transparency and extensibility—the QNX interprocess communication API hides any network transport. * self-hosted development environment—you can log in to a machine, compile some code and change the processing environment at run time. * Unix/POSIX system—because it works well and makes porting code easy. * hard realtime performance—QNX is a real RTOS with optimized libraries, fast interrupt response and a realtime scheduler.

Of these, network transparency was quite important for Cog because of the distributed nature of its various control elements. With QNX, processes can run on different CPUs yet communicate across a network with essentially the same overhead as processes communicating on the same computer. As such, a process can be as compacted or spread out as a network allows. Further, an application is easily expandable; you don't have to re-write code to run a process on its own node. One tradeoff with QNX, notes Bryan, is that there's not a lot of off-the-shelf software, so the researchers had to write much of their own. Thus it was important to find a data-acq card where QNX drivers were available -- and they found that UEI fills the bill as concerns PCI data acquisition. Into the future This hardware and software have taken the researchers a large step towards a larger goal: to build a system that can move with the speed, precision, dexterity and grace of a human so it can physically interact with the world in human-like ways. These are prerequisites for going the next step, to multimodal coordination. To be truly effective as an embodied robot, Cog requires a general mechanism for overall sensor-motor coordination, a facility for effectively combining skills or at least preventing them from interfering with each other.