Concurrent Pascal as a robot level language - Cambridge University ...

Robotica (1986) volume 5, pp 269-272

CONCURRENT PASCAL as a robot level language - a suggestion Adolfo Steiger-Cargao and L.M. Camarinha-Matos Universidade Nova de Lisboa, Departamento de Informatica, Quinta da Torre-2825 Monte Caparica, (Portugal) (Received: September 28,1985)

SUMMARY This paper briefly describes actual robot level programming languages, focusing on their intrinsic limitations when compared with traditional concurrent programming languages or when used for robotic systems/flexible production workshops programming, and not only for an isolated manipulator control. To reduce such limitations, a suggestion is made to base the development of robotic programming systems on already existing concurrent languages {Concurrent Pascal, Modula-2), taking into account their built-in extension facilities for fastening the incorporation of (or easy interfacing with) existing packages or products already developed in robotics (robot models, CAD systems, vision systems, etc). Using such languages as a support base for a robotic station programming environment, with access to different components developed separately, will allow a better understanding of the inter-relations among components and their limitations when faced with an integration perspective. A. THE PROBLEM 1 Introduction In the last few years several studies have been made that may be regarded as important contributions in the area of robotics but focusing specifically on sub-problems. All this effort, mainly at university level, may be lost through the multiplicity of implementations and the artifacts utilized, by the often incomplete character of the academic "products" and, specially, by the lack of means of access to the diversified tools that could allow a distinct qualitative approach (CAD, simulators, vision "packages", declarative languages, etc). On the other hand, we must not forget that technology is evolving towards better workstations (with enhanced computational and graphic capabilities), distributed solutions and operating systems standards. It seems therefore that conditions have been created for the development of a robotic programming environment endowed with characteristics that will permit the integration of previous developments in a single system, simultaneously providing the required basic tools for the development of state of the art programming techniques. 2 A brief look at current languages The methods initially used with industrial robots, aimed essentially at simplicity for task programming.

This goal, however - at least at the present practical stage - has been shown to be incompatible with the implementation of more complex applications requiring sophisticated sensorial environments. The vulgarization of computerized control reinforced this question, imposing the acceptance of true programming languages (described as being of manipulator level or robot level). In these manipulator level languages, the aspects specifically connected to robotics essentially consist in commands for the positioning of the manipulator according to Cartesian references, freeing the user from worries about the specific control of the degrees of freedom of the individual robot. Typically, we may find specifications of the manipulator's motion in accordance with free or well defined trajectories (a straight line, for instance) operations of the manipulator (grasping, releasing, etc). However, the major part of these languages is extremely simplistic. Thus: • The control mechanisms normally are not much structured, and in many cases are at the level of languages such as Basic. • In the major part of these languages (excepting some not widely known), a near complete absence of notions of modularization and extensibility is to be found. • The data types to be processed normally are also rather poor, and the mechanisms to enable the definition of new types or families of data are not given. • The mechanisms for the expression of concurrency are in some cases absent and in others incipient, (with the possible exception of the TEACH language). This limitation is specially severe since we conceive that a robotic application is a real-time case where debugging becomes more difficult in inverse proportion to the structuring of the concurrency mechanisms afforded by the language. Even from the viewpoint of these language's concrete application area, severe limitations will be found in most cases where they are centered almost exclusively on the manipulator, ignoring other components of a "robotic system" such as: conveyors, feeders, sensors, several robots, or packages running on other computers, etc. The utilization of a single language allowing the modelization, control, and access to these diverse components seems to be the natural way. As regards sensorial aspects, the more widespread languages only consider Boolean signals. The absence of definition mechanisms of other data types makes difficult

Robot programming language

270 the virtualization supported by the construction of models based on an interpretation of sensorial information, i.e. it does not favour the establishment of cooperative sensorial models. Interaction between individual robots or between sophisticated sensorial systems (vision, for instance) is practically ignored by these languages. It seems therefore evident that when the goal is the control of the whole system (real-time application), and not merely that of an isolated manipulator, we will require a language possessing more powerful mechanisms, taking in account distributed systems communication needs. The role of concurrency, connected to multiprogramming and now also multiprocessing, is reinforced. 3 Which approach ? In the last few years several proposals of new robot-level languages1 have seen the light in an attempt to gradually incorporate a few additional concepts, whether connected with robot's activities (example: RAPT Geometric relationships between objects), or in the sense of an approach to general purpose languages (example: AL-Algol type control structures, concurrency, etc). This evolution has apparently occurred divorced from the work that for several years has been performed in traditional informatics in fields such as: - Programming languages - Real-time programming systems/operating systems. It seems therefore that the several robot level language proposals (except some rare exceptions) are found to be below the level already attained on the conventional programming languages. On the other hand, those task-level programming systems, where the user would specify the intended goal, without indicating how to achieve it (the algorithm), although constituting a goal in the future,2 seems to us still somewhat distant from practical realization. Several well known traditional programming languages link the aspects of modularity and potentiality of construction of new data types to aspects of concurrency with a minimally structured or "regular" treatment. Examples: Concurrent Pascal, Modula-2, Ada.3 Simultaneously, these languages present the characteristic of being easily "extensible" by the addition of new modules - groups of primitives - separately compiled and integrable in libraries in such a way as to allow an identical treatment as if they were "built in". From a practical point of view, this suggests that such results should be utilized for the rapid production of a robotic station programming system, decreasing the limitations of present day robot level languages. Also, it would be desirable to retain and improve the aspects connected with the modelization (geometric, cinematic. . .) of the robot and other robotic components. Additional innovation efforts could (and should) be directed towards the goal of task level languages.

B. PROPOSAL 1 Possibility of selection As seen above, it seems to us that a robotic station programming language should be not a sub-set but rather a super-set of a general purpose concurrent programming language. Besides the normal characteristics of such languages, it should include those specifics for the application area: - robot modelization; simulation; - sensor modelization; - other components modelization (conveyors, feeders, special purpose robots...); - module for communicating with other systems for accessing packages in other processing equipments. Thus, our proposal consists in starting from a traditional language (with the characteristics already achieved in classic informatics) and, using its extension capabilities, improve it by the addition of new characteristics, specific to robotics. This extension can be easily implemented utilizing the notions of module (class, monitor) and separate compilation. The new modules (groups of primitives) thus created will begin to be viewed as being part of an enlarged library of language functions being attached to the specific application programs by means of a "linker". The user himself may use these facilities to create new libraries. Such a programming system obviously requires a higher level of competence from the programmer, but it will be incomparably more powerful and will permit the utilization of much of the work already performed. The importance assigned to the realization of communication between computational systems is to be taken into account, since it could allow accessing important tools (CAD, image processing, etc) already developed, in the same programming environment, by means of filters that reject non-pertinent information. It is not intended to consider these tools as definitive in a robotic programming environment, but simply to make the most out of a previous investment in order to obtain a better perspective of the requirements. Among the possible choices of a language reasonably well known and having the characteristics already referred, the more viable ones seem to be: (i) ADA - adopted by the Department of Defense, USA. Advantages: - Standardization - Abundant documentation - Treatment of exceptions. Disadvantages: - "Heavy" system - Few implementations until now -Probably still difficult to install in diverse hardware, (ii) MODULA-2 Advantages: - Simplicity (much lighter than Ada, but this does not mean a great loss of potentialities) - Widely known, specially at mini and microcomputer levels.

Robot programming language Disadvantages: - entails the construction of a multiprogramming nucleus, since the primitives of process creation/commutation are of a relatively low level. (iii) CONCURRENT PASCAL-possibly the first (in time) structured concurrent programming language. Advantages: - generally the same as Modula-2. Disadvantages: - In the normal version,4 suffers from limitations at I/O level and separate compilation. In Enertec's microConcurrent Pascal (rnCp) implementation,5 that shows some characteristics of Modula and Portal, the I/O facets are much more open and allow the user to create device drivers for any I/O component. Also, the aspects of separate module compilation have been resolved in the more recent versions. This implementation also has the additional advantage of being easy to install in several machines, since it is normally compiled for an intermediate language - P being only necessary to rewrite a small interpreter for the desired processor. The documentation provided for the construction of the interpreter or for its installation on specific hardware - in particular the treatment of interrupts, that constitute the basis for the commutation of processes seems reasonable. No major difficulty has been found on installations we have performed. This aspect is specially interesting since, although many of the presently available compilers abide by this philosophy in order to be easily installed on new hardware, they do not provide, however, to the common user access to the utilisation of such facilities. There are several commercially available interpreters for the more common micro and minicomputers in existence, and we believe that for some implementations of Modula-2, such characteristics are also offered. Therefore, these two languages seem to be good candidates for these experiments. Some similar proposals advocating the use of ADA, have been made lately.6 However, we believe that this is a rather heavy language compared to the former two, and not easily utilized in small machines. However, the considerable sums being invested in this language should merit some attention. The aspects of mCP that in a way or another we consider important for the programming of robotic systems are: Modularization: - Classes, monitors. These mechanisms will permit the creation of new concepts-for instance, associated with the interpretation of sensorial information or to the notion of frame of coordinates. - Processes; - Device-monitors; Important for the encapsulation of special objects:

271 I/O peripherals. The importance of this possibility should be stressed, since in robotics, computers are to be connected to a large variety of physical artifacts possessing control characteristics somewhat different of the computer's classic peripherals. - Separate compilation. Concurrency: synchronization, mutual exclusion. In Modula-21* and Ada we find similar concepts. Task level programming involves a combination of aspects both related to control, real-time, etc. and problems very closely matched with Artificial Intelligence approaches. Programming the former is well described using procedural languages. The later requires mainly Artificial Intelligence tools such as Prolog or Lisp. However, already proven professional language versions with the same type of characteristics described earlier in this paper (concurrency, modular development, etc) are not known at the moment. This is the main reason because they are only marginally considered in this very pragmatic way. As a result, only the development of communication modules between programs built in different languages and systems will be considered. Recent developments as Smalltalk 80, Concurrent Prolog and Delta {distributed) Prolog associated with the 5th computer generation effort strongly suggests very early availability of convenient hardware and software solutions. 2 Examples As referred to before, the main characteristics of robot level languages - robot modelization - may be incorporated in a system similar to one we have been describing. We could, for example create a module with motion specification primitives (operations) - according to VAL, AML models or whatever. Thinking of a robot station and not only of the manipulator, we could create other modules or objects, viz. - Module with modelization of tactile sensors, providing the manipulation primitives of such sensors. - Module incorporating the vision system's primitives. It is to be noted that the entry procedures that correspond to such primitives may consist in a complete implementation of the vision algorithms or, alternatively, in an interface with a vision package already in existence and running in another computational system. It may also be noted that this type of language shows the tendency to discard the operating system and applications written in other languages, therefore "hi-jacking" the machine! Therefore, for the utilization of existing packages we must access other computational systems where such software can run (in case we don't want to rewrite them in the concurrent language). These considerations are obviously valid for any other situation. - Module for inter-system communications. - Modules with other component's control primitives -

272 conveyor belts, rotary tables, feeders,... (or of interface with those systems responsible for effective control). Here it will probably be necessary to invest some modelization efforts since these components, although simple, have not been the object of as much attention as the manipulators. It should be noted that we may build two versions of these modules one for control of real devices and another that constitutes a simulation with graphics interface, for instance. Thus, depending on which version is used for the LINK operation, we may either perform an "off-line" application test (simulated), or gradually migrate towards its utilization "on-line". The importance of these facilities for application implementation seems evident. These aspects naturally will be considerable for debugging an application, in view of the advantage of the same system supporting both the simulation and the real execution. Likewise, as referred previously, we are considering application domains that, from an informatic viewpoint, constitute typical real-time situations. Debugging this type of software is undoubtedly more complex than the case of purely sequential programs. The fact that we are dealing with relatively structured mechanisms of expression of concurrency, will partially diminish these difficulties (relatively to those if we used traditional robotics languages). It would also be feasible to construct supervision processes, having access to all data structures, allowing the inspection of the application's evolution and, eventually, the possibility of manual action on this evolution. Other modules to be developed in such programming environments will include: - A normal I/O module for interfacing with human operators. - A module for interfacing with eventual production data bases derived, for instance, from CAD systems. Another possibility is building up libraries with modelization for several robots or different components of the working cell, for future usage, in accordance with the particular configuration of each application. Presently, in our Department at the New University of Lisbon, a prototype system of a didactical/experimental nature is being developed with the following features: - A robotic system: manipulator, conveyor belt, rotary table; - Small vision system; - Semi-professional RENAULT robot; - Mobile didactic robot; with a multiprocessing control structure utilizing mCp as the basis for the installation of a programming environment for industrial robot stations.

Robot programming language C. CONCLUSION In view of the limitations of present day robot level languages, whether from the informatic viewpoint, or from the specific perspective of robotics, specially envisaged in terms of a station/production shop and not as a mere manipulator, a proposal is made for the creation of a more efficient programming environment. Instead of advocating the creation of a new language, as has been done frequently, our approach favors the adoption of a concurrent programming language easily adaptable to diversified hardware - microConcurrent Pascal or Modula-2, to be extended afterwards, by the creation of modules to control, modelize, and establish communication between the various components of a robotic station. This approach obviously does not intend to be revolutionary in terms of concepts, and it is essentially pragmatic: To make the most out of existing developments and products, whether in the area of traditional informatics or industrial robotics, in such a way as to make available, with a minimal investment, a reasonable system of robotic stations programming. This could be a starting point for more basic investments for the so called programming systems at task level. It is believed that having several components of evident usefulness (simulators, CAD databases, image processing systems, access to programs written in declarative languages . . . ) available and easily accessible, will facilitate progress towards the development of tools for task level programming. At least, it will permit a greater understanding of the interrelationships between such components and their limitations when faced by a task of integrating them.

References 1. Tomas Lozano-Perez, "Robot Programming" Proc. IEEE 71, No. 7 (July, 1980). 2. T. Lozano-Perez and R.A. Brooks, "An Approach to Automatic Robot Programming" MIT, AI Lab, AI Memo No. 842 (April, 1985). 3. J. Hope, "A simple Nucleus written in Modula-2" Eidgenossische Hochschule, Zurich Rep. 35 (March, 1980). 4. P.B. Hansen, The Architecture of Concurrent Programs" (Prentice Hall, New York, 1977). 5. C.A. Fulton, "MicroConcurrent Pascal (mCP) Users Manual" Enertec Inc., 19 Jenkins Ave., Box 1312, Lansdale, PA 19446 USA. 6. G. Gini and M. Gini, "Ada: a language for robot programming?" Computers in Industry 3, No. 4 (1982). 7. Modula Corporation, "Mac Modula-2, a Modula-2 development system for Apple Macintosh", Modula Corporation, 950 North University Ave., Provo, Utah 84604 USA (1984). 8. N. Wirth, "Modula-2" Eidgenossische Hochschule, Zurich Rep. 36 (March, 1980).