Distributed Programming and Coordination forAgent-Based Modular Automation

Alfred A. Rizzi, Jay Gowdy, and Ralph L. Hollis

TheRoboticsInstitute

CarnegieMellon University�jayg,arizzi,rhollis� @ri.cmu.edu

Abstract

A promisingapproachto enablingthe rapid deploymentand reconfigurationof automatedassemblysystemsis tomake use of cooperating,modular, robust robotic agents.Within suchanenvironment,eachroboticagentwill executeits own program,while coordinatingwith peersto produceglobalycooperativeprecisionbehavior. Tosimplify theprob-lem of agentprogramming,the structureof thoseprogramsis carefully designedto enablethe automaticencapsulationof informationnecessaryfor executionduring distribution.Similarly, the programmingmodel incorporatesstructuresfor thecompactspecificationandrobustexecutionof poten-tially complex andfragile cooperative behaviors. Thesebe-haviors utilize a run-timeenvironmentthatincludestoolstoautomaticallysequencetheactivities of anagent.Takento-gether, theseabstractionsenableaprogrammerto compactlydescribethehigh-level behavior of theagentwhile relyingonasetof formallycorrectcontrolstrategiestoproperlyexecuteandsequencethenecessarycontinuousbehaviors.

1. Introduction

Most robot programmingapproachesare basedonstandardcomputerlanguages,with theadditionof spe-cial primitives,constructs,andlibrariesto supportthephysicalcontrol of a robot [1]. Theselanguagesaredesignedto enablethe control of a single robot, anddonotinherentlysupportdistributedsystemsof robots.More abstractprogrammingmodelshave recentlyap-peared[2, 3], but typically theseareeither “task” or“process”basedandareappliedto theprogrammingofwork cells(whichmightcontainmultiplerobots).Thispaperexploresthedistributedprogrammingmodelwearedevelopingfor usewith theArchitecturefor AgileAssembly[4, 5], an ongoingproject in the Micrody-namicSystemsLaboratoryatCarnegieMellon Univer-sity’sRoboticsInstitute(for additionalinformationseehttp://www.cs.cmu.edu/ � msl).

The overall goal of the Architecturefor Agile As-sembly (AAA) is manufacturingagility – enabling

Figure1: A minifactorysegment

both the rapid deploymentand rapid reconfigurationof automationsystems– facilitating the early deliv-ery of a productto marketandthe ability to adapttochangingtechnologiesandmarketneeds.AAA strivesto achieve this form of agility by utilizing modularro-bustroboticagents [6]. Agentsaremechanically, com-putationally, andalgorithmicallymodularmechanismswhich operatein a deliberatelylimited domain, butpossessesa high degreeof capabilitywithin that do-main.For theremainderof thispaperwewill focusonminifactory, o specificinstantiationof AAA, designedto facilitate four-degree-of-freedom(4-DOF) assem-bly of high-value, high-precisionelectro-mechanicalproducts(seeFigure1). Minifactoriescontainagents(calledcouriers)thatare“experts”in producttransportandlocalplanarmanipulation,andotheragents(calledmanipulators)that are “experts” at vertical insertionand part rotation. Throughcooperative group actiontheseagentsperformthe4-DOFoperationsrequiredtoproducea product.

Modularity is a central philosophicalconcept inAAA; not only doesit enablescalingof the factorysystem,it alsooffersthepotentialfor improvedsystem

robustnessby eliminatingsinglepoint failures.Unfor-tunatelyit alsopresentsnew anduniquechallengesforthe systemprogrammer. As there is no central fac-tory “brain” andthusno singleprogramfor an entireAAA factory, eachagentmustexecuteits ownprogramwhich mustreliably interactwith thoseof its peersinorderto give rise to thedesiredoverall systembehav-ior. Whereasconstructinggenericdistributedsystemsof this form is a difficult problem, it is our conjec-turethatby restrictingour focusto a smallbut impor-tantclassof roboticsystems,sufficient constraintsareplacedon theproblemto makeit tractable.

Toward this end, we have developeda model foragentprogramsthat seeksto simplify the distributedprogrammingproblem:i) agentprogramsareselfcon-tained“applets,” thatutilize standardprotocolsto syn-chronizeand communicateabout their behavior; ii)eachagentmakesuseof a high-performancehybridcontrolsystemto manageits continuousbehavior. Theintentof this programmingmodelis to provide a highlevelof expressivenessandflexibility for theagentpro-grammer(be it a humandesigneror automatedcodegeneratingtool) while ensuringa structuredandreli-ableinterfaceto theunderlyingcontrolsystems.

��������� ������������������������������ ��� �!#" $ %'&)( *+!,.- !�/.0�1�( 2�34�5#687.9#: ; <= >@?�A 9.B.; BDC

E�F G@HJILKJMDKN�O MDK�IQP.HDMJF R O

S#T�UDV�WXT�Y Y Z�W[�\ Z.]�^�VJ_ T.U`ba�ced�f.ghji c i@k a�lma�cDn

o#p.qDr�sXp�t t u�sv uJwJx@u�q@y.z qe{

|~} �#����������e���Q�.�D� } � �

Figure2: Shift of control responsibilityfor distributedpro-gramming.

Onefundamentalchallengefor any robot program-ming systemis that the “program” mustspecifybotha system’s discretebehavior as well as its continu-ous behavior – i.e., it must coordinateboth the con-tinuousdomainof the robot’s control systemandthediscretedomainof eventmanagementassociatedwithoverall behavior. Most approachesto robot program-ming makea sharpdistinctionbetweenthesedomains– wherethe continuous,state-basedview is relegatedto theexecutionof controllers,andall decisionsaboutwhich controllersto run and when to run them aremadeby higher-level systemsusinga discrete,eventbasedview. We chooseto placethis distinctionat aslightlyhigherlevelandmakeit amoreformalabstrac-tion barrierthanis normal. Figure2 depictsa coursedecompositionof thecontinuumof tasksto beunder-takenby a robot’scontrolsystem,makingexplicit ourintentto move the“barrier” betweenthereal-timeandgeneralpurposetasks.In AAA, anagent’sexecutionis

dividedinto two distinctlayers:ahigher-level discretelayer responsiblefor theabstractsemanticsof factoryoperation,andalower-level continuouslayerthatman-agesthe sequencingandexecutingof specificcontrollawswhich,in turn,influencethephysicalenvironmentof the agent. The critical distinction is that the con-tinuousmechanismsareusedto guide the transitionsbetweencontrollersas well as to run the controllers,freeingthehigh-level agentprogramsto dealwith themorerelevant andabstractproblemof decidingwhatto do andhow to do it. This notion of automaticallymanagingthetransitionbetweencontrollerswasintro-ducedin [7], abstractlyfit to thedomainof minifactoryin [8], andrecentlydemonstratedexperimentally[9].

2. Distributed Programming

Thedistributedandcooperativenatureof AAA hasim-plicationsontheformof agentprograms:anagentpro-gram is not simply a script, but ratherdefinesan in-stanceof a classthat implementsa numberof specificmethods.The programmay definea new classto beinstantiated,or asubclassfrom a pre-existing standardone,but theclassmustimplementa standardinterface.This conceptis very similar to theJava “applets” thatareusedin world-widewebprogramming.For reasonsincludingeaseof portingandlicensingissues,wehavechosenPython[10], anotherobject-orientedlanguagewhichcanbeinterpretedor byte-compiled,to programour roboticagentsratherthanJava.

Every robotic agent program must provide twomethods:bind and run. They encapsulatethe twomajor conflictingrequirementsof anagentprogram–it must specify behavior in referenceto external en-tities,but mustrun in a completelydistributedfashionandcannotrely onany centralizedresourceor databaseduringexecution.For example,a couriermustbeableto know it will be interactingwith a particularmanip-ulator, but theinformationon how to contactthatma-nipulatormustresidewith thecourieratruntime.Sim-ilarly, amanipulatormayneedto know it will getpartsof a specifictype from a specificpartsfeedingdevicewithouthaving to contactacentraldatabaseatruntimeto get the geometricandproduct-specificinformationit needsto performits operations.

In the AAA environment, an agentprogram hastwo distinct phasesin its life cycle. First, it is writ-ten and simulatedwithin a centralizedinterfaceanddesigntool. This tool provides a factory developerwith a global view of the factory systemunder de-velopment[11]. Whenexecutingwithin the central-izedsimulationenvironment,thebind methodsimplycausesthe relevant itemsto be lookedup in the sim-ulationdatabasebeforeproceedingto executetherun

# Agent class definitionclass Program(CourierProgram):# Binding methoddef bind(self):# superclass has some binding to doCourierProgram.bind(self)

# Bind to a particular manipulatorself.source = self.bindAgent("FeederManip")# Bind to a particular factory areaself.corridor = self.bindArea("CorridorA")

# Execution methoddef run(self):# initialize the movementself.startIn(self.corridor)

# block until manipulator is readyself.initiateRendezvous(self.source, "Feeding")

# move into the workspaceself.moveTo(self.sourceArea)

# coordinate with manipulator to# get product from itself.acceptProduct()

# The coordinated maneuver is doneself.finishRendezvous("Loading")

# move out of the workspaceself.moveTo(self.corridor, blocking=1)

# instantiate the appletprogram = Program()

Figure3: A simplecourierprogram

method. The secondphaseoccurswhen the factorydeveloperdownloadsanagentprogramfrom thesimu-lationenvironmentto thephysicalagent.At thispoint,theagentprogrammustbebe“bound” with all of theglobalfactoryinformationtheagentwill requirewhileexecutingthe program. To bind a program,the inter-face tool executesthat program’s bind method,andusestheresultsto constructa small databasecontain-ing the informationnecessaryfor the agentto locate,bothgeometricallyandlogically, all of thefactoryele-mentsit will interactwith. This smalldatabaseservesasa startingpoint for anagent’s self-initializationandexploration of its environment. For example, in thesamplecourierprogram(Figure3) the bind methodcallsbindAgent("FeederManip"), which declaresthat the agentprogramwantsto know aboutthe ma-nipulatornamedFeederManipandassignsthe resultof thatbindingto a localmembervariablefor usein itsrunmethod.Asaresultof theinvocation,theinterfacetool will addthe relative positionof FeederManipinthecourier’s frameof referenceaswell asthenetworkaddressof FeederManipto thelocaldatabasewhichissentto thecourieralongwith theprogramtext.

The run methodcontainsthe “script” which actu-ally runsduring execution,implementingthe discretelogic of the agentwhich is responsiblefor initiatingandcoordinatingthe behavior of this agent. For ex-ample,the run methodin Figure 4 causesthe agentto loop, transferringpartsfrom a partsfeederto couri-ersthatrequestthem.Therunmethodis writtenusing

# Agent class definitionclass Program(ManipProgram):

# Binding methoddef bind(self):# bind a bulk feederself.feeder = self.bindDescription("ShaftFeeder")# bind product informationself.product = self.bindPrototype("ShaftB")

# Execution methoddef run(self):while 1:

# convenience function for getting a# product from a feederself.getPartFromFeeder(self.product, self.feeder)

# Wait for a courier to rendezvous# with the manipulator for feedingpartner = self.acceptRendezvous("Feeding")

# and transfer the product to the courierself.transferGraspedProduct(partner)

# instantiate the appletprogram = Program()

Figure4: A simplemanipulatorprogram.

conveniencemethodsdefinedby theprogram’s super-classes,which themselvescausetheexchangeof mes-sagesbetweenagentsusingAAA protocolsandthede-ploymentof hybrid-controllers(describedin Section3.below). For example,theconveniencemethodinvokedby self.getPartFromFeeder is implementedinthe parentclass,ManipProgram. This conveniencemethodextracts information from the productproto-typeandfeederinstancepassedinto it, andsetsupandmonitorscontrol policies which will robustly pick aproductof thattypefrom thatfeeder.

3. Control and Coordination

As we have alreadydescribed,an agentprograminAAA hastwo distinct but relatedrun-time responsi-bilities: i) it mustcarryout semanticnegotiationswithits peersto accomplishwork on behalfof the factory;andii) it mustproperlyparameterizeandsequencetheapplicationof low-level control strategiesto success-fully manipulatethephysicalworld. Theprogrammingmodelwe areutilizing simplifiesthe relationshipbe-tweenthesetwo responsibilitiesand minimizestheirimpactupononeanother. Specifically, to reducethecomplexity associatedwith writing agentprograms,thelow-level controlstrategiesarenow responsibleforthe detailsassociatedwith switchingandsequencingthe variouscontrol policiesavailable at any onemo-ment.

3.1. Real-time control

To simplify the developmentof agentprograms,theprocessof decidingexactly whenand how to switchbetweenlow-level control strategies is removed from

theagentprogramandisolatedfrom thehigh-level se-manticnegotiationsthataretheprimarydomainof theagentprogram. However it is importantto note thatthehigh-levelagentprogramcontinuesto maintainex-plicit control over the precisepolicies that are avail-able for useat any given moment. The fundamentalmodelweutilize for theexecutionof controlstrategieswaspresentedin [8]. Briefly, ratherthan relying ontheagentprogramto generatetrajectoriesthroughthefreeconfigurationspaceof theagent,theprogramde-composesthefreeconfigurationspaceinto overlappingregionsandparameterizingcontrolpoliciesassociatedwith eachregion. The left sideof Figure5 shows asimplistic“cartoon”renderingof this approach,where���

representthecontrolpolicieswhich areguaranteedto safelymove any statefrom anywherein the asso-ciatedshadeddomaininto the domainof the “next”controlpolicy. A hybrid control systemis thenrespon-sible for switchingor sequencingbetweenthe controlpoliciesassociatedwith this decompositionto achievea desiredoverall goal, inducinga monotonicallycon-vergentfinite stateautomataover the control policiessuchasthatdepictedon theright of Figure5.

F �

F �F �

F � F �

F � F �

F �

Figure5: Exampledecompositionof a trivial planarconfig-urationspace,andtheassociatedinducedgraphrelatingthecontrolpolicies.

Thisschemedescribesthebehavior of any oneagentin termsof a collectionof feedbackstrategies basedon the stateof the systemas perceived by the indi-vidual agent. The result is a hybrid on-line controlpolicy (onethat switchesbetweenvariouscontinuouspolicies)which makesuseof thecollectionof controlpoliciesthathave beenpassedto it by thehigher-levelagentprogram.By leaving the selectionof goalsandthe associatedprioritized decompositionof the statespaceto the agentprogramit remainspossibleto de-scribe(attheprogramlevel) arbitrarilycomplex behav-ior withoutconstructingcodetoundertakethecomplexreal-timemanagementof thosebehaviors.

Giventhismodelfor executingphysicalaction,it re-mainstheresponsibilityof theagentprogram(specif-ically the scriptdefinedby its run method)to create,

parameterize,and managethe currentlyactive setofcontrollersalongwith theassociatedsetsof goalsanddomains.Thusthescriptis only responsiblefor choos-ing the current“overall” goal alongwith appropriateintermediatesub-goals,and providing parameteriza-tions of control strategies to accomplishthosegoals.The complex and potentially error-proneproblemofmaking real-time changesto the underlying controlsystemis left to thehybridcontrolsystem.

The interfacebetweenthescriptandthis controllermanager is quite straightforward. The class fromwhich a particularagentprograminstanceis derivedprovidesstandardtoolsfor creatingandparameterizingcontrollersandtheirassociateddomains.Theseresult-ing controllersare then,at the directionof the script,placedinto an orderedlist of active controllers. Fi-nally, thecontrollermanagerwill selecttheappropriatecontrol policy (from this list) to executein real-time.Thedetailsof high-bandwidthmonitoringandcoordi-nationof anagentandits peers’stateis performedbytheselower levels,utilizing a dedicatedlocal commu-nicationsnetworktoshareinformationbetweenagents.This localnetworkis usedto passrelevantinformationbetweenagentsonly aboutthosevariablesthat effecttheir execution,resultingin efficient utilization of theavailablecommunicationbandwidthin a mannerthatis transparentto theagentprogram.

Communicationof progressandcompletionof tasksbackto thescriptis accomplishedby useof eithercall-back functionsor direct polling of the actualstateofthe agent. In general,the expectationis that scriptswill submita moderately-sizedlist of control actionsalongwith a setof fail-safeandfall-backstrategiesca-pable of respondingto the most dire circumstances,then sleep (wait for a call-back)until eitherprogresshasbeenmadeor afailurehasbeendetected.Whenap-propriateprogresshasbeenmadethescriptwill, whilemotionis still executing,appendadditionalcontrolac-tions to the “top” of the active controllerlist indicat-ing new goalsanddeletethosecontrol actionswhichareno longeruseful. If a failurehasbeendetectedtheprogramwill proceedin a similar fashion;only theac-tions addedto the list will most likely attemptto re-cover from theproblem.

By bothparameterizingthespecificcontrollers(set-ting the goal, defining the domain of applicability,specifyinggains,etc.) and orderingtheir placementon thelist of active controllers,a scriptis ableto spec-ify complex andefficient physicalmotion that is fun-damentallyrobust. This provides a rich andexpres-sive methodfor programsto specifyphysicalmotionwhile reducingtherisksassociatedwith writing thoseprograms. Within the minifactory system,an agentpresentsa “pallet” of control policies, eachwith an

# submit actions to move from self.current to areadef moveTo(area):# get the goal at boundary of area# and self.current in self.currentx,y = self.getBoundaryGoal(area)

# create and submit actioncontroller = self.goTo(x,y)domain = self.inArea(self.current)self.submit(controller, domain)

# reserve area, blocking if necessaryself.reserve(area)

# get goal at boundary of area and# self.current in areax,y,overlap = self.getOverlapGoal(area)

# create and submit action to cross into# the new areaself.submit(self.goTo(x,y), self.inRegion(overlap))

# create and submit action to drive to the# goal in area# note that a callback class is invoked when# this action starts which unreserves self.currentself.submit(self.goTo(x,y), self.inArea(area),

start=Unreserve(self.current))

# keep track of current areaself.current = area

Figure6: Codefragmentfor moveTo.

associateddomain of applicability, to the program-ming system. In addition to a standardcollectionofproportional-integral-derivative (PID) controllers thepallettypically includesotherstrategiesfor safelyexe-cutinglargemotionsin thepresenceof actuatorandge-ometricconstraintsor undertakingcooperative assem-bly taskswith peeragents(e.g. for performingvisuallyof forceguidedcoordination).

In practice,the detailsof this interfacearehiddenfrom the programmerby a set of standard“conve-niencefunctions.” For examplethemoveTo(...) callin Figure 3 would actually expandto the codefrag-mentshown in Figure6. It is herethat a specificre-sourcereservation protocol is implementedto ensuresafeoperation[6] andwherea “standard”setof con-trollers are parameterizedand placedon the list ofactive controllers. As a simple meansto coordinatethe overall activity of agents,minifactory makesuseof a distributedresourcereservation systemsto guardagainstinter-agentcollisions. In this particular in-stancea geometricregion in thefactoryis reservedbythecall to self.reserve, anda call-backmethodisregisteredto executeas the agententersthe destina-tion area. Theparticularcall-backmethodusedhere,Unreserve(...), freesthe reservation held on thecurrentareaassoonastheagentdepartsit, thusallow-ing its useby otheragentsin thesystem.

3.2. Agent interaction

Thusfar we have focusedon describinghow individ-ual agentscanbeprogrammedto accomplishspecific

def acceptProduct(source):# slave to manipulator when it is readycontroller = self.create("Slave")controller.master = sourcepredicate = self.create("WatchPartner")predicate.is_grasping = Trueself.insert(ControllerAction(controller, predicate))

# hold position after part placement and# manipulator withdrawalcontroller = self.holdPosition()predicate = self.create("WatchPartner")predicate.is_grasping = Falsepredicate.min_height = source.offsetaction = ControllerAction(controller, predicate)action.addStartCallback(self.tag("PartPlaced"))id = self.insert(action)

# wait until part placedself.waitFor("PartPlaced")# and clean up action listself.truncate(id)

Figure7: Codefor acceptProduct.

tasks.Constructionof a usefulAAA system,however,requiresthatagentssuccessfullyinteractwith onean-otherto undertakecooperative behaviors. Not surpris-ingly, ourapproachtoperformingthesecooperativeac-tionsutilizesthesameprotocolsandprogramingcon-structswe have beendescribing. The notablediffer-enceis thattheexecutionof thespecificcontrolstrate-giesmay requiresharingof significantstateinforma-tion betweentheparticipatingagentsin orderfor theirbehavior to betightly coordinated.

It makessenseto think of the two suchcooperat-ing agentsastransientlyforming an abstractmachineconsistingof their collective degreesof freedom,anda singleprogramdictatingthebehavior of thisabstractmachine – atermwewill useto describeacollectionofagentsthat areactively coordinatingtheir continuousbehavior with oneanother, as would happenwhen aminifactorycourierandmanipulatorcooperateto per-form a visually guidedinsertiontask. Of course,inactualityeachagentwill beexecutingits own programand associatedcontrol policies, and it is critical thattheparticipatingagentsreliablyenterinto,execute,anddissolve their coordinatedbehavior. Clearlyfor this tohappenthe agentsmust arrangeto executelow-levelcontrol strategieswhich are“compatible”– i.e. whenexecutedin parallelthey mustcommunicatetheappro-priatestateinformationto their peer(s)to jointly per-form thedesiredphysicaloperation.

As alreadydescribedin Section2.ourprogrammingsystemincludesprimitive tools to performthe neces-sarysemanticnegotiation– e.g., the variousforms ofrendezvous statementin Figures3 and4. Onesim-ple case,with extremelyasymmetricinteraction,is atransientmaster/slaverelationshipbetweentwo agents,with one agentabdicatingcontrol of its actuatorstotheother, which monitorsthestateof bothandpassesforce and torque commandsto its own actuatorsas

def transferGraspedProduct(partner):# from the product information and the partner# courier attributes calculate the courier# position and the manipulator position# necessary to place the product on the courier(cour_x, cour_y, manip_z, manip_th) = \

self.findPlacementTransform(partner)

# submit action to get ready to placecontroller = self.coordinatedMove(cour_x, cour_y,

manip_z-self.offset, manip_th)self.insert(ControllerAction(controller,

self.isGrasping()))

# submit action to go down to place product when# both courier and manipulator have arrived at# pre-placement positionscontroller = self.goto(manip_z, manip_th)predicate = self.coordinatedAt(cour_x, cour_y,

max_z=manip_z-self.offset, manip_th)self.insert(ControllerAction(controller, predicate))

# submit action to release part when force sensedcontroller = self.releasePart()predicate = self.forceThreshold(min_force = 0.5)self.insert(ControllerAction(controller, predicate))

# submit action to back off from courieraction = ControllerAction(

self.goto(manip_z-self.offset, manip_th),self.isNotGrasping())

action.addStartCallback("FinishedPlacement")id = self.insert(action)

# wait for placement to finishself.waitFor("FinishedPlacement")# register transferself.registerTransferTo(partner)# clean up action listself.truncate(id)

Figure8: Codefor transferGraspedProduct.

well asthoseof the slave agentvia a high-bandwidthlocal network. The detailsof this interaction,takenfrom a simulatedminifactory, areillustratedin Figure7 which shows theexpansionof theacceptProductprocedurefromFigure3,andFigure8 whichshowstheexpansionof thetransferGraspedProduct proce-dure. The acceptProduct methodabdicatescon-trol of the courier’s motions to a manipulatormas-ter until a product has been placed on it and themanipulatorhas backedoff by a given offset. ThetransferGraspedProduct methodcoordinatesthemotionsof themanipulatorandcourierandplacesthepartit hasalreadygraspedontothecourier.

Here, the invocationof acceptRendezvous andinitiateRendezvous, by the manipulator andcourier respectively, has indicatedthe willingnessoftheseagentsto participatein the cooperative behav-ior, aswell ashaving forcedthemto synchronizetheirexecution. Immediatelyfollowing this a set of con-trol policies are submittedthat causethe underlyingcontrol systemsto synchronizeandundertakethe de-siredcooperative behavior. Implicitly, thesubmissionand execution of thesecontrol policies (Slave andcoordinatedMove) has createda high-bandwidthcommunicationschannelbetweenthetwo agents.Thiscommunicationchannelis usedto enablethesupervi-sory controllermanageron eachagentto maketran-

sitions basedon statevariablescontainedwithin thepeer, andto allow relevantstate(andin this casecom-mandinformation)to passbetweenthetwo controlal-gorithms.

Notethatthroughoutthisprocesstheindividualcon-troller managersmaintainauthority over the specificpolicies that are executedby eachagent,and that itis only throughthe submissionof a compatiblesetofpolicies by both agentprogramsthat the desiredbe-havior is realized. We do not foreseethis extremelyasymmetricform of cooperationasthe typical behav-ior of agents,but it servesto illustratethepoint: typi-cally thecontrolpolicy will besegmentedbetweentheagentswith eachindividualcomputingthosetermsrel-evant to its own behavior. The manualspecificationof theseinteractionscanbea complex process.Fortu-natelya significantpercentageof the interactionsfallinto stereotypicclassesfor which conveniencefunc-tionscaneasilybeprovided.

4. Conclusions

The specificsof the AAA and minifactory environ-mentshave led us to considera new model for pro-grammingdistributedautomationsystems.Thismodelincorporatesfeaturesthatstandardizethespecificationof physicalaction and regulate interactionsbetweencooperatingentities. The ramificationsof thesefea-tures are manifestboth in the form and function ofthe resultingprograms,aswell asthe structureof therun-timeenvironmentin which they operate.As a re-sult, agentprogramsexecutein a structuredenviron-ment with standardizedmeansfor coordinatingtheiractivity, makingit possibleto constructcomplex mod-ular automationsystems,while programmingthembyfocussingpredominantlyon local behavior. We havedemonstratedthis capabilityboth in simulation(coor-dinatingtheactivity of upwardsof 40 agents),andex-perimentally(performingprecisionplacementwith 3cooperatingagents)[9].

4.1. Future work

Thereremainmany openpracticalquestionsabouttheimplicationsof our programmingmodel. For exam-ple, to producea working factory, usersmustgeneratea functionalsetof distributedcooperatingagentpro-grams.Fortunately, thescopeof any individual agentis limited, andeachagentwill includea setof pow-erful primitivesaswell asconveniencemethodsto fa-cilitate their usein stereotypicalapplications.Unfor-tunately, no matterhow shortor simplethe programsmay becomeasa resultof these“libraries,” the chore

of generatingasemi-customprogramfor eachagentinasystemremains.Beyondthepotentialtediumof gen-eratingtheseprograms,the programmeris essentiallyfacedwith producingalarge,distributedprogram,withall of theknown pitfalls of thatdomain,suchasdead-lock andlivelock.

To overcometheseissuesa meansof presentingthefactoryprogrammerdifferentwaysof viewing thepro-grammingproblemmustbe developed.For example,aprogrammermaywantto think in termsof a factory-centric view of the problem, where overall productmovementthrough the entire factory may be speci-fied througha work-flow representation,i.e. whatpro-cesseshave to occurandin whatorder. Alternatively,a usermay want to considera product-centricview,whereproductmodelsarespecifiedandannotatedwithprocessinformationto describetherelativemotionbe-tweenpartsindependentlyof themachinesusedto per-form thosemanipulations.In the future, we envisionanAAA programmingenvironmentthatincludestoolswhichsupportthesmoothtransitionbetweenthesevar-iousviews of the designandprogrammingproblems.Furthermore,they will rely on user-guidedsearchandoptimizationmethodsto semi-automaticallytransformthe information provided by thesedifferentviews oftheprobleminto factory layoutsanddistributedagentprograms.

Regardlessof whatview theuserhasof factorypro-gramming,agent-centric,factory-centric,or product-centric,ultimatelyany distributedfactorysystemmustexecutethoseprogramson a set of agentswhich in-teractingwith eachother and with the productcom-ponentsto performan assemblytask. This paperhaspresentedtheprogrammingmodelandprotocolswhichwill form thebasicbuilding blocksfor futuresystemswhichcanbringthevisionof rapiddeployment,recon-figuration,andreprogrammingof automatedassemblysystemscloserto reality.

Acknowledgments

This work wassupportedin part by the NSF throughgrantsDMI-9523156andCDA-9503992.Theauthorswould like to thankall the membersof the Micrody-namic SystemsLaboratory, and in particularArthurQuaid,ZackButler, andPatrick Muir, for their invalu-ablework on theprojectandsupportfor thispaper.

References

[1] T. Lozano-Perez.Robotprogramming.Proceedings ofIEEE, 71(7):821–841,1983.

[2] G.BerryandG. Gonthier. TheESTERELsynchronous

programminglanguage:design,semantics,implemen-tation. Science of Computer Programming, 19(2):87–152,November1992.

[3] R. W. Harrigan. Automatingthe operationof robotsin hazardousenvironments. In Proceedings of theIEEE/RSJ Int’l Conf. on Intelligent Robots and Sys-tems, pages1211–1219,Yokohama,Japan,July1993.

[4] R. L. Hollis and A. Quaid. An architecturefor agileassembly. In Proc. Am. Soc. of Precision Engineering,10th Annual Mtg., Austin,TX, October15-191995.

[5] R. L. Hollis and A. A. Rizzi. Opportunitiesfor in-creasedintelligenceandautonomyin robotic systemsfor manufacturing.In ����� International Symposium ofRobotics Research, Hayama,Japan,October1997.

[6] A. A. Rizzi, J.Gowdy, andR. L. Hollis. Agile assem-bly architecture:An agent-basedapproachto modularprecisionassemblysystems. In IEEE Int’l. Conf. onRobotics and Automation, pagesVol. 2, p. 1511–1516,Albuquerque,April 1997.

[7] R. R. Burridge,A. A. Rizzi, andD. E. Koditschek.Se-quentialcompositionof dynamicallydexterousrobotbehaviors. International Journal of Robotics Research,18(6):534–555,June1999.

[8] A. A. Rizzi. Hybrid controlasamethodfor robotmo-tion programming.In IEEE Int’l. Conf. on Robotics andAutomation, pages832–837,Leuven, Belgium, May1998.

[9] J. Gowdy, R. L. Hollis, A. A. Rizzi, andM. L. Chen.Architecture for agile assembly: Cooperative preci-sion assembly. In IEEE International Conference onRobotics and Automation Video Proceedings, 2000.(submitted).

[10] G. vanRossum.Python Tutorial. Corporationfor Na-tional ResearchInitiatives,Reston,VA, August1998.

[11] J.Gowdy andZ. J.Butler. An integratedinterfacetoolfor the architecturefor agileassembly. In Proc. IEEEInt’l. Conf. on Robotics and Automation, pages3097–3102,Detroit,MI, May 1999.