realistic robot simulation
Post on 13-Oct-2015
293 Views
Preview:
DESCRIPTION
TRANSCRIPT
-
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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.
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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.
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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/
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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.
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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.
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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/
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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.
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
4 movetoP3 SET_NEXT_TARGETP3loop:GET_NEXT_STEP(untilStatus=1)
5 movetoP4 SET_NEXT_TARGETP4loop:GET_NEXT_STEP(untilStatus=2)
P1
P2 P3
P4
Figure1.7:Motionexample
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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.
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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/
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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.
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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/
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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/
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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.
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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.
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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/
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
Computethespeedprofile
Computethespeedprofile
Computethespeedprofile
PTP Linear Circular Spline
finished
Distributetask
loadglobalandtaskdata
loadglobalandtaskdata
loadglobalandtaskdata
loadglobalandtaskdata
Figure2.10:Taskpreparation/JAN91/
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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/
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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.
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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/
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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/
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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.
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
36
BMVERT
initializememory
fillinthesystem-layout
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
37
INIT
communicatewithBMVERT
fillinthesystem-layout
structure
suspenduntileventEV_INIT
makeacopyofthetaskstructure
calculatepathparameters
TheprocessBMVERT
ERTV
communicatewithBMVERT
fillinthesystem-layout
structure
suspenduntileventEV_ERTV
resettheeventEV_ERTV
calculateinversekinematics
TheprocessBMVERT
resettheeventEV_INIT
Figure3.3:FlowchartoftheprocessesINITandERTV
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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.
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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.
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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.
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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.
-
RRS-InterfacefortheVolkswagenRobotControllerVRS1 G kselDedeo lu
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
top related