Staff and students at Lancaster University have, for the past five years, been involved in the development of an autonomous robot excavator -LUCIEthe Lancaster University Computerised Intelligent Excavator. An excavator provides a good opportunity for development, as it is basically a highly efficient and well developed four degree-of-freedom manipulator arm, but with the complete absence of automation or intelligence. The aim of the project is to add autonomy in order to produce a robot

more »

... or with the following characteristics: 0 It should concentrate on the task of trenching, and be able to produce a good quality and accurate smooth-bottomed trench. It should adapt to different soil types without human intervention. 0 It should cope with obstructions, such as boulders in the trench. 0 It should eventually be a self-contained system with no cables to external computers. Figure 1 -Fifth scale hydraulic model The first stage of the work was sponsored by the U.K. Engineering and Physical Sciences research Council (EPSRC) and involved site studies of the excavation process [Green 19901. The techniques and strategies of skilled drivers were observed and analysed. A working hydraulic fifth-scale model was constructedsee figure 1and this enabled automated digging strategies to be developed in the laboratory. A full-sized rapid prototype was then produced using largely off-the-shelf components The purpose of the prototype was to prove the concept and to further refme the system requirements. A hardware platform was provided by the JCB excavator company in the form of a JCB 801 tracked mini-excavatorsee figure 2. An identical system architecture to the fifth-scale model was adopted which enabled software to be transferred easily from one to the other. The main processor used was a Harris RTX2000 communicating via a standard industrial STE (IEEE 1000) bus. This processor is a high speed device optimised for the FORTH computer language. For more details see [Bracewell 19901 & [Seward 19921. Although the rapid prototype met the initial aims of the project listed above, the solution lacked compactness, robustness and was reasonably expensive in hardware terms. Neither was the rapid prototype mobilei.e. the arm was under computer control but no attempt was made to control the tracks. Figure 2 -The JCB 801 mini-excavator Having shown that the initial aims are realistic it was decided to re-engineer LUCIE in a more robust and professional mannerthe next stage being referred to as a development prototype. The hardware is described in 0-7803-2988-4196 $4.00 0 1996 IEEE 963 Authorized licensed use limited to: Lancaster University Library. Downloaded on December 11, 2008 at 11:49 from IEEE Xplore. Restrictions apply. section 3.0. It was also decided to make LUCIE mobile by extending automation to the tracks. This immediately emphasises the problems of safety with such large and powerful mobile robots. It is the approach to these safety problems that forms the bulk of the remainder of this paper. Basic software architecture One of the most important outcomes of the rapid prototype was the effective high level decomposition of the system into discrete modules. A useful guide to minimising coupling between modules is to consider the points where a human would intervene in the system in the event of a failure. This is shown in figure 3 . The safety manager is not shown connected at this stage as it has a unique status. This is discussed in more detail later. ~ { Navigationmanager \\ Figure 3 .. Top-level decomposition with points of human intervention Two of the above modules, the low-level arm controller and the digging manager will be considered in more detail. The purpose of the low-level arm controller is to take movement commands from the digging manager and send the appropriate control signals to the electrohydraulic valves. Experiments with the fifth-scale model revealed the desirability of a dual control strategy which is closely reflected in the human approach to digging. When moving in air (i.e. tipping the spoil and positioning the bucket teeth) a positional controller is required. The commands from the activities manager thus instruct the bucket to move to specific X,Y,Z coordinates in space. Angle sensors were placed on the arm joints to provide closed-loop control. When moving in soil a velocity controller is required. The commands from the activities manager instruct the tip of the bucket teeth to comply with a particular velocity vector (i.e. speed and direction). This strategy accepts the fact that movement in the ground needs to be highly adaptive as ground conditions change, and that there is little likelhood of reaching a specific point via a predetermined path. Error feedback is used by the activities manager to modify the velocity command in order to optimise performance. Thus if the excavator cannot achieve the demanded velocity because the ground is too hard, the activities manager will direct the low-level controller to attempt a shallower dig where the ground is expected to be softer. This approach has proved very effective in providing pseudo-force feedback without the need of additional force sensors. The low-level arm controller is currently implemented in "C". Of the above high-level modules, it is most difficult to provide an early detailed requirements specification for the digging manager. The digging manager is the module that directs the digging process and has knowledge of the tactics required for efficient operation. To help the prototyping of the digging manager a design platform concept was used. The design platform allows the developers to try out and modify ideas, as well as reacting swiftly to requirements changes in other system components. The aim of the design platform is to provide maximum flexibility without compromising on maintainability. Maintainability is essential not only because of the potentially fast and possibly radical prototyping process, but also because of the unstable nature of developing the system using students. The purpose is to produce a detailed and static specification of the activities manager module. This specification is then used to produce an optimised and well engineered software solution. In order to construct a design platform, it is necessary to have at least a basic understanding of the robotic system and the high level goals of the control software. Most useful intelligent robots will be finite state machines. These are systems which are in one or other particular state of activity depending upon the stimuli received. These stimuli can be as a result of signals from sensors, timers, switches or work instructions from a higher level programme. The stimuli trigger the switch from one state to another. Figure 4 shows a state transition diagram for "digging within reach". The words inside the boxes describe particular states and the words in italics outside the boxes indicate the stimuli that triggers the transition from one state to another. The digging manager is implemented using the well known AI technique of a production system [Seward 1992 ] in ADA. The semi-formalism of this technique assists in making the safety case for the robot. About seventy production rules are required for excavation, but because the system is a finite state machine only a sub-set of the rules needs to be considered within any particular state. 964 Authorized licensed use limited to: Lancaster University Library. Downloaded on December 11, 2008 at 11:49 from IEEE Xplore. Restrictions apply. within-I deg. b coords-OK I conten ts-released nof-full