---
title: "An Overview Of AL, A Programming System For Automation"
authors:
  - "Raphael A. Finkel"
doi: ""
url: "https://ijcai.org/proceedings/1975/120"
pdf: "https://ijcai.org/proceedings/1975/0120.pdf"
venue: "Proceedings of the Fourth International Joint Conference on Artificial Intelligence"
year: 1975
pages: "758-764"
track: "Robots And Productivity Technology"
keywords:
---

# An Overview Of AL, A Programming System For Automation

Raphael A. Finkel

*Proceedings of the Fourth International Joint Conference on Artificial Intelligence*, pages 758-764.

## Abstract

AL is an high-level programming system for specification of manipulatory tasks such as assembly of an object from parts. AL includes an ALGOL-like source language, a translator for converting programs into runnable code, and a runtime system for controlling manipulators and other devices. The system includes advanced features for describing the motions of manipulators, for using sensory information, and for describing assembly algorithms in terms of common domain-specific primitives. This paper describes the design of AL, which is currently being implemented as a successor to the Stanford WAVE system.

## Full text

## AN OVERVIEW OF AL, A PROGRAMMING SYSTEM FOR AUTOMATION

## Raphael Finkel, Russell Taylor, Robert Bolles, Rlohard Paul*, Jerome Feldman· . Stanford Artiflolal Intellleenoe Laboratory Stanford, California USA

June 3, 1975

![Image](https://ijcai.org/proceedings/1975/fulltext/120/image_000000_0af149199edddee74c1c2445db07f6e04a29b0a795b1fa6cd467059e3f6cd492.png)

This research was supported In part by the National Science Foundation under contract No. Gl-42906 and in part by the Advanced Research Projects Agency of the Office of Defense under Contract .No. DAHC-15-73-C-0435. The views and conclusions in this document are those of the authors and should not be interpreted as necessarily representinc the official policies, either expressed or implied, of the fundinc agencies.

## ABSTRACT

AL is an high-level programming system for specification of manipulatory tasks such as assembly of an object from parts. AL includes an ALGOL-like source language, a translator for converting programs into runnable code, and a runtime system for controlling manipulators and other devices. The system includes advanced features for describing the motions of manipulators, for using sensory information, and for describing assembly algorithms in terms of common domain-specific primitives. This paper describes the design of AL, which is currently being implemented as a successor to the Stanford WAVE system.

## AN OVERVIEW OF AL

This short paper cannot cover the subject of AL in depth; a complete discussion may be found in AL , A Programming System for Automation, Stanford Artificial Intelligence Laboratory Memo AIM-243, Stanford University Computer Science Department Report STAN­ CS-74-456, by the authors of this paper.

## INTRODUCTION

The development of robot manipulators such as the "Unimate" has led to the belief that these tools are in some way general-purpose devices and that they might be programmed like a computer. As a general­ purpose programmable device, the robot manipulator provides a possible answer to the need for automation of assembly in batch manufacturing industries where small production runs rule out the use of special­ purpose equipment.

We are implementing a system called AL for small scale batch manufacturing where setup time is the key factor. We rely on a symbolic database and previously­ defined assembly primitives to minimize programming time. The system is capable of high-level planning and intelligent interpretation of user-defined primitives. The principal aim of this work is not .to provide a factory floor programming system but rather to design a language which will be a tool for investigating the difficulty, necessary programming time, and feasibility of writing programs to control assembly operations.

## PHILOSOPHY OF DESIGN

## DATA AND CONTROL STRUCTURES

The principal mode of input to AL is textual, as opposed to spoken or manual (joystick). There are levels of complexity which are much more readily transmitted from man to machine through an interiace oi symbolic text. For example, simultaneous motions of two arms and termination and error conditions are more likely to be unambiguously described through the medium of text because a textual language can provide a consistent framework for such intuitive ideas. Non­ textual forms of input for defining target locations and suggesting arm trajectories to avoid collisions are most useful when applied in conjunction with a program text which supplies the overall intent of the programmer. The supervisor level of AL is simple enough to allow natural teaching by showing; it should be easy to interface such devices as joysticks and vocal input into AL, although we do not intend to do so at present.

Experience with languages like SAIL and WAVE has shown that text macros are a· useful feature; they reduce the amount of repetitive typing. AL has a general-purpose text macro system interfaced into the scanner and parser.

The datatypes available include those types necessary to refer to one-dimensional measures (like distance, time, mass) and three-dimensional measures (like directed distance, locations, orientations). Arithmetic operators are available not only for the standard scalar operations like multiplication and addition, but also for such operations . as rotation and translation.

Provision is made for simultaneous execution of several processes. This allows calculation and arm motion to take place simultaneously; several manipulators can be in independent or coordinated motion.

## MOTION SPECIFICATIONS

Experience with WAVE has shown that calculating trajectories for manipulators is desirable but time­ consuming. Trajectory calculations, together with other calculations which need only be performed once, are done at compile time. This allocation of effort drastically reduces the computing load at execution time and . eliminates wasteful recomputation every time a sequence of actions is executed.

A wide range of exceptional conditions can occur during the motion of a manipulator. Appropriate action must be taken as soon as any of these occurs, for example to start up a new concurrent process or to notify the user. Therefore, AL allows the flexible specification of conditions to be monitored during motions (and during execution of blocks of code in general) and what to do in the case that a tested condition occurs.

## USE OF A PLANNING MODEL

Since locations are not known exactly during the planning of a trajectory, there is a clear dist inction between planned values and runtime values. Planned values are used for trajectory calculation; at runt ime, trajectories are modified if necessary to account for any discrepancies. The planned values are therefore a database on which trajectory calculations are computed.

Assembly tasks require that one object be affixed to another. We model this by havine a semantic attachment between objects. If two objects are affixed, and one moves, the second one should move accordingly, that is, its planning value should be properly modified. The planning model includes information on attachments of objects. The affixment concept carries over to the runtime system, which does the equivalent modifications of the actual values. This saves ~he user the tedious bookkeepine operations required to determine where an object is after its base has been moved.

More generally, the compiler maintains a wide variety of information about expected runtime states. This includes information like the accuracy within which the planning value is known, how heavy an object is, how many faces it has on which it can rest, how wide the fingers of an arm should open to erasp it. This information may come from several sources, includine explicit assertions by the user and built-in knowledee about the system hardware. AL has a eeneral framework for representing and using such knowledee.

## USE OF DOMAIN-SPECIFIC KNOWLEDGE

The system will eventually have enoueh domain­ specific knowledge to allow programs to be written in terms of common assembly operations, rather than exclusively in terms of detailed single motions. At the simplest level, this involves a library of common assembly macro-operations that can be conditionally expanded to perform particular subtasks. Beyond this, we foresee an interactive system that can take a "high level" description of an assembly algorithm and fill in many of the detailed decisions required to produce a consistent and efficient output program.

A user will be able to specify different parts of a task at various levels of detail. The system is designed to accept explicit advice telling exactly how some particular subtask is to be accomplished. This is especially important for early versions of AL, which are not likely to be very "smart" and will therefore require a fair amount of explicit help. Other parts can be described by assertions which specify prerequisites and effects. The system will then complete the program incorporating the advice and satisfying the other assertions. The system can show the user how it is filline in the details to produce an output program, and why. This is very important both for debucging and for explaining to the user any requests for advice that it must make.

## THE RUNTIME SYSTEM

The calculation of trajectories is time-consuming but not time-critical; servoing of devices is time-critical but not especially time-consuming. Therefore, the compiler is written in a high-level laneuaee, SAIL, which runs on a large timeshared computer (a PDP-10) and the runtime system is desiened to run on a dedicated minicomputer (a PDP-11/45).

The runtime system supports simultaneous execution of many processes. Several manipulators or devices might be running simultaneously, and each motor requires a separate process; several condition monitors might be active; several code segments (doine, perhaps, calculations) might be simultaneously active. Those processes which are dealing with real-time devices (joint servos and condition checkers) must be guaranteed service at regular intervals; the comp!Jlation processes can fill in any time gaps.

The wide range of conceivable tasks implies that pure hardware servoing does not in general suffice. The reason for this is that hardware servoine restricts use to one of a small number of servo modes (typically position, velocity, or force), and has no provision for motions of accommodation or motions whose modes might change in midstream due to some software­ detectable condition. Pure hardware servoing could not be readily modified to account for new feedback devices or methods. A philosophy of software servoing has these advantages: It is possible to program the manner in which feedback is to be used, to interface new types of sensors, to modify the servo while the arm is in motion, to supply the driving proeram with information concerning the success of the motion as well as to keep it up-to-date on the arm status. It also allows coordination of several arms, with one actin& as a master and the others following. Hardware servoine would not save computation since the computer would need to perform an equivalent servo calculation in order to understand what the manipulator is doihe.

## GENERAL SYSTEM OUTLINE

## HARDWARE

Currently two Stanford Electric Arms, built by Victor Scheinman [Scheinman], are available. They are called YELLOW and BLUE. Each has six joints and a hand that can open and close. The joints are controlled by electric motors; each joint has both position and velocity feedback. Motor drives are sent from the computer to the arm via a dieital-to-analog converter (0-to-A); feedback signals are routed throueh an analog-to-dieital converter (A-to-D) back to the computer.

Various other devices are designed and implemented as needed. We use tools, jies and special markings for several purposes: to render a task possible (an example is the arm itself), to improve efficiency (a mechanical screwdriver), and to overcome some of our sensory and mechanical limitations (a screw dispenser).

## SOFTWARE

See figure 1 for a picture of the system.

The SUPERVISOR is the top level of AL. It runs on the timesharing computer and provides an interface between the user and the other parts of the system: 1) listening to the user's console and interpreting simple command language input; 2) controlling the compiler, starting it and relaying its error messages back to the user; 3) signalling the loader whim it is necessary to place compiled code into the mini; 4) handling the runtime 'interface to the mini.

The USER sits at a console and makes requests of AL. These fall into several categories: compilation, loading, execution of programs, debugging of code, requesting of status information, asking for immediate arm motion, saving and restoring the state of the world at safe points, requesting explanation of certain compiler decisions. There are two different consoles at which a user can sit: one is connected to the timesharing computer, through which he can speak to the supervisor and all the parts of AL residing on the timesharing computer; the other is connected to the mini, and through it the user can investigate the runtime system and cause modifications.

The COMPILER reads AL programs from files (or, optionally, directly from the user's console) and produces load modules. The compiler is divided into three phases: The PARSER, which produces parse trees of the program, the EXPANDER, which expands those parse trees by replacing high-level primitives with low' level primitives, and the TRAJECTORY CALCULATOR and CODE GENERATOR, which creates the output files.

The LOADER takes the load modules prepared by the compiler and enters them into the mini's runtime system. Address relocation and linking are done at this time. The loader also sets up the data area in the runtime interface in the timesharing computer; these data include output strings, procedure linkages, and information necessary for diagnostic purposes during runtime. Loading is often done in a partially incremental fashion, installing new code following previously loaded code.

The RUNTIME INTERFACE, which resides in the timesharing computer, is charged with initiating the mini program, fielding procedure calls from the running program to procedures on the timesharing machine, returning values from these procedures, and fetching values from the mini for debugging purposes. The interface has the power to interrupt the execution of the program and to modify the status of the runtime system, for example, by patching in additional programs or modifying the values of some variables. This allows the user to control the program through the timesharing computer.

FIGURE 1.

![Image](https://ijcai.org/proceedings/1975/fulltext/120/image_000001_471eba6d630d5b49b0c9d1df7b02601ca666ef0ebb079738cabb71e4b51da422.png)

The RUNTIME SYSTEM is the set of programs which reside in the l"(lini. This system includes kernel programs for time-slice cpu sharing and process control and a set of dynamically created processes. These are of three basic types: a) An INTERPRETER examines the code prepared by the compiler and executes the numeric computations requested. When a move is to be started, the interpreter creates a servo for each joint and waits until all these servos are finished. b) A SERVO handles the motion of one moving joint. c) A CONDITION-MONITOR repeatedly examines certain conditions (whatever the programmer has specified). If it should discover that its condition has occurred, it creates an interpreter to take appropriate action. The runtime system also includes routines for communication with the runtime interface in the timesharing computer.

## AN EXAMPLE

A simple task dealing with the objects shown in Figure 2 illustrates some of the features of AL:

1. Pick up the bracket with the YELLOW arm and position it next to the beam so that the holes line up,
2. Pick up the bolt with the BLUE arm,
3. Fasten the bracket to the beam by inserting the bolt in the holes,
4. Return the arms to their park positions.

Some of the features to be demonstrated are: the affix structure, reference frames, dimensions, and multi­ processing. We demonstrate these capabilities by presenting a highly commented AL program to accomplish the task stated above. Except for the missing macro bodies, this program is complete; it could perform as indicated.

AL is a multi-level programming language; at one extreme the user can write detailed, system..:like programs and at the other he can describe the tasks and any partial ordering among them and let the system determine necessary details. Our example is written in an intermediate level. In particular, it assumes that there are several general-purpose macros and routines which understand how to GRASP and RELEASE things and carry out a NORMAL\_SEARCH to insert somethin11 into a hole.

Capitalized words in the example are key words within AL. Lower case words are user-defined identifiers. Comments are surrounded by curly brackets.

## whole\_task: BEGIN

(First d~clare the necessary FRAMEs and d~scrib~ how they art initially related. A FRAME ts a coordinate systtm. It has two compon~nts : tilt location of tilt origin (a cfistanc~ VECTOR) and tilt orimtation of tilt ax~s (a ROT). Fram~s art typically ustd to dtscribt objects and important features of objects. Tlltr~ art several predeclared frames in AL. STATION is tilt f rame which represents tilt ruorA station's fra'ltlt of reference. Each hand available to tAt system also ltas a fram~ variable, whose value (continually updated) is tilt position of tllat hand. Currently there art two such frames : YELLOW and BLUE .

The attach structure representing the initial world is shoum in Figure J. Tht arrorus indicat~ how tlae mov~ment of a frame affects othtr frames . If a frame at the tail of an arrnru is moved (by the arm, visually updateci, etc.) the frame at th~ htad of the arrow will bt automaticall\_y updated. T ht doubt~ arrows ar~ tit~ results of RIGIDLY AFFIXing one Jramt to another.)

FIGURE 2.

![Image](https://ijcai.org/proceedings/1975/fulltext/120/image_000002_8f8010bf48a7e6df3cd25b272efe6d3b595d2cd19212ce2a8401ec29eec931f0.png)

FRAME beam, beam\_hole; FRAME bolt; FRAME bracket, bracket\_hole, bracket...grasp; beam .... FRAME(ROT(Z, 90·DEG), VECTOR(I0,6,0));

(Tite b~am is exp~cted to be positioned at (/0.61)) in tlae station's coordinau system (tilt default unit for distance measur~ments is centimeters) and rotaud 90 degrees about the station's Z vtctor. AL A.nows @out · dimensions lik~ DEG for degrees. Dimensions art adjuncts to variable types; new ones can bt defined in terms of old ones.)

## beam\_hole .... beam:~<TRANS(ROT(X, 90.DEG), VECTOR(3,0,7));

{The TRANS represents Oat position of the beam\_holt with respect to the beam. Tilt premultiplication 111 the frame beam positions the btam\_ltolt in tilt station's coordinat~ system.)

## AFFIX beam\_hole TO beam;

(As shown in figure J)

ASSERT FORM(DEPROACH, beam\_hole, TRANS(NILROT,VECTOR(0,0,-3));

(Trajectories consist of a path from the current position, through a departure point , possibly tltrouglt some via points, through an approach point, and finally to the destination. Th~ primary use of via points is to avoid collisions during the motion. All FRAMEs have a DEPROACH TRANS associated witlt tlttm. TRANSes are essentially tlte same as FRAMEs . When~ver leaving (or moving to) a FRAME tlte standard departure (or approach) used is that FRAME's DEPROACH TRANS . Tlat station loas a DEPROACH TRANS ruloiclo is tlortt inclots abovt it. Whenever one FRAME is AFFIXed to anotlter, try default tlte former talw on tlte latter's DEPROACH. TAt result of tltis ASSERT is tltat tlte arms will approach. tloe beam !tole from tlot side instead of from above.)

FIGURE 3.

![Image](https://ijcai.org/proceedings/1975/fulltext/120/image_000003_3c17e259fa5c4d10b375a5bc7558cde2e9768978df08d09bffd43882567f6e5b.png)

bracket .... FRAME(ROT(Z,i5*DEG), VECTOR(20,1i,O)); brackeLhole .... bracket* TR ANS(R OT(X, I80·DEG ),VECTO R(3,3,0)); AFFIX brackeLhole TO bracket; bracket~rasp .... bracket· TRANS(ROT(X, I80·DEG),VECTOR(0,3,3)); AFFIX bracket~rasp TO bracket RIGIDLY;

{Titt RIGID AFFIXment insures tloat a cltange of bracket\_grasp will automatica/l' cltange bracket, wlaiclo in turn ruill automatically change bracket\_loole. Tltis is quite convenient if tloe position of tlot wltole 'object' is being updated try one grasping position (ie. bracket\_grasp ).)

bolt .... FRAME(RQT(Z,90·DEG)· ROT(X,I80*DEG),VECTOR(I6,30,0)}.

{Tite rotation portion of tltt FRAME ltas bffn specified as a composition of two primitive rotations.)

DEFINE OZ · "72.007789·DYNES"; DEFINE INCHES · "2.5i·CM";

(Some of tloe standard macros art defined next.)

## DEFINE grasp

(TRANS speciaLdeparture,speciaLapproach; FRAME ATOM the\_arm (DEFAULT YELLOW); FRAME ob ject,grasp\_point, thing\_ob ject\_affixed\_to; DISTANCE SCALAR opening\_before\_departure, openingJor \_approach(DEFAUL T I S...CM), thlckness(DEF AUL T O.I·INCHES)) · " (body of macro goes ltere) ";

(Tioe expansion of such. a macro can depend upon tloe supplied arguments, tltt DEFAULT arguments, and ·any values in tlte eurrent planning model.)

```
DEFINE release (FRAME ATOM the_arm(DEFAULT YELLOW}. FRAME the_ob ject,the.Jlew_parent; DISTANCE SCALAR the_opening (DEFAULT 15·CM)) · " (body of macro goes ltert) "; DEFINE normaLsearch (FRAME ATOM the_arm(DEFAULT YELLOW); DISTANCE SCALAR increment(DEFAUL T .3·CM), distanceJwd; FORCE SCALAR stoppingJorce; SCALAR number _of _tries(DEF AUL T 9))
```

· " (body of macro goes lttre) ";

(Tiois ruould include some automatic error recovery and a call to t Itt operator if somet lting drastic goes wrong.)

## CO BEGIN

(This COBEGIN.COEND construction descriHs two independent subtask.s (one for YELLOW and one for BLUE) which can bt executed in any order determined by the runtime system; in parallel or urially. Tltis, of course, assumn that tltt two arms work in completely separate parts of the workstation so tlttrt is no possibility of a collision.)

ypickup: BEGIN (pick up the bracket with yellow) grasp('Ob ject· bracket,grasp...point· bracket...grasp, openingJor \_approach·3,..CM);

!Only tltt ntctHary parameters nud to be specified. By default tAt YELLOW arm will be used and there will H no special approaches or dtpartures . One tfftet of grasp is to AFFIX the object to the arm.)

MOVE bracket\_hole TO beam\_hole · VECTOR(0,0,-.3) WRT beam\_hole;

(The YELLOW arm (since it holds the bracket to which bracket\_hole is AFFIXed) positions itself so that tltt bracket\_hole lines up with tAt beam\_ho/e, but is .3 cm away from tlot beam\_hole. The WRT operator is one way of describing a vector within a frame of refertnct othtr than the station's.)

MOVE YELLOW TO · · VECTOR(0,0,.6) WRT beam\_hole ON FORCE(Z WRT beam\_hole)>50·0Z DO STOP YELLOW ON ARRIVAL DO ABORT("·ERROR· bracket went too farj;

{The · represtnt s tAt current position of the arm. The arm moves .6 cm in Z relative to the beam\_hole's frame . The purpose of this move is to push the bracket up against tht beam. If tltt beam is there, tltt arm rvill stnst an opposing force. If not, the arm rvill succeed in moving forward t ht prescribed .6 cm. In order to check for these possibilities, two condition monitors have been included with the MOVE statement. Tltt first one monitors the forct and stops tht arm if the forct exceeds '0 ounces (which means everything is ok.). The second one is an inttrrupt type condition. If the arm succtHfully carries out tlae complete MOVE, this monitor is awakened, tht message is printed, and control is given to an pperator.)

END ypickup; bpickup: BEGIN !pick up the bolt ruith blue) grasp(the\_arm· BLU E,the\_ob ject· bolt,grasp\_pciint·bolt, openingJor \_approach·3·CM); END bpickup; CO END;

(Figurt J shorus tht world after the parts have bttn picktd up.)

MOVE bolt TO beam\_hole · YECTOR(0,0,- 5.3) WRT beam\_hole;

(Tht BLUE arm positions itself so that tltt bolt is lined up with the btam\_ho/e and its tip is .J cm away from the outside of tltt bracktt\_holt.)

normal....search(BLUE, .2·CM, 1.6·CM, 60...0Z, 9);

(This pushes the bolt through the bracket\_ho/e and partly into tht beam\_ho/e. If control continuts past this statement tht bolt is assumed to be part11 in tlt.t Ito/e.)

MOVE BLUE TO · * FRAME(ROT(Z,90·DEG},VECTOR(O,O,i}} ON FORCE(Z WRT BLUE)> 60~~<0Z DO

STOP BLUE;

(This pushts and truists tlt.t bolt into the holt. Wilen tilt forct exceeds 60 ounces, tile bolt is assumed to bt completely seated in tile Ito/e. Tlttrt is no clteck to make sure t Itt bolt seats proper/,.)

## CO BEGIN

parky: BEGIN {reltast the bracket and parkl release(the\_ob ject· bracket,

the\_opening· 3*C M ,the\_new\_parent·beam); MOVE YELLOW TO YPARK; END parky; parkb: BEGIN (release the bolt and park) release(the\_arm· BLU E,the\_ob ject·bolt, the\_opening· 3·CM ,the\_new\_parent·beam); MOV.E BLUE TO SPARK; END parkb; CO END;

END whole\_task

## CONCLUSIONS

AL is important for several reasons. It shows what sort of considerations are necessary for flexible control of mechanical manipulation. It demonstrates the feasibility of programmable assembly. It provides a research tool for investigation of new modes of software servoing, assembly primitives, arm-control primitives, and interactive real-time real-world systems.

AL is currently limited by the lack of certain features which would make it more competent. Many of these have to do with the fact that feedback is used only in a threshold way; either a monitor triggers or it does not. Fine control of the arm would be enhanced by more sensitive force-sensing elements on the hand and a means of programming accommodating, non­ threshold response to this sensory input. Visual feedback should be implemented to provide better positioning capability, error detection, and error recovery. Moving assembly lines imply that AL should be able to understand motions which it does not cause directly through manipulation; objects should have a dynamic capablility. Collision detection and avoidance remain difficult issues. AL would be more error-free if the trajectory calculator could ensure that the arms never interfere with each other or with objects in the current world.

## BIBLIOGRAPHY

- [Bolles and Paul] R. C. Bolles, R. Paul, Tht Uu of Sensory F cedl>ack in a Programmable A Htmbly Sy5tnn, Stanford Artificial Intelligence Project, Memo No. 220, October 1973.
- [Finkel] R. Finkel, R. Taylor, R. Bolles, R. Paul, J. Feldman, AL , A Programming System for Automation, Stanford Artificial Intelligence Project, Memo No. 243, November 1974.
- [Inoue] H. Inoue, Foret Fttdback in Precise Autmbly Tasks, Massachusetts Institute of Technology A. I. Memo No. 308, August 1974.
- [Nevins] J. L. Nevins, D. E. Whitney, S. N. Simunovic, System A rchitecturr for A sumbly M aclaines, The Charles Stark Draper Laboratory, Inc., Memo No. R-764, November 1973.
- [Paul) R. P. Paul, Mode/ling, Trajectory Calculation and Servoing of a Computer Controlled Arm, Stanford Artificial Intelligence Project, Memo No. 177, March 1973.
- [Rosen) C Rosen, et. al., Exploratory Rtsearclo. in Advanced Automation, Stanford Re,earch Institute Report, December 1973.
- [Scheinman] V. D. Scheinman, Design of M antpulator, Stanford Artificial Project, Memo No. 92, June 1969. a Computer Intelligence
- [Will] Peter M. Will and David D Grossman An E xptrimental System for Computer Controlled Mechanical Assembly, IBM Research Report RC 4922, Yorktown Heights, New York. July, 1974.

![Image](https://ijcai.org/proceedings/1975/fulltext/120/image_000004_e034ad70e36706eaa690ee6fb4ad27de5f8de661c76fca637ae125dafd827a7f.png)

## References

1. and Paul] R. C. Bolles, R. Paul, Tht Uu of Sensory F cedl>ack in a Programmable A Htmbly Sy5tnn, Stanford Artificial Intelligence Project, Memo No. 220, October 1973.
2. R. Finkel, R. Taylor, R. Bolles, R. Paul, J. Feldman, AL , A Programming System for Automation, Stanford Artificial Intelligence Project, Memo No. 243, November 1974.
3. H. Inoue, Foret Fttdback in Precise Autmbly Tasks, Massachusetts Institute of Technology A. I. Memo No. 308, August 1974.
4. J. L. Nevins, D. E. Whitney, S. N. Simunovic, System A rchitecturr for A sumbly M aclaines, The Charles Stark Draper Laboratory, Inc., Memo No. R-764, November 1973.
5. R. P. Paul, Mode/ling, Trajectory Calculation and Servoing of a Computer Controlled Arm, Stanford Artificial Intelligence Project, Memo No. 177, March 1973.
6. Rosen)
7. C Rosen, et. al., Exploratory Rtsearclo. in Advanced Automation, Stanford Re,earch Institute Report, December 1973.
8. V. D. Scheinman, Design of M antpulator, Stanford Artificial Project, Memo No. 92, June 1969. a Computer Intelligence
9. Peter M. Will and David D Grossman An E xptrimental System for Computer Controlled Mechanical Assembly, IBM Research Report RC 4922, Yorktown Heights, New York. July, 1974.