The CLARAty Ar chitecture for Robotic Autonomy�

RichardVolpeIssaNesnasTaraEstlin

DarrenMutzRichardPetras

Hari Das

JetPropulsionLaboratoryCaliforniaInstituteof Technology

Pasadena,California91109Phone:818-354-4321

Email: firstname.lastname@jpl.nasa.gov

Abstract— This paperpresentsan overview of a newly de-velopedCoupledLayer Architecturefor RoboticAutonomy(CLARAty), which is designedfor improving themodularityof systemsoftwarewhile moretightly couplingthe interac-tion of autonomyandcontrols. First, we framethe problemby briefly reviewing previouswork in thefield anddescribingtheimpedimentsandconstraintsthatbeenencountered.Thenwe describewhy a freshapproachof the topic is warranted,and introduceour new two-tiereddesignasan evolutionarymodificationof theconventionalthree-level roboticsarchitec-ture. Thenew designfeaturesa tight couplingof theplannerandexecutive in oneDecisionLayer, which interactswith aseparateFunctionalLayerat all levelsof systemgranularity.TheFunctionalLayeris anobject-orientedsoftwarehierarchythatprovidesbasiccapabilitiesof systemoperation,resourceprediction,stateestimation,andstatusreporting. The Deci-sionLayerutilizesthesecapabilitiesof theFunctionalLayerto achieve goalsby expanding,ordering,initiating and ter-minatingactivities. Bothdeclarativeandproceduralplanningmethodsareusedin this process.Currentefforts aretargetedat implementingan initial versionof this architectureon ourresearchMars rover platforms,Rocky 7 and8. In addition,we areworking with theNASA roboticsandautonomycom-munitiesto expandthe scopeandparticipationin this archi-tecture,moving toward a flight implementationin the 2007time-frame.

TABLE OF CONTENTS

1. BACKGROUND OF THIS EFFORT2. THE CHALLENGE3. THE CLARATY ARCHITECTURE4. IMPLEMENTATION5. SUMMARY6. ACKNOWLEDGMENTS

1. BACKGROUND OF THIS EFFORT

History Outsideof JPL

The developmentof RoboticsandAutonomyarchitectureisasold asthefield itself. Therefore,it is not possiblehereto�

0-7803-6599-2/01/$10.00c�

2001IEEE

completelyreview the body of work uponwhich this effortbuilds. Instead,wewill simplydescribesomeof themorere-centor dominanttrendsinfluencingthenew architecturepre-sentedin this document.

Efforts in robotic architectureshave largely arisenfrom apragmaticneedto structurethesoftwaredevelopmentfor easeof systembuilding. As such,they have grown in scopeandcomplexity asthecorrespondingsystemshave grown. Earlyefforts concentratedin detailedsoftware packages[19], orgeneralframeworks [2]. Only in the last decade,with theemergenceof fast computerswith real-timeoperatingsys-tems,haveinfrastructuresbeendesignedasopen-architecturecontrollersof modernrobotsystems[33][28][10].

In parallel with robot control efforts, artificial intelligencesystemsfor planning/schedulingand executionwere devel-oped which relied on underlying closed-architecturerobotcontrollers[15][30]. The tendency of thesesystemsto beslow and computationallycostly led to the emergenceof aminimalist schoolof thoughtusing Behavior Control [11].But with fastercontrol layersavailable,anda generaldesireto leverageplanningfunctionality, newer systemsimplementamulti-tieredapproachthatincludesplanning,execution,andcontrolin onemodernsoftwareframework [1][3].

While theseend-to-endarchitectureshave beenprototyped,someproblemshave emerged. First, there is no generallyacceptedstandard,preventingleverageof theentirecommu-nity’s effort. This problemhasleadto the second,which isthatimplementedsystemshavetypically emergedasa patch-work of legacy andothercodenotdesignedto work together.Third, roboticsimplementationshave beenslow to leveragethelargerindustrystandardsfor object-orientedsoftwarede-velopment,within the Unified Modeling Language(UML)framework. Therefore,we believe the time is ripe to revisitroboticsandautonomyefforts with fresheffort aimedat ad-dressingtheseshortcomings.

History Insideof JPL

The JetPropulsionLaboratory, California Instituteof Tech-nology (JPL) hasa long history in building remotelycom-mandedandcontrolledspacecraftfor planetaryexploration.

Mostof thiseffort hasconcentratedonverysimpleandrobustexecutionof linear sequencestediouslycreatedby groundcontrollers. Areaswhereexpertisehasconcentratedon so-phisticatedon-boardclosedloop control have beenlargelyoutsideof the traditionalareasof robotics,falling insteadintherealmof aerospaceguidanceandnavigation. Further, theimplementationof thesesolutionshavebeenin handtailoredsoftwaresolutions,optimizedfor specificspacecraftandlim-ited CPU and memory. Only more recentlyhave conceptsfrom roboticsandautonomystartedto beusedor consideredfor flight missions[25][24].

Therefore,thehistoryof roboticefforts at JPLhasbeenpri-marily within the researchprogram. The oldestof theseef-forts werein theareasof manipulatorandteleoperationsys-tems,andhadlimited softwareor softwarearchitecturecom-ponents[8]. Oneof the first major softwarearchitectureef-forts was within the TeleroboticTestbed,a large researcheffort for developingautonomous,multi-robot, satelliteser-vicing [7]. While a very complex systemconformingto theNASREMarchitecture[2], it reliedonseveralsubsystemsus-ing disparatesoftwareparadigms.Exceptthroughthediffuseefforts of the individual researchparticipantsand their sub-sequentassignments,little of thissoftwarestructuresurvivedthedemiseof theTestbed.Afterward,many smalleron-orbitmanipulatorresearchprojectsexisted, eachwith their ownsoftwareimplementation:RemoteSurfaceInspection(C andVxWorks), Satellite Servicing (C and assembly),MOTES(Ada and VxWorks), etc. [36][9][5]. Eachof theseeffortsprovided parallel duplication of similar functionality withminimal codesharingdueto architecturaldifferences.

In parallel with theserobot manipulationefforts were sev-eral mobile robot efforts, eachdeveloping software infras-tructurein relative isolation. At aboutthe sametime astheTestbed,therewas the developmentof a large Mars RoverplatformnameRobby, usingC andVxWorks[38]. Researchwith Robbyendedastherewasa paradigmshift from largeroverswith softwarefor deliberativesensingandplanning,tosmallroverswith reactivebehaviors[18]. Thefourthof these“Rocky” vehicles,programmedin C andForthwithoutanun-derlyingoperatingsystem,soldtheconceptof placingtheSo-journerroveron thePathfinderMission.However, Sojourneritself was programmedwith software written from scratch,not inheritedfrom its predecessors.

Only asSojournerwasbeingbuilt did new roverresearchbe-gin to addressthe problemof providing a software infras-tructurewith modularity, reconfigurability, andcodere-useimplicit in the design. To this end, a new rover, Rocky 7,wasbuilt, andits developmentteamselectedtheControlShellC++ software developmentenvironmenthoping to set it asa new standard[28][35]. But assubsequentresearchroverefforts were started,a new spectrumof control infrastruc-turesre-emergedin rover tasks(e.g. FIDO, DARPA TMR,Nanorover, etc),similar to thesituationseenin manipulationtaskshalf adecadebefore[27][41][34].

In thesametime-frameastheconstructionof SojournerandRocky 7 therewasa largescaleeffort in AutonomyandCon-trol for flight, but targetedfor cruiseandorbit, not surfaceoperations.Underthe aegis of the DeepSpaceOneproject

andlaterrenamedtheRemoteAgentExperiment(RAX) [25],this wasa collaborativeeffort betweenJPLandNASA AmesResearchCenter(ARC). Emerging from it, was a determi-nationat JPL to build a fundamentallynew softwarearchi-tecturefor all futuremissions,namedtheMissionDataSys-tem [13]. MDS is a state-based,object-orientedarchitec-turethatmovesawayfrom previousmissioncontrolconceptswhich aresequence-based.While it wasoriginally targetedfor orbital insertionandouter-planetmissions,it is now ad-dressinga Marssurfacemissionschemefor its first applica-tion.

Therefore,giventhelargeefforts in softwarearchitecturede-velopmentat JPLundertheMDS flag, andgiventhehistoryof dividedefforts in theroboticsresearchcommunity, it is theobjective of authorsof this report to put forth a new frame-work for robotsoftwareat JPLandbeyond. This reportout-linestheresultsfor thefirst year, describingthebroaddesignof the resultantCLARAty architecture,providing someini-tial implementationefforts, and outlining the directionsforupcomingconstructionof end-to-endrover control softwareunderthis new framework.

2. THE CHALLENGE

Having briefly reviewed the history of robot control archi-tectures,it is apparentthat more work is required. In thissectionwe will summarizethe impedimentsto successthathave existed in the past,outline the reasonsfor attemptingto overcomethemwith a new architecture,anddescribetheconstraintson thesolutionto beprovided.

Impedimentsto Success

Thereare numerousimpedimentsto the successof controlframeworksfor roboticssystems.Thesemaybecategorizedasfollows:

ProgrammaticVision— Implicit in the successof any re-searchendeavor is the needto sustainthe effort with fund-ing, especiallyearlyin its development.Typically it hasbeendifficult to maintainsignificantresearchfunding for controlarchitecturedevelopment.This is primarily becausethe endproductis infrastructure,notanew robotsystemoralgorithm.While this new infrastructuremight enablebetteror fastersystemandalgorithmdevelopment,suchindirectresultshavebeendifficult to sell programmatically.

Not InventedHere (NIH) — For themostpart,autonomyandrobotic systemsarestill in the domainof researchproducts,andnotcommercialproducts.Therefore,it is typical for eachresearchteamto want to develop and grow its own prod-ucts. This expressestheir inventiveness,as well as givingtheir work a uniquesignatureusedin promotionof their re-sults.

Fearof unknownproducts— Closelytied to NIH, is thefactthatresearchproductsfrom outsideof one’s teamhave vary-ing and unknown levels performance,quality, and support.Therefore,useof other’sproductsmightnotonly diluteone’sresearchidentity, but consumevaluableeffort while trying to

adoptthem.

Flexibility — Also, becauseof the research nature ofrobotics,thereis still no absoluteconsensuson how to bestsolve theproblemsthatexist, or evenwhich arethemostim-portantproblemsto solve. Therefore,researchersoften de-sire maximumflexibility from their hardwareandsoftware,to meetthe specificneedsof new projects. This desireforflexibility is oftenat oddswith any softwareframework thatis not specificallytailoredto thetask.Simply put,no onear-chitecturecanbe optimal for all problems,andif oneis tooflexible it quickly losesany structurethatgivesit value.

Overhead— Oftencoupledtoadesirefor flexibility is aneedto optimizeperformance.Thiscomesin theform of computa-tionaloverheadfor therobotsystem,aswell assystembuild-ing overhead,encounteredin theuseof softwaredevelopmentproductswhichareunfamiliaror unwieldy.

Critical Mass— Evenif anew softwareinfrastructureis rec-ognizedasbeingvaluable,that valuemight not be realizedunlessa large enoughgroupof researcherschoosesto stan-dardizearoundit. Oncesuchagroupexistsandprovidescrit-ical mass,thestandardenablesmucheasierexchangeof ideasandsoftware,which in theorycan“snowball”. However, it isa difficult decisionfor any oneresearchteamto join a newstandarduntil critical masshasbeenreached.This is becauseany externalstandardwill requireoverhead,while the bene-fits mayonly comeaftercritical massis achieved.

LearningCurve— Humannatureandconservative logisticsof any researchprogramprovide a resistanceto abandoningwell known and understoodmethodsfor new onesthat re-quire an investmentof time to learn. This is especiallytruewhen projectsare on short developmentcycles, which hasbeenmoretruein recentyears.

TechnicalVision— Becausemost researchershave had todevelopinfrastructureto build theirsystems,they havedevel-opedopinionsabouttheir preferredsolutions. While manymaybewilling to abandonthesesolutionsin favor of anex-ternalproduct,somewill surelyhaveatechnicalvisionwhichis atoddswith externalproducts.Dependingon thestrengthsof their convictions,theseresearchersmaynot join thelargercommunityin theuseof anexternalarchitecturestandard.In-dependentof theimplicationsfor their own research,thelossof their participationis likely to be detrimentalto the com-munity.

Needsfor a New Start

Giventheseimpedimentsto theacceptanceof a unifying ar-chitecture,onemaywonderwhy thereshouldbean impetusfor its creation.The primary reasonis thatwhich drivesthedesirefor roboticsin thefirst place:eliminationof the needfor peopleto wastetheir time on lesserendeavors. Therearethreepathsto this goal.

1. Elimination of duplicative efforts which prevent attain-mentof critical mass:

Parallel Duplication— As previously discussed,there areoftenduplicativeeffortswithin bothroboticmanipulationandmobility research.Thisdiminishesthefinal productsby wast-ing resourceson solving the sameproblems,with differentinfrastructure,at thesametime.

SerialDuplication— It is alsoevident that asnew researchtasksstart, they often wipe the slatecleanto eliminateoldsystemproblemsandlack of familiarity or trust with previ-ousproducts.Typically, theonly softwarewith legacy is duesolely to a singleindividual, not thelocal community. Obvi-ously, without theability to bridgeto groupownership,trans-fer outsideof institutionsis evenmorerestricted.

2. Follow softwarecommunitylead:

Opensourcemovement— The valueof sharedsoftwarehasbeen dramatically illustrated by Linux, GNU, and othershare/freewareproducts.Typically thishasexistedwithin thedesktopPC market, but thereis no obvious reasonwhy thismodel cannotbe leveragedby software within the roboticscommunity. As evidenceof this fact,therehasrecentlybeenan announcementfor Intel sponsorshipof an open sourceComputerVisionLibrary [20].

Object-orienteddesign— Complementaryto theopensourcemovement,hasbeenthegrowth of object-orienteddesignforPCsoftware.In muchof thecommercialsoftwareindustryitdominates.However, this paradigmis largely under-utilizedin robotics,isolatingthe community. Further, it promisestobetterfacilitatesoftwaresharing,discussednext.

3. Leveragecomplimentaryefforts:

Softwaresharing— To build critical massamongsta world-widebut relatively smallroboticscommunity, it wouldbeex-tremelybeneficialto haveanarchitectureframework thatwaswidely accepted.Not only would this enableeasiersharingof designconcepts,but, more importantly, it would enablethe direct transferof software to all parties. Even sharingamongstthe limited communitiesof JPL andNASA is cur-rently arduousand thereforerare. A first stepwould be toeliminatethesehurdlescompletely.

MissionDataSystemandX2000— Recently, NASA hasin-vestedheavily in large scaleefforts in spacecrafthardware(X2000) andsoftware (MDS) which promisean infrastruc-tureto beleveragedandexpanded[39][13]. It is to thebene-fit of NASA roboticsefforts to leveragetheseproductswhereapplicable.Sincethespacecraftcontrolproblemis verysimi-lar to thegeneralroboticsproblem,it is anticipatedthatthereis much to be gainedby this leveraging. Obviously othersourcesof relevant technologywill exist outsideof this lim-itedset,andwill alsobeincorporatedwhenapplicable.

Constraintson theSolution

Given theseneeds,there are several issuesthat will con-strainthesuccessof anarchitecturalsolution.First, thereis aneedfor communityacceptance.Without acceptanceby theroboticsandautonomycommunity, both from usersandde-

velopers,therecannotbeasuccess.Full acceptanceis proba-bly not� possible,or evendesirablein agrowing researcharea.However, asdescribedpreviously, it is importantto reachalevel of critical mass,sothatusersanddevelopersgainmorethanthey losefrom adherenceto standardsandparticipationin softwareexchange.

Second,it is vital to spanthe many divideswithin the nec-essaryuseranddevelopercommunities.Thesedividesexistin many forms,betweenandwithin roboticsandAI researchareas.They canresultfrom a desireto solve differenttypesof roboticsproblems,all theway from partsassemblyto hu-manoidinterfaces. Or they canresult from an emphasisondifferent phasesof product life cycles, from basicresearchto fieldedsystems.Within andacrossinstitutions,thediffer-encescanbeculturalaswell, spanningdepartmentsfrom me-chanicalengineeringto computerscience,andorganizationsfrom academiato commercialcompanies.

Third, thereis a desireto leverageexisting software in re-searchandNASA flight efforts. In particular, atJPLtherehasbeena substantialeffort in thenew MDS, which is very sim-ilar to the architecturework describedherein,but hasbeenlargely focusedon the problemsof zero-gravity spacecraft,not robotsoperatingon planetarysurfaces.

Finally, it is a requirementto leveragestandardpracticesinindustry. This is neededto avoid reinventionof the wheel,and enableNASA roboticsefforts to adopt techniquesandsolutionscommonlyemployed in commercialproducts,andwithin theglobalsoftwarecommunity.

3. THE CLARATY ARCHITECTURE

In responseto theseneedsandrequirementswe have devel-opedtheinitial framework for anew AutonomousRobotsoft-ware architecture. Due to its structure,it is call the Cou-pledLayerArchitecturefor RoboticAutonomy, orCLARAty.Thissectionwill review this new structure,andits evolution-ary differencesfrom its predecessors.It will introducethetwo layersof thearchitectureandprovideanoverview of theinteractionbetweenthem.

Review of Three-LevelArchitecture

Typical robot andautonomyarchitecturesarecomprisedofthree-levels— Functional,Executive, andPlannerasshownin Figure1 [17][31][1].

The dimensionalong eachlevel can be thought of as thebreadthof the systemin termsof hardwareandcapabilities.Thedimensionup from onelayer to thenext canbethoughtof asincreasingintelligence,from reflexive,to procedural,todeliberative. However, theresponsibilitiesandheightof eachlevel arenot strictly defined,andit is moreoftenthannot thecasethat researchersin eachdomainexpandthe capabilitiesanddominanceof the layer within which they areworking.The resultaresystemswherethe FunctionalLayer is dom-inant [29][37][23], or the executive is dominant[31][10] orthe the planneris dominant[15][14]. Further, thereis stillconsiderableresearchactivity which blurs the line between

Planner

Executive

Functional

SYSTEM

INT

EL

LIG

EN

CE

Figure1. Typical three-level architecture.

PlannerandExecutive,andquestionsthehierarchicalsuperi-ority of oneover theother[21][16].

Anotherproblemwith this descriptionis lack of accessfromthe Plannerto the Functional Level. While this is typi-cally thedesirableconfigurationduringexecution,it separatesthe plannerfrom information on systemfunctionality dur-ing planning. Oneconsequenceis that Plannersoften carrytheir own separatemodelsof the system,which may not bedirectly derived from the FunctionalLevel. This repetitionof informationstorageoftenleadsto inconsistenciesbetweenthetwo.

A third problemwith this descriptionis theapparentequiva-lenceof theconceptsof increasingintelligencewith increas-ing granularity. In actuality, eachpart canhave its own hi-erarchywith varying granularity. The FunctionalLayer iscomprisedof numerousnestedsubsystems,theexecutivehasseveraltreesof logic to coordinatethem,andtheplannerhasseveral time-linesandplanninghorizonswith differentreso-lution of planning.Therefore,granularityin thesystemmaybe misrepresentedby this diagram. Worse, it obscuresthehierarchythatcanexist within eachof thesesystemlevels.

ProposedTwo-LayerArchitecture

To correct the shortfalls in the three-level architecture,weproposean evolution to a two-tiered Coupled Layer Au-tonomousRobotArchitecture(CLARAty), illustratedin Fig-ure2. This structurehastwo majoradvantages:explicit rep-resentationof thesystemlayers’granularityasathird dimen-sion1, and blendingof the declarative and proceduraltech-niquesfor decisionmaking.

The addition of a granularitydimensionallows for explicitrepresentationof the systemhierarchiesin the FunctionalLayer, while accountingfor the de factonatureof planninghorizonsin theDecisionLayer. For theFunctionalLayer, anobject orientedhierarchydescribesthe system’s nesteden-

�The conventionemployed hereis to considerlower granularityto mean

smallergranulesizes.

FunctionalSYSTEM

INT

EL

LIG

EN

CE

GRANULARITY

Executive

PlannerCOMMON DATABASE

Figure2. Proposedtwo-layerarchitecture.

capsulationof subsystems,andprovidesbasiccapabilitiesateachlevel of thenesting.For instance,acommandto “move”could be directedat a motor, appendage,mobile robot, orteam. For the DecisionLayer, granularitymapsto the ac-tivities time-linebeingcreatedandexecuted.Due to thena-tureof thedynamicsof thephysicalsystemcontrolledby theFunctionalLayer, thereisastrongcorrelationbetweenitssys-temgranularityandthetime-linegranularityof theDecisionLayer.

The blending of declarative and proceduraltechniquesinthe DecisionLayer emergesfrom the trendof PlanningandSchedulingsystemsthat have Executive qualitiesand viceversa[31][14]. This hasbeenafforded by algorithmic andsystemadvances,as well as fasterprocessing. CLARAtyenhancesthis trendby explicitly providing for accessof theFunctionalLayerathigherlevelsof granularity, thuslessfre-quently, allowing moretime for iterative replanning. How-ever, it is still recognizedthat there is a need for proce-dural systemcapabilitiesin both the Executive interfacetothe FunctionalLayer, as well as the infusion of proceduralsemanticsfor plan specificationand schedulingoperations.Therefore,CLARAty hasa singledatabaseto interfacePlan-ningandExecutiveFunctionality, leveragingrecentefforts tomergethesecapabilities[16].

Thefollowingsectionswill developtheseconceptsby provid-ing anoverview of featuresof boththeFunctionalandDeci-sionLayers,aswell astheconnectivity betweenthem.

TheFunctionalLayer

The FunctionalLayer is an interfaceto all systemhardwareand its capabilities,including nestedlogical groupingsandtheir resultantcapabilities. Thesecapabilitiesare the inter-facethroughwhich theDecisionLayerusesthe roboticsys-tem. Figure3 shows a very simplifiedandstylistic represen-tationof theFunctionalLayer. TheFunctionalLayerhasthefollowing characteristics:

Object-Oriented— Object-orientedsoftwaredesignis desir-ablefor severalreasons.First, it canbestructuredto directly

............

......

...

...

HARDWARE

ENVIRONMENT

robot

motor sensor cameraswitch

A2D digital IO framegrabber

joint�

locomotor

linkage stereo

arm mastwheel

team

manip.

Figure3. ProposedFunctionalLayer.

SYSTEM

My Rover ’sArm

My Rover ’sLocomotor

GRANULARITYMy Rover

AB

STR

AC

TIO

N

Appendage

Locomotor

Rover

Motor

Robot

CoordinatedSystem

Figure 4. SimpleexampleillustratingobjecthierarchyandClassinheritanceconcepts.

matchthenestedmodularityof thehardwarein a roboticsys-tem. Second,at all levels of this nesting,basicfunctional-ity and stateinformation of the systemcomponentscan beencodedandcompartmentalizedin its logical place. Third,properstructuringof thesoftwarecanuseinheritanceproper-ties to managethe complexity of the softwaredevelopment.Finally, this structurecanbegraphicallydesignedanddocu-mentedusingtheUML standard.

Figure 4 gives a simplified description of the Object-Hierarchyfound in the FunctionalLayer. In this diagram,afourth Abstractiondimensionhasbeenaddedto illustratetheinheritancestructureof the classesin the FunctionalLayer.At the bottom,a rover objectaggregatesarm andlocomotorobjects. While theseobjectscomprisea specificMy Rover

system,eachis derivedfrom parentclasseswhich aremuchmore� general.

An advantageof this structureis that it makessystemexten-sionmucheasier. First, multiple copiesof theobjectscanbeinstantiated(e.g. two copiesof My Rover’s Arm — left andright). Second,two child classesmay inherit all of the Ap-pendageproperties(e.g. My Rover’s Arm andanotherclass,Your Rover’sArm, wherethelatteris somewhatdifferentfromtheformer).

Moving up the classabstractionhierarchy, inheritancerela-tionshipsmay get morecomplicated.Both AppendageandLocomotorcanhave a commonparentof CoordinatedSys-tem,whichin turnhasthesameparentasRover, calledRobot.Also, while theMotor classhasno children,it is aggregatedinto the CoordinatedSystemclass. In this way, motor func-tionality isspecifiedcentrallyin oneobjectandavailableatalllevelsbelow it in thehierarchy, greatlysimplifying softwaremaintenance.

EncodedFunctionality— All objectscontainbasicfunction-ality for themselves, accessiblefrom within the FunctionalLayer, aswell asdirectly by the DecisionLayer. This func-tionality expressesthe intendedandaccessiblesystemcapa-bilities. Thepurposeof thisstructureis to hidetheimplemen-tationdetailsof objectsfrom thehigherlevelsof granularity,aswell asproviding a genericinterface.

To the extent possible,baselinefunctionality is provided inparentclasses,andinheritedby thechildren. Thesechildrenmayreplacethis functionalityor addto it. For instance,in thepreviousexample,theAppendageclasswill containagenericinversekinematicsmethod,whichcanbeusedby its children.However, My Rover’s Arm may overwrite this functionalitywith anclosed-formalgorithm,optimizedfor it’s specificde-sign.In addition,it mayaddfunctionalityspecificto theclass,suchasstow() or unstow() methods.

In additionto inheritanceof functionality, thereis alsopoly-morphicexpressionof functionality. Typically, onememberfunctionnameis usedin all levelsof thehierarchy, represent-ing a capabilitythat is appropriatefor that level (e.g. move,read,set,status,etc.). Sincethe DecisionLayer canaccessall levelsof theFunctionalLayerhierarchy, it usesthis struc-ture to simplify its interactionsat differentgranularity. Forinstance,a movecommandissuedto theRover objectwouldnavigatefrom on placeto anotherusingthe Locomotor, butwithouta requirementto follow astraightline or find sciencetargetsalong the way. If the DecisionLayer wantedto dothelatter, insteadof usingtheRover interfaceit wouldaccessthe move of the Locomotordirectly, while alsoaccessingasciencetargetfinderobject.

ResidentState— Thestateof thesystemcomponentsis con-tainedin theappropriateobjectandobtainedfrom it by query.This includesstatevariablevalues,statemachinestatus,re-sourceusage,healthmonitoring,etc. In this way, the Deci-sionLayercanobtainestimatesof currentstateor predictionsof futurestate,for usein executionmonitoringandplanning.

LocalPlanners— WhereastheDecisionLayerhasa global

plannerfor optimaldecisionmaking,it mayutilize localplan-nersthat are part of FunctionalLayer subsystems.For in-stance,pathplannersandtrajectoryplanners,canbeattachedto manipulatorandvehicleobjectsto provide standardcapa-bilities without regard to global optimality. Like all otherFunctionalLayer Infrastructure,the useof suchlocal plan-nersis anoptionfor theDecisionLayer.

ResourceUsagePredictors— Similar to local planners,re-sourceusagepredictionis localizedto the objectsusingtheresources.Queriesfor thesepredictionsaredoneby theDe-cisionLayerduringplanningandscheduling,andcanbere-questedat varying levelsof fidelity. For instance,the powerconsumptionby the vehicle for a particulartraversecanbebasedon a hard-codedvalue,an estimatebasedon previouspower usage,or a detailedanalysisof the upcomingterrain.The level of fidelity requestedwill be basedon time andre-sourceconstraintson theplanningstageitself, marginsavail-ablefor thetime window underconsideration,aswell astheavailability of moredetailedestimateinfrastructure.In somecases,subordinateobjectsmaybeaccessedby superioronesin theprocessof servicinga detailedpredictionrequest.

Simulation— In thesimplestform, simulationof thesystemcanbeaccomplishedby providing emulationcapabilityto allthe lowest level objectsthat interactwith hardware. In thiscase,thesuperiorobjectshavenoknowledgeof whethertheyareactuallycausingrealactionsfrom therobot. Suchsimu-lation is a baselinecapabilityof the architecture.However,it typically cannot bedonefasterthanreal-timewhile usingthe samelevel of computerresources.Therefore,it is ad-vantageousto percolatesimulationcapabilityup to superiorobjectsin the hierarchy. The costof this is increasingcom-plexity in the simulationcomputations.For somepurposessuchcomplexity maybevaluable.But, aswith ResourceEs-timation,levelsof fidelity maybespecifiedto provideusefulsimulationwith reducedcomputationwhendesired.

TestandDebug— For initial developmentand regressiontestingassystemcomplexity grows,all objectsmustcontaintestanddebug interfacesandhaveexternalexercisers.

TheDecisionLayer

TheDecisionLayerbreaksdownhighlevelgoalsinto smallerobjectives,arrangesthem in time due to known constraintsandsystemstate,andaccessestheappropriatecapabilitiesoftheFunctionalLayerto achieve them.Figure5 showsa verysimplifiedandstylistic representationof theDecisionLayer.TheDecisionLayerhasthefollowing characteristics:

Goal Net— TheGoalnetis theconceptualdecompositionofhigherlevel objectivesinto their constituentparts,within theDecisionLayer. It containsthe declarative representationofthe objectivesduring planning,the temporalconstraintnet-work resultingfrom scheduling,andpossiblya tasktreepro-ceduraldecompositionusedduringexecution.

Goals— Goals are specifiedas constraintson state overtime. As suchthey canbe thoughtof asboundingthe sys-tem andspecifyingwhat shouldn’t be done. An exampleis:

MISSIO

N PLA

NN

ING

SPAC

E

�

RO

BO

T PLAN

NIN

G SPA

CE

�

below "The Line"

Executive �Dominant

PlannerDominant

...

...

...

GoalNet

Goals

Figure5. ProposedDecisionLayer.

‘the joint angleshouldnot exceed30 degreesor be lessthan20 degrees’. Goalsmay be decomposedinto subgoalsdur-ing elaboration,andarrangedin chronologicalorderduringscheduling.Resultinggoalnetsandschedulesmaybesaved,or recalled[13].

Tasks— Tasksareexplicitly parallelor sequentialactivitiesthataretightly linked. They resultfrom thefixedproceduraldecompositionof anobjective into a sequence,which is pos-sibly conditionalin nature.In contrastto Goals,Tasksspecifyexactlywhatshouldbedone[31]. An exampleis: ‘the jointangleshouldbe25 degrees’.

Commands— Commandsare unidirectional specificationsof systemactivity. Typically they provide the interfacebe-tweentheterminatingfringesof thegoalnet,andthecapabil-ities of theFunctionalLayer. Closedloop controlwithin theDecisionLayer is maintainedby monitoringstatusandstateof thesystemascommandsareexecuted[4].

TheLine — The Line is a conceptual border betweenDecision-makingandFunctionalexecution[13]. It exists attheinstantaneouslowerborderof theelaboratedgoalnet,andmovesto differentlevelsof granularityaccordingto thecur-rentelaboration.Whenprojectedon theFunctionalLayer, itdenotestheborderbelow which thesystemis a black box totheDecisionLayer.

State— The stateof the FunctionalLayer is obtainedbyquery. Thestateof theDecisionLayer, whichis essentiallyitsplan,theactiveelaboration,andhistoryof execution,is main-tainedby this layer. It maybesaved,or reloaded,in wholeorpart.

LayerConnectivity

Giventhe two architecturallayers,FunctionalandDecision,thereis flexibility in the ways in which thesemay be con-

nected.At oneendof the spectrumis a systemwith a verycapableDecisionLayer, andwith aFunctionalLayerthatpro-videsonly basicservices.At theotherendof thespectrumisa systemwith a very limited DecisionLayer that relieson averycapableFunctionalLayerto executerobustlygivenhighlevel commands.If both a capableDecisionandFunctionalLayerarecreatedthentheremayberedundancy — however,this is seenas a strengthof CLARAty, not a weakness.Itallows the systemuser, or the systemitself, to considerthetrade-offs in operatingwith the interfacebetweenthe layersat a loweror higherlevel of granularity.

At lowergranularitythebuilt in capabilitiesof theFunctionalLayer are largely bypassed.This can enablethe systemtotake advantageof globally optimizedactivity sequencingbytheDecisionLayer. It alsoenablesthecombinationof latentfunctionalityin waysthatarenot providedby aggregationofobjectsathigherlevelsof granularityin theFunctionalLayer.However, it requiresthat theDecisionLayerbeawareof allthesmalldetailsof thesystemat lower granularity, andhavetime to processthis information. For missioncritical oper-ations, it may be worth expendinglong periodsof time toplanaheadfor veryshortsequencesof activity. However, thismodel can not be employed always, sinceit will force thesystemto spenda disproportionateamountof time planning,ratherthanenactingthe plans. While the plan may provideoptimalityduringits execution,inclusionof planningtime asa costmayforcethesystembeverysuboptimal.

To avoid this problemof overburdeningthe DecisionLayer,robust basiccapabilitiesare built into the FunctionalLayerfor all objectsin its hierarchies.This allows theinterfacebe-tweenthelayersto exist athighergranularity. In thiscase,theDecisionLayerneednotsecondguessFunctionalLayeralgo-rithms, andcanalsousemorelimited computingresources.Particularly in situationswhereresourcesusageis not nearmargins, or subsystemsare not operatingin parallel, it ismuch more efficient to directly employ the basic encodedfunctionality. It alsodirectly allows for problemsolving atthe appropriatelevel of abstractionof the problem,both forthesoftwareandthedevelopers.

Time-lineInteraction

The interactionof the two architecturallayers,can also beunderstoodby consideringthe creationandexecutionof ac-tivities on a time-line. Figure 6 shows the two layerswiththe sequenceof activation highlightedin green. In the De-cision Layer, high level goalsaredecomposedinto subordi-nategoalsuntil thereis somebottomlevel goal thatdirectlyaccessestheFunctionalLayer. Duringplanningandschedul-ing, this processoccursfor queriesof resourceusageandlo-cal plans. If high fidelity informationis requestedfrom theFunctionLayer, suchaswhenresourcemarginsaretight, thentheFunctionalLayerobjectmayalsoneedto accessits sub-ordinatesto improvethepredictions.

The resultantactivity list andresourceusageis placedon atime-line asshown in Figure7, activities on the top andre-sourceusageon thebottom.Schedulingwill optimally ordertheseactivitiesto enablegoalachievementwhilenotviolating

MISSION PLANNING SPACE

�ROBOT PLANNING SPACE

"The Line"

Executive�Dominant

PlannerDominant

...

...

...

GoalNet

Goals

......

.........

...

......

HARDWARE

ENVIRONMENT

robot

motor� sensor�camera�

switch�A2D�

digital IO� framegrabber

joint�

locomotor�

linkage�

stereo�arm� mast wheel

team�

manip.

Functional Level access�through method calls atlevel of object hierarchy

appropriate for goal

Resource predictions and local plans during elaboration.

State values and resourceusage during execution.

"The Line"

Figure 6. Proposedrelationshipof FunctionandDecisionLayers.

RE

SOU

RC

ES

AC

TIV

ITIE

S

TIME

Now Plan freeze Plan hor izon

EXECDOMAIN

PLANNERDOMAIN

EXECUTIONHISTORY

Figure7. Exampleof systemexecutiontime-line.

resourceconstraints.This process,however, mustbe frozenatsomepointsufficiently farin thefuture,sothatthescheduleis self-consistentat thetime it is meantto beexecuted.Also,the time horizonup to which theplanningandschedulingisdoneis limited to constraintheproblem.Both of thesetimeboundariesareshown in thefigure.

Inside the Plan Freezeboundary, it is the responsibilityofan executive to initiate actionsby accessingthe FunctionalLayer. This processis illustratedin Figure6 by thearrowstotheFunctionalLayer, andthegreenshadingof oneportionoftheobjecthierarchyit contains.As theactionstakeplace,re-sourcesareconsumed,typically in slightly differentamountsthanpredicted.Theusageis reportedto theDecisionLayer,wherediscrepanciespossiblytriggerconditionalpartsof thecurrentplan, and are usedto modify the future projectionsof resourceavailability on thetime-linewhich forcesreplan-ning to occur. This cycle is indicatedby the largearrows inFigure7.

The processdescribedis typical of systemswherethe pro-

ceduralcomponentsof the executive areseparatedfrom thedeclarative componentsof planningandscheduling.It is notnecessarythat theboundarybetweenplanningandexecutionexist at a specificpoint in time — planningandschedulingcanoccurverynearto thepresent,while executive-stylepro-ceduraldecompositionmaybeincorporatedinto distantplan-ning. Therefore,theplan freezeboundaryin Figure7 is notrequiredfor CLARAty, and the potentialcross-couplingofPlannerandExecutiveis oneof theprimaryreasonsfor merg-ing bothinto a singleDecisionLayer. As discussedlater, theformat of thesemergedactivities, andthe interfacebetweenthem,is currentlyunderdevelopment.

Finally, it is important to note that there is also a migra-tion of someexecutive-styleproceduralexpansioninto theFunctionalLayeraswell. Eachobjecthasbuilt in function-ality which will have a proceduraldecompositionof its ac-tions, andmay have it own mini-executive, or even planner.CLARAty doesnot precludethis, andallows for this func-tionality to be leveragedor bypassed,dependingon the de-sireof systemdesigners,andthecapabilitiesof theDecisionLayer.

4. IMPLEMENTATION

While the prototypingandimplementationof theCLARAtyarchitectureis still in its earlystages,somespecificationsandresultsareimportantto mention,illustrating the directionofthis work. Below aredescribedsomeof the tool andstan-dardchoices,heritagesoftwarethatwill be includedinto theframework, andprototypingstatusat this time.

ToolsandStandards

At this point in time, the following toolsandstandardshavebeenacceptedfor CLARAty andits development:

TheUnifiedModelingLanguage— UML is to be usedforsystemdesignanddocumentation.The intent is for full useof UML, includingtemplates.

C++ Language— C++will beusedto createCLARAty, dueto its wide use in academiaand industry, the needfor anobject-orientedimplementation,andtherequirementsof real-timesoftwareimplementation.

OSsupport— To provide both real-time software supportwhile allowing for workstationdevelopment,CLARAty willbeconstructedto rununderVxWorks,Linux, andSolaris.Ex-tensionto otheroperatingsystemsin thefutureis possible.

Standard TemplateLibrary — In the spirit of leveragingoffpublic domainstandardsemployedby the softwarecommu-nity, softwareandspecificationssuchas the StandardTem-plateLibrary, will beemployedwherepossible.

SoftwareDevelopmentTools— While it is possibleto buildall or partsof CLARAty by writing softwaredirectly with atext editor, it is desirableto employ a standardtool for orga-nizing, structuring,andstyling thesoftwarein a like manneracrossall developers.Considerationhasbeengiven to tools

suchas �������! �"$#&%('*) and +-,. /,0"$'!) , but nodecisionis final.Since� it is thedesireto not preventwide participationin useof CLARAty, toolswith largecostsarenot desirable.

Documentation— It is importantto provide documentationof all componentsof thesystemin variousforms. TheUMLwaschosenpartly for this reason.Othertoolsfor in-line codedocumentationstandardizationare being investigated. Theintent is to leveragecurrenttoolsandstandards,not to createnew ones.

Heritage

While CLARAty is a new architecturedesign,its designandprototypeconstructionwill rely on someimportantexistinginfrastructure.First,someof theinitial conceptsfor theFunc-tional Layer objecthierarchyweredevelopedby the Plane-taryDextrousManipulatorstaskatJPL[26]. Second,wewillusethe researchroversRocky 7 andRocky 8 to framesomeof the problems,and as testbedsfor prototypedsolutions.Third, many yearsof technologydevelopmentat JPL andotherNASA researchfacilities have providedvaluablesoft-warewhichwill beimplementedwithin theCLARAty frame-work. Amongthesoftwareslatedfor inclusionis: JPLstereovision [40], Carnegie Mellon UniversityandJPL pathplan-ning [32][22], estimation[6], planningandscheduling[12],executiondecompositionandmonitoring[31], andkinematicanddynamicscomputing[42].

5. SUMMARY

This paperhaspresentedour new CLARAty architectureforroboticautonomysoftware.Wehavebriefly reviewedthehis-tory of this topic, potential impedimentsto success,needsfor continuedeffort, andconstraintson acceptablesolutions.Given thesecircumstances,we have presentedanevolution-ary modificationof prior architecturalstructure,which ad-dressestheneedsof mergingproceduralanddeclarativeplan-ning, while providing an object-orientedencapsulationofsystemfunctionality. Thenew CLARAty structureis, there-fore, comprisedof Decision and FunctionalLayers, and acompleteoverview of eachof these,andtheir interaction,hasbeenprovided. Finally, a brief descriptionof currentimple-mentationeffortswasincluded.

6. ACKNOWLEDGMENTS

As discussed,someof the conceptsin this paperleveragethosedevelopedby the Mission Data Systemteamat JPL.We would like to thankthemfor their continuedinteractionon architecturedesignissues.

The researchdescribedin this paperwascarriedout by theJetPropulsionLaboratory, CaliforniaInstituteof Technology,underacontractwith theNationalAeronauticsandSpaceAd-ministration. Referenceherein to any specificcommercialproduct,process,or serviceby tradename,trademark,man-ufacturer, or otherwise,doesnot constituteor imply its en-dorsementby theUnitedStatesGovernmentor theJetPropul-sionLaboratory, CaliforniaInstituteof Technology.

REFERENCES

[1] R. Alami et al. An Archtecturefor Autonomy. InternationalJournalof RoboticsResearch, 17(4),April 1998.

[2] J. Albus, H. McCain, and R. Lumia. NASA/NBS StandardRefer-enceModel for TelerobotControl SystemArchitecture(NASREM).NBS TechnicalNote 1235, National Bureauof Standards,Gaithers-burg, MD, July1987.

[3] JamesAlbus. 4-D/RCSReferenceModel Architecturefor UnmannedGroundVehicles. In IEEE Internation Conferenceon RoboticsandAutomation, SanFrancisco,April 24-272000.

[4] P. Backes et al. AutomatedPlanningand Schedulingfor PlanetaryRover Distributed Operations. In IEEE Internation ConferenceonRoboticsandAutomation, Detroit MI, May 1999.

[5] P. Backes,M. Long, andR. Steele.TheModularTelerobotTaskExe-cutionSystemfor SpaceTelerobotics.In IEEEInternationConferenceonRoboticsandAutomation, AtlantaGeorgia,May 1993.

[6] J. Balaram. KinematicStateEstimationfor a Mars Rover. Robotica,SpecialIssueon IntelligentAutonomousVehicles, 18:251–262,2000.

[7] J. BalaramandH. Stone. AutomatedAssemblyin the JPL TelerobotTestbed. In Intelligent RoboticSystemsfor SpaceExploration, Nor-well, MA, 1992.Kluwer AcademicPublishers.

[8] A. Bejczy. RobotArm DynamicsandControl.TechnicalMemorandum33-669,JetPropulsionLaboratory, Pasadena,CA, February1974.

[9] A. Bejczy and Z. Szakaly. An 8-D.O.F. Dual-Arm Systemfor Ad-vancedTeleoperationPerformanceExperiments.In Fifth AnnualWork-shop on SpaceOperations Applicationsand Research (SOAR ’91),HoustonTX, July9-111991.

[10] J.Borrelly etal. TheORCCADArchitecture.InternationalJournal ofRoboticsResearch, 17(4),April 1998.

[11] R. Brooks. A Robust LayeredControl Systemfor a Mobile Robot.IEEE Journal onRoboticsandAutomation, 2(1),March1986.

[12] S. Chien,R. Knight, R. Sherwood,andG. Rabideau.IntegratedPlan-ning andExecutionfor AutonomousSpacecraft.In IEEE AerospaceConference, AspenCO,March1999.

[13] D. Dvorak, RasmussenR., G. Reeves, and A. Sacks. Software Ar-chitectureThemesin JPL’s MissionDataSystem.In IEEE AerospaceConference, Big Sky, Montana,March2000.

[14] T. Estlin,G. Rabideau,D. Mutz, andS.Chien.UsingContinuousPlan-ningTechniquesto CoordinateMultiple Rovers.In IJCAI WorkshoponSchedulingandPlanning, Stockholm,Sweden,August1999.

[15] R.Firby. AdaptiveExecutionin Complex DynamicWorlds. PhDthesis,YaleUniversity, Departmentof ComputerScience,1989.

[16] F. Fisheret al. A PlanningApproachto Monitor andControlfor DeepSpaceCommunications.In IEEEAerospaceConference, Big Sky MT,March2000.

[17] E. Gat. On Three-LayerArchitectures. In D. Kortenkamp,R. Bon-nasso,and R. Murphy, editors, Artificial Intelligence and MobileRobots, Boston,MA, 1998.MIT Press.

[18] E. Gat et al. Behavior Control for RoboticExplorationof PlanetarySurfaces.IEEETransactionsonRoboticsandAutomation, 10(4):490–503,1994.

[19] V. Hayward and R. Paul. Robot Manipulator Control Under UnixRCCL: A Robot Control “C” Library. International Journal ofRoboticsResearch, 5(4),Winter1986.

[20] http://www.intel.com/research/mrl/research/cvlib/. OpenSourceCom-puterVisionLibrary. Intel.

[21] R. Knight et al. IntegratingModel-basedArtificial IntelligencePlan-ning with ProceduralElaborationfor OnboardSpacecraftAutonomy.In SpaceOpsConference, ToulouseFrance,June2000.

[22] S. Laubach. Theoryand Experimentsin AutonomousSensor-BasedMotion Planningwith Applicationsfor Flight PlanetaryMicrorovers.PhDthesis,CaliforniaInstituteof Technology, May 1999.

[23] M. Maimone,I. Nesnas,andH. Das. AutonomousVision-BasedMa-nipulationfrom a Rover Platform. In IEEE Symposiumon Computa-tional Intelligencein RoboticsandAutomation, pages351–356,Mon-terey, California,November1999.

[24] J. Matijevic et al. ThePathfinderMicrorover. Journal of GeophysicalResearch, 102(E2):3989–4001,1997.

[25] N. Muscettola. RemoteAgent: To Boldly Go WhereNo AI SystemHasGoneBefore.Artificial Intelligence, 103(1-2):5–48,1998.

[26] I. Nesnas,M. Maimone, and H. Das. Rover Maneuvering for Au-tonomousVision-BasedDexterousManipulation.In IEEEConferenceonRoboticsandAutomation, SanFrancisco,CA, April 2000.

[27] P. S. Schenker et al. FIDO Rover andLong-RangeAutonomousMarsScience.In Intelligent RobotsandComputerVision XVIII, SPIEPro-ceedings3837, Boston,September, 1999.

[28] S. Schneideret al. ControlShell: A SoftwareArchitecturefor Com-plex ElectromechanicalSystems. International Journal of RoboticsResearch, 17(4),April 1998.

[29] M. Schoppers.A SoftwareArchitecturefor HardReal-TimeExecutionof AutomaticallySynthesizedPlansor Control Laws. In AIAA/NASA

Conferenceon IntelligentRobotsin Field, Factory, Service, andSpace(CIRFFSS), HoustonTX, March20-241994.

[30] R.Simmons.StructuredControlfor AutonomousRobots.IEEETrans-actionsonRoboticsandAutomation, 10(1):34–43,1994.

[31] R. Simmonsand D. Apfelbaum. A Task DescriptionLanguageforRobotControl. In IEEE/RSJIntelligent RoboticsandSystemsConfer-ence, Vancouver Canada,October1998.

[32] S. Singhet al. RecentProgressin Local andGlobalTraversabilityforPlanetaryRovers. In IEEE Conferenceon Roboticsand Automation,SanFrancisco,CA, April 2000.

[33] D. Stewart,R. Volpe,andP. Khosla.Designof DynamicallyReconfig-urableReal-Time SoftwareusingPort-BasedObjects. IEEE Transac-tionsonSoftware Engineering, 23(12),December1997.

[34] E.Tunstel,R.Welch,andB. Wilcox. EmbeddedControlof aMiniatureScienceRover for PlanetaryExploration. In 7th InternationalSympo-siumonRoboticswith Applications,WAC’98, AnchorageAlaska,May1998.

[35] R. Volpe. Navigation Resultsfrom DesertField Testsof the Rocky7 MarsRover Prototype.InternationalJournal of RoboticsResearch,18(7),1999.

[36] R. Volpe andJ. Balaram. Technologyfor RoboticSurfaceInspectionin Space.In AIAA Conferenceon Intelligent Robotsin Feild, Factory,Service, andSpace(CIRFFSS), Houston,Texas,March20-241994.

[37] R. Volpe et al. Rocky 7: A Next GenerationMars Rover Prototype.Journal of AdvancedRobotics, 11(4):341–358,1997.

[38] B. Wilcox et al. RoboticVehiclesfor PlanetaryExploration. In IEEEConferenceonRoboticsandAutomation, pages175–180,NiceFrance,May 12-141992.

[39] D. Woerner. X2000 Systems And TechnologiesFor MissionsTo The Outer Planets. In 49th International AstronauticalCongress/InternationalAstronautica Federation, Melbourne, Aus-tralia,September28-October2 1998.

[40] Y. Xiong andL. Matthies. Error Analysisof a Real-Time StereoSys-tem. In ComputerVision andPatternRecognition, pages1087–1093,1997.

[41] Y. Xiong andL. Matthies.Vision-guidedAutonomousStairClimbing.In IEEE Conferenceon RoboticsandAutomation, SanFrancisco,CA,April 2000.

[42] J. Yen andA. Jain. ROAMS: Rover AnalysisModeling andSimula-tion Software. In nternationalSymposiumon Artificial Intelligence,RoboticsandAutomationin Space(i-SAIRAS’99), Noordwijk, Nether-lands,June1999.

BIOGRAPHIES

Richard Volpe, Ph.D., is the Principal Investigatorfor theLong RangeScienceRoverResearchTeam.His researchin-terestsincludereal-timesensor-basedcontrol, robot design,softwarearchitectures,pathplanning,andcomputervision.Richardreceived his M.S. (1986) and Ph.D. (1990) in Ap-plied Physicsfrom Carnegie Mellon University, where hewasa US Air ForceLaboratoryGraduateFellow. His the-sis researchconcentratedon real-timeforceandimpactcon-trol of robotic manipulators.SinceDecember1990,he hasbeenat theJetPropulsionLaboratory, California InstituteofTechnology, wherehe is a SeniorMemberof the TechnicalStaff. Until 1994,he wasa memberof the RemoteSurfaceInspectionProject, investigatingsensor-basedcontrol tech-nology for teleroboticinspectionof the InternationalSpaceStation.Startingin 1994,heled thedevelopmentof Rocky 7and8, next generationmobilerobotprototypesfor extended-traversesamplingmissionson Mars. In 1997,he receivedaNASA ExceptionalAchievementAwardfor thiswork, whichhasled to the designconceptsfor the 2003Mars rover mis-sion.

IssaA.D. Nesnas, Ph.D.,is thecognizantengineerfor theAr-chitectureandAutonomyResearchtask. His researchinter-estsincludesoftwareandhardwarearchitecturesfor roboticsystems,autonomoussensor-basedcoordination,actuationandcontrol,computervision, object-orienteddesign,andar-tificial intelligence. Issareceived a B.E. degreein Electri-cal Engineeringfrom ManhattanCollege, NY, in 1991. HeearnedtheM.S. andPh.D.degreesin roboticsfrom theMe-chanicalEngineeringDepartmentat the University of NotreDame,IN, in 1993and1995respectively. In 1995,hejoinedAdeptTechnologyInc. asa seniorprojectengineerinventingand implementingseveral new technologiesfor high-speedvision-basedrobotic applicationsandholdsa patentfor theImpulse-basedflexible partsfeeder. He alsoparticipatedintheNCMS Consortiumworking with industryleadersin fac-tory automationsuchas Ford, GM, Delco Electronics,andCumminsEnginedesigninghardwareandsoftwarestandardsfor robotic assemblycells. He hasjoined NASA at the JetPropulsionLaboratoryasamemberof technicalstaff in 1997.At JPLhehasworkedon thePlanetaryDexterousManipula-

tor project researchingautonomoussensor-basedmanipula-tion for rovers. In additionto his dutieson the ArchitectureandAutonomytask,Issais alsoworking on a flight projectfor autonomoussensor-basedlanding on Mars. He hasre-ceivedseveralNotableOrganizationalValueAdded(NOVA)AwardsandanExceptionalAchievementAwardfor hisworkat JPL. Issais a memberof Eta KappaNu andTau BetaPiNationalHonorSocieties.

Tara Estlin, Ph.D.,is aseniormemberof theArtificial Intel-ligenceGroupat theJetPropulsionLaboratoryin Pasadena,California where she performs researchon planning andschedulingsystemsfor roverautomationandmulti-roverco-ordination. Dr. Estlin has led several JPL efforts on au-tomatedrover-commandgenerationand planning for dis-tributedrovers,andis a teammemberof theJPLLongRangeScienceRover team.ShereceivedaB.S.in computersciencein 1992from TulaneUniversity, anM.S. in computersciencein 1994anda Ph.D.in computersciencein 1997,both fromtheUniversityof TexasatAustin. Shehasnumerouspublica-tionsin planning/schedulingandmachinelearning,includingsuchhigh profile forumssuchasAAAI, IJCAI, and ICRA.Her current researchinterestsare in the areasof planning,scheduling,andmulti-agentsystems.

Darr en Mutz received the Bachelorof Sciencedegree inComputerScienceat theUniversityof California,SantaBar-barain 1997. CurrentprojectsincludeLong RangeScienceRover (LRSR),statisticalhypothesisevaluation,andtheAu-tomatedPlanningandSchedulingEnvironment(ASPEN).

Richard Petras is a memberof the TeleroboticsResearchandApplicationsGroupattheJetPropulsionLaboratory,Cal-ifornia Instituteof Technology. He is currentlya memberof

theLongRangeScienceRover(LRSR)Team,supportingthedesign1 of aroboticarchitecturefor planetaryrovers.Previouswork at JPL involveddesignof theORCAA architectureforthe Rocky 7 researchrover, developmentof algorithmsforan articulatedcameramast,and low level software for mo-tor control, vision systems,andscienceinstruments.Beforecomingto JPLRichworkedon SpaceShuttleandSpaceSta-tion avionics for IBM FederalSystemsDivision (laterLoralSpaceInformation Systems)implementingredundanthard-wareandsoftware.Richgraduatedfrom Drexel Universityin1985with aB.S.in MechanicalEngineering.HegothisM.S.in SpaceSciencesfrom theUniversityof Houston,ClearLakein 1994.

Hari Das, receivedhis ScDdegreeon MechanicalEngineer-ing from MIT in 1989. He is a SeniorMemberof TechnicalStaff at JPL. His researchinterestsare in the developmentandevaluationof roboticsystemsfor biomedicalandplane-tary explorationapplications.