Computer-Aided Civil and Infrastructure Engineering 19 (2004) 28–41

A Control Architecture for Robotic Excavationin Construction

Q. P. Ha∗

ARC Centre of Excellence in Autonomous Systems (CAS), Faculty of Engineering, The University of Technology,Sydney, PO Box 123, Broadway 2007 NSW, Australia

&

D. C. Rye

ARC Centre of Excellence in Autonomous Systems (CAS), Australian Centre for Field Robotics, The University ofSydney, Rose Street Building J04, 2006 NSW, Australia

Abstract: This article presents a hybrid control archi-tecture developed for robotic excavation. The lower-levelcontrollers are designed using a combination of slidingmode control and fuzzy logic control. Control strategiesat the higher level involve task decomposition in asso-ciation with statecharts, and task execution and verifica-tion. Typical machine tasks are decomposed into subtasksand/or states. Graphical notation is introduced to facili-tate software implementation of the control flow withinstatecharts. For each subtask, a statechart via its states atdifferent priority levels selects to activate a number of cor-responding lower-level controllers as a result from reso-lution of the machine resources and the control and dataflows. The control architecture is designed with a view tomanaging hierarchical complexity, and facilitating the ap-plication of formal verification methods, software reuse,and lower-level control results. Field test results throughthe task of digging a trench are provided to demonstratethe feasibility of robotic excavation in moving toward con-struction automation.

∗To whom correspondence should be addressed. E-mail: quangha@eng.uts.edu.au.

1 INTRODUCTION

The past two decades have witnessed some success-ful applications of advanced robotics and automationtechnologies in construction. Intense competition, short-ages of skilled labor, and technological advances areforcing rapid change in the construction industry, moti-vating increased attention on construction automation.Construction typically involves a number of earthmov-ing machines including excavators. Common excavationoperations in construction include general earthmoving,digging, and sheet piling for removing large amounts ofmaterial, alongside the precisely controlled actions re-quired for trenching and footing formation.

Despite acknowledgment of the rapid progress ofrobotics and automation applications in construction(Gambao and Balaguer, 2002), there have been few ac-tual implementations of robotic excavators. Much of thework on terrestrial excavation has focused instead onteleoperation. Although a number of valuable theoret-ical and experimental contributions have been madeby academics in the field of robotic excavation (see,for example, Singh, 1997; Bradley and Seward, 1998;Ha et al., 1999), autonomous operation of a full-scaleexcavator has not been commercially demonstrated todate.

C© 2004 Computer-Aided Civil and Infrastructure Engineering. Published by Blackwell Publishing, 350 Main Street, Malden, MA 02148, USA,and 9600 Garsington Road, Oxford OX4 2DQ, UK.

A control architecture for robotic excavation 29

The application of robotic technology and computercontrol is an important key to construction industry au-tomation. The usual task of a backhoe excavator is toloosen and remove material from its original location,and to transfer it to another location by lowering thebucket, digging by dragging the bucket through the soil,then lifting, slewing, and dumping the bucket load. Anautonomous excavator can be regarded as a robot havingits arm not fixed relative to the work piece. It plasticallydeforms the work piece (soil) by applying large shearforces, and at the same time is caused to move relativeto the soil by the same large forces. Strategic dig plan-ning and bucket trajectory planning remain importantissues in such a dynamic environment as a constructionsite. While performing a robotic task, the excavator mustchange in an appropriate way the profile of the soil be-ing worked. Moreover, the high variability in soil condi-tions encountered in construction makes robotic excava-tion very much more difficult than conventional robotictasks. Excavation automation is thus a multidisciplinarytask encompassing a broad area of research and devel-opment: planning, monitoring, environment sensing andmodeling, navigation, and machine modeling and con-trol. In addition to the axis control problem at the low-est level (Ha et al., 1999), task planning and executionat higher levels are also important considerations in au-tonomous excavation. Traditionally, a planner is used todetermine a sequence of primitive actions that, when ex-ecuted, will transform the world from an initial state toa goal state. Planning in general is thought to be hierar-chical. Planning, according to Arkin (1998), should alsobe deliberative as it requires relatively complete knowl-edge of the world and uses this knowledge to predict theoutcome of its operations.

This article presents a control architecture for a mini-excavator that is retrofitted as an 8-DOF robotic ex-cavator, as described in Le et al. (1998). At the lowerlevel, fuzzy logic control is used to encapsulate expertexperience for capturing soil in difficult digging condi-tions, in conjunction with sliding mode control to im-prove robustness against control uncertainties. Super-ficially, the key control objective is to fill the bucketin the shortest possible time. The higher-level controlinvolves behavioral/hierarchical control schemes, whichare based on the decomposition of tasks of the roboticmachine into subtasks or states. This approach pro-vides the flexibility to execute complex task spaces us-ing Unified Modeling Language (UML) capsules andstatecharts.

The remainder of the article is organized as follows.Section 2 introduces the experimental robotic exca-vator and its equipment, whereas Section 3 describesthe proposed architecture framework. A rationale forthe decomposition of excavation tasks is presented inSection 4. The structure of higher- and lower-level con-

trol is addressed in Section 5 and field-test results arepresented in Section 6. Finally, a conclusion is given inSection 7.

2 EXPERIMENTAL ROBOTIC EXCAVATOR

A 1.5-ton hydraulically actuated mini excavator is usedas the basis for our experimental work. This machinehas been extensively modified to produce a robot hav-ing eight hydraulic actuators: right and left travel mo-tors, a cab slew motor, and two-way hydraulic cylin-ders on the boom swing, boom, dipper arm, bucket,and back-fill blade axes. Electrohydraulic servovalvesare installed, replacing the original manually actuateddirection control valves. Ancillary equipment added tosupport the servovalves include an accumulator with un-loading valve, solenoid check valves, and an oil-to-airradiator.

The experimental excavator is extensively instru-mented with a number of machine-state and environ-ment sensors. The robotic arm joint angles are measuredusing absolute encoders. The hydraulic system is instru-mented with transducers that measure the actuator pres-sures and the valve spool positions. Strain-gauge forcesensors enable direct force measurement during digging.A commercial time-of-flight laser measurement systemis used to scan the terrain on one side of the bucket,providing a surface profile with 10 mm resolution anda statistical error of ±15 mm within a sensing range of1–8 m. Control is achieved through digital controllers inconjunction with an industrial PC. Figure 1 shows thesensing and control hardware; loop closure is achievedwithin the industrial PC, with the digital controllers pro-viding interface and safety monitoring functionality. Thesystem is fully self-contained, with power derived fromthe excavator’s electrical system.

In addition to data obtained by machine sensors, esti-mation of some inaccessible states is required for controland monitoring purposes. In robotic excavation, it is alsodesirable to estimate the uncertain forces arising frominteractions between the bucket and the soil, and otherexternal disturbances such as friction and load inertiachanges, so as to reject their influence and achieve robustperformance. For this, various estimation techniques canbe used. In Ha et al. (2000), a variable structure systemsapproach to friction estimation and compensation hasbeen applied to electrohydraulic servo systems for exter-nal disturbance rejection in force-and-position control ofthe robotic excavator.

3 ARCHITECTURE FRAMEWORK

Our proposed architecture will be embodied as capsuleand statechart objects within the UML framework for

30 Ha & Rye

Ethernet

Laptop computer , Moni tor

Industr ia l PC

M2000 servo contro l lers

PressureTransducers

Servo valvecontrol ler

Servo valvecontrol ler

CAN bus

D A CA D C

Laser ,GPS,INS and othervisual sensor

Serial l ines

Hydraul iccyl inder

Hydraul iccyl inder

Encoder

TCP/ IP

SSI

...

...

Fig. 1. Excavator system diagram.

real time object-oriented modeling (ROOM) detailed inSelic et al. (1994). This framework provides a suitableabstraction level and well-defined task interfaces. Somenecessary terminology is introduced below:

Capsules are complex, potentially concurrent, andpossibly distributed active architectural components thatinteract with their surroundings through one or moresignal-based boundary objects called ports. A port is apart of the capsule implementation that interfaces withother capsules. Ports realize protocols, which define thevalid flow of information (signals) between connectedports of capsules. Requiring capsules to communicateonly through ports allows for fully encapsulating theirinternal implementations from the environment. Portscan be conjugated to show the incoming and outgoingdirections. Connectors capture the key communicationrelationships between capsules. Statecharts are used toimplement the functionality of simple capsules. Morecomplex capsules combine the statecharts with an in-

ternal network of collaborating sub-capsules or sub-tasks joined by connectors. The state-machine, the sub-capsules, and their connections network represent partsof the implementation of a capsule. Figure 2 shows theproposed machine task architecture with the followingcapsule types:

GUI: Graphical User Interface that allows for inter-actions with the user.

Expert: This capsule will provide all information re-garding decision-making, planning, and execution oftasks according to the goal defined by the user. Addi-tionally, this capsule will involve activation of axis con-trollers that are required for execution of a task. It willalso make recommendations to the conflict resolutioncapsule on how a particular conflict may be resolved.

Conflict resolution: Concurrent execution is supportedwith arbitration provided by the conflict resolution cap-sule. Different types of conflict resolution approaches(command fusion and command arbitration algorithms)

A control architecture for robotic excavation 31

Machine

Conflict Resolution

Sensor Processing

Safety Management

Expert

GUI

Sensor Actuator External World

Control

Task library

Fig. 2. Machine task architecture. (Capsules are representedby the bold rectangles, with ports shown as the light squares

at the capsule boundaries.)

can be found in Pirjanian (1999) and the referencestherein.

Sensor processing: This capsule involves sensor signalconditioning, filtering, and any processing required.

Safety: The safety capsule monitors a health message(ON and OK) from all activated object tasks. If any activetask fails to transmit this message the safety coordinatorcannot send its health message to the safety capsule. Thesafety capsule will set safe values to the output vector.

The machine system developed can include later com-munication modules to send its information in a networkto communicate with other machines. The basic taskstructure can be seen as a task with one upper-level in-terface and zero or lower-level task interfaces, as shownin Figure 3. The structure comprises two capsule types:

Task supervisor: This capsule will provide a mapping ofthe task control policies from the subtasks, based on thecontrol input received through the upper level task in-

TaskSupervisor

Subtask 1 Subtask n

Upper level taskinterface

Sameleveltask

or safetyInterface

Lower leveltask interfaces

SensorInterface

Machine task

Fig. 3. Basic task structure.

terface. The capsule will resolve these policies into com-mands for the subtasks that are under its control. It willalso react to internal events that are sent from the sub-tasks. If its policies cannot be resolved by the subtaskevents, a request will be returned through the upper leveltask interface for proper handling. In some cases the tasksupervisor may require the help of another task of thesame level or may need to send a safety issue to thesafety module, using a fail-safe mechanism. All sensorinformation is received from the sensor interface. Infor-mation acquired can be used by the state-machine fortrigger transitions, situation assessment, and controlleractivation.

Subtasks: These capsules will provide the subtask al-gorithms through one or more subtask interfaces. Theywill also help to resolve any control situation that doesnot require intervention by the task supervisor. For com-plex systems, these subtasks can be further decomposedinto a subtask supervisor and a set of simpler subtasks.

This basic structure can functionally and recursively bedecomposed to whatever depth is necessary, allowing formodeling of arbitrarily complex structures. A complexsubtask is decomposed into simpler subtasks. When thisdecomposition is completed, a subtask can be expressedin terms of sequential and/or concurrent execution ofatomic states. Note that there are two types of atomicstates: one that interacts with the machine controllersand the other that cannot be made simpler by furtherdecomposition.

Furthermore, our basic task structure can be used toprovide levels of authority as presented in Figure 4. Thehighest level can be seen as the machine manager thathas different subtask managers. The lowest level imple-ments the machine controllers. The lower-level task in-terfaces are connected to a conflict resolution moduleand interact with the hardware actuators. The structureshown in Figure 4 is a static representation of executabletasks. A dynamic representation during run time will re-semble a tree, to allow for creating, adding, deleting, andexecuting particular tasks.

Task dataflow is only permitted from level (i) to level(i − 1), within a same level, or between the task super-visor and subtasks by using message passing. The onlyexception is the safety messages that go directly to thesafety capsule from any level.

This conceptual framework can be viewed as a three-dimensional task-composition space where X-axis rep-resents task taxonomy (subtasks shown in Figure 3),Y-axis represents flow of control or subfunctions (recur-sion and statecharts), and Z-axis represents levels of au-thority (Figure 4). All tasks can be represented as nodeswithin this task-composition space.

Inheritance can be used to abstract some of the com-mon classes that will be used to implement robotic

32 Ha & Rye

Conflictresolution

Output vector

TaskSupervisor

Subtask 1 Subtask n

TaskSupervisor

Subtask 1 Subtask n

TaskSupervisor

Subtask 1 Subtask n

Fig. 4. Implementing authority levels.

tasks. For instance an abstract statechart may providesimilar methods required for implementing some roboticfunctionality such as status and basic exception handlingcapabilities.

4 EXCAVATION TASK DECOMPOSITION

4.1 Rationale

In general, a task algorithm describes how the machineshould attempt to reach a specified goal. In task plan-ning, the task algorithm is decomposed into a number of(perhaps hierarchical) subtasks with a predefined orderof execution (relative priority) by combining states oratomic states that do not need to be further decomposed.The basic philosophy behind the proposed control ar-chitecture is summarized as follows. The decompositionshould be formulated such that it can cover all specifica-tions of the task. It follows that a task can also be com-posed from subtasks and sub-states to form a super state(a state of nested states). The proposed architecture canbe considered as a hybrid one combining top-down andbottom-up approaches. It allows for component reuse,and for building complex states if required.

For a descriptive notation, a task of a robotic systemcan be represented as a set of subtasks, with predefinedentry conditions and exit conditions, and a priority ororder of execution determined by a state-machine:

Task = tuple[{subtask1, subtask2, . . . , subtaskn},entry-conditions, exit-conditions,

priority state-machinemain]

Subtasks can be executed sequentially, in parallel, orboth, depending on the information supplied to the state-machine and the priority. Concurrent state-machines canbe seen as threads, so that relative thread priority willdefine the order of execution. The following basic oper-ations applicable to tasks are defined:

Task union, T = T1 ∪ T2, returns a task that is theunion of tasks at a particular level. Entry-conditions,exit-conditions, and a state-machine for the new com-bination need to be supplied. Task unions help to buildmore complex tasks.

Task intersection, T = T1 ∩ T2, returns a task that isthe intersection of tasks at a particular level. Task inter-sections help to identify common subtasks in the staticrepresentation that can be instantiated on the dynamicrepresentation (run-time objects).

Conditional task implies a condition in the form ofa Boolean expression T = Ti if x, where the taskTi will be active only if the Boolean expression xholds.

In the same manner, some properties are defined:Subset: Let STi and Ti be two tasks. Then STi is a

subset of Ti if every element of STi is also an element ofTi.

A control architecture for robotic excavation 33

Equality: Let T1 and T2 be two tasks. Then T1 is equalto T2 if they have the same elements.

Cardinality (or size): It determines the number of dif-ferent elements in a set. It can be used to count the num-ber of subtasks within a defined task. Furthermore, taskcomplexity can be measured as the number of states thatare involved in a task.

Task scope resolution: It returns the absolute path tofind the local state or subtask with respect to the expertmain state-machine.

State-Machine ::= tuple{variables, status,

current state, priority,

entry-conditions, exit-conditions,

substatesi , transitionsi }where,

Status ::= {Off|Idle|Run|Undefined|TimeOut|Exception}

variables used in the state-machine can be seen as pro-gramming language variables, and “current state” is aspecial variable that keeps track of the current state ofthe state-machine. Priority indicates the execution or-der used when scheduling the subtask relative to othersubtasks.

Transition is a special function that monitors the oc-currence of an event. Functions can be defined as entry-conditions, code, or exit-conditions. A function containsthe activated controller’s code and any algorithm re-quired to execute the task at this abstraction level. Theindex “i” takes values from 1 to n.

4.2 Task decomposition for robotic excavation

Here, an excavation task will be decomposed into sub-tasks that are associated with states in UML statecharts,which can overcome the limitations of traditional finitestate-machines while retaining benefits of finite model-ing (Douglas, 1999). A state is linked in real-time withthe machine controllers using information obtained fromsensors and estimators to activate the appropriate con-trollers. Statecharts consist of states, transitions, synchstates, and pseudostates. A state includes the existencecondition of a subtask and its entry and exit actions. Tran-sitions, triggered by the receipt of events, are executed toaccomplish navigation around a statechart. Synch statesare state vertices that help model the synchronization ofcompound tasks or concurrent states. Pseudostates areused as initial, terminal, or transient states that are vis-ited for short periods of time.

The control architecture for our robotic excavator uti-lizes the capsule types described in the previous section.In particular:

Expert: This capsule involves all earthmoving tasksdefined for the excavator, and contains the lower-level controllers that are implemented using model-based sliding mode controllers or fuzzy logic controllers.Details of these low-level controllers will be given inSection 5.

Conflict resolution: For digging hard soil, a conflict mayoccur between activated controllers for the boom, suchthat there is contention between axes for the availablehydraulic power and/or pressure. In that case it is nec-essary to increase the digging force while the boom alsoneeds to be lifted to release hydraulic oil pressure. Thiscapsule is therefore required for properly resolving theconflict.

Sensor processing: Window-average filtering is used tocalculate the track speeds from the encoders; the capsulealso validates operating ranges of the pressure transduc-ers and encoders.

Safety: The safety capsule monitors a health message(ON and OK) from all activated object tasks. If any ofthem fails to send its health message to the safety capsule,then this capsule will set the output vector to 0, closingall hydraulics valves.

In Santos et al. (2000), for the task of digging a trencha task decomposition can be proposed as follows:

Task 1 = Dig a trench of certain dimensions. This exca-vation task is decomposed into:

Subtask 1: Execute a dig cycleState 1: Position bucket in free spaceState 2: Digging soil. The digging portion of the workcycle involves the following states:LowerBoom (S1), Penetrate (S2), Drag (S3), and Cap-ture (S4).State 3: DumpState 4: Feasible to continueState 5: Reposition bucket tip

Subtask 2: Obstacle handlerState 1: Hard soil handlerState 2: Size-particle handlerState 3: Hard-surface handler

Subtask 3: Environment tracking (from the laser sensor)State 1: Surface profilerState 2: Bucket tracking

This task can be expressed in our formal syntax asfollows:

Task 1 = tuple({Subtask 1, Subtask 2, Subtask 3},priority, entry-conditions, exit-conditions,state-machinemain), where

priority = 1,entry-conditions = {TaskSelected, TrenchData, Task

Validated, MemoryAllocated},

34 Ha & Rye

exit-conditions = {TaskFinished, TaskError}.Subtask 1 ::= tuple(functions, priority, entry-

conditions, exit-conditions, state-machinetop1), where

functions = {DoPositionBucketFreeSpace,DoDigSoil, DoDump,DoRepositionBucketTip},

priority = 1,entry-conditions = {TrenchData, LaserData,

InitialPosition},exit-conditions = {Ready2NextDig, OutOfSurface,

SubtaskError}.Subtask 2 ::= tuple(functions, priority, entry-conditions,

exit-conditions, state-machinetop2),Subtask 3 ::= tuple(functions, priority, entry-conditions,

exit-conditions, state-machinetop3).

Consider next the task of dragging the bucket teethalong a surface within 5 cm tolerance. Its decompositionis as follows:

Task 2 = Drag a surface for a certain length:

Subtask 1: Execute a drag cycleState 1: Position bucket in free spaceState 2: Dig in Soil (only states 3 and 4)

Subtask 2: Obstacle handlerState 1: Hard soil handler (not used)State 2: Size-particle handlerState 3: Hard-surface handler

Subtask 3: Environment tracking (laser)State 1: Surface profilerState 2: Bucket tracking (not used).

Note that in general an excavating task can be com-posed by the subtasks that eventually comprise somecommon states or element tasks. These element tasks caninclude “adjust the engine throttle to maintain a constantspeed,” “keep the current position for a certain time,”“curl the bucket inward,” “curl the bucket outward,”“rotate the arm inward,” “rotate the arm outward,” “luffthe boom up,” “luff the boom down,” “swing the boomto the right,” “swing the boom to the left,” “crawl thetracks forward,” “crawl the tracks backward,” “lift theblade up,” “lower the blade down,” “crawl the tracksright,” and “crawl the tracks left.”

A careful and deliberative task decomposition canallow for a reuse of subtasks. To enhance flexibility, astate-machine that runs only part of its states must haveproperly defined transitions. Furthermore, modulescan also be implemented partially and completed laterin an organized fashion. Exception handling uses theimplementation of the abstract state-machine that hasthree states (off, on, and error), inherited by any of theimplemented state-machines. Every time the programthrows an exception, the exception is handled within

that state-machine otherwise it is escalated. In our case,the robotic excavator displays a warning message andstops its operation.

5 LEVEL CONTROL

5.1 Higher-level control

Hierarchical organization of manipulator control is dis-cussed in Koivo (1989), and behavior-based approachesfor robot control are presented in Arkin (1998). A hybridhierarchical-behavioral robotic architecture, developedby Borrelly et al. (1998), has shown high performance ofvarious autonomous machines. In the work on roboticexcavation we propose to combine behavior-based andhierarchical architectures to produce strategies for plan-ning and controlling the machine at higher levels. Practi-cally, excavation tasks can be decomposed into behaviorsthat activate an appropriate set of suitable controllers.Approximate reasoning with “If-then” rules is incorpo-rated to encapsulate human expert knowledge of earth-moving operations. The description of a particular be-havior is based mainly on observation and study of howexpert operators command excavators when digging. Us-ing a hierarchical-behavioral approach, a layered con-trol hierarchy of lower and higher levels is proposed forour control architecture. Lower-level controllers are ac-tivated upon the technical resolution of conflicts and alsoof resource sharing, and the management of the controlflow and the data flow using statecharts, described inDouglas (1999), and rule-based reasoning. At the higher-level control, the proposed hybrid architecture involvescontrol schemes that are based on decomposition of typ-ical excavation tasks into states or state elements. Eachtask is represented by a state in a statechart. Unlike finitestate-machines as proposed by Fok and Fabuka (1991),statecharts allow for component reuse, concurrency, andfor complex nested states (superstates) if required. Astatechart is used to represent a state-machine consist-ing of states and transitions between states, together withsynchronization states and pseudostates. Every state ob-ject has entry and exit actions, and executes the particularbehavior or activity until a transition is set and the stateis exited (Santos et al., 2000). Transition conditions canbe refined to have event priorities if more than one con-dition is true at the same time, or can be seen as if/elseor switch/case structures. For transition between state el-ements, a characteristic function γ i associated with thestate Si is defined here as follows:

γi ={

1, transition from Si to Sj

0, Si is active, i = 1, 2, . . . , r

To illustrate this control architecture, consider the tasksof loading, and of digging a trench to a certain depth.

A control architecture for robotic excavation 35

S1 - Posi t ion bucket t ip

entry: Nul l

exit: Nulldo: RunPosi t ionContro l lers()

Tr0 [StartCommand] / In i t ia l ise()

S2 - Dig in soi l

do: RunDigSubstates( )

do : RunDumpSubSta tes( )

S3 - Dump on Truck

entry: Nul l

exit: Null

entry: Nul l

exit: Null

do: RunPosi t ionContro l lers()

S5 - Reposi t ion bucket t ip

entry: Nul l

exit: Null

S4 - Feasible to cont inue

entry: Nul ldo: Calculate Feasibi l i ty()

exit: Null

Tr1 [AtInit ialPosit ion] / Nul l

Tr2.1 [FinishDig] / SaveTrajectory()

C

Feasible == t rue

T3.1 [OnTrenchAxis] / Nul l

Tr2.2 [Volume >= MinDumpVolume] / Nul l

Tr4[Done]/Feasib le =IsFeasib le() ;

Tr5[Ready] / Nul l

[else]

Tr2.3 [Volume < MinDumpVolume] / Nul l

Fig. 5. A statechart for trench forming.

In truck loading, one pass in the task of removing soilfrom a pile can be decomposed into the sequence ofstates of positioning the bucket with a specified attackangle, penetrating the soil by curling the bucket inward,lifting and swinging the boom, and then dumping soilby curling the bucket outward. Another common con-struction task, that of digging a trench as decomposed inSection 4, can be implemented using the statechartshown in Figure 5, where each subtask (state) cancall for another level of lower authority as seen inFigure 4. The digging portion of the excavation work

cycle and the dump cycle are then considered as sub-states of this statechart, and will be described in thenext section. Transition between task elements is de-termined mainly by deducing whether the digger hasreached a position predetermined according to expertexcavator-operator heuristics by measuring the Carte-sian position error. Environment sensing is obtainedvia laser, GPS, or visual sensors mounted on top ofthe machine (Figure 1) for location and ground pro-filing to assist with task planning prior to a diggingcycle.

36 Ha & Rye

5.2 Lower-level control

The usual role of a backhoe excavator in construction isto loosen and remove material from its original locationand to transfer it to another location by lowering thebucket, digging by dragging the bucket through the soil,then lifting, slewing, and dumping the bucket load. Atthe lowest level in the statechart hierarchy are the stateelements to be used for the control of machine axes. Theactuators driving the boom swing, boom, dipper arm,and bucket attachments of the excavator are axial hy-draulic cylinders, and the flow of hydraulic oil to eachcylinder is regulated by an electrohydraulic servovalve.Feedback from the arm angular position, hydraulic oilpressure, and actuation force are obtained respectivelyvia absolute encoders, pressure transducers, and distur-bance force observers. In moving toward automatic ex-cavation there is a need of accurate position control ofthe bucket tip. For this, kinematic and dynamic models ofexcavators are given in Koivo et al. (1996). These mod-els assume that the hydraulic actuators act as infinitelypowerful force sources. Instead of tracking desired po-sition or force trajectories, interaction control seeks toregulate the relationship between the end-effector po-sition and the force exerted by the bucket on the soil.Impedance control has been proposed in Ha et al. (2000)as providing a unified approach to both unconstrainedand force-constrained motion of an excavator arm. Thebucket tip is controlled to track a desired digging trajec-tory in the presence of environment and system param-eter uncertainties. As a result of the impedance controlstrategy, both the piston position and the ram force ofeach hydraulic cylinder that are required to exert a givenbucket force at a particular position in world space canbe determined. The problem is then to find the controlvoltages that must be applied to the servovalves to trackthese desired commands. A robust sliding mode controltechnique is developed to implement impedance controlfor an excavator using generalized excavator dynamics.The development of these low-level sliding mode con-trollers, where desired dynamics and robust performanceof the closed-loop axis control system are achieved byforcing the system state to remain on a pre-determinedsliding surface, has been described in Ha et al.(2001).

In construction automation, there are many situationswhen the robotic excavator has to operate autonomouslyto handle hard soil, obstacles or the cases when thebucket becomes stuck. Shi et al. (1995) have shown thatknowledge-based control can out-perform model-basedcontrol in these situations. Here, in conjunction with themodel-based controllers, which are required for fast andaccurate tracking of the excavator arm in air and in softto medium soil, this proposed architecture has the capa-

bility of resolving the “hard” soil difficulties by activatingknowledge-based controllers using fuzzy logic inference.Associated with the element tasks τ i of a typical con-struction subtask in a statechart that are mentioned inSection 4, fuzzy logic controllers, FLCi , have been de-veloped and can be activated as low-level controllers inconjunction with the sliding mode controllers. For exam-ple, FLC3 and FLC4 respectively implement the task ele-ments “curl the bucket inward” (τ 3) and “curl the bucketoutward” (τ 4) using the bucket cylinder pressures andthe rate of change of bucket joint angle as inputs, andthe bucket spool valve opening area as the output. Sim-ilarly, FLC5 and FLC6 use the arm cylinder pressuresand arm angular speed as inputs and the arm spool valveopening area as the output to implement the elementtasks “rotate the arm inward” (τ 5) and “rotate the armoutward” (τ 6) (Santos et al., 2000). The rule sets are, ingeneral, heuristically formulated from observing skillfuloperators of earthmoving machines. For instance, the el-ement task τ 5 “rotate the bucket inwards” is controlledby FLC5 using the following rule set:

If (pressure is PL and angular speed is PL) then (spoolis PM)

If (pressure is PL and angular speed is PS) then (spoolis PL)

If (pressure is PL and angular speed is ZR) then (spoolis PL)

If (pressure is PM) then (spool is PL)If (pressure is PS) then (spool is PL)If (pressure is ZR) then (spool is PM),

where the linguistic labels are defined as PL = posi-tive large, PM = positive medium, PS = positive small,ZR = zero, NS = negative small, NM = negativemedium, and NL = negative large, and the pressure, an-gular speed, and spool position are referred to the bucketaxis. The center of gravity method is used for defuzzifi-cation. Weights can be incorporated within each fuzzyrule to allow for enabling or disabling, and for furtheradjusting rule activation if required.

6 FIELD TEST RESULTS

Experiments have been performed using a robotic1.5-ton mini-excavator. Data acquisition and control al-gorithms are written in C++ and executed under theWindows NT operating system. The sampling time ischosen to be 10 ms, and data are communicated betweenthe five control system processors by message-passingover a CAN bus at 250 kbit/s. The control hardware or-ganization and machine equipment are reported in Leet al. (1998). Some typical excavation tasks in construc-tion can be executed to demonstrate automation.

A control architecture for robotic excavation 37

0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 2.4-1.1

-1

-0.9

-0.8

-0.7

-0.6

-0.5

-0.4

-0.3

-0.2

Z (m

)

X(m)

Digging trajectory

s1

s2

s3

s4

A

B C

D

E

Fig. 6. Bucket tip trajectory, digging “soft” soil.

In this section, the proposed control architecture forrobotic excavation is demonstrated through trench form-ing, a common task in construction. The average task du-ration for a single-pass digging portion of the trenchingcycle is 15 seconds, which is an average time for a humanoperator to complete this task. The recorded data for theentry and exit points of the dragging phase are utilizedto generate the desired trajectory in joint space for thenext digging cycle. Assume that the digging portion of theexcavation work cycle is to be executed. The correspond-ing state “S2-Dig in soil” then involves five main statesSi, i = 1, . . . , 5: LowerBoom (S1), Penetrate (S2), Drag(S3), Capture (S4), and LoadToTruck (S5). For illustration,the implementation of state S4 Capture is described here.The entry conditions that the arm is fully contracted orthe bucket is full or the bucket tip is out of the soil statedin the transition for this state must be true. Then state S4

will be executed by running the associated lower-levelcontroller. If the bucket is horizontal in the case of fullbucket filling, then the transition condition for S5 is trueand the next state LoadToTruck will be executed. Addi-tionally, a time-out transition is implemented so that ifthe bucket gets stuck or cannot finish the dig in an allo-cated time, the rule base will activate knowledge-basedcontrollers or provide a new strategy to remedy the sit-

uation. This strategy could be discarding the contents ifthe captured soil volume is less than 50% or else goingto state S5. Field tests have been conducted that involvetrenching in soils categorized as “soft,” “medium,” and“hard.” The recorded data for the entry and exit pointsof the dragging phase are employed to generate the de-sired trajectory in joint space for the next digging cycle.Figures 6–8, show the measured Cartesian trajectory ofthe bucket tip corresponding to each phase for thesecategories, respectively. In the figure, segments AB, BC,CD, and DE correspond respectively to the previouslydefined phases S1, S2, S3, and S4. In the absence of hardinclusions, the tip motion during the dragging phase isobserved in Figures 6 and 7 to satisfy a desired toler-ance of 5 cm. Figure 8 shows that the bucket teeth can-not, however, penetrate “hard” soil smoothly becausethe required soil cutting force exceeds the excavator’sforce capacity. The bucket must then be lifted, and thesurface scratched with the bucket teeth to loosen the soilunderneath.

Figures 9–11 show the hydraulic pressures measuredat the head side (solid line) and rod side (dashed line)of the bucket (top), arm (middle), and boom (bottom)cylinders for the cases of digging soft, medium, and hardsoil, respectively. The force generated by each cylinder

38 Ha & Rye

Fig. 7. Bucket tip trajectory, digging “medium” soil.

Fig. 8. Bucket tip trajectory, digging “hard” soil.

A control architecture for robotic excavation 39

0 5 10 15 20 25-5

0

5

10

15

Buc

ket

pre

ssu

re[M

Pa]

Time [s]

HeadRod

0 5 10 15 20 250

5

10

15

20

Arm

pre

ssu

re[M

Pa

]

Time [s]

HeadRod

0 5 10 15 20 250

5

10

15

Boo

m p

res

sure

[MP

a]

Time [s]

HeadRod

Fig. 9. Hydraulic cylinder pressure measurements during trenching “soft” soil.

0 5 10 15 20 25-5

0

5

10

15

Bu

ck

et

pre

ss

ure

[MP

a]

Time [s]

HeadRod

0 5 10 15 20 250

5

10

15

20

Arm

pre

ss

ure

[MP

a]

Time [s]

HeadRod

0 5 10 15 20 250

5

10

15

20

Bo

om

pre

ss

ure

[MP

a]

Time [s]

HeadRod

Fig. 10. Hydraulic cylinder pressure measurements during trenching “medium” soil.

40 Ha & Rye

0 5 10 15 20 25 30-5

0

5

10

15

Bu

ck

et

pre

ss

ure

[MP

a]

Time [s]

HeadRod

0 5 10 15 20 25 300

5

10

15

20

Arm

pre

ss

ure

[MP

a]

Time [s]

HeadRod

0 5 10 15 20 25 300

5

10

15

20

Bo

om

pre

ss

ure

[MP

a]

Time [s]

HeadRod

Fig. 11. Hydraulic cylinder pressure measurements during trenching “hard” soil.

can be estimated approximately from the pressure dif-ference across the cylinder. It is observed that diggingmedium and hard soil requires large forces, as one wouldexpect. The marked differences, observed in the oil pres-sure measurements of Figures 9–11 when trenching soilwith various stiffness, correspond to only slight varia-tions in the bucket tip trajectories for three differentkinds of soil.

7 CONCLUSION

In this article we have proposed a control architecturefor robotic excavation with the construction automationfocus. A formal and graphical architecture frameworkbased on UML statecharts and capsules has been de-veloped and applied to the autonomous execution ofsome excavation tasks of a hydraulically actuated roboticexcavator. The control architecture is designed with aview to managing hierarchical complexity, and facilitat-ing the application of formal verification methods, soft-ware reuse, and lower-level control results. For higher-level control, behavioral and hierarchical approaches arecombined for decomposition and execution of some ex-cavation tasks.

At the lower level, fuzzy logic and sliding mode con-trol are used in conjunction to achieve robustness ofthe closed-loop axis control system and to capture ex-pert experience when handling unmodeled situationsencountered in digging hard soils. Field tests of dig-ging various types of soil show promising results. Atthis stage relatively hard soil and some included hardobstacles can successfully be handled. It is believedthat the methodology can be extended to coordinatedcontrol of complicated autonomous machines at manyscales and with a variety of distinct dynamic operatingregimes. The experimental results described here sug-gest the technical feasibility of achieving autonomousrobotic excavation in moving toward constructionautomation.

ACKNOWLEDGMENTS

This work is supported, in part, by the ARC Centreof Excellence programme, funded by the AustralianResearch Council (ARC) and the New South WalesState Goverment. Assistance during field tests pro-vided by Dr. Q. H. Nguyen and M. Santos is gratefullyacknowledged.

A control architecture for robotic excavation 41

REFERENCES

Arkin, R. C. (1998), Behaviour-Based Robotics, MIT Press,Cambridge, MA.

Borrelly, J. J., Coste-Maniere, E., Espiau, B., Kapellos,K., Pissard-Gibollet, R., Simon, D. & Turro, N. (1998), TheORCCAD architecture, International Journal of RoboticsResearch, 17(4), 338–59.

Bradley, D. V. & Seward, D. W. (1998), The development,control and operation of an autonomous robotic excavator,Journal of Intelligent and Robotic Systems, 21, 73–97.

Douglas, B. P. (1999), Real-time UML: Developing EfficientObjects for Embedded Systems, 2nd edn., Addison-Wesley,MA.

Fok, K. Y. & Fabuka, M. R. (1991), An automatic navigationsystem for vision-guided vehicles using a double heuristicand a finite state machine, IEEE Transactions on Roboticsand Automation, 7(1), 181–8.

Gambao, E. & Balaguer, C. (2002), Robotics and automationin construction, IEEE Robotics and Automation Magazine,9(1), 4–6.

Ha, Q. P., Nguyen, Q. H., Rye, D. C. & Durrant-Whyte, H. F.(1999), Force and position control of electrohydraulic posi-tion systems of a robotic excavator, in Proceedings of 16thInternational Symposium on Automation and Robotics inConstruction, Madrid, Spain, 483–9.

Ha, Q. P., Nguyen, Q. H., Rye, D. C. & Durrant-Whyte,H. F. (2000), Impedance control of a hydraulically-actuatedrobotic excavator, Automation in Construction, 9, 421–35.

Ha, Q. P., Nguyen, Q. H., Rye, D. C. & Durrant-Whyte, H. F.(2001), Fuzzy sliding mode controllers with applications,IEEE Transactions on Industrial Electronics, 48(1), 38–46.

Koivo, A. J. (1989), Fundamentals for Control of Robot Ma-nipulators, John Wiley & Sons, New York.

Koivo, A. J., Thoma, M., Kocaoglan, E. & Andrade-Cetto, J.(1996), Modeling and control of excavator dynamics duringdigging operation, Journal of Aerospace Engineering, 9(1),10–18.

Le, A. T., Nguyen, H. Q., Ha, Q. P., Rye, D.C., Durrant-Whyte,H. F., Stevens, M. & Boget, V. (1998), Towards autonomousexcavation, in A. Zelinsky (ed.), Field & Services Robotics,Springer-Verlag, London.

Pirjanian, P. (1999), Behavior Coordination Mechanisms—State-of-the-art, Technical Report IRIS-99-375, Institute forRobotics and Intelligent Systems, School of Engineering,University of Southern California.

Santos, M., Ha, Q. P., Rye, D. C. & Durrant-Whyte, H. F. (2000),Global control of robotic excavation using fuzzy logic andstatecharts, in Proceedings of 17th Symposium on Automa-tion and Robotics in Construction, Taipei, Taiwan, 595–65.

Selic, B., Gullekson, G. & Ward, P. (1994), Real-Time Object-Oriented Modeling, John Wiley & Sons, New York.

Shi, X., Wang, F. Y. & Lever, P. J. A. (1995), Task and behaviourformulations for robotic rock excavation, in Proceedings ofthe IEEE International Symposium on Intelligent Control,Monterey, CA, 248–53.

Singh, S. (1997), The state of the art in automation of earthmov-ing, ASCE Journal of Aerospace Engineering, 10(4), 179–88.