Mechanical and Electrical Architecture

The WAM Arm is modular and comes in three major configurations: 4-DOF (degrees of freedom), 7-DOF with a Wrist, and 7-DOF with Gimbals. Both the 4-DOF and 7-DOF with Wrist configurations have a tool-plate at the end that supports attaching a BarrettHand, Barrett's 6-axis Force/Torque Sensor, and customer-designed tools and sensors.

NOTE:
There are several different models of the BarrettHand, the most recent of which is the BH8-280 model. The base of the BH8-280 is blue, while older models are gold or black. Before plugging a BH8-280 into a WAM, make sure that the WAM's wiring is 280-compatible. (Contact support@… for information about upgrading an older WAM to be 280-compatible.)

Both the Hand and the WAM make use of Barrett's proprietary brushless DC motor controllers, known as Pucks. Each Puck is mounted to the back of the motor it controls and contains:

• A magnetic encoder for sensing the angle of the motor shaft
• Power electronics for regulating motor current
• A 32-bit DSP for communications and control

The Puck is very good at performing high-precision current control. Since the current flowing through a motor's windings is proportional to the torque that is applied to the motor shaft, the Pucks allow a user to apply any desired motor torque.

When paired with the WAM's unique cable transmissions, the Pucks make the robot inherently torque controlled. Traditional transmissions made with gears have either high friction or significant backlash; it is a fundamental design trade-off. Both friction and backlash interfere with the clean transmission of torques between a joint and its motor. The WAM has very low friction and no backlash; as a result, a motor torque is (to a good approximation) proportional to a joint torque. This property is often referred to as “backdrivability”.

All of the Pucks in a WAM (one on each motor) communicate with a Control PC over CANbus in order to receive torque commands and report motor angles. When running the WAM, customers typically use the PC/104 computer inside the base of the robot as the Control PC. However, if a more powerful computer is needed, it's also possible to use an external computer equipped with a CAN card.

Safety Architecture

Since the WAM is intended to interact with humans, safety has always been a key driver in the design. While the WAM is in operation, its behavior is continuously monitored by the Safety Module, a dedicated embedded system housed inside the base of the robot.

The Safety Module monitors:

• The velocity of the WAM's end point (Velocity fault)
• The velocity of the WAM's elbow (Velocity fault)
• The torques being commanded by the control program (Torque fault)
• The amount of power being drawn/generated by the system as a whole (Voltage fault)
• The health of the control program and Puck motor controllers (Heartbeat fault)
• The state of the E-stop buttons (Other fault)

If a fault condition is detected, the Safety Module will shut the robot down. The particular fault that occurred will be indicated by a red LED on the WAM's Control and Display Pendants. Specific information about the fault will be shown on the Pendants' 7-segment numeric displays.

The Safety Module has three states: Active, Idle, and E-stopped. When the WAM is Active, the illuminated green button on the Control Pendant labeled “Activate” will be lit. When the WAM is Idle, the illuminated yellow button on the Control Pendant labeled “Reset/Idle” will be lit. When the WAM is E-stopped, both the “Activate” and “Reset/Idle” button lights will be off.

In the Active state, the Pucks are allowed to push current through the motors, thus applying system torques. In both of the other states, the WAM is held in a “resistive braking” mode. This mode uses the motors to passively oppose all motion without completely locking the joints in place. The resistive braking mode is designed to promptly stop the robot without damaging the system and without trapping a person who may be pinned by the arm.

In the Idle state, the Pucks ignore all torque commands and instead perform the resistive breaking function. In the E-stopped state, all power to the Pucks is turned off and the resistive breaking mode is enforced by the Safety Module itself.

There are two different classes of safety faults. “Soft faults” (such as Torque faults and most Velocity faults) trigger a transition to the Idle state; this strategy is used when the fault is likely due to environmental conditions, controls problems, or certain kinds of bugs in the control program. “Hard faults” (such as Heartbeat faults) trigger a transition to the E-stopped state; this strategy is used when the integrity of the Pucks themselves is in question. A soft fault is less disruptive than a hard fault because the Pucks don't lose track of their corresponding motors' encoder position (their power is not disrupted). In contrast, the WAM must be re-homed following a hard fault.

Software Architecture

In addition to having a CAN card, it is necessary for the Control PC to use a real time operating system. A normal computer operating system does not make any guarantees about when a particular program will be allowed to execute. If the operating system decided, for example, to write a large chunk of data out to the hard disk, it could be 10s or 100s of milliseconds before the program controlling the WAM regained control of the processor. During that entire period, the Pucks would continue to apply the last commanded torque. A person interacting with the robot would feel the arm jerk slightly when the WAM program issued large correctional torques to compensate for the drift that had occurred during the uncontrolled time. Under certain conditions, the robot might even become unstable (though the Safety Module is designed to detect instability through velocity faults and torque faults). For proper operation of the WAM, it's very important for the Pucks to receive their torque commands on time.

Barrett uses the Xenomai real time co-kernel in conjunction with the Ubuntu Linux distribution to form a real time operating system. Essentially, Xenomai allows the programmer to create a thread of execution that has a higher priority than all of Linux. Xenomai is also very careful about how it handles CPU interrupt requests.

NOTE:
Xenomai integrates very closely with a computer's specific hardware. It is sensitive to implementation details that are irrelevant to normal operating systems. It is often the case that information about these details is not published by computer equipment manufacturers. The implementation may even change across different revisions of the “same” product! It is not always possible to use a given computer to run the WAM. Because of this, Barrett strongly recommends using either the WAM's internal PC/104 or a pre-configured computer supplied by Barrett.

Unfortunately, this real time functionality comes at a cost: there are many common operations that are not allowed in a real time thread. Forbidden operations include:

• Printing text to the screen
• Writing to a file
• Communicating over a socket (even in non-blocking mode)
• Using the malloc() function in C or C++
• Using the new operator in C++

The requested action will still be performed if one of these features is used in a real time thread, but the thread will automatically drop from “primary mode” into “secondary mode”. A Xenomai thread running in primary mode is a real time thread. A Xenomai thread running in secondary mode behaves like a normal Linux thread; it does not make a real time guarantee. It is important to structure a WAM control program such that the real time sections do not use these forbidden operations.

Almost all programs that run the WAM share the following structure:

1. Look on the CANbus to identify the configuration of the WAM and any other products that are present
2. Initialize the products
3. Start a real time control thread that does the following tasks once every 2 milliseconds:
   1. Ask the WAM Pucks to report their motor angles
   2. Use the measured motor angles to calculate joint angles
   3. Perform some calculations that result in a set of desired joint torques
   4. Use the desired joint torques to calculate motor torques
   5. Command the WAM Pucks to apply the desired motor torques
   6. Sleep for the remainder of the loop period
4. In the original (non-real time) thread, produce different WAM behaviors as desired by instructing the control thread to perform different joint torque calculations

Any number of joint torque calculations are possible, and any behavior that the WAM is capable of can be defined in terms of a joint torque calculation. This is true because, fundamentally, the WAM is only capable of sensing motor angles and applying motor torques.

The calculation can make use of any information available to the control program, such as joint angles, user input, or data received over the network. However, there is an important caveat to the previous statement: Since the calculation must be done in real time, the data that the calculation relies on must be available in real time. Programmers must be very careful to mediate the exchange of data between the control thread and other non-real time threads in a way that avoids making the control thread wait for data from a non-real time source.