Bullwinkle and Whiplash

Hardware

Xavier What we here at CMU often call "Bullwinkle" is really two robots grafted together. One part, our "original" Bullwinkle, is serial number 1 of the Real World Interface ATRV-2 line. It is a four-wheeled, skid-steered platform with a payload of up to 220 pounds. It mounts forward-, aft-, and side-facing sonars. It has an Inertial Navigation System consisting of its wheel encoders and a fiber-optic gyrocompass.

Bullwinkle mounts one Chipmunk single-board computer, a Carnegie Mellon developed design, which communicates via serial connections with both the microprossessor built into the ATRV and the PIC servo and IO boards which control the arm. The Chipmunk is a 500 MHz Pentium III processor in an 11 x 7 x 21 cm case with an on board framegrabber, ethernet, and video card.

The other half of the current Bullwinkle is Whiplash, a 5-degree-of-freedom anthropomorphic arm contructed by Metrica/TRACLabs for the Johnson Space Center and on loan to Carnegie Mellon. It is a custom-manufactured mechanism, with a maximum extended length of roughly one meter. The end effector is an electromagnet mounted on springs at the end of the wrist.

Low-level control of the arm's joints is provided by an array of PIC-SERVO boards and one PIC-IO board, built by J. R. Kerr. Each joint of the arm is controlled by a PIC-SERVO, while the PIC-IO manages the electromagnetic end effector. The boards receive input via a serial line from the Bullwinkle's chipmunk computer, an encoder feedback line, and one of two limit switch sensors. The limit sensor is only utilized during the "homing" sequence, as the "limit" sensors are in te middle of the range of most joints. The boards provide full PID control of position or velocity, with built-in trapezoidal velocity profiling when in position mode. Their maximum servo rate is 1953.12 Hz, while their maximum command rate to the joint actuators is 1000 Hz. The actual command rate from the software controller to the PICs is in the neighborhood of 20 Hz.

Research

One of Bullwinkle's first projects, prior to its link with Whiplash, was the Mars Autonomy Project. This program demonstrated navigation on a vehicle of the scale identical to that of NASA's FIDO rover that is baselined for a flight mission in 2005. Using a stereo vision algorithm developed at JPL, Bullwinkle demonstrated collision avoidance and route planning in Mars-like terrain.

After the addition of the Whiplash arm, Bullwinkle became part of the DiRA project. The primary objective of this project is to develop fundamental capabilities that enable multiple, distributed, heterogeneous robots to coordinate tasks that cannot be accomplished by the robots individually. The basic concept is to enable individual robots to act independently, while still allowing for tight, precise coordination when necessary. Individual robots will be highly autonomous, yet will be able to synchronize their behaviors, negotiate with one another to perform tasks, and "advertise" their capabilities. The main technical challenge of the project is to develop an architectural framework that permits a high degree of autonomy for each individual robot, while providing a coordination structure that enables the group to act as a unified team. Bullwinkle works with Xavier and RoboCrane on this project.

The DiRA project has grown into the TRESTLE project. Autonomous assembly of large structures will require teams of robots. Much like any human work crew, heterogeneous capabilities will also be necessary. The TRESTLE project is developing the architectural framework necessary to coordinate robots performing complex assembly projects. In specific, the project seeks to develop architectural tools used to coordinate actions performed by multiple robots. These tools form the core of an executive layer that orchestrates and monitors tasks across robots to perform assembly tasks. Since the number of possible failure modes over many robots working on long sequences of actions is high, TRESTLE incorporates the ability of humans to cooperatively manage tasks. By employing Sliding Autonomy, we allow the operator to manage the assembly in three different ways. First, a portion of the system's tasks can be predefined to be under operator control. Second, the operator can intervene and manually switch the system to operator control. Third, the system can automatically shift to operator control after a failure.


Greg Armstrong
Last modified: Thu Feb 17 14:22:25 EST 2005