armtutorial4.pdf

7/23/2019 Armtutorial4.pdf

1/9

Arm Tutorial 4

Arm Tutorial 4 project build order

A) If you have built all the other projects from the previous solutions step bystep, you just need to build the projects in Column A.

B) If you havent built any of the previous tutorial solutions, you need to buildall included projects in the order shown in Column B.

Column A Column B

1. KUKATutorial4Orchestration

2. KUKATutorial4Dashboard

1. Util

2. KUKACommandTypes

3. ArticulatedArm (in abstractservices)

4. KUKAUniversalMotionPlanning (inabstract services)

5. SimulatedLBR3Arm6. KUKAArmTutorialSimulation

7. Transformation

8. KUKATutorial3MotionPlanning

9. KUKATutorial4Orchestration10. KUKATutorial4Dashboard

Queuing motion statements

Industrial robot programs usually consist of long series of motion commands.

These motion commands describe paths that move a tool to its destinationpositions, e.g. a grip position, a place position, a tool-reload position, or ofcourse process positions like welding spots or gluing paths. Often the pathsbetween process positions and non process positions need a couple of extrapoints that help maneuver the robotic safely in a very crowded cell.

Even today in industrial environments, path positions for a robot arm areusually recorded manually in a cell-ramp-up phase. For this, the operatorbrings the robot arm into position and uses a record function to tell the robothow to move to this position within the path. These recording steps generatethe list of motion commands. In more modern cases, paths come predefined

out of a CAD/CAM system. But even in these cases human operators usuallyneed to adjust path positions to fit the real cell environment, since the


2/9

simulation model and the reality never match completely. So also in the half-automated case robot operators need to deal with lists of adjacent motioncommands.

In this tutorial we want to show a way of how we can queue motion

commands for our simulated robot arm. The challenge in this highly parallelenvironment is not so much about where to define the queue, but how to waitwith the next command until the arm has finished the current command.

The dashboard has now a list control that queues motion commands. After acartesian or axis-specific target position has been entered, choosing themotion type (PTP or LIN) will add a motion command to the queue.

Unlike the previous tutorials, the robot will only move after the Start buttontriggers the execution of motion commands within the queue.In the following example, we queue three motions:

1) PTP motion to the cartesian position (-0,2; 0,2; 0,2);2) LIN motion to the cartesian position (0,2; 0,2; 0,2);3) PTP motion to the axis position (0, 0, 0, 0, 0, 0, 0);


3/9

Now we have a very simple path for the arm. It would be nice of course if youcould save or load these robot programs. A simple serialization of thecommand queue would already be a start, but since this is out of scope forthis tutorial we did not include this in our source code.

When pressing the start button, the upper most command in the queue is

processed. As soon as the motion is finished, the command is taken out of thequeue and the next command if available is processed. After theprocessing of each command, the end-of-move notification for theorchestration also contains the current position as axis values and in cartesiancoordinates. These are then posted to the dashboard. After finishing themovement, all commands reappear in the queue and they can be executedagain.


4/9

PTP

LIN

PTP

You will notice that the arm makes a short stop at the end of each motion.This is due to the fact that every motion is planned by itself with its ramps foracceleration and deceleration. Commercial robot controllers usually offer theprogrammer to define blended motions. When interpreting such a motion, the

controller knows that it shouldnt come to a stop at the destination point, but tocontinue with the next motion without loosing too much speed. To enable thearm to execute such a motion, the programmer needs to allow a certain pathdeviation around the destination point.

LINblended LIN

actual end-of-arm path in a blended motion

The blending algorithm is also out of scope for this tutorial and might comewith a future release. For now, since we offer the programmer to lookprogrammatically at several motion commands in the queue at the same timebefore motion execution, we encourage our readers to try generating ablending algorithm at this point.


5/9

Coding for Arm Tutorial 4:

All commands coming from the dashboard are sent to the orchestrationservice. So the only partner the dashboard needs to know is the orchestrationservice. In this case, it might seem overkill to insert an extra orchestrationservice between the dashboard and the arm. But already in the second mobiletutorial, when new devices are attached and controlled through thedashboard, the benefits of the orchestration service become clear.

Arm Tutorial 4 Services Overview:

New services for arm tutorial 4:

ArmTutorial4Dashboard: User Interface with an added listcontrol for queued motions

Orchestration: Queues motion commands for therobot arm

The diagram shows the two connections between the dashboard and theorchestration service:- Channel to the orchestration service: Adding commands, deleting

commands and start of the currentcommand queue

- Channel fromthe orchestration service: Notifications about changes in thecurrent command queue (e.g. when acommand has finished)


6/9

Sending commands to the orchestration service

In the following code snippet you see how a request for a PTP motion from

the dashboard service is processed. A new instance of the type PTPMove iswrapped into a DSSPOperationWrapper class. This wrapping is needed tobe able to send the PTPMove within the body of a CommandRequest. (umpstands for the universal motion planning proxy, where the PTPMove type isdefined.)

Then the wrapped object is put into a AddCommand request and sent to theorchestration port _orchPort.

/ / / / / / handl er f or PTP movements t o a poi nt def i ned by angl es

/ / / / / / ptp parameter s / / / tasks to perf orm I Enumerat or OnDr i vePTPHandl er( OnDr i vePTP ptp)

{/ / Generat e Oper ati onump. PTPMove op = new ump. PTPMove( ) ;

ump. PTPMoveReques t r eq = new ump. PTPMoveReques t ( ) ;req. Dest Poi nt = ptp. DestPoi nt;r eq. MoveType = ptp. Type;op. Body = req;

/ / Send operati on t o orchest rat i on servi ceyi el d return Arbi ter . Choice(

_or cMai nPort . AddCommand(new orch. AddCommandRequest ( new ut i l . DsspOperat i onWr apper(op) ) ) ,del egate( Def aul t Updat eResponseType r esp){

LogI nfo( "Successf ul Response recei ved") ;},Defaul t Faul t Handl er

) ;yi el d break;

}

The PTPMove object is ultimately derived from the abstract class

CommandType. This base class type is used for the command queue itself,so that all incoming command requests can be handled the same within theorchestration service.


7/9

Filling the command queue

The command queue is defined as a List of DsspOperations.

/ / / / / / Kukat utori al 4orchestrati on St ate

/ / / [ DataContr act ( ) ]

publ i c cl ass Kukatutori al4orchestrati onStat e{

L ist _operati ons = new List () ;

publ i c L is t Operat i ons{

get { return _operati ons; }set { _operati ons = val ue; }

}}

Any incoming command is processed in the AddCommandHandler. It isrequired for each command to be derived from CommandType. If this is thecase, the command is added to the command queue (_state.Operations) andis inserted into a notification object (not), which holds all current commandsin a list. This List is then sent back to the Dashboard through the subscribermechanism, so that the Dashboard can now update its queue display with thecurrent remaining commands in the queue.


8/9

/ / / / / / Handl er f or addi ng commands to t he queue

/ / / / / / command par amet er s

[ Servi ceHandl er( Ser vi ceHandl erBehavi or. Excl usi ve) ]/ / / tasks to perf orm

publ i c I Enumer at or AddCommandHandl er ( AddCommand command){

/ / Onl y add CommandTypes t o the Operat i onsToDo Li st and t he noti f i cat i on messagei f ( command. Body. Operat i on. Operat i on. Body i s commands. CommandType)

{ _s t at e. Operat i onsToDo. Add( command. Body. Operat i on. Operat i on) ;not . Body. Commands. Add( command. Body. Operat i on. Operat i on. Body as commands. CommandType) ;

}el se thr ow new Except i on( "Command t ype not support ed! ") ;

command. ResponsePort . Post ( Def aul t Updat eResponseType. I nst ance);

/ / update noti f i cati on and send i tnot. Body.DestAngl es = nul l ;not. Body.DestPosi ti on = null ;not . Body. SequenceFi ni shed = f al se;base. SendNoti f i cati on( _subMgrPort , not) ;

yi el d break;}

Executing the command queue

As soon as a Start message arrives at the orchestrationservice, the startmessage handler will process the command queue. As long as commandsare in the queue, the first command is examined to see the general type of thecommand. Depending on the type, the orchestration service decides on whereto forward this command. In the following code snippet, you can see that theop.Body is checked for being a UniversalMotionPlanningRequest. If that isthe case, the command is sent to the Motionplanning port (_mpPort), and twoanonymous handlers are activated for a fault or a success response.

The command TryPostUnknownType is used because the operation that issent is of the general type DSSPOperation. TryPostUnknownType willcheck by itself if any of the main port handlers of the target service can handlethis operation. If not, this function call returns false.


9/9

whi l e ( _stat e.Operati ons. Count > 0){

op = _state. Operati ons[0];

/ / Send message t o Moti on Pl anni ng ser vi cei f ( op. Body i s Ut i l . Uni versal Moti onPl anni ngRequest ){

success = _mpPort . TryPostUnknownType(op) ;

/ / Handl e the resul t, especi al l y t he f aul t

Por t Set resp = op. ResponsePort asPort Set ;yi el d return Arbi t er. Choi ce(

resp,del egate( ump. Uni versal Moti onPl anni ngResponse umpr) { },del egate( Faul t f ) {

notFaul t. Body.Recei vedFault = f ;notFaul t . Body. Commands = not . Body. Commands;base. SendNoti f i cati on( _subMgrPort , not Faul t ) ;except i onI nTarget Servi ce = true;}

) ;}i f ( except i onI nTarget Servi ce)

yi el d break;i f (! success) LogErr or( "Command not accept ed by recei ver ! " ) ;

/ / update state and noti f i cati on_s t at e. Operat i ons. RemoveAt ( 0) ;_s t at e. _f i ni shedOperat i ons. Add( op) ;not . Body. Commands. RemoveAt ( 0) ;

/ / Wait f or noti f i cati onyi el d return ( Arbi ter . Recei ve(

fa l se, _mpNot , del egate( ump. Noti f i cati onMoveFi ni shed not 2){

not . Body. DestAngl es = not 2.Body. Desti nat i onAngl es;not . Body. DestPosi t i on = not 2.Body. Desti nat i onPoi nt;base. SendNoti f i cat i on( _subMgrPor t , not ) ;

}) ) ;

}

/ / Af t er f i ni shi ng t he sequence, reset t he moti on commands and send not i f i cati onf oreach ( DsspOperat i on operati on i n _st ate. _f i ni shedOper ati ons){

_s t at e. Operat i onsToDo. Add( operat i on) ;not . Body. Commands. Add( ( commands. CommandType) operat i on. Body) ;

}_s t at e. _f i ni shedOperat i ons. Cl ear ( ) ;not . Body. SequenceFi ni shed = t r ue;base. SendNoti f i cati on( _subMgrPort , not) ;not . Body. SequenceFi ni shed = f al se;

yi el d break;}

Now that the motion planning service has answered the sent command witheither a success or a fault message, the code waits for a notification thatindicates that the motion is finished. Therefore a handler for the notificationNotificationMoveFinished is activated.

If the motion planning service answered the command positively with aUniversalMotionPlanningResponse, it will send a NotificationMoveFinishedas soon as the motion has finished execution by the arm. Then the destination

values of this position are written into a notification object from theorchestration service. This notification then is sent to all subscribers. In ourcode, this notification is received by the dashboard service that now showsthe new position values of the end of arm. Finally, the original commandqueue is restored and sent to the GUI.

armtutorial4.pdf

Documents