Realistic Robot Simulation

FinalProjectDevelopmentandImplementationofthe

Realistic Robot SimulationInterfacefortheVolkswagenRobotControllerVRS1

GkselDEDEO

LU

August1995-January1996VolkswagenAG,Wolfsburg

Advisor:Prof.SetaBO OSYANIstanbulTechnicalUniversity

ElectricalandElectronicFacultyControl&ComputerEngineeringDepartment

Supervisedby:

Prof.Dr.-Ing.J.HesselbachDr.-Ing.KerleDipl.-Ing.R.ThobenTechnischeUniversittBraunschweigInstitutfrFertigungsautomatisierungundHandhabungstechnik

Dipl.-Ing.P.BeskeVolkswagenAGElektroplanungAbt.Wolfsburg

RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu

1

TableofContents

Introduction..........................................................................................................................2

1.TheRealisticRobotSimulationProject ........... ........................................................... 31.1ThepurposeoftheRRSProjectanditsbenefits.... ................................................ 31.2Off-lineprogrammingandsimulationwithComputer-Aided-Ro boticsTools ....... 51.3RRS-InterfaceSpecifications .................... ......................................................... 10

2.RoboticsatVolkswagen ............................ ............................................................... 202.1VWasanindustrialrobotcontrollermanufacturer.. ............................................ 202.2HardwarearchitectureofaVWRobotControllerVRS1 . .................................... 222.3SoftwarestructureofVRS1 ....................... ......................................................... 232.4ProgrammingwithVRS1.............................. ...................................................... 30

3.RCS-ModulefortheVolkswagenRobotControllerVRS1 . ...................................... 343.1Thepathmodule................................... .............................................................. 343.2RCSVWinternals ................................ .............................................................. 46

4.IntegrationoftheRCSVW-ModulewithROBCAD ..... ........................................... 584.1OverviewofROBCAD............................... ........................................................ 584.2ROBCADOff-lineProgramming(OLP)DevelopmentEnvironm ent .................. 604.3TheControllerModellingLanguage .................... ............................................... 61

5.Conclusionwithcomparativeevaluationoftestmoti ons........................................... 635.1Testmotions .................................... ................................................................... 635.2ImplementedRRS-Services .......................... ...................................................... 715.3Summaryofthework ................................ .......................................................... 73

References........................................ .................................................................................74

Appendices A.FurthertestmotionsforcomparisonwithROBCAD. ..............................................77 B.Exemplarlogentriesofsimulation........... ................................................................84 C.CompletelistofRRS-Services................ .................................................................89 D.ControlfileandRRS-orientedactionprogramused withROBCAD......................91 E.SourcecodeoftheRCSVW-Modulewithcompilatio ndirectives...........................99


2

Introduction

The aim of the Realistic Robot Simulation (RRS) Pro ject has been to define a neutralsoftware interface which would allow Computer Aided Robot ics Tools to use originalrobot controller algorithms for a more accurate simulat ion. Derived from the originalcontroller software, Robot Controller Simulation (RC S-) Modules can be supplied bycontroller manufacturers as black-boxes to any simulati on system supporting the RRS-Interface.

The objective of this work is to develop the RCS-Module for the Volkswagen RobotController VRS1 and to integrate it into the ROBCAD sy stem of TecnomatixTechnologies.Assuch, thishasbeenthevery firstRR S-Softwarepackagedevelopedbythe Volkswagen Group, which has been among the projects par tners since its start in1992.

Designapproach

InordertoeasefuturemaintenanceeffortsfortheRC S-Software,particularemphasishasbeen put on keeping the original controller software part s of the module as intact aspossible. Consequently, the first step has been to impl ement an interprocesscommunication library under theUNIXoperating system.A s a result, the original pathmodulehasbecomefullyportableonUNIXcompatibleplatf orms.

ThesecondstepconsistedofdevelopingtheRRS-Servicesw hichcouldbesupportedbythe original controller.During this phase, a shell-progra mhas been used for testing theRCS-Module,makingthedesiredRRScallsinsteadoftheCAR -Tool.

Finally, themodule has been integrated intoROBCAD running o n a SiliconGraphics-Indigo platform by using the Controller Modelling Language technique of this CADsystem.

Results

Aftersixmonthsofdevelopmentwhichcoveredthetime period fromAugust1995untilJanuary 1996, aworkingRCS-Module has been achieved and put into operation underROBCAD. The RRS-Interface for VRS1 has already proven to be of considerablebenefit, since path deviations up to 90 milimeters during PTP- motions could be easilyobservedinanumberofcases.

Unfortunately, ROBCADs limited RRS-Interface capabiliti es did not allow theRCSVW-Module to be tested to the desired extend before a possible industrial use.Moreover, the tight time frame in which the RCSVW-Modu le has been developed,implemented and integrated into ROBCAD did not allow a s ound investigation of thesources of deviations between ROBCADs motion planner a nd the original controllersoftware.Forthisreason,inmostoftheavailablee xamples,graphicalmethodshavebeenusedtodepictthesedifferences.


3

1.TheRealisticRobotSimulationProject1.1ThepurposeoftheRRSProjectanditsbenefit s

Various interactiveandgraphics-based tools have been int roduced in industry to enablecomputer aided planning, simulation and off-line programming of industrial robots.These tools usually provide visualizations of robotized productio n cells, based ongeometrical and kinematic modelling, as well as models fo r the behaviour of thecontrollers involved. Until recently, this modelling was mostly based on defaultcontroller models, whose replacement with the origina l one usually required extensivemeasurementsoftherobotbehaviourinreality.Neverthel ess,theseeffortsdidnotleadtosufficient simulation accuracy for down-loading programs and executing them withoutreteaching.

Inordertoimprovethesituation,thecompaniesfromth eEuropeanAutomotiveIndustryinitiated the project Realistic Robot Simulation (RRS ), in which suppliers of robotcontrollers andComputerAidedRobotics (CAR-) Tools coope rate in order to define acommon interface forcontroller simulatingsoftware. As technicalexperts they involvedmanufacturers of robots and robot controllers (ABB, Com au, Fanuc, Kuka, RenaultAutomation,Siemens,Volkswagen),andmanufacturersof off-lineprogrammingsystems(Dassault Systeme, Deneb, Silma, Tecnomatix). For n eutral project management, theFraunhofer-Institute for Production Systems and Design T echnology (IPK Berlin) wasselectedasanindependantresearchinstitute.

BenefitsofRobotControllerSuppliers

By implementing RRS-Interfaces for their software, c ontroller suppliers can providesimulation products which assure a better utilization of CAR-Tools at their customer'ssite.Thesesimulationsoftwarescanbeused inallC AR-Tools supporting this interface.Hence, controller suppliers do not need to implement dif ferent simulation products foreveryCAR-Tool.Furthermore,theycanfocusonthedeve lopmentofdedicatedproductswithoutreimplementingthegeneralpartsofCAR-Tools. Consequently,thiseffortallowsthecontrollersuppliertominimizeimplementationeff orts.

BenefitsofCAR-ToolSuppliers

Suppliers of CAR-Tools do no longer have to implement and verify specific controllermodelsforaccuratesimulationoftheirCAR-Tools.Sinc etheoriginalcontrollersoftwarewill be used, verification will become obsolete. Up to now, CAR-Tool suppliers haveimplemented and verified their controller simulation m odels for each controller type.Therefore,thisapproachsavesdevelopmentresourcescons iderably.

BenefitsofCAR-Users

Byusingoriginalcontroller softwarewithinCAR-Tools, t he simulation accuracy of theindustrially appliedCAR-Toolswill be improved,whichwill effectively reduce down-times of the manufacturing equipment. Once a new contr oller type is acquired, the


4

automotive companies can also buy the corresponding simul ation product for a precisesimulation.Without a long implementation and verificat ion phase, a precise simulationcanbeusedduringtheinitialoperationphaseofanewco ntrollertype.

RealizationoftheprojectThe RRS-Project was started in January 1992 by defining the requirements of theinterface.Astheparticipantsagreedtoconcentrateon thecontrollersoftwareformotionbehaviour and kinematics, simulation deviations from real ity of less than 0.001 radiansfor planned joint values and less than 3% for cycle time s have been desired. It wasrequired to have several controllers of the same or dif ferent controller type andmanufacturer running in parallel in the same simulation . Finally, the interface had tosupportdataconsistencyofsimulatedandrealcontroller s.

FromMarch '92on,the firstsketchof the interfaceh asbeenelaborated.Thesketchhasbeen continously enriched and improved by feasability studi es and by cross checkingwith the functionalitiesof the involvedcontrollers. Aftermorethan32projectmeetingsversion0.0oftheRRS-InterfaceSpecificationwasava ilableinDecember'92.

Implementation work on first Robot Control Simulatio n (RCS-) Modules began inJanuary '93. Until May '93 RCS-Modules with a dummy functiona lity have beenimplemented and implementations including original control ler software have beendistributed to the manufacturers of off-line programming sy stems in July '93. InDecember '93, tested integrations of fiveRCS-Modules in fo ur simulation systems andtheverifiedversion1.0oftheRRS-InterfaceSpecifica tionhavebeenpresented.

1991 July Formationoftheproject1992 January Definitionandreviewofrequirements

March FirstsketchesofarchitectureandservicesNovember Developmentofcallingconventionsandtestsof twareDecember Completionofversion0.0oftheRRS-Interface Specification

1993 January Implementationofshellversionwithdummyfu nctionalityMay ImplementationofprincipalservicesJuly DistributionofobjectcodeSeptember FirstcompleteprototypesDecember Presentationofresultswithfirstworkingprotot ypes

1994 January Finalreviewofversion1.0oftheRRS-Interface Specification

1995 August StartforthedevelopmentofVolkswagensRCS-Modu leSeptember Version1.1oftheRRS-InterfaceSpecificatio n

1995 November IntegrationworkoftheRCSVW-ModulewithROB CAD1996 January FirstRCSVWtestmotionsunderROBCAD

Table1.1:DevelopmentoftheRRS-Project


5

1.2Off-lineprogrammingandsimulationwithCompu ter-Aided-RoboticsTools

1.2.1Off-lineprogramming

Anoff-lineprogramming(OLP)systemcanbedefinedasaro botprogramminglanguagewhichhasbeensufficientlyextended,sothatthedevel opmentofrobotprogramscantakeplacewithoutaccesstotherobotitselfbutbymeansof computergraphics/CRAxx/.Off-line programming systems are important both as aids in progra mming industrialautomationaswellasplatformsinvolvedinroboticsr esearch.

The use of off-line programming and simulation systems to program industrial robotsenables the shift of program creation and optimization a way from production, therebyreducingdown times in production cells.As such, off-line programming also offers thepossibilityofusingsimulation technology toexperimentwi thavarietyof scenariosandprocesses, in order to optimize processes without interf ering with production orendangeringthecells.Evenbeforeaunit isconstructeda ndput intooperation,avarietyoferrorsandweakpointscanbeidentifiedandavoided.

ThemostimportantadvantagesthatOLPsystemsofferm aybesummarizedasfollows:

Possibilityofprogrammingduringproduction => Increaseinavailabilityofproductionequipment

Dramaticalreductionofon-lineprogrammingtimeinrobotiz edcells => Set-upperiodsareshortened

Programminginparallelwiththeconstructionofequipmen t => Run-uptimesarereduced

Determinationandoptimizationofcycletimes

Reachabilitytestsandinvestigationsofcollisionwith theequipmentorotherrobots

Additionalsafetyduringtheon-lineprogramming

Today, a great deal of time and expertise is required to i nstall a robot in particularapplicationandbring the system toproduction readiness. Thereareanumberof factorsthatmakerobotprogrammingadifficulttask.Programmingrob ots,oranyprogrammablemachine, has particular problems which make the development of production-readysoftwareevenmoredifficult,mostofwhicharise fr om the fact thata robotmanipulatorinteracts with its physical environment. Even simple progra mming systems maintain aworldmodel of this physical environment in the form of loc ations of objects and haveknowledgeaboutpresenceandabsenceofvariousobjectsenc odedinprogramstrategies.


6

Geometricaldescriptions(VDA_FS)

ComputerAidedDesign Tools

Processplanning

Processinformations(e.g.weldingspots)

Robotizedcellplanning

Robotselection

Path&actiondefinitionscorrections&optimizationsSimulation

Executablerobotprograms

Programconversionwith downloadmodels

Realrobots

Figure1.1:Off-lineprogramming

During development of a robot program, it is necessary t o keep the internal modelmaintained by the programming system in correspondancewith t he actual state of therobot's environment. Interactive debugging of programs with a manipulator requiresfrequent manual resetting of the state of the robot's e nvironment. Such state resettingbecomesespeciallydifficultwhentherobotperformsan irreversibleoperationononeormoreparts.

1.2.2Simulation

The ideal simulationapproaches reality so closely tha t programsdevelopedoff-line canbe loaded onto and executed by real controllers without ha ving to correct them at theshop floor. Although the current technological state do es not allow such a precision,simulatorshavealreadyproventobeofeconomicbene fit/BER94/.

Incontrasttoteach-inprogrammingofa robotwhich requir esbasicallyahighaccuracyintermsofrepeatability, foroff-lineprogrammingtheac curacy inthepositioningof therobotplaysthedominant role /BERN94/.Absolutepositioninga ccuracydependson thequalityof themanufactured robot and the accuracy of the robotmodel used formotioncontrol. To ensure quality manufacturing and to identify ro bot model parametersaccurately, advanced measuring procedures and model-based parame ter identificationmethods are required. These procedures and methods make up the techniques called


7

robotcalibration .Calibrationresultsareasetofidentifiedrobotpara meterswhichcanbeusedbytherobotmanufacturerasacheckonthequalityof robotproductionandby therobotuser to improve the robot'sabsolutepositioningaccura cy,using for instance thesedataforthecompensationofoff-linegeneratedrobotprog rams.

ActuatorModel

WorldModel

MotorEncoderValues

DeformationModel

KinematicModel

TCPpositionandorientation

Figure1.2:Robotmodel/BERN94/

As illustrated in the figure 1.2, the robot model is defined as an integration of fourmodels; the actuatormodel, defining themechanical relations hip between robotmotorsand joints; the kinematic model, describing the robot's o verall movement; thedeformationmodel, characterising the compliance in the robot joints and links; and themeasurement target model, specifying the tool-center-point ( TCP) with respect to therobotflange.

Theabsoluteposeaccuracyoftherobotistodayrestric tedbyroughkinematicmodelling.By robot calibration , it can be improved close to repeatability. Research he re includesdevelopment of suitable models, low cost measuring equipme nt, data acquisition andmanagementsystemsandautomaticgenerationofappropriate calibrationdatasets.

A central cause for deviations is the motion behaviour of the robot controller. Itssimulation is still unsatisfactory, despite enormous e fforts that have been undertaken torebuildtheinterpolationofrealcontrollersinsim ulation.Figure1.3showsanexampleofdeviations between the original robot controllers (RCSV W) and a simulated ones(ROBCAD)behaviour.

Figure1.3:Deviationsbetweentwodifferentrobotcontrollers


8

1.2.3DeviationofSimulationandRealityinRobotics

Thenatureofsimulationimpliesacertaindegreeofa bstractionfromreality/BER95/.Foraccurateandrealisticsimulationofatechnicalsyste m,eachcomponentofthesystemhastobemodeled inaadequateway.With respect to practical a pplication the relevance ofeach component for the simulation purpose aswell as th e effort required formodellinghavetobeconsidered.

Figure 1.4 illustrates the major components for an industria l robot involved in motionprogramming.User interface, languagesystem,pathcontrol , transformationandpartsofthe servo control are mainly software components. Pa rts of the servo control, poweramplifier, positionmeasurement andmotors aremainly electronic or electromechanicalcomponents,whilegearsandmechanicalstructurearepurem echaniccomponents.

Robotcontrollersofdifferentmanufacturersprovidedif ferent languagesystems thataretailored to the specific capabilities of the controlle rs like interpolation procedures andcondition handlers. On the other hand, most simulation systems provide a generallanguagethatisalsousedintaskspecificprogrammingenvironme nts.Theprogramsaretranslated to the specific native controller language an d down-loaded afterwards. Inaddition, several simulation systems provide also emulat ions of native controllerlanguages.Programsthatareup-loadedfromtherealcontro llermaybeexecutedthere.

ServoControl

UserInterface

LanguageSystem

Pathcontrol

InverseTransformation

Gears

MechanicalStructure

PositionMeasurement Motors

Figure1.4:Majorrobotcomponentsinvolvedinrobotprogramming/BER95/


9

Several instructions like ptp or linearmotion arecommontomostcontrollers.But someotherlanguageelementslike fly-byhavenotonlyadifferentsyntacticalstructure,buta lsodifferent underlying semantics. For instance, fly-by may be commanded and executedwith respect toa fly-byzone, toa speed reductionor to a precision sphere. Providing asupersetofallmechanismswouldenable theprogrammer to specify semantics thatmaynot be executed by a real controller. Providing no fly-b y mechanism would make theuniversal language completely inefficient. The problem is pr incipally avoided byemulating the native language. However, other problems ari se : on the one hand, itrequiresaconsiderableeffortsincethelanguagesystems ofseveralcontrollershavetoberebuiltforseveralsimulators.Ontheotherhand,re buildingasystemiserror-tedious.

Thepathcontrolofrobotcontrollersprovidesthewidely usedmotiontypesasptp,linearand circular and often special motion types like weaving, s pline motions or optimizedmotions.Additionally, features like fly-by, event genera tion and conveyor tracking areprovided. The corresponding mechanisms may be modified by a variety of parameterslikespeedandorientationfollow-up.

In order to move simulated robot arms, most simulation systems also provide a pathcontrol system. The path controls of robot controller s and simulation systems providesimilarfunctionalityandparametrization.However,t heydifferobviouslyintheextendoffunctionality and its performance. Such deviations arise from the orientation follow-upandfly-byduringlinearandcircularmotion.Inadditionto theinaccuraciesinspace,alsothe execution times of motions deviate. This leads to con siderable errors in cycle-timesimulation.

Several attemps have been made for improvement of the simulation accuracy for pathcontrol: Special parametrizable path controls that include a variety of interpolationprocedureswithanumberofcombinationshavebeendeveloped, thesimulationsystemshavebeenextendedforopeninterfacesthatallowthe integrationofpathcontrols,specialinterfaces have been designed for the integration of pa th controls of specific realcontrollersintosimulationsystems.

Theinversetransformationofarobotcontrollerconve rtscartesiansetpointsonpathstothecorresponding jointvalues of the robot.Since the tr ansformation is computationallyexpensiveandhas tobeperformed in high frequency, the tra nsformationalgorithmsaresimplified and do not precisely match the real kinemati cs of the mechanical arm. Thiscausesabsolutedeviationsbetweenprogrammedandexecutedpath s.

Theservocontrol,motors,gearsandpositionmeasureme ntforthecontrolloopthatkeepsthe real robot armon the path given by the path contr ol.Dependent on path geometry,speed,acceleration,etc.,themechanicalstructurefol lowsthepathmoreorlessprecisely.Insimulationsystems,dynamicmodelsofthesecompon entsarenotincommonuse.Onereasonliesinthefactthatreliablevaluesforrequir edparameterslikefrictionaredifficultto obtain. Another reason lies in the more important deviations caused by the pathcontrol.


10

1.3RRS-InterfaceSpecifications

Using theRealistic RobotSimulation Interface, CAR Tools have access to the originalcontrollersoftwarebymeansofRRS-Services.Theseca nbecategorizedasfollows:

Baseservices

INITIALIZERESETTERMINATEGET_ROBOT_STAMPGET_RCS_DATAMODIFY_RCS_DATASAVE&LOADRCS_DATA

Kinematicandconversionservices

GET_INVERSE_KINEMATICGET_FORWARD_KINEMATICMATRIX_TO_CONTROLLER_POSITIONCONTROLLER_POSITION_TO_MATRIXGET_CELL_FRAMEMODIFY_CELL_FRAMESELECT_WORK_FRAMES

Principalmotionservices

SET_INITIAL_POSITIONSET_NEXT_TARGETGET_NEXT_STEPSET_INTERPOLATION_TIME

Motionmodificationservices

SELECT_MOTION_TYPESELECT_TARGET_TYPESELECT_TRAJECTORY_MODESELECT_ORIENT_INTERPOL_MODESELECT_DOMINANT_INTERPOLSET_ADVANCE_MOTIONSET_MOTION_FILTERSET_OVERRIDE_POSITIONREVERSE_MOTION

Motionparameterservices

SET_JOINT_SPEEDSSET_CARTESIAN_POSITION_SPEEDSET_JOINT_ACCELERATIONSSET_CARTESIAN_POSITION_ACCEL.SET_CARTESIAN_ORIENTATION_ACCELSET_JOINT_JERKSSET_OVERRIDE_SPEEDSET_OVERRIDE_ACCELERATION

Fly-byandpointaccuracyservices

SELECT_FLYBY_MODESET_FLYBY_CRITERIA_PARAMETERSELECT_FLYBY_CRITERIACANCEL_FLYBY_CRITERIASELECT_POINT_ACCURACYSET_POINT_ACCURACY_PARAMETERGET_CURRENT_TARGETID

Trackingservices

SELECT_TRACKINGSET_CONVEYOR_POSITION

Conditionhandlingservices

DEFINE_EVENTGET_EVENTSTOP_MOTIONCONTINUE_MOTIONCANCEL_MOTION

Weavingservices

SELECT_WEAVING_MODESELECT_WEAVING_GROUPSET_WEAVING_GROUP_PARAMETER


11

1.3.1Overviewofthefunctionality

CAR-Toolsinitializeaninstanceofrobotcontrollerm odelusingtheservice INITIALIZE/RRS95/.Thisservicereturnstheparameter RCSHandle,whosevalueidentifiesuniquelythisrobotinstanceandwhichhastobepassedtoeachser vicecallworkingon it. Incasetheservice INITIALIZE is successful, themodel is considered tobevalid, thus allRRS-Interfaceservicesmaybeappliedtoit.Atthispoint, GET_ROBOT_STAMP maybecalledtogetrobot'ssignaturedata.

For jogging or passing start positions, the service SET_INITIAL_POSITION may beapplied. After calling this service, SET_NEXT_TARGET can be used to pass the targetpositionforthefirstmove.

The key service for motion reporting is GET_NEXT_STEP. After each call, it reports astatus which gives important information for further poss ible calls : If the status is 0,GET_NEXT_STEP returns the next interpolated position. By succesive c alls of thisservice,motionscanbescannedwiththehighestresoluti on.Ifthisservicereturns1,thismeansthatthecontrollerneedsanewtargetposition .Inthiscase,anewtargetpositionispassedbytheservice SET_NEXT_TARGET.

The desired type of motion may be specified by SELECT_MOTION_TYPE, SELECT_TRAJECTORY_MODE, SELECT_ORIENTATION_INTERPOLATION_MODE andSELECT_DOMINANT_ INTERPOLATION . A number of SET- commands are availablefor the modification of the speed profiles. Fly-by beha viour and point accuracy aredetermined by the services SELECT_FLYBY_MODE, SET_FLYBY_CRITERIA_PARAMETER, SELECT_FLYBY_CRITERIA, CANCEL_FLYBY_CRITERIA, SELECT_POINT_ACCURACY and SET_POINT_ACCURACY_PARAMETER .

To change the look ahead of the interpolation, SET_ADVANCE_MO TION may be called .REVERSE_MOTION commands the controller to move backwards on a path. SET_OVERRIDE_SPEED changes the speed and SET_OVERRIDE_POSITION adds offsets tothecurrentTCPwhiletherobotmoves.

GET_NEXT_STEP returns 2 if the last given target is reached or if th e speed is zerobecauseofa STOP_MOTION command.After STOP_MOTION,movesmaybecontinuedby CONTINUE_ MOTION or all targets given to the controller may be cancelle d byCANCEL_MOTION. These services are provided in order to influence a manipula torsmotionbyexternalsignals.

In order to receive events from a controller, the RRS -Interface provides three serviceswhich cooperate with GET_NEXT_STEP. DEFINE_EVENT allows the programmer todefineeventswithdifferentmodesdependentoncombination sof time, traveleddistanceandposition. GET_NEXT_STEP returns the number of eventswhich occured during thelast interpolation step. If any, detailed information abo ut the events may afterwards berequested by the service GET_EVENT. With CANCEL_EVENT, one also has thepossibilitytocancelaneventbeforeitoccurs.


12

Framesofreference

TheRRS-interfacesupportsacomprehensivecontroller int ernalkinematicmodel,whichmay be accessed and modified by the services GET_CELL_FRAME, MODIFY_CELL_FRAMEand SELECT_WORK_FRAMES.

Usingcartesianpositiondata,themovementoftherobot canbedefinedbymeansoftwoframes.ThesearegivenbytheToolIDandtheObjectIDo ftheservice SELECT_WORK_FRAMES.Thecartesianpositiondatais thecoordinateof theT oolIDframewith respecttotheObjectIDframe.Assuch,itdefinesthetargettor eachintheObjectIDframebytheToolIDframe.

The cartesian position data is defined with a homogeneous matrix which contains thepositionandtheorientationvalues.Thenames for the elementsarechosenaccording to/PAU81/

The vectors n,o and a describe the orientation frame a nd the vector p describes thepositionofaframe.Theredundantfourthrowisomitted.

nx ox ax px o:orientationvectorny oy ay px a:approachvectornz oz az px n=oxa0 0 0 1

KinematicModels

Besides the two frames TOOL and OBJECT needed to describe the motion of a robot,someothersareusedtobuildormodifythegeometrical descriptionofacell(figure1.5).

Through the service MODIFY_CELL_FRAME, a programmer can modify the kinematicmodel of a robot's environment, which consists of a table containing the kinematicrelationsbetweentheframes.

BASE

TRANSLATOR

TRANS-BASE

TOOL

FLANGE

WORLD

TABLE-BASE

OBJECT

CONVEYOR

CONVEYOR-BASE

OBJECT

Figure1.5:Kinematicmodel/RRS95/


13

FramesareaddressedbyFrameIDs.SixIDsarereserved andhaveauniquemeaning:

WORLD :Thisistheoriginframeofthecell.BASE :Thisframerepresentsthesideoftherobotarmw hichisattachedtothe

WORLDFLANGE : It representsthe side of the robot armwhich is attached to a tool or an

object.TOOL :This frame isreserved fortools,whichcanbeat tached totheFLANGE

sideoftherobotor,indirectly,totheBASEsideofi t.OBJECT : This frame is reserved for workpieces. They may be attached to the

FLANGEorBASEsideoftherobot.CONVEYOR :Thisframeisreservedforconveyortracking. Therobotcontrollerdoesn't

controlthepathoftheconveyor,butismerelysync hronizedwithit.

Nr FrameName RelativeToName FrameType FrameData JointNr.1 TOOL FLANGE Constant 4x3 -2 FLANGE BASE Robot - 1to63 BASE TRANSLATOR Constant 4x3 -4 TRANSLATOR TRANS_BASE TranslateX - 75 TRANS_BASE WORLD Constant 4x3 -6 WORLD - - - -7 OBJECT TABLE Constant 4x3 -8 TABLE TABLE_BASE RotateZ - 89 TABLE_BASE WORLD Constant 4x3 -

Table1.2:Frames/RRS95/

Transformations

To let theCAR-Tools performmathematical transformatio ns in the sameway as robotcontrollersdo,RCS-Modulesmayprovide the services GET_FORWARD_KINEMATICS,GET_INVERSE_KINEMATICS, MATRIX_TO_CONTROLLER_POSITION andCONTROLLER_TO_POSITION_MATRIX .

ThehomogeneousmatrixisauniquerepresentationofaTCP locationanditsorientation.Though various algorithms can be used to define the relations hip between a controllerlocationandatransformation,thesealgorithmsstill exhibitthefollowingproblems:

Thedefinitionofthealgorithmsmaybeambiguous,suchtha tonetransformationmayyieldtomultiplesolutionsorsingularities.

Thecontrollermayperformsomeadditional hiddenmath that is not apperentordocumented,includingnumericalround-offthatisduetothepr ecisiondifferencesbetweentheCAR-Toolandthecontroller.

Thedefinitionofthealgorithmsmaychange,dependingonth econtrollerversion.


14

Theservices GET_INVERSE_KINEMATICS and GET_FORWARD_KINEMATICS providetransformations from cartesian positions to joint angl es and vice versa.GET_FORWARD_ KINEMATIC computes the TCP-pose with respect to the definedreference coordinate system for a given joint position . These transformations will beperformed with respect to the current tool and object fram es selected bySELECT_WORK_FRAMES service.

FlybyandPointAccuracy

Flyby means that the controller can look ahead and take into account more than thecurrent target when planning a path and calculating robots m otion. The biggestadvantage of the flybymode is that the corners can be rounded tomaintain a constantspeed.

Thebasicflybyserviceisthe SELECT_FLYBY_MODE,usedtoturnthemodeonandoff.Furthermore, to fully support the flyby programming capabiliti es of robot controllers,SELECT_FLYBY_CRITERIA and SET_FLYBY_CRITERIA_PARAMETER services aredefinedtoallowrespectivelytheselectionandsettingof flybyparameters.Tocancelanyselectedcriteria,theservice CANCEL_FLYBY_CRITERIAshouldbecalled.

Point accuracy defines a window which determines when the robot arrives at a targetpoint. This accuracy can be programmed with SELECT_POINT_ACCURACY andSET_POINT_ACCURACY services.

MotionConcept

As illustrated in the figure 1.6, SET_NEXT_TARGET and GET_NEXT_STEP are keyservicesformotion.

Principally, SET_NEXT_TARGET is used by the CAR-Tool to supply the programmedtarget positions to the RCS-Module, one target at a time . Then, GET_NEXT_STEP iscalledrepeatedlyinordertoreceiveinformationaboutro botsmotiontowardsthetarget.Each time this service is called, a new interpolation s tep with the highest possibleresolutionisreported.

INITIALIZE

SET_INITIAL_POSITION

SET_NEXT_TARGET

GET_NEXT_STEP

TERMINATE

Figure1.6:TheprincipleRRS-services


15

Inthisway,thetargetsareconsumedbytheRCS-Module, whichmaysignaltheneedfornewtargetsbymeansof theStatusparameter.Byusingthis outputparameter,theRCS-Modulehasthepossibilitytolook-aheadforanindefinite numberofpositions.

If the return status of GET_NEXT_STEP is 0, this means that the RCS-Module hascalculatedand is reportinganewpositionof the robot. In such a case, no new target isneeded. Conversely, if the Status is 1, it should be unde rstood that the RCS-Moduleneeds more target data. In the latter case, an additio nal output parameter, namelyElapsedTime,isusedtodeterminethevalidityofreportedpositions. If ElapsedTimehasavalueotherthan0,anewpositionoftherobot isrepor ted,otherwisetheRCS-Module isjustaskingformoretargetdata.

Ifthe Statusof GET_NEXT_STEP is2,itmeansthattheRCS-Modulehascalculatedandisreportingthefinalpositionoftherobot.Inthiscas e,therobotisstoppedeitherbecausethetargetisreachedorasaresultofa STOP_MOTIONcall.

To summarize the use of these parameters, an example wh ere the path to be followedconsists of four positions (P1 through P4, figure 1.7) may b e helpful. Below is animaginary robot program for this motion, accompanied wit h the corresponding RRS-servicecalls.Afterhavingreachedthefirsttarget(P2), flybymodewillbeturnedon.

1 movetoP1 SET_INITIAL_POSITIONP1

2 movetoP2 SET_NEXT_TARGETP2loop:GET_NEXT_STEP(untilStatus=2)

3 flybyon SELECT_FLYBY_MODE



P1

P2 P3

P4

Figure1.7:Motionexample


16

First,theinitialposeof therobotandthetargetare set toP1andP2 respectively.Then,the service GET_NEXT_STEP is called in a loop until it returns 2, indicating that thetargethasbeenreached.Afterturningtheflybymodeon, thenexttarget(P3)issupplied.SomewhereonthewaytoP3,theRCS-Moduledemands fort hefollowingtargetsothatitcanperformacornerrounding.Atthispoint,P4iss uppliedwith SET_NEXT_TARGETagain. Since the flybymode is still on, theRCS-Module will report Status=1 before itreaches P4. This, however, will be ignored by the CAR-Too l which will keep callingGET_NEXT_STEP untilStatus=2.

InterruptingMotion

Byusingtheservice STOP_MOTION,itispossibletostopamotionwhichiscurrentlyinprogress.As shown in the figure 1.8,when theRCS-Module receives this command, itgenerates a controlled, smooth deceleration until the si mulated robot stops. The CAR-Tool has to call the GET_NEXT_STEP service further in order to get the interpolatedpositionstepsduringthisdecelerationphase,until zerospeed is reported from theRCS-Module. The STOP_MOTION command leaves the on-going motion in a resumable,pendingstate, inwhichthecurrenttargetposition isnot cleared fromtheRCS-Module'smemoryandremainsvalid.

STOPMOTION

deceleration

time

speed

acceleration

CONTINUEMOTION

Figure1.8:Stoppingandcontinuingmotion

The CONTINUE_MOTION service restarts the last non-terminated motion that wasstoppedbythe STOP_MOTION command.After the receiptof the CONTINUE_MOTIONcommand, theRCS-Module generates a controlled accelerat ion for the simulated robotand considers the actual motion parameters such as speed a nd motion type for thecontinuedmotion.Togettheinterpolationsteps belongi ngtotheaccelerationphaseandtotherestofthepath, GET_NEXT_STEPwillhavetobecalledagain.

The CANCEL_MOTIONservicecanbeusedafteramotionisstoppedby STOP_MOTIONin those caseswhere themotion shall not be resumed. Since the current and all furthertarget positions are cleared from thememory, themoti on can no longer be resumed byCONTINUE_MOTIONandistreatedascompleted.


17

1.3.2RRSCallingConventionsandintegrationwithCAR-Tools

TheRRS-Interface requires the controller simulation packages from different controllervendors to be connectable to different CAR-Tool software packages. Both kinds ofsoftware packages may be written in several languages (C , Pascal, FORTRAN), arecompiledwithdifferentcompilersand have to runondif ferenthardwareplatforms (e.g.HP,IBM,SiliconGraphics,SUN).Furthermore,theRCS- Modulesneedaccesstoseveraloperating system features (e.g. memory management, file access, multitasking, taskcommunication)and finally, theRRS-Interfacehas tob eextendible. Inordertomanageall these requirementsand to reduce technical risks, rules for callingRCS-Modules andoperatingsystemshavebeenintroduced/RRS95/.

TherulesforcallingRCS-Modules

Each RCS-Module exports one function as its main entr y point. The desired RRS-service ispassed to this functionasaparametercalled OPCODE.This avoids linkingproblemsifanRCS-Moduledoesn'tsupportallservicesof t heRRS-Interface.Incaseofanunsupportedservice,theRCS-Modulemustreturnaner rorstatus.

AllparametersoftheservicesarepassedwithinoneIn put-DatablockandoneOutput-Data block. References to the Input andOutput blocks are pas sed with the functioncallofthemainentrypoint.

ThemainentryisanANSI-Cfunction,whichhasthef orm

voidrcsx(void*in,void*out);x has to be substituted by an abbreviation of two characters denoting the RCS-supplier,towhichtwodigitsmaybeaddedforaversionnu mber.Theparameters void*in and void*out passthepointerstotheInputandOutputBlocks.

The specification makes a distinction between Input/Outpu tBlocks andInput/OutputData: The Input and OutputBlocks consist of a header, a parameter list and possibly a

String-Dataandunusedspace. The Input and OutputData consist of the header, a paramete r list and possibly

String-Data. The lengthof theInputandOutputDatavariesdependingon th eparametersof the

servicecalled.

input/outputdata input/output

block

header

unused

parameterlist

stringdata

Figure1.9:Thestructureoftheinputandoutputblocks/RR S95/


18

TheheaderofeachInputBlockcontainsthefollowingelem ents:

INPUT_DATA_LEN: Thenumberofbytesactuallyused for inputdata (including th eheader).OUTPUT_BLOCK_SIZE : The number of bytes that may maximally be used forOutputData.OPCODE :Thenumberofthedesiredservice.

TheheaderofeachOutputBlockcontainsthefollowingelem ent:OUTPUT_DATA_LEN :The number of bytes actually used for output data (includ ingtheheader)

INPUTBLOCK:

INPUT_DATA_LENGTH

OUTPUT_BLOCK_SIZE

furtherintputparameters

stringdata

unused

OPERATIONCODE

RCS_HANDLE

private

RCS_PRIVATE_DATA

OUTPUTBLOCK:

OUTPUT_DATA_LENGTH

STATUS

furtheroutputparameters

stringdata

unused

header

parameterlist

Figure1.10:DatastructuresofanRCS-Call/RRS95/ All parameters of a service are transferred in the par ameter list of a block. Each

parameterhasafixedbyteoffsetintheparameterlist relativetothestartingaddressoftheblock.

Astringisrepresentedasastring-offsetandanullte rminatedarrayofcharacters.Thestring-offset isplaced intheparameter listandthen ull terminatedarrayofcharactersisplacedwithin the stringdata.Thestring-offset is t heoffset to the firstcharacter inthearrayrelativetothestartofInputorOutput-Block.


19

Therearetwospecialparameterswhichareusedbyalls ervices:RCS-Handle : RCS-Modules may instantiate any number of robot simula tions. Aninstanceofarobotiscreatedbyan INITIALIZE servicecall.Forfurtheraccesstothisinstance,the INITIALIZEservicereturnstotheCAR-Toolafieldofeigthbytes calledRCS-Handle. This is the first parameter in the input par ameter list of all servicesexceptthe INITIALIZEservice.Status :EachRRS-servicehasthisoutputparameterreporting thesuccess/errorstatusoftheservice.

Thetwomoduleconceptforintegration

This concept assumes a communication line between the C AR-Tool and the RCS-Module.Atypicalsolutionmayberealizedwithsharedme moryandsemaphores.

EachtimetheCAR-ToolwantstocallanRRS-service, itwritestothesharedmemorythecontentsoftheInputBlockandraisesasemaphore.The RCS-Modulewhichwaitsonthissemaphore reads the InputBlock,works,writes theOutputBlo ck to the shared memoryandraisesasemaphorefortheCAR-TooltoreadtheOut putBlock.

Since thismethoddoes not require that theobject codes are delivered to the user, eachpart can supply its module independently. Another advantage of this method is thatproblems of calling conventions from one language to another are avoided. The RCS-Modulecanbewritteninanylanguageandthesameistrue fortheCAR-Tool.

CAR-Tool'sRCS-Shell

CAR-Tool

signalRCS-Module

writeinputblock

waitsignalfromRCS-Module

readoutputblock

work

RRS-Interface

CAR-ToolSoftware

readinputblock

work

getsignal

writeoutputblock

signalCAR-Tool

RCS-Module

Shared-Memory

Figure1.11:Two-moduleconceptforintegration/RRS95/


20

2.RoboticsatVolkswagen

2.1VWasanindustrialrobotcontrollermanufactu rer

Volkswagen,besides being the first rankingautomobileman ufacturer inEurope, is alsooneofthe mostimportantrobotmanufacturersofthe continent.Havingbeenamongthevery firstcompaniestoplanandconstructrobotizedproductio ncells in theearly70's, ithas presently got more than 6000 industrial robots, world-wi de in use throughout thegroup.

In 1972, as the new VW product GOLF required an important vari ation in terms ofmodels,single-purposemanufacturingequipmentsweretobet akenoutandreplacedwithmore flexible production facilities. At this point of tim e, basing on earlier experienceswithsomeUSA-made industrialmanipulators,thedecisiont odevelopandproduceownrobotswas taken.During 20 years of independentwork,more tha n twenty kinematicalstructures and three controller generations have been de veloped, by which topcost/performanceratioswereachieved.

In1993,forreasonsofrationalization,VWmadeacontr actwiththecompanyKUKAfortheproductionanddeliveryofindustrialrobotsconsistingo fVolkswagencontrollersandKUKA mechanics. As a result, the costs for manipulator mechanics were reduced inaverage by 40%. Furthermore, the production of the controll ers was taken on by thecompanySEF.In1995,thedesignofanewrobotcontroller ( RCV) incooperationwithKUKAhasbeenstarted.ThisnewcontrollerwillbePC -basedand rununderWindows-95andVxWorks.

VW Wolfsburg 1092 Hannover 577 Braunschweig 246 Kassel 119 Emden 1006 Salzgitter 12 Mosel 184 Brussels 194 U.S.A. 74 Mexico 6 Brasil 17 SouthAfrica 17 Pamplona 244AUDIIngolstadt 1109 Neckarsulm 677SEATMartorell 402SVWChina 2VolkswagenGroup 5978Sold 104TotalProduction 6082

Table2.1:IndustrialrobotsthroughouttheVW-Group

15,4% 7,2% 67,4% 3,5% 5,1% 1,4%

939 439 4099 205 311 89

Handling

Assembly

Spotwelding

Arcwelding

Coatin

g

Others

Figure2.1:ApplicationareasatVW


21

Figure2.2:ManipulatortypesusedbytheVolkswagenGroup

MainfeaturesoftheVRS1controller

32-BitMicroprocessor(Motorola68030withco-processor68882) Jointcontrollercycle-time:5ms(min),15ms(standar d) Pathmodulecycle-time:10ms(min),15ms(standard) FastI/OData-bus(1,5MBaud) Absolutemeasuringsystems,upto24serialbits Supportof12joints Driveramplifiers(ACorDC)in19''cardformat Distancesupto100mfromthemanipulatortothecontrolle r Dataarchivingviaintegratedfloppy-disk Operationmodeselectionfromtheteach-pendant IntegratedPLCfunctions Upto128Inputs,128Outputs,127Sequences,127sub-programs Multi-sensorguidance Programmablesensorinterfaces Sensorinformationstakingeffectinabout20ms. Programmableanalogue/serial/parallelinterfaces Off-lineprogramming(upload,download) Menuorientedteach-inprogramming Sub-programtechnique Conditionalbranching Mirroringofprograms Interpolationtypes:Linear,Circular,Spline,Synchro- PTP,Twist Weavingwithalloronlyhandaxes Fly-bymode

Manipulatortype AmountK15,L15,R30,R100 825G8,G10,G15 460G60 832G80,G100 627G120,G120A,G121 951GP100 129P30 20P50 260P60 22P80 8

Manipulatortype AmountP100 10P200 30PLaser 8S1,S2 98VK10 100VK30 46VK120 1270VK150 105VK360/125 281Total 6082


22

2.2HardwarearchitectureofaVWRobotController VRS1

Themodules of aVRS1 robot controller (singleCPU vers ion)which are connected bymeansofaVME-Busareillustratedinthefigure2.3.

VME-BUS32-bitdata&address

CPU30ZBE4MByteDPR2MByteEPROMRTC,32KSRAM2Timer/parallelports

Ethernet

3xRS232

Floppy

SCSI

RAM-SCC

16KDPR68302

SSI Ser.1 Ser.2

0,5-2MBSRAMProgrammemory

6(12)JointamplifiersSSI

Jointspeedvalues

Ring-Bus

Teach-pendant16x40characterLC-Display

Emergency-Off/Confirmation DrivesOffbuttons

Keypad Serial(Bitbus)

Jointpositionvalues

Input/OutputUnit

Systemrelays

D/A

System&UserI/O18(12)Analogueoutputs

7Figure2.3:ComputerarchitectureoftheVRS1controller


23

2.3 SoftwarestructureofVRS1

TheVolkswagenRobotControllerSoftwareVRS1consist sofmanyprocesseswhichruninparallelunderthePDOSreal-timeoperatingsystem. Eventoday, itssoftwarestructurestillkeepsthetracesofitsfirstimplementationwh ichranontwoCPU's,oneforthepathmoduleandtheotherforthetasksubmissionandrobotopera tionsystem.

With the exception of some sub-routines written in ass embly, the software part of thecontroller is almost totally coded in theC programming l anguage.The underlying real-timeoperatingsystem is PDOS.VMEPROMconsists of t he real-timekernel of PDOSand isdeliveredwiththecontroller.OtherPDOSutiliti esareonlyused fordevelopmentpurposes.

Power-Up,Power-DownSafe-guardingmemory32Kb

RandomAccessMemory4(1)Mb

5Key-diskette

3,5"720Kb

SRAM-Disk0,5-2MbProgram/DataDiskette

3,5""720Kb

ResidentMemory

Operatingsystem&PathmoduleEproms

4(1)Mbit

4(1)Mbit

4(1)Mbit

4(1)Mbit

4

3

7

6

8

910

1 2

1 Power-UP AutomaticloadingoftheoperatingsystemfromE PROMS2 Power-UP AutomaticloadingofthepathmodulefromEPROMS3 Power-UP Automaticwarm-upwiththedatarecoveredduring thePower-DOWN4 Power-DOWN Automaticsavingoftheactualdata(Sequence, pointnumberandothers)5 Key-Diskette Theoperatingsystemcontrolsaccesstopro tecteddata.6 Floppy-Disk Loadingofthesavedprogramsorconstantsfro mthefloppydiskintothe

memoryandSRAMdisk.7 Datasaving Savingoftheprogramsorconstantsfromhard (SRAM)disktofloppies.8 Verify Datacomparisonbetweenthefloppyandhard(SRAM)dis ks.9 Verify DatacomparisonbetweentheRAMandhard(SRAM)di sks.10 Verify DatacomparisonbetweentheRAMandthefloppydisk.

Figure2.4:VRS1ControllerSoftware/VRS1/


24

2.3.1Featuresoftheunderlyingoperatingsystem

VMEPROMisaPDOSbasedreal-timemonitor.Themainf eaturesofitskernelare:

Multitasking,multiuserscheduling Systemclock Memoryallocation Tasksynchronization Tasksuspension Eventprocessing CharacterI/Oincludingbuffering

The PDOS kernel is the multitasking, real time nucleus of the VMEPROM /VME89/.Tasks are the components comprising mostly a real time a pplication. It is the mainresponsibilityofthekerneltoseethateachtaskispr ovidedwiththesupportitrequiresinordertoperformitsdesignatedfunction.

Themost important responsibilities of the kernel are t he allocation of memory and theschedulingoftasks,sinceeachtaskmustsharethesyst emprocessorwiththeothers.Thekernel saves a task's context when it is not executing a nd restores it again when it'sscheduled. Among other responsibilities of the kernel, the maintenance of a 24 hoursystem clock, task suspension and rescheduling, event proces sing, character bufferingandothersupportfunctionscouldbestated.

TaskA task is defined as a program entity which can execute ind ependently of any otherprogramifdesired.Fromthispointofview,it isthemo stbasicunitofsoftwarewithinareal timekernel.A user task consists of an entry in t he task queue, task list and a taskcontrolblockwithuserprogramspace.

Fromthetimea taskiscodedbyaprogrammeruntil its te rmination, it is inoneof fourtask states. Tasks move among these states as they are created, begin execution, areinterrupted,waitforeventsandfinallycompletetheir functions.Thesestatesaredefinedasfollows:

Undefined: Ataskisinthisstatebeforeitisloadedintothet asklist.Itcanbeablockofcodeinadiskfileorstoredinmemory.

Ready: Whenataskis loadedinmemoryandenteredinthetask queueandtasklistbutnotexecutingorsuspended,itissaidtobeready.

Running: AtaskisrunningwhenscheduledbytheVMEPROMkernelfrom thetasklist.

Suspended: Whenataskisstoppedpendinganeventexternaltothe task,itissaidtobesuspended.Asuspendedtaskmovestothereadyorrunningstate whentheeventoccurs.


25

Undefined Ready

Running SuspendedFigure2.5:Taskstates/VME89/

VMEPROM allows 64 independent tasks to reside in memory and s hare CPU cycles.Each task contains its own task control block and thus ex ecutes independently of anyother task. Intertask communication and synchronization are integral partsof real timeapplications sincemany functionsare too largeorcomplex f or any single task. For thispurpose, the kernel uses common or shared data areas call ed mailboxes, along with atableofpreassignedbitvariables,calledevents,tosync hronizetasks.Ataskcanplaceamessageinamailboxandsuspenditselfonaneventwait ing forareply.Thedestinationtask is signaled by the event, looks in the mailbox, res ponds through the mailbox andresetstheeventsignalingthereply.

EventsTasks communicate by exchanging data through mailboxes, whe reas they synchronizewith each other through events. Events are single bit flags that are global to all tasks.Therearefourtypesofeventflags:

1-63 software64-80 softwareresetting81-127 system

128 localtotask

Events1through63aresoftwareevents.Theyaresetan dresetbytasksandnotchangedbythetaskscheduling.Itispossibleforatasktosuspendit selfpendingasoftwareeventand then be rescheduledwhen the event is set. Depending on the application, one taskmusttaketheresponsibilityofresettingtheeventfor thesequencetooccuragain.

Events 64 through 80 are like the normal software events e xcept that the kernelautomatically resets the eventwhenever a task suspended on that event is rescheduled.Thus,onlyonetaskisrescheduledwhentheeventoccurs.Th eseeventsaresetandresetbytheSendMessagePointer(XSMP)andGetMessagePointe r(XGMP)primitives.

EventflagsEvent flags are global system memory bits, common to a ll tasks. They are used inconnectionwithtasksuspensionorothermailboxfunctions .

MessagebuffersVMEPROM maintains 64 64-byte message buffers for intertask communication. Amessage consists of up to 64 bytes plus a destination tas k number. There is also thepossibilitytosendmorethanonemessagetoanytask.


26

MessagePointers

VMEPROM supports shorter message pointer transfers betwe en tasks with the SendMessagePointer(XSMP)andGetMessagePointer(XGMP) primitives.Whenapointerissent,theevent [destinationmessageslotnumber+64] isset.Similarly, incaseamessagepointerisretrieved,thecorrespondingeventis cleared.

Tasksuspension

Any task can be suspended pending one or two events. In such a state, a taskwill notreceiveanyCPUcyclesuntiloneofthedesiredevents occurs.

2.3.2SoftwarecomponentsofVRS1

Processname FunctionINTER1 Receipt of hardware interrupts generated by the co-process or,

determination of the receiver-task and generation of a so ftwareinterrupt

BMVERT On-lineinterpolationandthehandlingoftheon-linetasksINIT MotionplanningERTV Usednearsingularities,wheretheconventionalinversek inematic

routinesdonotcomeupwithanoptimalbehaviourHTASK Frequentlyneededcomputations,mostlytransformationsSETINT Conversion of the exception vectors of the MC68020-CPU 29

intothoseoftheco-processorMC68882TRACE Bufferingofthe taskand result datastructuresfortracingREGLER ControlofthejointsROBO Task-schedulingofthemainCPUHAND Teach-inprogrammingoftherobotHART Criticalreal-timetasksin Hand operationmodeFYSY AccesstothefloppyandharddisksAUTO Automaticand Single-step operationmodesSENSOR ProcessesingofthesensorinformationsSPS ExecutionofPLCcommandsMEMPRO Controlofsomecriticalmemoryareasforsecuritypur posesMEMVERW MemorymanagementonthemainCPUDISPPER Outputoftheteach-pendant

Table2.2:SoftwarecomponentsofVRS1/HOC90/


27

2.3.3Thepathmodule

The path module consists of the processes INTER1, BMVERT, ERTV and INIT. It isresponsible for thetrajectory generation, including the calculation of interpolation stepswhich the manipulator joints have to follow for a given motion. To this module aremotiontaskstobesubmitted,whichcanbeoneofthefoll owingtypes:

Start-task Continue-task On-linetask

Basically,amotiontaskisadescriptionofthestart andtargetpositionstogetherwiththemotion typeaswell asanumberof additional parameters . If the robot is not already inmotion, a taskof type start has to be submitted. Following the submission, the proces sresponsible for the control of the joints will pick up the results from a special datastructureuntilthepathmodulereportsthatthemotionha scometotheend.

A task is submitted to the path module through a task structur e, which includes thefollowinginformations:

TaskcodewithmotiontypePositioninformationsTCPpositionRoll-Pitch-YawanglesoforientationJointvalues(12)forStartpoint(usedonlywithstart-tasks)TargetpointViapoint(usedforcircular&splinemotion)Additionalpoint(forsplinemotion)ToolvectorSpeedsatdepartureonthepathatarrivalAccelerationatthebeginningDecelerationatarrivalMaximumjerkRadiusoftheprecisionsphereWeavingparametersWeavingformAmplitudeAnglePlanePeriodSensorparameters

Figure2.6:Taskdatastructure


28

Theresultdatastructureisdescribedbelow:

TaskcodewithmotiontypeErrorFlagvariablesLastresultFly-bymodeactiveTCPpositionRoll-Pitch-YawanglesoforientationJointvalues(12)JointandTCPvelocities

Figure2.7:Resultdatastructure

If the arrival speed at a target is other than zero, in order to have a smooth cornerroundingatthatpoint, thepathmodulewill need toknow aboutthe following target.Acontinue-task is used to submit motion tasks one step ahead, thereby m aking someinformations (e.g. speed profile) belonging to the next m otion already available for aproperfly-bybehaviour.

An on-line task becomes particularly meaningful when the process i n which themanipulator is involved has to take sensor informations int o account and interrupts itsmotion.Theaction to be taken could simply be a veloc ity change or a jump to anotherprogrammed point or sub-program. On-line tasks are designed to cope with suchsituationsandbringhigherflexibility.

Belowisanexampleforatypicalprogramexecution:A tthebeginning,theTCPisatthepointP1.A start taskissubmittedtothepathmodulewiththecoordinates ofP2astarget.During the motion, before entering into the precision sph ere covering the target, acontinue task for circular motion is given. As the TCP moves t owards P4, a secondcontinuetaskisusedtodescribethenextmotion,whichwillbel inear.AtapointbetweenP4 and P5, a sensor could indicate that the target object i s near enough to halve thevelocityforasmootherapproach.Forsuchachange,an on-linetaskissubmitted.

P5

P1 P2

P3

P4

PTP

Circular

viapoint

Linear

P5

Figure2.8:Exampleoftasks


29

Thefigurebelowshowshowmotiontasksaresubmittedby thecontrollertothepathmodule.

Createatask

Waitforatask

Copythetask

nextpoint

distribute task

Dataexchange

preparetask

generateinterrupt

On-lineinterpolation

Endofthepathsegment

ControllerSoftwareOff-lineprocess On-lineprocess

PathModule

Figure2.9:TaskadministrationinVRS1/JAN91/

Determinethedirectionvectorandorientation matrix

Determinethevia-pointandorientation matrix

Determinesplineparametersandintegrate

Computethespeedprofile




PTP Linear Circular Spline

finished

Distributetask

loadglobalandtaskdata




Figure2.10:Taskpreparation/JAN91/


30

2.4ProgrammingwithVRS1

2.4.1Theteach-pendantThe basic element used for on-line programming is the tea ch-pendant. For the ease ofprogramming, a teach-pendant should be available there, wher e the manipulator isplanned to be used.This, however,would require that the co ntroller-box stands near totherobotintheproductionline,wherethespaceisusuall yquitelimitedandestimatedat5000DMper squaremeter. For this reason,Volkswagen designed its manipulators in awaywhichalloweddistances up to 100meters between the controller andmanipulator,lettingtheteach-pendantbepluggedintotheinstallation -boxoftherobot/BES95/.

By means of the VW teach-pendant (figure 2.11), programmers have access to allfunctionsthatthecontrollerVRS1offers.Thebasic elementsofthisdeviceare:

Display Functionkeys Jointmotions/Coordinatesystemskeys Numberblock DrivesOn/Off Operatingmodeswitches Approval/EmergencyOffkeys Joystick(optional)

F2 F3 F4 F5Joy-stick

KoorSyst

Neu-Start

CLR ESC

1V

2V

3V

4V

5V

6V

7V

ZNG+

ZNGAUF

ZNGZU

ZNG-

7R

6R

5R

4R

3R

2R

1RSHF

+/-

0 1

2 3

4 5

6 7

8 9

ANTRIEBEEIN AUS

Single-Step

Auto Hand

F1 FunctionKeysReturnKey

Joint/GrippermotionsDecimalKeypad

Joystick

ConfirmationbuttonOperationModeSwitchEmergency-OffSwitch

ActuatorsOn/Off

Display

VRS1

Figure2.11:TheVRS1Teach-pendant/VRS1/


31

DisplayThecommunicationbetweentheprogrammerandtherobotc ontrollertakesplacethroughthedisplay,whichoftenconsistsof liquidcrystalcell s.Alluser inputsaswellassystemmessageswillbeechoedonthedisplay.

FunctionkeysTherearethreetypesoffunctionkeys.Thefirstgroup issimilartotheoneonapersonalcomputer, allowing the user to move the cursor to a desired location. To confirm theentryofavarietyofparameters,theuser isexpected topresstheenterkeyorswitchtheoperationmode.

Thesecondgroupoffunctionkeysguides theuser throughthe menus,wherehealwayshas the possibility to jump from one parameter menu to an other and to build up hisprogramsflexibility.

Bymeans of the third group, one has access to the tool's functionalities (e.g. grippers,paint guns or more complex assembly-devices) which are to be executed during theprogram.

Jointmotions/CoordinatesystemsOne may use the joint motion keys to move each joint forward or backwards. Thecoordinate systems key allows to switch to a variety of motions as well as to selectcoordinatesystemssuchasbase,tool,flange,joint1an dexternal.

Thenumberblockisusedfornumericalentries.

DrivesOn/OffDuringtheprogrammingaswellas in theautomaticoperatio nmode,thisbuttonmaybeusedtoturnofftheamplifiersofthedrives.

OperationmodeswitchIn the Hand operationmode, programs can be enteredor edited. In this mode it is alsopossibletochangesystemsettingsandrundiagnosticpro grams.

Inthe SingleStep mode,therobotexecutesaprogramunder thecontrolof twobuttons.Thereleaseofoneof thesebuttonswillcausean imm ediatebrakingandstoppingof themanipulator.Asa securitymeasure, the programmermust b e keeping the Confirmationbuttonpressedwhenheispresentinrobot'sworkcelltoob servetheprogramexecutioninrealprocessspeed.

In the Automatic operation mode, the manipulator will execute the selecte d programwithoutpause.Inthismode,nobodyshouldbeinsidetheprot ectedzonewhichcoverstheworkcell.

Inadditiontotherobotmanipulator,thewholeequipment (transportband,elevators)canbeswitchedoffbypressingthe EmergencyOff button.

The joystick allows the motion of the TCP in cartesi an coordinates inside workcell,therebydefiningitsspeedbyintegratedpotentiometerswithi nthelimits.


32

2.4.2Teaching-in

Thestructureofarobotprogramcanbedividedintothree groups: Geometry Additionalinformations Text

Eachrobot joint isequippedwithsensorswhichdeliverinfo rmationsabouttheposition,speedandmotiondirectionof the joint.At theprogramm ingphaseof thegeometry, themanipulator is moved via joint-motion buttons or joystic k of the teach-pendant to thedesiredpositionandjointencodervaluesarestored.The sepositionscanbecritical,inthesensethatanactionmighthavetobeexecutedthere (suchasspotweldingorgrippingofanobject),ortheymayonlybeauxiliarypoints insert edforacollision freepath.Duringthe programming, each stored pose is assigned a position a nd a predefined sequencenumber. These stored positions build up a robot program. Th ough the geometry of aprogramdefinesthedesiredrobotpositions,itdoesnotspe cifyhowthesepositionsaretobereachedandwhattodothere.

As illustrated in the figure 2.12, each programmed pose include s the followinginformations:

Action : In its widest sense, the action specifies the input/ou tput values of thecontroller. These may be implemeted as gripper functions, on/off switching ofactuators or output of analogue signals, as well as wai ting for a condition beforemovingon.AswithPLCs,theseconditionsmaybecombine dinanumberofwaysastoachievewelldefineddependencies.

Dynamics/Path geometry : To this category belongs the interpolation type (PTP,linear,circular,spline,weave,twist),fly-byparamete r(radiusoftheprecisionsphere),acceleration(alsodecelerationandjerk)andspeed(begi nning,pathandarrivalspeeds)informations.Beginningfromthefirstpose,allthese parameterswillbeassignedtheirdefaultvaluesdependingonthemanipulatortype,someoft hemwillbeautomaticallycopiedintothesetofthefollowingposition.

kinematicinformations-speed-precision-acceleration-jerk-interpolationtype

geometricinformations-coordinatesasjointvalues-toolvector

processinformations

organizationalinformations

-Sensor-Weaving-Searchmode-Pliers-Ananlogueoutputs-PLC-Functions

-Endofpathrecognition-Cross-check-Jumppoints-Sub-programs-Wait-times-Documentation

Figure2.12:Poseinformations/VRS1/


33

Text : This section offers an on-line documentation of program s for the use ofmaintenancepersonnel.

Testingofprograms

After being taught, a program has to be tested before it is executed in the automaticoperationmode.Testsareaccomplished in the single-stepmode,where theprogrammerhastwochoices:Hecaneitherexecutetheprogramwit hamaximumspeedof25cm/minandletthecontrollerignorefurthersecurityconditi ons,orusethe Confirmationbuttontoallow the manipulator to move in real process speed. This button is equipped with aspringwhichallowsthreedifferentpositions:Released, fullypressedorhalf-pressed. Ifthe programmer does not keep the button in the half-pressed s tate, all drives will beswitchedoff..Duringthetest,thebiggestadvantageofusi ngrealmagnitudesintermsofspeedwillbetheavailabilityofrealisticcycletime s.

Ifarobotprogramdoesnotmeetthedesiredcriteriaat aspecificpoint,theinformationsofthispointcanbedirectlyedited.

The VRS1 controller supports also the shift, mirroring, r otation and copying of wholeprograms,whichcanbeverybeneficialinsymmetricalpro ductionlines.

Fly-bycapability

Usually, paths to be followed by robot manipulators consi st of a set of curves in thespace,atwhoseintersectionsdifferentTCPspeedswil lbeexpected.Besidethis,resultingsometimes from the motion type being used, the joint driv es can be subject tounacceptablyhighaccelerationratesinordertofollowa predefinedpath.

TheVWrobotcontrollerVRS1allowsacontrolled fly-b yat suchpoints,whosecrucialparameteristheradius rofaprecisionsphere.Asshowninthefigure2.13,thec ontrollerwill automaticallychange the radiusof this spherewhen ever the speed ratio is reduced.An important drawback of the fly-bymode is that the cor ners are only reached with agivendegreeofprecision.Ifapointhas tobe reached asexactly aspossible, thearrivalspeedtoitmustbeprogrammedaszero.

A

r V=100%r'

V=60%

A

B CB

AFigure2.13:Automaticalchangeofthefly-byzone/VRS1/


34

3.RCS-ModulefortheVolkswagenRobotController VRS1

TheresponsibilitiesoftheRCSVW-Modulemaybesum marizedas tocommunicatewiththeCAR-Tool inordertoreceiv eRRSservice

callsviainputblocksanddeliveroutputblocksfo rthem. to interpretRRScommands and convert them intoVRS 1s internal

format to allow simultaneous simulation of multiple robots by means of

initializingasmanycontrollersoftwares(pathmod ules)asneededForabetterunderstandingofthedatatypesandal gorithmsusedbytheRCSVW-Module,itwould behelpful to have a closer look at each c omponent of the pathmodule to seetheirworkingandthewaytheycommunicatewitheac hother.

3.1Thepathmodule

3.1.1Overviewofalgorithms

Atthebeginningoftheirexecution,acommonproce durefollowedbyallcomponentsofthe path module is to call an initialization functi on which will register their processidentifiers into a global data structure called system layout . In this way, each processallocatesaslotnumberforlateruse.

Secondly,eachcomponent initializes its localand someof theglobal variables.Finally,they all enter into their endless loops where they wait for specific software eventssignaling job-submissions for them. After working a nd producing output data, they allsignalthissituationbymeansofresettingtheeve ntstheyhavewaitedforandsuspendtillthenextjob.INTER1The process INTER1 may be considered as the main en try point of the path module,because the RRS-Interface uses this process to sub mit any kind of motion tasks.Originally, its role is to handle hardware interrup ts generated by the co-processor andgiveafurthersoftwareinterrupttotherelatedpr ocess.

BMVERTThis process is responsible for the calculation of interpolation steps during a motion.Before entering into its main loop, this program wi ll first also check the existence ofINTER1, INIT and ERTV by using message slots, and t hen wait for a reset task. Nomotiontaskwillbeprocessedunlessthesestepsar eproperlytaken.

In its endless loop, after being activated by the p rocess INTER1, BMVERT will firstwake up process INIT and wait until the latter comp utes a number of parametersindispensable for the on-line interpolation. Then, it will compute a motion step andgeneratea result eventsothateitherthejointcontrollertaskoft herealmanipulatorortheRCSVW-Module fetch the new joint values formotion. Before continuing, itwillwaitfortheresettingofthesame result event.


35

INTER1

Resetalltaskeventflags

fillinthesystem-layout

structure

suspenduntileventEV_AINT

resettheeventflagEV_AINT

VRS1ControllerSoftware

RCSVW-Module'sRRSservice:GET_NEXT_STEPTaskforthe

backgroundmathematics?

Copythetaskstructure

activatetheprocessHTASK

resettheeventflagEV_AINT

decodethetask-code

Start-typetask?

STOPtask?

seteventEV_STOP

SettheeventEV_AINT+1to

activateBMVERT

TheprocessHTASK

TheprocessBMVERT

yes no

yes

yes no

no

Figure3.1:FlowchartoftheprocessINTER1


36

BMVERT

initializememory


structure

TheprocessINTER1

available?

TheprocessERTV

available?

reporterror

exit

TheprocessINIT

available?

suspenduntileventEV_AINT+1

RESETtask?

resettheeventEV_AINT+1

TheprocessINIT

suspenduntileventEV_AINT+1

resettheeventEV_AINT+1

Start-typetask?

activatetheprocessINIT

viaeventEV_INIT

suspenduntiltheeventEV_INIT

isreset

lastresult

?

STOPeventset?

Calculatethenextinterpolationpoint

Processthesensorinformation

initializetheglobaltask-

controlstructure

suspenduntiltheeventRRS_EV_ERGisreset

Copythecomputedvaluesintotheresultstructure

settheeventRRS_EV_ERG

VRS1ControllerSoftware

RCSVW-Module'sRRSservice:GET_NEXT_STEP

yes no

noyes

noyes

no

yes

no

yes

no

no

yes

yes

Figure3.2:FlowchartoftheprocessBMVERT


37

INIT

communicatewithBMVERT


structure

suspenduntileventEV_INIT

makeacopyofthetaskstructure

calculatepathparameters

TheprocessBMVERT

ERTV

communicatewithBMVERT


structure

suspenduntileventEV_ERTV

resettheeventEV_ERTV

calculateinversekinematics

TheprocessBMVERT

resettheeventEV_INIT

Figure3.3:FlowchartoftheprocessesINITandERTV


38

During the design and developmentof the RCSVW-Modu le, particular effort has beenspent to keep the original controller software as i ntact as possible. This, however,required the implementation of some interprocess co mmunication tools of PDOS on aUNIXplatform.Forthisreason,thefirststephas beentodevelopasetofcommunicationservicesforthepathmodule.

The most important advantage of such an approach is that the original path modulebecomes fully portable on UNIX compatible systems. Throughout its design, theRCSVW-Module has been extensively tested on both IB M RISC/6000 and SiliconGraphicsIndigomachines,runningwithAIXandIRIX operatingsystemsrespectively.

Beforedescribingtheimplementationofthelibrary ,itwouldbeappropriatetogivesomebasicinformationaboutthetoolsavailableonmost UNIXcompatibleoperatingsystems.

InterprocessCommunication(IPC)toolsunderUNIX

There are several forms of interprocess communicati on, ranging from asynchronoussignaling of events to synchronous transmission of messages between the processes.Thesemechanismsallowarbitraryprocessestoexcha ngedataandsynchronizeexecution/DAN91//BAC86/.

Messages : The message type of IPC allows processes to communi cate through theexchangeofdatastoredinbuffers.Thisdataistr ansmittedbetweenprocessesindiscreteportions called messages. These can be sent or received by processes, which can alsosuspend their execution if they are unsuccessful at performing their operation. In otherwords, a process which is attempting to send a mess age can wait until the receiver isreadyandviceversa.

Beforeamessagecanbesentorreceived,auniquel y identifiedmessagequeueanddatastructuremust be created. Eachmessage consists of a message type, message size andtextaddressaswellasapointertothenextmessa geonqueue.

Sharedmemory :Processescancommunicatedirectlywitheachoth erbysharingpartsoftheir virtual address space and then reading and wr iting the data stored in the sharedmemory. Processesmay use system calls to create a new region of shared memory, toattachthemtotheirvirtualaddressspaceortode tachthem.

Sincethesystemcalls forsharedmemorydonotpro vide locksoraccesscontrolamongtheprocesses,thesemustsetupasignalor semaph orecontrolmethodtopreventaccessconflictsandtokeeponeprocessfromchangingdat athatanotherprocessisusing.

Semaphores : Thesemaphoresystemcalls allowprocesses to synch ronize execution bydoing a setof operations atomicallyon a set of se maphores.A semaphore is a positiveinteger,whichcanbe incrementedordecrementedvi asemaphoreoperations.Aprocesscan test for a semaphore value to be greater than a certain value by attempting to


39

decrementthesemaphorebyonemore than thatvalue . If theprocess is successful, thenthesemaphorevalueisgreaterthanthatcertainva lue.Otherwise,thesemaphorevalueissmallerthan it.Whiledoing this, theprocesscan have istexecutionsuspendeduntil thesemaphorevaluewouldpermit theoperation,orthe semaphore facility is removed.Theabilitytosuspendexecutioniscalleda blockingsemaphoreoperation .

3.1.2Developmentofaninterprocesscommunicationlibraryu nderUNIX

Inordertobeabletolettheoriginalpathmodule runonaUNIXplatform,oneneedstoprovidesomenecessary intertaskcommunicationproc eduresand relateddatastructures.For the development of the RCSVW-Module, the only f unctions which needed to beimplemented were the xsev (set event flag), xtef (test event flag), xsui (suspend untilevent), xgmp (get message pointer) and xsmp (send message pointer). Some otherfunctions such as xrts (read task priority), xstp (set task priority), asm and xpel werewrittenasdummyfunctionsandhavenofunctionalit y.

Though the system calls mentioned above dooriginal lymake use of system signals ofVMEPROM,ithasbeenobservedthatthestandardmes sageutilitiesonUNIXplatformswere much more suitable for the development of a re liable set of communicationservices.Forthisreason,byusingsomeadditional datastructures,the'eventsignals'havebeenimplementedas'messages'.Inthisway,whena processpendsanevent,itdoesnotactually make a pause system call, but gets blocked waiting for a specif ic type ofmessage.Similarly,thesettingofaneventdoesno tcausesignalstobegenerated,butasmanymessagestobesentasneeded.

Toprovide such a communication library, theRCSVW- Module needs two InterprocessCommunication (IPC) facilities, namely a message qu eue and a semaphore set.ThroughoutthedevelopmentoftheRRS-Interface,a numberofwaysofallocatingtheseIPCresourceshavebeenconsideredinmanyaspects andfinally,thetechniquewhichwillbedescribedherehasprovedtobeanacceptableso lution.

Atthispoint, itshouldbe indicatedthatthetype softhemessagessentthroughouttheselibrarycallsplaythemostimportantrole,whereas theircontentsarefixedandrelativelyshortstringsofrathersymbolicvaluessuchas wakeup! .The figure3.4 illustratesthedistributionofmessagetypesfordifferentroboti nstancesandeventtypes.

Message_type=(RobotNumber*1000)+Events_offs et+128+event_type

RobotNr.nEvent_offset

SettingeventsResettingevents

RobotNr.n+1Event_offset

SettingeventsResettingevents

0 Messagetype

Figure3.4:Messagetypes


40

Such a distribution allows the use of a single comm on message queue by many robotinstances, each of them having their own event flag s and message slots, expecting tocommunicatewiththeothermembersoftheirpathmo dule.Assuch, themessagequeuedoes not exhibit an important restriction in regard to the maximum number of robotinstanceswhichcanbesimultaneouslyinstantiated.

An important point to be considered herewould be t hemutual exclusion of the librarycalls bymany processes of a path module, which cou ld access to global variables andchangethemsimultaneously, leading towrongaction s.Topreventsuch inconsistencies,semaphoreshavebeenusedtocontrolaccesstoeven tflagsandmessageslots/BEN90/.

TheRCSVW-Modulehasbeendesignedtomakeuseofo nlyonesemaphoreset,whosevariables are separetely dedicated to the use of si ngle robot instances. Hence, themaximumnumberofrobotinstanceswhichcanbesimu latedinparallelisdirectlylimitedwiththeamountofsemaphorecountersavailablein aset.AtypicalvalueforthelatteronUNIXsystemsis25,beingthelowestlimitcompared withtheothersystemrequirementsofthemodule.

Eventflags

Event flagsunderVMEPROMareglobal booleanvariab les, accessible by all processesrunningonthesystem.However,theirmost importan t function is theautomaticwakingprocedureoftheprocesseswaitingfortheir(re)se t.

Aneventflaghasbeenimplementedasacharacterv ariabletogetherwithanarrayoflongintegers.The flagvariableisthestateoftheeventflag,whereast hearray sleeping isusedtostoretheprocess identifiersof theprocessesp ending them.Considering thatthepathmodule itself consists of four processes, the varia ble MAX_SLEEP_NUM has beendefinedasfive.Indeed,thearray sleepingcouldhavebeenreplacedwithasimplecountervariable,buthasbeenkepttoeasedebuggingeffor ts.

typedefstruct{charflag;pid_t

sleeping[MAX_SLEEP_NUM];}event_flag_type;

Ifaprocesswishestoaccessanyoftheeventflag sbymeansofa libraryfunction,itfirstmakesa semaphoreoperation to decrement thevalue of a binary semaphore counter (Poperation).After finishing itswork, it increments this valueagain (Voperation). In thisway, it canbe ensured that processeswill not ente r into critical code areas at the sametime.


41

xsev(seteventflag)

The setting of an event consists of two steps. Firs t, the flag variable is set to its newvalue. Then, the sleeping array is searched for nonzero entries to find out about thenumberofprocesseswaitingformessagesofthisev enttype.Ifsuchanentry is found,amsgsnd systemcallisusedtosendmessagesofaspecific typeinordertowakeuptheseprocesses.

xsui(suspenduntilevent)

Incaseaprocesswantstopendanevent,itfirst checksthestateofthateventflag.Incasethe flag has already got the desired value, the fun ction will simply return, letting theprocesscontinueitsexecution.Otherwise,thefunc tionwill lookforafree sleeping arraycell to register its process identifier and then ma ke a msgrcv system call to receive amessage,whosetypeisafunctionoftherobotinst ancebeinginvolved,theeventnumberaswellastheeventtype(setorreset).Inthisw ay,theprocesscanbeblockeduntilsuchamessageisputintothemessagequeue.


42

Psemaphoreoperation

suspendedprocessesentry?

Vsemaphoreoperation

return

Vsemaphoreoperation

return

xsev

sendmessage

Psemaphoreoperation

Eventalready(re)set?

Vsemaphoreoperation

return

enterpidassleeping

Vsemaphoreoperation

waitformessage

return

xsui

yes no

yes no

Figure3.5:Flowchartsofthecommunicationfunctionsxsevandxsui


43

Psemaphoreoperation

anymessage

?

anyprocesssuspended?

Vsemaphoreoperation

sendmessage

return

xgmp

clearthemessageslot

Psemaphoreoperation

anymessage

?

anyprocesssuspended?

returnOK

Vsemaphoreoperation

sendmessage

returnerror

xsmp

clearthemessageslot

Vsemaphoreoperation

noyes

yes no

yes no

yes no

Figure3.6:Flowchartsofthecommunicationfunctionsxgmpandxsmp


44

Messageslots

Similar to event flags, message slots are also glob al variables. They have beenimplementedusingthefollowingdatastructure:

typedefstruct{ pid_ttaskid; void*message; }message_slot_type;

xsmp(sendmessagepointer)

Thisfunctionwillassigntheprocessidentifierof thecallingprocesstothe taskidvariableandstorethemessagepointerargumentintothe messagevariable.Afterthis,aneventoftype (64+slot number) will be generated to wake up pending processes using the xsevfunction.

xgmp(getmessagepointer)

The function xgmp reads the message variableofa specificmessageslotand returns it scontents.Ifthemessageslotisempty,anerrorva luewillbereturned.

3.1.3Memoryrequirementsofthepathmodule

Originally,thepathmodulemakesuseofa systemlayout datastructurewhichdeterminesthe beginning addresses of other data structures.W ith this technique, there is only oneabsolutememory address that the controller softwar e (or the RCSVW-Module) has todetermine, namely that of the system layout . The individual processes making up thecontroller softwaredo all acquire this addressby meansof xgmp (getmessage pointer)calls, making them fully independent of specific me mory partitionings which can befoundonavarietyofhardwareplatforms.

Asitcanbeseen fromthedatastructurebelow,th econtrollersoftwareaccomodatesthenecessarydatastructuresandmodularitytosupport uptofoursimultaneouspathcontrol.However, this feature has only been used for test p urposes so far and has never beenimplementedforindustrialuse.

Arrayof30integers Themessageslotnumberthatpr ocesswilluseArrayof30integers TheprocessidentifierArrayof30integers Theprocessnumber(internalto themodule)Arrayof30integers Numberofthepathmoduletowh ichtheprocessbelongsArraysof5integersandpointers

Tracepointersandpathmodulenumbersfortrace-bu ffers

Arrayof4pointers Pointerstotheglobaldatastru ctureofeachpathmodule

System-layoutdatastructure


45

Althoughthismethodbringsahighdegreeof flexib ility,processesonaUNIXplatformhavetomakesomeadditionalsystemcallstoattach thesharedmemorysegmenttotheirvirtualaddressspace.UnderUNIX,sincetheshared memorysegmentsare identifiedbya system-wide valid integer value, the RCSVW-Module passes this identifier to thecomponentsofthepathmoduleasanargumentofthe execlp call.Thenextstepofthesechild processes is therefore to make a shmat (attach shared memory) call for gainingaccesstothissegment.

Thesharedmemorysegmentofeachrobotinstanceis illustratedinthefigure3.7.

Eventflags Messageslots

System-layout Motion-taskstructureResultstructure

RobotparametersMotionparameters

Globalcontrolstructure

Figure3.7:Sharedmemorysegmentofarobotinstance


46

3.2RCSVWinternals

3.2.1Datastructures

AsdescribedintheRealisticRobotSimulationInte rfaceSpecifications,anRCS-Modulemustbeabletoinitiateasmanyrobotinstancesas requiredbytheCAR-Toolandsupportsimultaneous simulation of all of them. For this pu rpose, the RCSVW-Module keepstrackof itsrobotinstancesbyusingadatastruct ureoftype robotinstance , inwhichthefollowinginformationsarestored:

Thestampoftherobot ProcessIDsoftheprocessesmakingupthepathmod ule Theidentifierofthesharedmemorysegment Thebeginningaddressoftheeventslotsinthesha redmemory Thebeginningaddressofthe systemlayout datastructure Controlflagsformotion Thekinematicmodeloftherobot CurrentOBJECT,BASEandTOOLFrames MatricesforOBJECT->BASEtransformationsandvice versa Controldatafordebugging

Therobotstamp

Thestampofarobotinstanceconsistsofthreecha racterstrings/RRS95/:

Manipulator type : This string is provided as a parameter by theCAR- Tool during theINITIALIZEserviceanddeterminestherobotdatafi letobeopenedbythemodule.ThefilenameresultsfromtheconcatenationoftheRob otPathNameandtheManipulatorTypeaccordingtothefollowingrule:

filename=RobotPathName+"r"+ManipulatorType+ ".org"

Originally, this robot data is available as an ASCI I file on the key-diskette of thecontroller.The advantageof this nomenclature is t hat thepresent setof available robotdatabecomestotallyaccessibletotheCAR-Toolwit houthavingtodefineanyadditionaldatatypesfortheRRS-Interface.

example: RobotPathName : /local/robcad/dat/ManipulatorType : vk010filename : /local/robcad/dat/rvk010.org

Controllerversion: Thisstringhasafixedvalue,whichis"VRS1".

Software version : In the same way as it is done in the original path module, thisparameter is read froma file named"version"under theModulePathNamedirectory. IntheRCSVW-Module, the date information is also appe nded to the version string. (e.g."VERSION001.9(date:20.05.94)")Incasesucha f ilecannotbe found,defaultvalueswillbeassignedtotherelatedvariables.


47

ProcessIDsofthecomponents

TheprocessIDsofthechild-processesmaybeextre melyuseful, inthattheyprovidetheRCSVW-Modulewith a means of checkingwhether the c omponents of a pathmodulestillexistornot.Incaseoneoftheseprocesses ortheoperatingsystemgeneratesakindofterminationsignal,theRCSVW-Modulemustbeabl etorealizethissituation,handleitproperlyandreportittotheCAR-Toolatthenext call.Forthisreason,eachRRS-servicecallispreceededbyatestofallsub-componentso fthepathmodulebeinginvolved.Thisis accomplished by generating kill system calls with null signals, which will performnormalerrorcheckingbutwillnotsendanysignal /STE92/.Ifanyofthesesystemcallsfail, other processes belonging to this path module will be terminated and the sharedmemorysegmentofthatrobotinstancewillberemov edfromthesystem.

Controlflagsformotion

Tokeeptrackofsomeeventswhichareinternalto thecontrollersoftwareandtoensureaproper submissionofmotion tasks, a control bit-fl agvariable has been introduced. The10leastsignificantbitsofthisflagvariableand theirusearedescribedbelow.

Continue-tasksubmitted

ProcessINTER1hasbeenactivated

Via-positionforcircularmotionhasbeengiven

Targetpositionforcircularmotionhasbeengiven

Via-positionreached

Stoppedduringmotion

IgnorelastresultflagwithCONTINUE

Fly-bymodeison

Targetposition set

Initialpositionset

01234567unusedbits 89

Figure3.8:Motioncontrolbit-flagsofarobotinstance

TheprocessINTER1hasbeenactivated.Thisbit-flagshowsthatamotiontaskhasbeensub mittedtothepathmodulebymeansofactivating the process INTER1. As illustrated in th e flow chart of the RRS-serviceGET_NEXT_STEP,thenormalprocedurefollowingsuch asubmissionwouldbetowaitfor theeventRRS_EV_RESULT,and then to fetch the result from the result structure.Afterthis,dependingonthevalueofthe lastresult variable,eitherthis flagortheeventRRS_EV_RESULTwouldberesettopickupanotherint erpolationpoint.

Via-targetposition(forcirculartypemotion)has beengiven.If the motion type is circular, two target position s are needed to define the pathunambiguously. This flag will make it certain that nomotion tasks will be submitteduntilthesetwotargetposeshavebeensetviaSET _NEXT_TARGETservice.


48

Targetposition(forcirculartypemotion)hasbeen given.Since the order inwhich the two targets are given is definitive for the selection of therightarctofollow,thisflagisusedtogetherwit hthevia-targetpositionflag.

Via-position(duringcircularmotion)hasbeenreac hed.Duringcircularmotion,thepathmodulewillreport thattheresultis the lastoneeven ifonlythevia-targetpositionisreached.However,t hisresultstatushastobe ignoreduntilthetargetposition isattained.Byusing this flag , theRCS-Modulecan findoutwhetherthelastresultreportisduetovia-ortargetpos ition.

RobotstoppedduringmotionThis flag enables the module to realize that a moti on task has been stopped by theSTOP_MOTION service. The service CONTINUE_MOTION ca n be successfuly usedwhenthisflagisset.

Ignorethe'lastresult=2'whencontinuingAsaresu

Realistic Robot Simulation

Documents

Transcript of Realistic Robot Simulation