A Reusable and Flexible Control Station for Preparing and Executing Robotics Missions in Space

ABSTRACT. Although robotics space missions can have different profiles, they all have to face the same typical challenges: (1) how to economically set up a workstation for control and monitoring of a space robot and (2) how to efficiently and safely operate this robot remotely via a communication chain characterised by low bandwidth and appreciable end-to-end delays. The FAMOUS (Flexible Automation Monitoring and Operation User Station) station is intended to be a re-usable (hence, economic), flexible and robust control station to support the user throughout the mission preparation phase, and to safely monitor and control the robot during the mission itself. Economic set-up is achieved by offering an adaptable control station made of a series of predefined components from which a mission-specific control and monitoring station can be established with a minimum of effort, i.e. where coding of additional software components is limited to those that are really specific to the actual mission. Efficient and safe operation can be achieved by supporting the so-called "Interactive Autonomy" mode of control, in which an operator gives the go-ahead only to the execution of successive qualifiable "macro"-commands ("Compound Tasks"), that are fully validated through simulation during mission preparation.

KEYWORDS: Robotics, reusability, Interactive Autonomy, mission preparation, mission control.

The 'FAMOUS/Generic' User Station

The purpose of the Flexible Automation Monitoring and Operations User Station - FAMOUS - project is to define, implement, test and deliver a generic work station to actively support a ground-based operator for all tasks associated with the preparation and execution of space-based robotics. By a "generic work station" is meant a workstation that is easily adaptable / configurable / re-usable to any type of robotics mission. The FAMOUS/Generic station becomes a control station for the robotics on any given mission through a process of instantiation (configuration, installation of additional, dedicated software) of the generic station to the specific application.

The scope of robotics applications that FAMOUS will have to be able to support covers a wide range of missions involving robotics. Such missions include:

• internal robotics on space station or other pressurised environments in low earth orbit;
• external rotics on space station or MIR modules, low earth orbiting free flyers, planetary or deep space missions, etc.

This wide scope of applications makes it necessary to provide a comprehensive set of functions and tools in FAMOUS, to cater for all possible situations, and to allow for easy integration of new functions dictated by specific mission aspects.

Hence the FAMOUS/Generic station which is the main result of this project will provide the capabilities to support all the types of applications identified above, and will have a modular, open architecture, so the following types of mission may be envisaged as well in the future:

• robotics for lunar missions, e.g. robots on rovers;
• sample-collecting robots on e.g. missions to comets.

In the current project, the first instantiation (adaptation) of FAMOUS/Generic will be done for ESTEC's CAT test-bed, as an example of internal robotics in a pressurised environment. The resulting development is referred to as FAMOUS/CAT.

The next instantiation is for the JERICO project (Joint European Robotics Interactive and Calibrated Operations), where FAMOUS will be used as the mission preparation and control station for the SPIDER robot arm. Future application of FAMOUS include the Geostationary Service Vehicle (GSV), LEDA, and potentially others.

Principles Behind FAMOUS/Generic

The Interactive Autonomy as Mode of Operation for FAMOUS

An operator remotely controlling the execution of robotic tasks may require different levels of interaction:

• when the operator is confident in the correct execution of the tasks, a fully automated execution of a robot program is sufficient. In such a case, the operator has only to give the "go ahead" to initiate a (series of) robotics tasks;
• for other phases, he may want to be actively in the loop, as the next robotic operation may depend on the results of previous tasks.

Also, the level of interaction required by one task may not be the level required by another task, depending on the particular application domain. Typical examples include:

• When the same activities have to be repeated again and again, with high accuracy and short execution time, robot programs are run in pure automated mode: there is no user intervention, except for the initial go-ahead. This mode of operations is called " Industrial Mode". Although such a mode of operation is typically found in industry, it is also applicable to on-board laboratory applications for which the repetition of the same experiment is required, for example to provide statistical information to the scientists from multiple executions of the same operation, maybe with different experiment parameters.
• For robots operated manually by a remote operator, like robots moving in hostile or difficult environments (nuclear power plant, deep sea, even operation theatres for brain surgery), the operator directly operates the robot by means of joysticks, levers or master arm whose movements are copied by the "slave" robot. This mode of operations is sometimes called " Telemanipulation", or " Direct Mode". Inherent features of this mode of operation include:
  • flexibility: the operator can control the robot in any way he wants (within the limits of the system as described below) as required by circumstances surrounding the robot operations as they are performed;
  • directness: the operator is directly in control of the robot, much like the relationship between a driver and his car, a pilot and the airplane;
  • performance limitations: the robot operations are limited in speed by the human operator in the loop, and by the time constants of the control loop proper - the longer the loop delay is, the slower will be the robot movements possible in order to maintain safe control over the robot by the human operator;
  • bandwidth demanding: where direct visual contact between robot environment and the operator is not possible, video cameras are required for mono- or stereoscopic monitoring, requiring large data transfer bandwidths. The control loop itself also requires relatively high data rates.
• Between these two extremes, the operator may want to control only the most "interesting" parts of the execution of his application: instead of being involved in all the execution details, or not being involved at all, he may want to have the possibility to decide on the direction of the application, based on the evolution observed by monitoring, and leave the details of the operations or the complete control in between the "interesting" parts, to automatic systems. This would offer a maximum of comfort and efficiency, as the intelligence of the operator would be used for tasks that really require it, leaving robot automatic systems to perform the routine tasks. This mode of operations is called "Interactive Autonomy".

As on-ground control station for space applications, for which the problem of communication delays is crucial, the FAMOUS control supports Interactive Autonomy mode of operations. However, a station supporting the Interactive Autonomy mode has the capability to support the Industrial Mode as well: the operator only has to initiate the first step of the whole A&R application, and the robot does the rest.

For robotics applications for which the delays in the communications are small or neglectible, as for ground-based systems, FAMOUS can advantageously support the telemanipulation mode of operations as well, as it provides a set of functions that will be useful also for this mode. Currently, however, only the Interactive Autonomy mode of operations is considered.

Using a Standard Hierarchical Breakdown of Robotics Activities

We have seen that a control station supporting the Interactive Autonomy concept will provide enough comfort and flexibility for space operations. In practice, an operator in front of the FAMOUS station during the mission execution phase will only give the go-ahead for the execution of successive "macro"-commands and qualify these commands by parameter values, if required. Each macro-command, called "Compound Task", is intended to be executed without interruption by the robot and corresponds to the performance of a basic step in an whole operation scenario. Between each Compound Task, the operator takes decisions.

During the mission preparation phase, these Compound Tasks need to be defined (and validated through off-line simulation, as explained later). Actually, a Compound Task usually includes a whole series of simpler robotic activities that repeat or may repeat themselves in other Compound Tasks. Based on this observation, the notions of Actions and Tasks have been defined:

• a Task is a further breakdown of a Compound Task, and implements a standard robot movement or function, such as to insert a peg in a hole. It is the standard building blocks to make up any new Compound Task;
• an Action is the lowest level robotics activity that can be directly mapped to a robot ability, such as to move from point A to point B.

The benefit of using a standard decomposition method for robotics activities within FAMOUS lies in the possible re-use of Actions, Tasks and possibly Compound Tasks. Indeed, the decomposition method may lead to identify common activities across different A&R applications, commonalities that can explicitly be listed in a library available on the station.

Of course, the engineers in charge of the coding of the activities in the relevant robotic programming language cannot expect that all the required Actions, Tasks, etc., will be found in the library: the programmers will probably have to add a few new activities for their own needs.

The existence of a library will also encourage programmers to make the effort to design new activities as being generic (i.e. with parameters) and re-usable.

This breakdown is compatible with the one promoted by ESA's Control Development Methodology, which, however, does not explicitly covers Interactive Autonomy.

Robotics Operations Supported by FAMOUS/Generic

FAMOUS needs to support, and will support, the following four main phases of robotics operations:

• pre-preparation phase;
• preparation phase;
• utilisation phase;
• contingency phase.

The pre-preparation phase consists of configuration activities that need to be addressed once for each robotics application, i.e. a given utilisation of robotics devices in a given environment. The pre-preparation phase includes activities such as building the World Model database, defining the 2D and 3D graphical user interfaces and modelling the sources of data measurements. This phase also includes writing program Templates for the robot of the target mission. By "Template" is meant programs with parameters for which values still have to be specified.

The preparation phase consists of giving values to the program Templates and validating them through simulation in a series of possible utilisation contexts (e.g. door open or closed, etc.).

The higher level programs correspond to Compound Tasks (CTs). As defined in the previous section, CTs are the programs that the FAMOUS operator can directly initiate during the execution phase (Actions and Tasks are run as part of a Compound Task).

Additional programs known as Transition Compound Task are also created or prepared for making the robot (and other objects) move between different locations in the workcell. Indeed, after having performed a given Compound Task, the robot will usually need to move to another location to perform the next desired Compound Task.

The planning for execution of the programs is prepared and possibly negotiated with an external Mission Control authority. This planning is built upon the constraints of precedence between Compound Tasks (some Compound Tasks can be executed only after others) and information on resources requirements (e.g. time required to perform the Compound Task). Operational constraints on the sequence of the Compound Tasks and resources requirements as an input to overall mission planning are defined with the help of FAMOUS, while the mission planning as such remains a Control Centre responsibility.

During the utilisation phase, the programs are uploaded in the robot controller and the Compound Tasks defined in the previous phase are successively initiated by the FAMOUS operator, who may define last-minute parameters, such as the volume of the liquid the robot has to inject during a step in an experiment execution. Once the Operator has given the go-ahead for a chosen Compound Task, the corresponding program is executed with the specified parameters, as long as the request does not break some operational or security rule.

Throughout the utilisation phase, FAMOUS offers the Operator(s) the means to monitor the robot activities. An Automated Watchdog, configured during the preparation phase and switchable on/off during the utilisation phase, also helps supervise and monitor the operations, by constantly checking the telemetry stream and triggering the display of windows highlighting data that the operator should focus on. Driven by the telemetry, a "mirror robot" can be visualised on the FAMOUS monitoring screen, together with a view of what is the expected robot behaviour.

In case of contingency (e.g. the robot turns out to be in an unexpected state at the end of an activity, or an error message appears) a skilled FAMOUS operator has the possibility to quickly reprogram the robot, using the facilities offered by the station during the preparation phase: this situation is known as "Recovery Programming".

The FAMOUS/Generic Architecture

The whole FAMOUS system is organised as a series of Servers providing services to MMI Clients applications:

• MMI Clients are components that do not provide any service to any other component. They usually do not perform any major processing and their role is typically limited to offer a comfortable user interface.
• FAMOUS Servers will be those processes providing services to a calling process, namely a FAMOUS MMI Client or another FAMOUS Server.

Depending on the operational phase, a particular MMI Client may or may not run. What MMI Client may be activated and the number of identical MMI Clients that can concurrently run is controlled by a particular server: the Administration Server.

The tables below briefly identify each MMI Client and Server that are part of the FAMOUS/Generic system and provide a summary of the functions they support. Note that all components but the ones marked by an asterisk (*) are expected to be re-used without any modification for particular robotics missions.

Note that this architecture is open for future enhancements and support of new types of robotics missions, as MMI Clients and Servers may be modified (enhanced or adapted) and new ones added with minimal impact on the other elements, hence scope for re-usability in quite different operational environments are kept at a maximum.

The FAMOUS/CAT Implementation

Because of the mission-readiness aspect of FAMOUS, the station must directly rely on available software packages. Hence, Tecnomatix' ROBCAD has been chosen as the actual heart of the off-line programming, simulation and 3D visualisation, whereas Tcl-Tk, a Motif-like GUI, has been chosen for the implementation of the 2D graphical user interfaces of the additional components (typically the MMI Clients). The Inter-Process Communication system between the MMI Clients and the Servers will be based on Tcl-DP, an extension of Tcl-Tk based on TCP/IP.

Note that the architecture of FAMOUS/Generic does not prevent the station from being based on a commercial package different than ROBCAD. The usage of Tcl-Tk and DP is not constraining at all as they are widely (and freely) available on multiple platforms.

The station, in its FAMOUS/CAT demonstration version/instantiation, will use the ESTEC ACS/ACM communications package for communicating with the robot controller and the payloads of the laboratory, and will be hosted on a Silicon Graphics Crimson class machine, equipped with a VideoLab board for realtime video. For those specific elements, a minimum of specific software is required.

In another instantiation of FAMOUS, e.g. for FAMOUS/JERICO, the Communications Server is likely to be a completely different piece of software, but yet keeping the same interface with the rest of the FAMOUS station.

Conclusions

The FAMOUS/Generic suite of software can be seen as a package or toolkit supplied by ESTEC to an A&R project, providing the project with a proven basis for commencing definition of project-specific FAMOUS instantiation, and for supporting development and utilisation.

Although this was not emphasised in the paper, this bundle also includes a set of standard documents (URD, SRD, ADD, SUM) from which the project-specific documents can easily be derived.

The FAMOUS/CAT instantiation will validate and refine the concept of a standard robotics package and demonstrate the flexibility that can be reached in practice with a station controlling a space-borne robotics application according to the principle of Interactive Autonomy.