AL(ID:486/al:001)
Assembler for robots
for Assembly Language and Arm Language (because it was first used for the arm)
Standford Research Institute 1969
Robotic language for the Stanford Arm, developed by Victor Scheinman at SAIL. It was a small electrically-controlled arm, with six degrees of freedom. AL was used to descibe the mathematical functions which the arm would then fit.
Despite its name, AL was an ALGOL 60 derivation.
The technology was transferred to Karlsruhe in 1980 to be made into a new higher level language
Places
Related languages
| ALGOL 60 | => | AL | Based on | |
| WAVE | => | AL | Evolution of | |
| AL | => | Karlsruhe AL | Evolution of | |
| AL | => | SRL | Based on |
References:
in Langages et Methods de Programation des Robots Industriels, IRIA Press 1979 view details
The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one.
There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages.
The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM.
Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) .
It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers.
The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA).
As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found.
It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel.
We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work.
Graz / Austria, May, 1973
in Langages et Methods de Programation des Robots Industriels, IRIA Press 1979 view details
in Langages et Methods de Programation des Robots Industriels, IRIA Press 1979 view details
Institution: Stanford University, Department of Computer Science
Title: AL, a programming system for automation.
Author: Finkel, Raphael A.
Author: Taylor, Russell H.
Author: Bolles, Robert C.
Author: Paul, Richard P.
Author: Feldman, Jerome A.
Date: November 1974
Abstract: AL is a 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 individual motions of manipulators, for using sensory information, and for describing assembly algorithms in terms of common domain-specific primitives. This document describes the design of AL, which is currently being implemented as a successor to the Stanford WAVE system.
in Langages et Methods de Programation des Robots Industriels, IRIA Press 1979 view details
Institution: Stanford University, Department of Computer Science
Title: AL users' manual
Author: Mujtaba, Mohamed Shahid
Author: Goldman, Ron
Date: January 1979
Abstract: This document describes the current state of the AL system now in operation at the Stanford Artificial Intelligence Laboratory, and teaches the reader how to use it. The system consists of AL, a high-level programming language for manipulator control useful in industrial assembly research; POINTY, an interactive system for specifying representation of parts; and ALAID, an interactive debugger for AL. pdf Extract: Design Philosophy of AL (includes WAVE)
Design philosophy of AL
2.1.1 Introduction and historv
The WAVE system for manipulator control was designed and implemented by Lou Paul in 1973 on the Scheinman Stanford model arm and was used extensively by him and Bob Bolles.
The experience with WAVE led to the initial specifications of AL in 1974 by both of them and Jerry Feldman, Ray Finkel, and Russ Taylor.
The initial implementation of the compiler and runtime system for Al was done by Finkel and Taylor, and subsequently taken over by Ron Goldman. Vic Scheinman designed the arm currently in use at SAIL, while Tom Gafford and Ted Panofsky are responsible for the computer interface to the manipulator. Ken Salisbury and Gene Salamin are currently maintaining the hardware.
The work of Paul and Bruce Shimano was responsible for developing the kinematics of manipulation and the arm servo code. Shimano subsequently implemented force compliance, while Tatsuzo lshida has done a theoretical analysis of two arm cooperative manipulation. Salisbury is currently maintaining the arm servo code.
ALAID, for debugging AL programs, was initially implemented by Finkel. A newer version is being implemented by Hamid Nabavi,
The first AL parser was written by Bill Laaser and Pitts Jarvis, and subsequently taken over by Shahid Mujtaba.
POINTY, a related system, was conceived in 1975 by Dave Grossman and Taylor, and init ialiy implemented by Taylor. Maria Gini, Pina Gini and Mujtaba have subsequently implemented a newer version. Enrico Pagello has also contributed to it. POINTY is currently maintained by Mujtaba.
The design of AL has continually been modified and updated on the basis of new experience and information by Grossman, Shimano, Goldman, and Mujtaba under the overall guidance of Tom Binford.
The AL system is geared towards batch manufacturing where setup time is a key factor. To minimize programming time we rely on a symbolic data base and previously defined assembly primitives, and a quick and simple means of putting into a program the things we want to tell the manipulator to do. By testing out the system on undergraduate industrial engineering students with minimal experience in manipulators and robotics, we have found that learning to use the AL system is relatively simple, and that it is unnecessary to learn the complete system before putting it to use. Team programming sessions by researchers in manipulation at the Workshop on Software for Assembly held in November 1977 at SAIL showed the possibility of learning to program AL in a short time. The AL system has also been used for term projects in a Robotics course given in the Fall quarter of 1978.
We assume that the batch manufacturing environment is fairly structured and known - the positions of fixtures, parts, tools, etc. are known and not expected to vary from one assembly to another by any appreciable amount. By simulation it is possible to predict where each object is at any instant of time, and whether it is held in a manipulator, if it is to be moved, and whether sufficient information has been given, so that communication with the user is minimized during execution, Because of the high degree of structure in the manufacturing environment, we try to do as much computation as possible before an assembly begins.
2.1.2 Plantime and runtime systems
Experience with WAVE (the predecessor to AL) had shown that calculating trajectories for manipulators was a desirable feature. It was thus decided that trajectory calculations, together with ail other calculations which need only be performed once, should be done at compile time on the assumption that this allocation of effort would reduce the computing load at execution time and eliminate recomputation every time a sequence of actions is executed. This sequence of planning and execution led to the existence of two systems - the plantime system and the runtime system.
The plantime system consists of the AL compiler whose function is to take the user written AL program, simulate it, point out errors to the user, and output instructions to the runtime system. The compiler performs a simulation of the program (called world modeiling) to verify that it is indeed possible to do what the user asks within the limits of what AL is capable of doing, and to warn the user about unexpected consequences (e.g. if the user accidentally asks that the arm be moved through the table). The runtime system takes the output of the plantime system, and proceeds to perform the motions.
This approach is changing because of subsequent developments.
Computation costs have dropped dramatically and this makes possible the future use of multiple processors in distributed computation. Better arm servo software, faster arrn solution and more sophisticated path calculation algorithms tend to reduce the computation load, thereby permitting more decisions to be made at runtime. It was also realized that certain trajectories are best computed during runtime (e.g. force compliant motion, moving belt, when the workplace is highly unstructured). (See Discussion of Trajectory Calculation Methods by Mujtaba in Progress Report 4.).
2.1.3 Data and control structure
The principal mode of input to AL is textual. The use of symbolic programming means that for parts in a pallet, for instance, there is no need to define the position of all the parts, if the distance between parts (which is usually constant) is known. Once the corner of a pallet is taught and the part separation is known, laborious record-playback programming is no longer necessary given proper software in an associated minicomputer, [Engelberger, J,F. in A Robotics Prognostication, Joint Automatic Control Conference Proceedings 1977, p 198.
Symbolic programming simplifies the interfacing of AL with other means of generating world models, like interactive graphics and computer aided design. It permits the setting up of library programs which may be called by supplying the relevant parameters. The use of symbolic programming eases the job of specifying complex motions if such motions can be parametrized or described algebraically - for example, it is easier to tell the hand to move a certain distance along an arbitrary direction than it is to move it manually when multiple joints have to be adjusted simultaneously. Teaching by doing, on the other hand, requires the recording of a very large number of points (tape recorder mode) unless only the end points of motions are of interest and the nature of the paths between these end points are unimportant.
There are levels of complexity which are much more readily transmitted from man to machine through an interface of symbolic text. Simultaneous motions of two arms, specifications for termination, and error conditions are more likely to be unambiguously stated through the medium of text, since these may require mult iple logical relationships to be satisfied. Non-textual forms of input can be a very useful rneans for defining target locations, suggesting arm trajectories designed to avoid collisions, initial setup of a workstation, and other purposes of this nature.
AL makes use of more data types than other conventional high level languages do. In addition to SCALAR numbers, it allows the specification of VECTOR, ROTATION, FRAME, TRANS, and EVENT data types. A VECTOR consists of a triple of three real numbers. A ROT consists of a direction vector and an angle to indicate the amount of rotation. A FRAME describes the position and orientation of an object, while a TRAIVS describes the relationships between FRAMES. In addition, arrays of all these data types may be defined. Arithmetic operators are available not only for the standard scalar operations but also for such operations as rotation and translation.
We want to write programs in a natural manner. The machine-language like aspect of current manipulation languages makes it cumbersome to write long programs in any structured way. We want a language which lends itself to a more syst ematic and easily understood programming style. To this end, the use of ALGOL-Ii ke cont roi structures are an improvement over linear machine-language code with jumps. The block structure of ALGOL is also present in AL.
Experience with languages like SAIL and WAVE has shown that text macros are a useful feature; they reduce the amount of repetitive typing, and allow symbolic definition of constants and variables in a way which would be otherwise impossible. AL has a general-purpose text macro system. Procedures are provided, as in other languages, to reduce the amount of code when similar computations or operations need to be done at numerous places in a program.
AL also permits the control of parallel processes by allowing the flow of control of the program to be divided up, which allows certain operations to be performed simultaneously (e.g. simultaneous movement of different manipulators), after which the various processes merge back together. Synchronization primitives are also provided.
2.1.4 Motion of objects
AL has a mechanism to keep track of the location of a component piece of an assembly automatically as the assembly is moved; this mechanism is called affixment and used extensively with the concept of FRAME to describe objects.
Frames may be affixed to each other, so that after affixing an object to the manipulator, the user can forget about the manipulator completely, and think in terms only of where objects have to interface with other objects. instead of having to worry about how to move the arm, the user can specify the final orientation and position of the object, and AL will take care of working out what the arm has to do in order to accomplish the stated objective. The user can think of movement of the objects rather than the movement of the manipulator. This is significantly different from other programming schemes where the program consists of a series of arm motions whose relationship to objects in the real world is known only to the user, and where the user effectively has to provide explicitly the distance and angular relationship of the object to the manipulator for each motion statement,
in Langages et Methods de Programation des Robots Industriels, IRIA Press 1979 view details
in Langages et Methods de Programation des Robots Industriels, IRIA Press 1979 view details
in Langages et Methods de Programation des Robots Industriels, IRIA Press 1979 view details
in Langages et Methods de Programation des Robots Industriels, IRIA Press 1979 view details
in Langages et Methods de Programation des Robots Industriels, IRIA Press 1979 view details
in Kosinski, M.S. "SPL/I Language Reference Manual" Intermetrics Report 172-1 (July 1976). view details
in [PFT] Verbesserte Programmiemng von Robotern in der Montage [Improved Programming of Robots in Assembly] PFT-Entwicklungs-notiz Karlsruhe (1981) view details
in Machine Intelligence 10, J.E. Hayes, Donald Michie, and Y-H. Pao, editors, Ellis Horwood Ltd., Chicester, England, 1982. view details
in [PFT] Verbesserte Programmiemng von Robotern in der Montage [Improved Programming of Robots in Assembly] PFT-Entwicklungs-notiz Karlsruhe (1981) view details
in [PFT] Verbesserte Programmiemng von Robotern in der Montage [Improved Programming of Robots in Assembly] PFT-Entwicklungs-notiz Karlsruhe (1981) view details
in [PFT] Verbesserte Programmiemng von Robotern in der Montage [Improved Programming of Robots in Assembly] PFT-Entwicklungs-notiz Karlsruhe (1981) view details
in [PFT] Verbesserte Programmiemng von Robotern in der Montage [Improved Programming of Robots in Assembly] PFT-Entwicklungs-notiz Karlsruhe (1981) view details
in [PFT] Verbesserte Programmiemng von Robotern in der Montage [Improved Programming of Robots in Assembly] PFT-Entwicklungs-notiz Karlsruhe (1981) view details
Resources
- Page at computer museum
external link - Display at Stanford
The kinematic configuration of the arm is non-anthropomorphic (not humanoid) with 6 joints (5 revolute, 1 prismatic) and links configured such that the mathematical computations (arm solutions) were simplified to speed up computations. Brakes were used on all joints to hold the arm in position while the computer computed the next trajectory or attended to other timeshared activities. Drives are DC electric motors, Harmonic Drive and spur gear reducers, potentiometers for position feedback, analog tachometers for velocity feedback and electromechanical brakes for locking joints. Slip clutches were also used to prevent drive damage in the event of a collision. Other enhancements include a servoed, proportional electric gripper with tactile sense contacts on the fingers, and a 6 axis force/torque sensor in the wrist.
external link - Image at Staford
