Coordinated MultiMove system

leonardolt

Hi, has anyone worked with coordinated syncronizes multimove sytems and could explain me how do the working object, tool and robtarget orientation work together to find the final robot wrist position and orientation?

 I read the multimove application manual several times but I could not figure out how stuffs work in this system. Specialy, I don't undestand how to create, starting from zero, my own corrdinated syncronized multimove cell.
 Maybe I don't have the experience needed, but my impression is that the information available on this subject is rough and inconplete.

 Thanks in advance for any help.
 Leo

Henrik Berlin

Hi,

The basic idea is like this

1. Start by creating your program for the tool robot using a fixed workobject.

2. Attach the workobject to the workpiece robot

3. Create a path with exactly the same number of instructions for the workpiece robot as for the tool robot. This is needed even if you want the robot to stand still. I would recommend you to create a "dummy" program that matches the tool program but does not make the robot move. This is to take it one step at the time.

4. Add the Sync instructions before and after the path

5. Add the IDs to the move instructions. Use the ID to map the instructions of the tool robot and the workpiece robot to one another.

6. Run the program

7. Now you may want to adjust the program of the workpiece robot to make life easier for the tool robot.

 

RobotStudio has a feature to distribute the motion of a programmed path onto both the workpiece robot and the tool robot. You can also define constraints for e.g. joint values and tool angles.

 

This was the short version, but probably you had already got to this stage.

leonardolt

 Thank you for your reply, Henrik.

 In my first atempts to create a multimove system I followed exactaly these steps you pointed, but I gess my problem is in the 2nd step, on attaching the working object to the workpiece robot. When I try to do this my program halts by an unrecoverable error. So, I wonder if you could give me more details abous this. It seems that the problem in my system  is related to defining the robhold and ufprog of the workobject and the tool.

 The other poit I want to ask you is about the orientation of the robot that is holding the workobject. As long as I understand, in this robot the tool orientation is, indeed, the working object final orientation. On the other hand, the working object orientation is the orientation of the coordinated system placed in the TCP. Its XYZ coordinates are the coordinates of the robot base coordinate system upon the TCP working object. Am I right?
 I got to these considerations yesterday after creating this topic, so they are based in some experimental results. Until now I could not figure out the meaning of the robtarget coords and orientation, but that's the next step.

 I'm very conscious that this post got really confused, so I'm sory for that. One of my expectations on discussing this is to clarify some ideas.
 Thanks
 Leo

Henrik Berlin

For details about the workobject definition please check the MultiMove Application Manual.

webwiz/772/MultiMoveAppMan_3HAC021272-001_revH_en.zip 

 

Of course, the MultiMove feature makes the robots move coordinated but it may be helpful to think about it in the following way. (assuming we have a synchronized MultiMove program with one tool robot and one workpiece robot.)

1. The workpiece robot moves to the position specified by the move instruction of its program. The robot uses the programmed tool, which may be tool0, or any user-defined tool. The workpiece robot can use any (fixed) workobject for its motion. It may (or may not) be helpful to define the tool to coincide with the workobject moved by this robot (i.e. the workpiece robot). But there is no dependency between the tool of the workpiece robot and the workobject that it moves.

 

2. The tool robot moves to the robtarget of its program. The robtarget is defined relative to a workobject. And the workobject is (in the MultiMove case) moved by the workpiece robot.

 

Henrik Berlin2010-05-21 14:59:27

leonardolt

Hi, Henrik.

 Thanks for your reply. I read this MultiMove application manual, but it did not solve all my doubts about the orientation of the multimove system. Whit your post I understood that the moving workobject has nothing to do with workpieceholder workiobject. Now, I still have some doubts, but I could put the system to work in the desired orientation in some empirical way. At this time it's enough for some experiments.

 I have a pair of robots here that need to work in sync and coordinated mode. I tried to configure the multimove in this system. At the first time it seemed that everything went fine. But when I program the workpieceholder robot to move over 30mm/s the moving gets "particulated", as if I used fine zone for all points. The issue is that I'm not using fine zone, but a 5mm one. Another thing is that is I enable only one robot, the movement gets perfec at any speed.
 Do you know if this behavior under higher speeds is normal? Is there anything I could do to overcome this?

 Thanks a lot
 Leo

Henrik Berlin

I don't know, but perhaps the motion of the workpiece robot will be affected by the zones of the tool robot. (Are they fine-points?)

 

Anyway, moving the topic to the RobotWare forum.

leonardolt

 No, they are not. I'm using 5mm zone. There is another fact that prevents me of thinking abou a zone problem: when I star the movement, some moves are done very well, just as it should be. Just after, it starts moving in that "stop and go" way. I looks like the path moves are stored in a kind of queue. Thus, the first moves that are alredy stored are done perfectly, but soon the queue gets empty, because the controller can not fill in new movements faster then the robots moves.

 Any sugestions abou how could I overcome thins? Are there any "test procedure" that could help me in seeking for the solution?

 Thanks
Leo

leonardolt

Dear Henrik,

 Watching to this Fanta can challenge video (http://www.abb.com/product/seitp327/f0cec80774b0b3c9c1256fda00409c2c.aspx) I saw that when the operator moves the joystick all the robots move together. In my Multimove system that does not happen. So, I realy think I', missing something in the configuration os the system.
 Can you provide me an example of a program using this kind of coordenation?

 I advance, I post here the pieces of my code where I tried to configure the multimove:

! Workpiece robot:
PERS wobjdata wSNews02_R1:=[FALSE,TRUE,"",[[1347,0,0],[0.50833,0.508325,-0.491536,-0.491528]],[[-0.0009375,-0.00280142,0.000715256],[1,-3.06331E-06,-2.29495E-06,-1.10501E-05]]];
PERS tooldata tR1_FFScanC01:=[TRUE,[[0,0,405],[0.9239,0,0,0.3827]],[0.5,[0,0,250],[1,0,0,0],0,0,0]];
PERS robtarget pIniSN02 := [[0,0,50],[0,0,1,0],[0,0,0,1],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
PERS tasks Task_list{2} := [ ["T_ROB1"], ["T_ROB2"] ];

PROC Main()
IF NOT(IsSyncMoveOn()) THEN
    SyncMoveOn SyncOn, Task_list;
ENDIF
ClearPath;
StartMove;
ENDPROC


! Tool robot:

PERS wobjdata w_SNews03_R2:=[FALSE,FALSE,"ROB_1",[[1000,0,00],[0,0,0,1]],[[0.0001177,-0.00143051,0],[1,1.91842E-06,-5.31972E-06,1.16336E-05]]];
PERS tooldata tFFScan03 := [TRUE,[[0,0,405],[1,0,0,0]],[0.5,[0,0,250],[1,0,0,0],0,0,0]];
PERS robtarget pInicioR2:=[[0,0,300],[1,0,0,0],[0,0,0,1],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
PERS tasks Task_list{2} := [ ["T_ROB1"], ["T_ROB2"] ];

PROC Main ()
IF NOT(IsSyncMoveOn()) THEN
    SyncMoveOn SyncOn, Task_list;
ENDIF
ClearPath;
StartMove;
ENDPROC

 Can you see anything wrong in this declaration? Is there anything else I should have done?

Thanks a lot
Leo

mattdavis

if you put the tool robot's active workobject to the the workholding workobject and then move the workholding robot the tool robot should follow (even jogging with the pendant)

it's same as moving a rotator with the robot positioned in the workobject moved by the rotator. My system does this in jog mode anyway, I have many times accidentally left the robot in the rotator workobject and then tried to jog the rotator only to have it tell me its out of reach and see the robot all stretched out 20m away.

leonardolt

 Well, I don't know where is my mistake, but I have the coordinated workobject (w_SNews03_R2) active on the tool robot and it does not move when I jog the workholding robot. Am I missing something?

 In my application the robots are put one in front of the other. Thus, when the workpiece robot moves in +X (workpiece robot base coords) I need the tool robot to folow him moving its arm backwards in -X (tool robot base coords). Unfortunately, that's not what happens. The tool robot also moves its arm in +X direction.
 I tried rotating the tool robot's object frame coord system (oframe) to see if it understands that the workpiece robot is in front of it, rotated 180A?, but it didn't work. The tool robot moves and reorients its tool as I change the oframe. The problem is that it seems to move its reoriented TCP as if the workpiece robot was just overlaying it.
 So, how sould I program the robots for undestandig that  they are mounted like this: 0--     --0?

Sorry for so many doubts, but I have no experience in this Multimove world.

mattdavis

I'm not 100% sure but I think you need to rotate the base frame of your robots (and it would help to give them the correct distance apart).

If you are working in robotstudio then place the robots and building a system from layout should do this for you.

leonardolt

 Mattdavis, thank you for the reply.

 I tried to calibrate the tool robot's base frame using the relative calibration method. That worked perfectly. Now I have both robots working coordinated with no mispositioning or misorientation. The coordinated jogging situation is also solved. So those are buried problems. Thanks again.

 From now on I'll focus on another problem. Maybe you can also help me on this issue: The two robots are moving over their pre-defined points. These points are spaced 5mm one from another, and the zone is 2. In low speed (20mm/s) the motion is soft, once I'm not using fine zone. When I set the speed to 40 mm/s a part of the path is done softly. In the rest, the robots move in a stop-and-go way, as if i was using fine zone. Do you have any idea about what could be happening?

Thanks so much for all
Leo

mattdavis

if you check the error log are you getting lots of Corner path failure errors?

If you have a 2mm zone and 5mm in between points there is very little room between the zones and if the robot is already inside the next zone when it get around to doing its calculations it will give this corner point error and motion ends up very similiar to a fine point.

I had the same issue with pipe cutting with points about 20mm apart and 5mm zones, try dropping the zone size or increasing the distance between points. z0 will still perform smooth motion, it is very different to fine point and maybe what you want.

leonardolt

 Manipulating the zone size didn't produce any substantial difference. I also changed the Prefetch Queue time. Increasing it up to the maximum made the movements smooth for a longer time, but did not solve the real problem. I also noticed that id I stop the arm switching MotorsOn to off, when I restart the motion, the robot moves smoothly for a distance and then starts stop-and-going again.

 After this experiments I'm pretty sure that this problem is more related to CPU overload than to zone settings. I'm saying that because whne I put only one robot to work, disabling Multimove functionality, the whole path is done perfectly.

 More than increasing std_servo_queue_time, is there another thing that can be configured that would improve system's performance?

 Thanks
 Leo

leonardolt

 By the way, I forgot to say, I can't increase the distance between points because each point is a measurement checkpoint. This measurement has nothing to do with rapid programming, it's performed automaticly by te tool.
 I'll take this opportunity to register that changing Path Resolution, Queue Time, CPU Load Equalization and Process Update Time parameter had no or little effect in the stop-and-going problem. Until now, only the Queue time produced a reasonable result.

leonardolt

 Well, for those who want to know the end of this story, I finally got rid of stop-and-going moving. I realized that in the multimove moving sequence there were sequences of repeated SyncID. I just replaced them for unique IDs and that was enough for a whole smooth move all over the path.

 So, I want to thank for everybody thar helped me on this post.
 Best regards
 Leo