ORCA: optimized robot for chemical analysis - includes related articles on ORCA's gravity-sensing joy-stick, absolute digital encoder and uses outside the laboratory - Technical - Cover Story

Gary B. Gordon

This analytical PC peripheral is a congenial assistant, a sophisticated robotic teaching environment, and an interesting study of robotic architecture. Although optimized for the analytical laboratory, it also has applications in electronic test, quality assurance, and the clinical laboratory, where heavy commercial assembly robots are unsuitable.

Analytical chemists currently spend approximately two thirds of their time preparing samples to be placed into instruments for analysis. This sample preparation is not only tedious, but also subject to errors introduced by human interaction and human variation. At the same time, an ever-increasing number of samples to be analyzed each year coupled with a declining pool of skilled chemists has resuited in a pressing need for automation to improve the productivity of the analytical laboratory.

Samples arrive in the laboratory in liquid, solid, and gas form. Quantities range from the microgram or microliter size to tank cars filled with tons of material. The instruments that are used to analyze these samples, such as gas and liquid chromatographs, usually require that the samples be cleaned up to remove almost all of the components of the material except for the chemical compounds of interest. Sample preparation involves many steps, including weighing, grinding, liquid pipetting and dispensing, concentration, separation, and chemical reaction or derivitization. In most . cases this work is done by hand, although instruments are available that perform particular preparation operations. To provide a system that performs a majority of the operations required for sample preparation requires a great deal of flexibility and versatility.

A robotic system seemed like the appropriate solution. But what type of robot? Robots designed for manufacturing and assembly are not well-suited for the analytical laboratory. The requirements for a laboratory robot go beyond the traditional characteristics associated with manufacturing systems. Since today's laboratory and instruments are designed for people, automation is difficult because not all the pieces of the laboratory are designed to work with robots. In contrast, assembly lines redesign the environment, process, and products to work easily with robots. It will be a long time before the chemical laboratory retrofits for automation.

Manufacturing robots in general are optimized for a different problem: very accurate positioning of often heavy payloads, in seldom reconfigured environments. These robots perform a small number of tasks very precisely in a small work volume. In contrast, an analytical robot is required to perform a wide range and number of tasks over an existing laboratory workbench and interact with existing laboratory containers and instruments. The same might be said of a robot for many other applications, such as electronic test, quality assurance, or clinical laboratory analysis (see "The HP ORCA System Outside the Analytical Laboratory" on page 9). To fit into existing laboratory environments, a robot must be installable without modification to the laboratory furniture. This will allow both rapid installation and easy relocation of the robot within the facility. The robot's work volume must allow the robot to reach the entire bench area and access existing analytical instruments. There must also be sufficient, area for a stockroom of supplies for unattended operation.

The laboratory robot can be involved in three types of tasks during an analytical experiment. The first is sample introduction. Samples arrive in a variety of containers. It is time-consuming and a potential source of error for the operator to transfer the sample from the original container to one that is acceptable for automation. The robot, however, can be trained to accept a number of different sample trays, racks, and containers, and introduce them into the system.

The second set of tasks for the robot is to transport the samples between individual dedicated automated stations for chemical preparation and instrumental analysis. Samples must be scheduled and moved between these stations as necessary to complete the analysis. The third set of tasks for a robot is where flexible automation provides new capability to the analytical laboratory. There will always be new chemical samples that require analysis steps that have never been automated. To prototype the automation of such steps, the robot must be programmed to emulate the human operator or work with various devices. This last use may require considerable dexterity for a robot. All of these types of operations are required for an effective laboratory robot.

Additional considerations for a laboratory robot are that it be the size of a human arm and have the dexterity needed for interaction with current chemical instrumentation. Interchangeable end effectors (robot fingers) are required to allow the robot to work with the wide range of existing containers and consumables used in sample preparation. The robot should provide a simple and clean work area with no external wires to catch on glassware or instruments.

After evaluating a number of existing robots for this application, it was finally concluded that a robot could be designed that was optimized for chemical sample preparation and other applications that have similar requirements, as mentioned above. The results of this analysis are the concept and design described in this article. The new HP analytical robot is called ORCA, which stands for Optimized Robot for Chemical Analysis. Fig. 1 shows it installed on a lab bench.

An anthropomorphic arm mounted on a rail was chosen as the optimum configuration for the analytical laboratory. The rail can be located at the front or back of a workbench, or placed in the middle of a table when access to both sides of the rail is required. Simple software commands permit moving the arm from one side of the rail to the other while maintaining the wrist position (to transfer open containers) or locking the wrist angle (to transfer objects in virtually any orientation). The rectilinear geometry, in contrast to the cylindrical geometry used by many robots, permits more accessories to be placed within the robot workspace and provides an excellent match to the laboratory bench. Movement of all joints is coordinated through software, which simplifies the use of the robot by representing the robot positions and movements in the more familiar Cartesian coordinate space.

The physical and performance specifications of the HP ORCA system are shown in Table I.

A robot alone does not satisfy the needs of laboratory automation. Besides the physical aspects of the robot, the system must be able to work with other devices, computers, and software. The other major development of the ORCA project was the control software, which is called Methods Development Software 2.0, or MDS. MDS runs on the HP Vectra and other PC-compatible computers under the Microsoft(R) Windows operating environment. It is designed to allow instruments to be added easily to the system. By the use of industry-standard communication interfaces, MDS can configure devices, and procedures can be developed to control and collect data from external devices. It is designed to be extensible; new modules can be added to the system at run time. MDS is also designed to be remotely controlled by other programs. This allows the laboratory robot system to be a server in a hierarchical automation system.

Most previous robots were programmed in coordinate space with computer-like languages. The HP ORCA system, on the other hand, is taught by first demonstrating to the robot a move, using another new development, the gravity-sensing teach pendant (see "Gravity-Sensing Joy Stick," page 12). The move is then given an intuitive name, for example get_testtube. Later, this or any other move can be called out by name and built into higher-level procedures. Simple to grasp yet powerful, this concept is easily expanded to control an entire benchtop of laboratory equipment. The user is freed to think about the greater task at hand rather than specific software details.

Having these components leads to our vision of the automated laboratory bench. For the first time, it is possible to provide automation for the analytical laboratory all the way from sample introduction to the final report without human intervention. The HP ORCA system provides the physical glue to tie together the individual chemical instruments as well as the information or data bus, so that the system can request, acquire, and distribute information to all components of the workbench.

ORCA System Overview

The HP ORCA system is shown pictorially in Fig. 2, which shows the major functional blocks. In the broadest sense, the input to the HP ORCA system is a high-level command, such as to analyze a drug (such as aspirin) for purity. Near the output end, the ORCA electronics deliver strings of millions of individual millisecond-by-millisecond commands to the six robot servos. To keep this transformation task from becoming overwhelming, it is broken down into manageable hierarchical levels.

Input to the system begins with a user interacting with the PC, which is running MDS. MDS provides experiment control through its own programming language. In conjunction with other applications on the PC, such as HP ChemStation software, MDS can also be used for chromatograph control. MDS consists of a core system, which is used to build and run reusable tasks called procedures, and one or more modules, such as the robot module.

The MDS robot module accepts MDS procedure commands for controlling the robot and parses the commands into endpoints for each of the segments of the robot moves. A typical robot move might be from a starting point taught to the robot and named OverBalance to an ending point named On Balance. These endpoints define straight-line segments. The output of the MDS robot module, and in fact the output of the PC, is a string of taught Cartesian waypoints representing the robot moves, sent every few seconds over an HP-lB link (IEEE 488, IEC 625) to the kinematics processor.

The kinematics processor consists of software runrang on a dedicated 68000 microcomputer. One of its tasks is coordination of the six axes of the robot to provide smooth motion and arrival at the Cartesian endpoints. This is accomplished in part by interpolation. The kinematics processor also handles tool offsets, so that, for example, a test tube can be rotated about its lip instead of its point of support. The final function of the kinematics processor is to compute the acceleration and deceleration profiles and the speed of each move so that motion is smooth and the axes' speed limits are not exceeded.

Physically, the kinematics processor shares a cabinet with the servo power supply. This cabinet has no controls and can be located out of the way under the bench. The output of the kinematics processor is coordinated position commands in joint space for motion along the path, sent over an RS-422 bus to the robot at a frame rate of 25 Hz.

The last functional block of the system is the joint interpolators, which are distributed throughout the robot. The 25-Hz commands from the kinematics processor are coarse enough that they would cause the robot to vibrate and growl, so instead they are linearly interpolated into 1.25-millisecond demand signals, which are sent to the digital servomechanisms.

Mechanical Design

Robot design benefits greatly from a careful optimization of lightness, stiffness, speed, and payload. Airplanes seem almost simpler in comparison, with some being able to carry 100% of their empty weight, compared to 10% to 20% for robots.

Playing off against the performance goals were economic considerations, so exotic materials such as titanium and carbon fiber were not seriously considered. Further, with the continuing shrinking of electronics, a decision was made to imbed much of it in the structure itself. This diminished the payload slightly, but greatly simplified the wiring and improved the reliability.

The ORCA industrial design achieves other less-tangible goals with little or no additional expense. It provides a smooth structure for easy cleaning, accessibility for maintenance, a compact design for dexterity in tight places, and an attempt to achieve pleasing lines.

ORCA, unlike any other commercial robot, is an anthropomorphic shell or exoskeleton, with its chambers tightly packed with six axes of servo control electronics. Fig. 3 shows an exploded view. The shells are of aluminum, chosen over plastics for thermal conductivity. They draw out what little heat is generated by the pulse-width-modulated servos, and spread it over the surface of the robot, where it is dissipated by convection. The shells are ribbed internally for torsional rigidity so that the robot is mechanically sound with the covers removed, allowing easy service.

ORCA is sealed roughly to the proportions of humans. The similarity continues with its "muscles"--its motors--which are physically displaced toward the torso; the elbow and wrist motors are situated at the shoulder. This reduces the static moment loads the robot must carry because of its own weight.

Particular effort went into refining the hand to cut weight and bulk to a minimum. One interesting feature is that the axes that pinch and rotate the fingers are coupled mechanically and in software. The fingers are mounted to parallel gear racks, which are opened and closed by spinning a pinion gear that engages them both. Without coupling, whenever the finger bar was rotated, it would wind the finger racks around the center pinion gear, open the fingers, and drop the object. The easy solution is to feed a proportional correction signal to the pinch servo any time the finger bar is commanded to rotate; software is cheaper than mechanisms. Fig. 4 shows the interior of the hand.

Because of the immense advantages of keeping the hand light and small, gear technology was pushed near its limits. Hardened ground gears and tight machining tolerances are employed to maintain the five-year minimum lifetime goal for all mechanisms.

ORCA is supplied mounted on an optical-bench-style table-top, which comes in several sizes. This surface forms a stable platform, and its grid of threaded holes provides convenient attachment points as well as reference locations for instruments and accessories. A linear rail assembly is fitted to either the rear, the front, or the centerline of the surface. The chassis contains the rail motor, which propels the torso by engaging a steel-cable-reinforced plastic chain stretched tightly alongside the rail. A simple flat cable similar to that used in printers also folds into the rail cavity and carries dc power and the serial ORCA bus, which affords bidirectional communications with the six robot joints.

The most interesting feature of the shoulder and elbow joints is their harmonic drive reduction units, shown in Fig. 5. These drives use a ring gear with internal teeth, which engages a flexible inner gear shell. The flexible inner gear has slightly fewer teeth than the outer rigid ring gear. For example, in the shoulder reducer, the ring gear has 102 teeth, while the flexible gear has 100 teeth. Lobes inside the inner flexible gear shell force it into an egg shape and into contact with the rigid outer ring gear. One rotation of the lobe assembly causes the two gears to displace relative to one another by two teeth, or 2% of one revolution of the flexible gear. Thus the reduction ratio of one stage is 50:1, or far larger than that obtainable with a single stage of pinion gears. Furthermore, since many teeth are engaged, the torque transmitted can be substantial. Because the engagement is compliant, harmonic drives exhibit little or no backlash. They are more expensive, but are common in robots and other high-performance applications because they perform better and reduce the total number of parts required.

Proceeding outward towards the hand, the moment increases, and saving weight becomes more and more important. Every gram saved becomes a gram of payload. Saving bulk is of equal importance. The hand, shown in Fig. 4, packs two servos for rotating the finger bar and changing the grip, all into a cozy 20 cubic inches. Since the drive train for the grip extends through the rotating finger bar, commands to these two servos must be coordinated; otherwise, rotating the finger bar would drastically change the grip on the object held, as explained previously.

The Kinematics Processor

The kinematics processor is one of the most interesting blocks of a robot, and gives an insight into how robots work. Its input is position data received from the PC over the HP-IB every few seconds, directing the robot to move in a coordinated manner from the last Cartesian position to the next. For example, a command string might direct the robot to move from coordinates over a test tube rack to coordinates over a balance a meter away. Altogether it looks like a complicated task, but when broken down into individual steps it is easy to grasp.

Robot Joint Space and Cartesian Space. One important simplification in understanding robots is to understand the difference between two different coordinate spaces: the Cartesian space in which the task is defined, and the robot joint coordinate space in which ORCA operates. It takes six coordinates to specify the position and orientation of an object in space. In our familiar Cartesian system, these coordinates are x, y, z, yaw, pitch, and roll. ORCA is fixed in yaw, so we restrict our interest to the other five degrees of freedom. A sixth degree is added, however, and that is pinch, to control the fingers. In friendlier terms, we will refer to these six degrees of freedom as rail (x), reach (y), height (z), bend, twist, and grip.

Robot joint space is defined as the joint positions of the robot that must be established to place an object in space with a specified position and orientation. ORCA has six movable joints, each controlled by a servo. Setting each of these correctly will position an object in Cartesian space. The six joints represent the six degrees of freedom in robot joint space. They are rail, shoulder, elbow, wrist, twist, and grip. Note that only rail, twist, and grip are the same in both coordinate systems.

Part of the reason for belaboring these differences in coordinate systems is that as the tasks of the robot are divided up, some are distinctly easier to perform in Cartesian space and others in robot joint space. In any case, the transformation must eventually be made to the joint space coordinate system to control the robot.

Controlling the Robot. The first step in robot control is to define the straight line along which the coordinated motion will occur. This is a matter of straightforward interpolation in Cartesian space. For example, when the robot is 40% of the way to its destination, the six individual coordinated degrees of freedom (x, y, z, bend, twist, grip) will each be 40% of the way to their final values. If the final twist of a pouring operation starting at 50 degrees is to be 100 degrees, for example, then at the 40% point, the instantaneous twist command will be 70 degrees.

The second step is to compute the velocity and acceleration profiles so that the robot will accelerate up to speed, traverse a distance, and decelerate and smoothly stop at the end of the move. Here the task is twofold. One is to allow the MDS software to control the speed of the move. The second is not to exceed the hardware performance limits of any robot axis. This situation arises because an articulated robot like ORCA is capable of much faster speeds in some directions and portions of the working space than in others. For example, if the arm is fully outstretched it can move vertically very rapidly, but if commanded to move inward towards the torso, its speed is limited for a moment as the elbow tries to accelerate vertically to infinite velocity. The HP ORCA system avoids such situations by limiting the velocity and acceleration to the lower of two numbers: the command from the PC or the limits of the joint servos.

The kinematics processor code is mathematically intensive and requires a fairly powerful 16-bit microprocessor. The processor has quite a number of tasks to perform in addition to computing waypoints along the straight-line trajectory between the robot's initial and final positions. It takes the processor 40 milliseconds per waypoint to complete all of its computations and tasks. Thus the determination of where the robot shotfid be is not continuous at this point but periodic, and the period is relatively long. However, this is just an intermediate step in the control process. The information is still in the wrong coordinate system and is far too coarse for smooth motion control of the robot.

Immediately after computing each coarse Cartesian waypoint (every 40 ms), the kinematics processor converts the point into robot joint space coordinates. The x coordinate is easy to transform since it is the same in both spaces; the robot merely moves a certain number of millimeters down the rail to the new x coordinate. The same is true with grip commands to the gripper. They (in and out) and z (height) coordinates are slightly more complicated to transform, and use trigonometry to compute the shotrider and elbow joint angles in robot space. The wrist joint is not a factor if it is kept horizontal; its angle bears a simple relation to the shoulder and elbow joints.

In addition to transforming the waypoints from Cartesian space to robot joint space, the kinematics processor also applies the tool offset parameters, if there are any, so that a test tube can be rotated about its lip instead of its point of support, for example. The kinematics processor outputs a joint-space vector every 40 ms and sends it to the six joint servos for further processing.

Joint Servos. Two wires of the four-conductor ORCA bus that snakes through the robot carry the serial RS-485 joint commands to the joint servos, which are embedded in the robot shell. The other two conductors carry unregulated 32V power. The data structure sent over the ORCA bus is shown in Fig. 6. Each pair of joints is serviced by a microprocessor which strips off its command from the bus at 40-ms intervals. After each joint's two-byte position command is sent, an idle space is provided for the joint to send back its position and status.

The fourth step in the robot control process takes place in the joint microprocessors, which further interpolate the 40-ms interval down to 1.25-ms position demands for the joint servo. What is the purpose of all this interpolating? If the 40-ms points were sent directly to the servos, the robot motion would be jerky. Yet it is uneconomical to generate them faster than 40 per second; that would take an unnecessarily fast kinematics processor and would take up too much bus communication time. There is an easier way to get the fine increments to send to the joint servos to ensure smooth motion. This interpolation step is the task of the joint microcomputers, which divide the motion down into 1.25-ms intervals. This interpolation produces smooth, nonjerky robot motion by keeping the step noise at a frequency well beyond the passband of the robot servos.

This is a particularly easy interpolation to accomplish, since the number of steps chosen, 32, is a power of two. Interpolation then consists of subtracting successive positions, dividing the difference by 32 (a right-shift of a binary number by 5 bits), and successively adding that quotient into an accumulator initialized to the starting servo demand position.

A consequence of this design expedient is that the robot actually moves in slight scallops, 40 ms long, since a straight line in robot joint space is curved in Cartesian space. However, these deviations are on the order of thousandths of an inch and are insignificant.

The remaining task performed by the joint microprocessors is to close the digital servos at each joint. These servos use incremental encoders, dc motors, and pulse-width-modulated amplifiers--technology borrowed from HP plotters. 1 Briefly, each joint demand position is first subtracted from the actual position of that joint to generate a position error value. The servo motor is then commanded to move at a velocity proportional to that position error, with the velocity and position of the joint servo motor being derived from the incremental encoder. Since each joint position is fed back to the PC, the control software knows if the robot has bumped into anything, and can also employ integral control to correct small errors such as sag of the arm caused by the influence of gravity.

A new HP technology introduced in the HP ORCA system is digital absolute position encoding (see "Absolute Digital Encoder," page 14) at each of the major joints. Its purpose is to allow the mechanism to ascertain its position when first powered up.

Application Development Environment

Although clearly the most conspicuous element, the robot is but a piece of a total automation system that also involves controlling and collecting data from analytical instruments and common laboratory devices, such as pH meters and balances. The HP Methods Development Software (MDS), written to address this need, provides a development environment for creating automation systems with laboratory robotics. MDS runs under Microsoft Windows on an HP Vectra or other PC-compatible computer. This choice was based on users' preferences for a PC-based system, compatibility with HP ChemStations, and the features that Microsoft Windows provides for a multitasking graphical user interface.

The targeted customer for MDS is a laboratory robotics application developer, typically an analytical chemist with instrumentation and BASIC programming experience. These developers create applications that a technician runs and monitors. Robotics programming has to be presented in a conceptually simple format that makes it easy for the chemist to create tasks, which can then be combined to form an application.

Again, the differences between the use of a robot in the laboratory and the manufacturing environment were considered. Whereas a manufacturing robot is typically programmed to repeat a small set of tasks in a world that can often be defined with information from CAD drawings, a laboratory robot is used to perform a wide variety of tasks in a world where very little predefined knowledge is available. The laboratory robot must be taught how to interact with test tubes, vials, racks, balances, and other instruments.

Teaching a robot all of the individual positions and trajectories it must follow for every step in a laboratory application would be very time-consuming and tedious. The teaching process can be greatly simplified by providing a mechanism for teaching small manipulations instead of individual positions. These small manipulations can be used (and, most important, reused) as building blocks. This idea led to the concept of a robot motion. A motion in its simplest form is a sequence of robot positions. The motion is taught interactively using a special motion editor and the robot teach pendant. The motion is given a descriptive name, which is used in a program to have the robot execute, or move through, the sequence of positions. In MDS, the program is called a procedure. Procedures are used as building blocks to connect robot actions with control of other devices and instruments into higher-level tasks. Procedures can call other procedures, much like a subroutine call in BASIC.

The concept of a motion was generalized to be an abstract execution object, which led us to consider other types of objects that could be provided to simplify robotics programming. These types include:

* Tool. Defines the endpoint of the robot arm.

* Frame. Defines a frame of reference for a motion.

* Motion. A sequence of robot positions.

* Rack. A rectilinear array of positions (similar to a pallet).

* Syrconfig. A configuration for a syringe pump dispenser.

* Procedure. The basic programming unit.

* Device. A configuration for an RS-232 or HP-IB device.

The metaphor used to create and store these objects is that of entries in a dictionary. Motions, racks, tools, frames, syrconfigs, devices, and procedures are all types of entries that can be created. An entry is an execution object, and a dictionary is a file that holds the entry objects. Users create and name entries, and save them in a dictionary. Each entry type has its own special editor, or form, for defining or teaching the entry. Entries can be used as commands (motions and racks), or as modifiers of entry commands (tools and frames).

For example, the following procedure statement will execute a motion PickUpDispenserNozzle using a tool offset defined by the tool NozzleGripper and referenced to a frame NozzleStand:

PickUpDispenserNozzle WITH NozzleGripper AT NozzleStand

The frame and tool that a motion uses can also be attached to the motion from within the motion editor, and may provide defaults for the motion to use when it is executed. The use of long (31-character) names and the command modifiers

WITH and AT provide a very natural-language-like look to procedure statements for robot control and help the procedure code to be self-documenting. The use of longer names is simplified and encouraged by providing a variety of selection, copy, and paste features in the user interface, which reduces typing and programming errors that arise from typing mistakes.

MDS allows two dictionaries for editing and execution of entries: a user dictionary and a master dictionary. When an entry is referenced in a procedure statement, the user dictionary is searched first, and allows redefining entries that are in the master dictionary. Although developers are free to choose their own guidelines, the master dictionary is recommended for saving entries that are to be used across multiple applications and the user dictionary is generally application-specific.

The user interface for selecting entries to edit and for general browsing of the dictionaries is the MDS dictionary manager window (see Fig. 7). This window is the main user interface to MDS, and provides access to administration utilities, dictionary and entry manipulation, and selection of various views for the entry listings. Double clicking on an entry name presents an entry information dialog box, which in turn allows access to editing, execution, or printing of the entry. Keystroke accelerators are provided for quick access to common functions, such as editing and execution.

The dictionary manager also provides a command line, with history, for execution of commands. MDS supports the concept of a live command line, from which a user can execute anything at any time. The new execution preempts current execution. This feature is used most often to access or change the value of a variable quickly, and to execute procedures to correct problems when the application is paused. Variables that are defined exist until they are explicitly removed. These features give MDS an interactive feel, and allow the creation and testing of an application in terms of small units.

The other main user interface window is the MDS monitor (see Fig. 7), which shows display output from procedure statements and provides execution control and debugging facilities. Debugging facilities include execution stepping, tracing, and logging display output and errors to log files. A variable-watch window, which can be used to monitor the values of variables as they change, is also provided via the MDS monitor menu.

The procedure editor is the other most commonly used element for developing an application. Each procedure is edited within its own window. Multiple edit sessions are possible, and text can be copied and pasted between them. The procedure editor also allows execution of the entire procedure or any highlighted text. This feature allows quick and simple testing of statements and procedures. The procedure editor also provides direct access to other types of entry editors, including other procedures. For example, the user need only double click with the mouse to highlight the name of a procedure, or other entry, and press Ctrl+E to access the editor for that entry. The procedure editor's features encourage the use of small procedures that can be easily tested to become building blocks for higher-level procedures and enhance the interactive feel of MDS.

MDS Architecture

In addition to supporting the features described in the previous section, MDS is designed for extensibility. Because of the wide-ranging nature of laboratory robotics, and because it is a developing field, the types of instruments and objects with which the robot must interface cannot be predefined in the software. Thus the software has to be both configurable and piecewise upgradable. The software also has to support multitasking of execution and simultaneous editing and programming during execution. These requirements suggest a modular design, with several programs that interact with a defined protocol. Fig. 8 shows the MDS architecture.

The design of MDS is based on a core system that can be enhanced by the addition of software modules. It is implemented as several Windows programs that communicate with a set of MDS messages, and a set of Windows dynamic link libraries that provide the basic "glue" for the architecture. In Windows, the use of dynamic link libraries allows sharing of common code and sharing of data between programs. MDS takes advantage of dynamic link libraries for both of these purposes. Since Windows itself is implemented as several dynamic link libraries, the various programs that make up MDS do not have to include code for the windowing interface. Run-time memory requirements are also minimized by taking advantage of Windows memory management facilities that allow code segments and data to be marked as load-on-call and discardable.

An important design rule for MDS was that no data structure definitions could be shared between the programs and dynamic link libraries that make up MDS. This rule allows MDS to be truly modularized so that parts of MDS can be modified without affecting or requiring changes to other parts. A direct benefit was that it enabled the core system to be developed in Palo Alto while the robot and dispenser modules were developed at the Avondale site, 3000 miles away.

Instead of data structures being shared, a set of data objects were defined and supported with calls to access their properties. These data objects are supported within dynamic link libraries, which provide the function call access, and which "own" the data and allow it to be shared. For example, the MDSDICT dynamic link library supports the dictionary and entry objects, the MDSCFG dynamic link library supports the configuration and module objects, and the MDSCPLIB dynamic link library supports objects used for execution. The use of the dynamic link library's local heap for allocating the objects compensates for the performance penalty of the overhead of the calls to access the object data. Handles to the objects are passed among the MDS programs using MDS messages, which specify an action to take with the object.

Certain objects and their corresponding calls and messages are considered "core-only" property. Modules can only access information in these objects using an intermediary object that can be properly shared with modules. For example, the entry and dictionary objects are core-only, so an entry edit block object is used to create and edit an entry object and is accessible by modules. Even in this case, though, not all of the object's properties--its corresponding entry and dictionary for example--are accessible by modules. These properties can only be set by a part of the core (the module manager or browser in this case).

MDS modules extend the functionality of MDS by providing support for new entry types and commands. Currently, there are three modules available: the MDS system module, the ORCA robot module, and a dispenser module that supports the HP 1243A syringe pump dispenser. The system module is different from the other modules in that it is an integral part of the MDS core, while the other modules can be optionally configured to run as part of MDS. Modules are responsible for the control of their respective hardware and entry editors, and for execution of the commands and functions that they register with MDS. Although the current modules all support hardware, modules can be written simply to add commands or other functionality to MDS, such as interfacing with another software package.

MDS Core. The MDS core system consists of the module manager MDS.EXE, the browser MDSUSER.EXE, and the executive MDSEXEC.EXE (see Fig. 8). The executive in turn supports the MDS command processor MDSCP. EXE as a separate program that it manages. Three dynamic link libraries, MDSCFG.DLL, MDSDICT. DLL, and MDSCPLIB.DLL, complete the MDS core.

The module manager is the main MDS program. Its window appears only momentarily to show booting information, and is then hidden. The module manager acts as the main gateway for all MDS messages. It is responsible for maintaining the configuration of MDS modules (via MDSCFG.DLL) and dictionaries and entries (via MDSDICT. DLL). When MDS boots, the module manager reads configuration information from the MDS.INI file, and executes the module programs that are to be activated. Modules dynamically register their entry type and keyword information with the module manager at boot time. The module manager also supports dialogs for modifying the configuration, and for creating and saving entries.

The browser is the main user interface for MDS. Its window title is MDS Dictionary Manager, because that is how it appears to function to the user. Internally, however, it is not the dictionary manager; it serves only as the user interface to the module manager, which is responsible for maintaining dictionaries. This distinction between how a user views MDS and how MDS is implemented internally was important for maintaining a consistent internal design. The browser window provides the command line and a listing of entries defined in the selected dictionaries. The browser also supports the server portion of Windows dynamic data exchange (DDE) for MDS.

The executive provides the other window into MDS, the MDS Monitor window, which displays output from procedure PRINT statements. The executive also manages the MDS command processor and provides the user interface for execution control and debugging facilities.

The MDS command processor is responsible for procedure and text execution. All execution begins as text execution (from the command line, a procedure editor, or remote DDE execution), which is parsed and executed the same as a procedure. The syntax for the MDS procedure language is based on the HP ChemStation macro language (which is BASIC-like) with a number of enhancements.

Among the enhancements are support for the MDS entry concept and a PARALLEL command. The PARALLEL command allows procedures to be executed in parallel, sharing the same global symbol table and dictionaries. A set of commands for synchronization of parallel execution is also provided. This multitasking feature is used to increase the overall throughput of an application. For example, a procedure that tares a balance can be done in parallel with another procedure that uses the robot to get a beaker for weighing. When a PARALLEL command is executed, a new instance of the MDS command processor is run. Because Windows shares code segments for multiple instances of the same program, the command executes quickly, and the demands on memory are limited to the additional data segment for the new instance.

The MDS command processor parses and executes each line of a procedure at run time. An execution block object is used to pass execution information between the command processor and the modules during execution. Parameters to module commands are preevaluated for the module and passed on a shared stack object, whose handle is part of the execution block object.

An important part of automation is the ability to detect and recover from error conditions. MDS supports the ON ERROR statement, which specifies an error handling procedure to call. Through the use of a RESUME statement, the error handler can propagate the error back (RESUME EXIT), fix and retry the statement (RESUME R ETRY), skip the statement (RESUME NEXT), or have the user decide (RESUME ALERT). The automatic error handling can be disabled, so that an error dialog box is always presented to allow the user to decide what action to take. The user can execute new procedures to fix the problem and return the application to a continuable state. This feature is particularly helpful during development of the application, and reduces the need to abort and restart an application when something goes wrong.

MDS System Module. The MDS system module provides support for procedures and devices. It is a "core-smart" module in that it uses certain calls and messages that are considered core-only. For this reason, it is usually thought of as part of the core system. Also, it is not a true module, in that it only provides for the creation and editing of procedures and devices. Procedure execution is handled by the MDS command processor, which is maintained by the MDS executive. Device entries are used in procedures, so their execution is also handled by the MDS command processor.

Dispenser Module. Liquid handling is important in many laboratory robotics applications. Solutions must be prepared, filtered, and extracted. The use of liquid dispensing in combination with a robot and a balance allows the gravimetric preparation of solutions, eliminating errors that often occur with the more traditional volumetric methods.

The dispenser module supports the syrconfig entry type, and control of the HP GI243A syringe pump dispenser. A syrconfig specifies which syringe to use, the syringe size, and the dispense speeds. An AutoFill feature allows the user to set levels at which a syringe will automatically refill. When enabled, this feature eliminates the need for the application to keep track of syringe levels, thus reducing procedure coding. The dispenser module also registers a set of commands that are used with the syrconfig entry to dispense and fill liquids. The dispenser module is implemented as a single program.

For example, the following statement will dispense 10 ml of liquid using the syringe specified within the syrconfig Buffer:

DISPENSE 10 ML Buffer

With AutoFill enabled within the Buffer syrconfig entry, the syringe will fill and empty until 10 ml are dispensed, using the volume setting in the entry as a guide. During the fill and empty cycles, a valve is automatically switched so that filling is done from a reservoir and emptying is done out through a nozzle.

Robot Module. The robot module supports the HP G1203A ORCA robot. The robot module provides the tool, frame, motion, and rack entry types, and a set of commands and functions for explicit control of the robot arm. The main robot window presents current robot position and status information, and provides access to calibration and entry edits (see Fig. 9). Multiple editors can be opened at any time, and positions can be copied and pasted.

All of the robot entry editors except for the tool editor are used interactively with the robot and its teach pendant. The user can also manually enter position information. For example, the motion editor presents a form for recording a sequence of positions. Pressing the remote teach pendant Enter key automatically records the current robot location as the next position in the motion. The motion editor allows setting force (grip) and torque (twist), as well as speed for individual steps in the motion. These parameters, along with a reference frame and tool offset, are called motion attributes. Another attribute, Don't Change, can be applied to individual axis values, and indicates that the axis value does not change for that position, no matter what value might have been taught. Once taught, positions in a motion can be rearranged or copied between motions. A motion that is used to pick up an object can easily be reversed and saved as a motion that replaces the object.

A rack is defined by teaching two comer locations and an access location, and by entering the number of rows and columns for the rack in the rack editor. Once defined, the desired rack location, or index, is specified as a parameter to the rack name in the command to move the robot to that rack access location. By teaching a rack with respect to a three-point frame, the rack can be accessed in virtually any orientation, with the robot bend and twist axes changing to reflect the new access angle. A hand-reference mode of teaching, by which the bend is locked at an angle perpendicular (or parallel) to the rack surface, greatly simplifies teaching access to tilted racks and centrifuges.

The robot coordinate system is presented as a Cartesian system with additional bend, twist, and grip axes. The robot module provides the frame and tool offset transformations for motion and rack positions. The conversion to joint values and the straight-line trajectories are all computed in the robot kinematics processor. When executing a motion, for example, the robot module applies the frame and tool offsets to each position in the motions, converting these values into absolute positions to send to the robot kinematics processor.

Use of Other Laboratory Equipment

A critical requirement for the MDS software is that it be able to support common laboratory devices through standard interfaces. MDS supports control of HP-IB (IEEE 488) and RS-232 (COM) interfaces using the device entry type and procedures written to use the devices. The device entry type provides a simple form for assigning the address, COM port parameters, and buffer sizes. The MDS procedure language supports using the device entry name in place of a file name in the BASIC-like OPEN statement. This allows the BASIC examples included with most manufacturers' instruments to be easily incorporated into MDS.

Dynamic Data Exchange (DDE). Early in the project we envisioned MDS as being the master controller of the robotics bench. As the project progressed, it rapidly became evident that MDS must also be capable of being controlled by other applications and must be able to exchange data with other applications. High on the list of other applications were the HP family of ChemStation products and software provided by other manufacturers for instruments that HP does not provide.

Windows dynamic data exchange (DDE) was chosen as the mechanism for the control and exchange of data. DDE allows Windows applications to control and pass data using a client/server model. MDS supports DDE in both client and server modes. The DDE client support is handled by a set of commands that allow developers to add DDE to their application at a very high level. MDS handles all of the low-level details of the protocol. The DDE server support is handled by the MDS browser and command processor, and allows remote execution of any block of text that follows MDS command syntax. All MDS variables are accessible via DDE, both for setting and requesting values. In addition, MDS variables can be put on advise, or "hot-linked," which means that the client application is notified whenever the variable's value is changed.

By supporting DDE, MDS is able to interact with a wide variety of software that runs under Windows. Features that MDS lacks, such as database management and report processing, can be provided using software designed for that purpose, using DDE as the connection with MDS. Another example is the use of HP ChemStation software with MDS. Using DDE,

MDS is able to instruct the ChemStation to load and run methods for samples that the robot has prepared and placed in the chromatograph's injector. The use of DDE to integrate MDS with other Windows applications provides a new level of systems automation for the analytical laboratory.

Conclusion

The HP ORCA hardware and software provide a robotics system that is easily adapted to the needs and requirements of the analytical laboratory. The use of a gravity-sensing teach pendant, in conjunction with a graphical user interface, provides an intuitive and simple means for programming the robot. Supporting both client and server dynamic data exchange, the HP ORCA system can be fully integrated into the information flow as well as the sample flow of the analytical laboratory. Applications outside the analytical laboratory are also easily found (see "The HP ORCA System Outside the Analytical Laboratory," page 9).

Acknowledgments

The ORCA project involved an extraordinary amount of cooperation between groups at HP Laboratories and the automated chemical systems program at the HP Avondale Division (now at HP's Little Falls operation in Wilmington, Delaware), along with valuable input and support from HP Analytical Products Group management and the field engineering force. The authors enthusiastically acknowledge the numerous outstanding contributions made along the way by many individuals as the HP ORCA system emerged from a feasibility study and grew into a product. The HP Labs contributors included John Michnowicz (department manager), Miles Spellman (kinematics software), Jim Young (torso and product design), Stu Lerner (arm and finger mechanics), Carl Myerholtz (bus and joint servos), Andrew Stefanski (joint refinement and kinematics), Hans Neumann (arm and hand mechanisms), and Bob Widmayer (digital servos). Many valuable discussions were had with individuals who had worked on HP plotter technology. 1 The Avondale R&D team, led by Greg Murphy, included Eric Park (mechanical design), Gil Siegal (kinematics software), Phil Fuhrman (servo electronics), Dave Clouser (robot module), and Jeff Griffith (dispenser module). The manufacturing engineering team included Andrea Mon-is (hand), Dan Liszewski, and Bill Boyd. Marketing people who were key in shaping the HP ORCA system's feature set are Mark Shuman, Bill Berry, John Rollheiser, and John Poole. Lastly, special thanks to upper management for their support of the ORCA project.

                        Table I
           ORCA Robot Arm Hardware Specifications
Arm                     Articulated, rail-mounted
Degrees of freedom      Six
Reach                   [+ or -]54 cm
Height                  78 cm
Rail                    1 and 2 m
Weight                  8.0 kg
Precision               [+ or -]0.25 mm
Finger travel           40 mm
Gripper rotation        [+ or -]77 revolutions
Teach pendant           Joy stick with emergency stop
Cycle time              4 s (move 1 inch up, 12 inches
                        across, 1 inch down, and back)
Maximum speed           75 cm/s
Dwell time              50 ms typical (for moves within a
                        motion)
Payload                 0.5 kg continuous, 2.5 kg transient
                        (with restrictions)
Vertical deflection     <1.5 mm at continuous payload
Cross-sectional         1 [m.sup.2]
work envelope
Power requirements      100V, 120V, 220V, or 240V (+5%,
                        -10%), 350 VA, 47.5 to 66 Hz
Operating               5 degress C to 38 degrees C at 0
                          to 90% RH
environment             (noncondensing)

Reference

1. W.D. Baron, et 3.1, "Development of a High-Performance, Low-Mass, Low-Inertia Plotting Technology," Hewlett-Packard Journal, Vol. 32, no. 10, October 1981, pp. 3-9.

The HP ORCA System Outside the Analytical Laboratory

There are many applications in industry whore the precision of a manufacturing robot is not required. Often, in fact, such robots are genuine misfits. They are costly, bulky, heavy, and too complex to program for these simpler jobs. The HP ORCA system, on the other hand, is much better suited for these lighter tasks. lt weighs 1/10 as much as its industrial relatives, yet is just as reliable, and it is far easier to use because it behaves like an appliance or a PC peripheral. The robot can be connected to a PC, shown a task to do, and put to work without much fuss.

There are numerous small applications in manufacturing where one might not normally think of using robots. They include many of the repetitive tasks people now perform in assembly, test, and quality assurance.

At HP, two areas being looked at are instrument front-panel circuit board test and instrument final test. Front-panel controls are not yep/accessible electronically, and typically require human intervention to verify the operation of knobs, switches, and displays. These panels are quite amenable to robotic automation, Robotic fingers can manipulate controls, and carried sensors can monitor displays. Such robots fulfill a niche in medium-scale assembly, where the number of products to test is too many to do by hand, yet not enough to justify designing, building, and keeping track of hard-tooled test fixtures.

Other manufacturing uses lie in assembly tasks for which the HP ORCA system's 0.25-mm precision is sufficient. This rules out board loading and fastener inserting. On the other hand, as an assembly operation is studied, it often becomes apparent that there are many tasks in which dramatic savings and quality improvement can be had through robotics. Two examples are pick-and-place assembly and adhesives application.

The ORCA group at HP was encouraged when other HP groups came to us and wanted robots to try out. Four early users were in two areas: gas chromatograph manufacturing at HP's Little Falls site in Wilmington, Delaware, and column manufacturing at the Scientific Instruments Division in Palo Alto, California. The following stop/relates how the ORCA/NC lathe project came about at Little Falls.

The ORCA/NC Lathe Project

The ORCA/NC lathe project, conceived in a typical HP aisleway conversation, was initiated to address both current business needs and visions for the future. A shop supervisor at HP's Avondale, Pennsylvania Division, where many HP ORCA system components were fabricated and assembled, was able to bait an R&D manager with the dream of a robot building itself. The manager promptly found a prototype unit to donate to the shop, and an investigation of potential applications began. Five months later, the latest-model HP ORCA system was operating an unattended NC lathe.

Potential shop applications for a small flexible robot included the transfer of parts between hydraulic presses in a sequence of staking operations, the loading of components on a pneumatic manifold, and the loading and unloading of parts on a machine tool, such as a lathe or mill. The application of the lathe loader was chosen because it was the simplest in concept. It contributed to profitability by using outdated equipment (a ten-year-old lathe)and by reducing the shop cost driver rate, an important metric determined in part by the total of unattended machining hours.

The experience gained in the lathe loader project was expected to provide a knowledge base for future projects. It would help in establishing guidelines, planning resources, and scheduling more complex applications. Also, an understanding of the HP ORCA system's capabilities with respect to the fabrication business was needed. The experience objective was made explicit because other lathe autoloaders exist that are more accurate and simpler in design than the HP ORCA system.

The project team consisted of a fabrication process engineer, a tooling designer, and a journeyman machinist. The first challenge was positioning ORCA on the lathe. We wanted to access the full width of the lathe so we chose to bolt ORCA's rail onto the machine bed and operate the robot completely within the lathe shields. Although the ORCA rail ends are outside the shields, this decision meant that the robot would be operating in an environment with coolant and metal chips. Since the lathe is still used 80% of the time for bar-fed jobs, the robot is protected when not in use by being parked behind the turret under a plastic bag. ORCA loaded jobs are run without coolant and the robot is isolated from chips by a telescoping cover that extends over the rail cover.

The ORCA/NC lathe system includes an ORCA robot, a Hardinge HNC lathe, an HP Vectra QS/20 PC, and an optointerface board. The custom hardware consists of four part staging magazines, special grippers for the robot, a V-block, and a secondary/rail cover. The vertical magazines are mounted across the lathe bed behind the lathe turret and hold 75 parts each, The grippers are oriented such that the axis of the gripped part is perpendicular to ORCA's twist axis. The V-block is selfcentering and spring-loaded, and is mounted on the lathe turret. The secondary telescoping rail cover is attached to ORCA's torso casting.

In one cycle of the ORCA/NC process, running 50 seconds, the robot removes a part from the magazine, then pushes the part into the V-block and moves to a safe position. The lathe turret moves so that the V-block stuffs the part into the collet. The collet closes, the part is machined, the spindle stops, and the collet opens. ORCA removes the part and drops it down a slide leading to a box of completed parts.

The HP ORCA system and the specialized tooling were set up in a lab for development and moved onto the lathe two weeks before startup. In the lab, parts of the overall concept were simultaneously prototyped, then tested together. For example, the custom gripper fingers were revised five times, The purpose of two of the revisions was to increase the maximum gripping force transmitted to the part. ORCA's grip had to exceed the holding force of the magazine and V-block by enough force to pick and place parts reliably.

Critical requirements for success were robustness over time and the ability to run for one shift without operator intervention. Robustness is defined as the ability to run day after day without a crash or robot recalibration or repair. The application ran in the lab for thousands of cycles.

Overall system control is vested in an ORCA MDS program that calls robot subroutines and starts, pauses, and stops the lathe program via the interface board. To start the application cycle, the lathe program is loaded and started, and then the MDS program is started. The robot positions within the move subroutine programs were rough-taught with ORCA's joy-stick teach pendant and refined by keyboard input. Accuracy and repeatability of the movements were further enhanced by unidirectional programming.

The ORCA/NC system is currently used to machine two brass and aluminum valve stems. Only one part was used in the system's development. The other part was implemented by the machinist two months after release of the application. In six months of operation, about 16 hours per week, there have been no problems. This is partially because of the robustness of the system and very much because of the ease of use of the system software.

The ORCA/NC lathe project met every initial objective, is a good example of teamwork, and has become a shop showpiece. The machine shops at Avondale were bought by two former managers in November of 1992, when HP moved to Little Falls, The HP ORCA system continues to run 16 hours per week at the new company, American Manufacturing Technology.

Nancy Adams

Manufacturing Process Engineer

Little Falls Operation

COPYRIGHT 1993 Hewlett Packard Company
COPYRIGHT 2004 Gale Group