Dear,
I have two joint positions and I use movel to let the robot move betwen them. The robot reaches the proper positions. I tell the robot to move with a velocity V. If the tool flange of the robot moves parallel to my TCP, everything is fine. However, if the tool flange movement of the robot is not parallel to the TCP, the TCP velocity is either to low or to high. It seems that the robot moves at the given speed in movel , e.g. its own movement is executed at that speed instead of having the TCP speed being the given speedā¦
How to fix this? Or how do I calculate the proper speed orrection so the TCP moves at the desired speed?
Regards,
Max
As a note, the movel is located in a script file, not in the program tree. Which TCP is then used? You can select a tcp in the program tree, but thereās no such paramter in the script command. Iām using only a single (default) TCP, by the way, so I assume it uses the default for the movel calculations?
If you are using script you can use two URscripts that should be useful:
set_tcp(pose) # sets the TCP offset from wrist_3 p[āmetersā,āmetersā,āmetersā,ādegā,ādegā,ādegā]
get_tcp_offset() #returns current tcp offset from wrist_3
Since you are using URscript you will also need to use trans_pose() to have movement with respect to tool. Check this link out: Moving WRT to custom feature/tool
Anyways hope this helps and best of luck!
Hello Michael,
thank you for your answer, unfortunately, itās not the positions that Iām having trouble with, itās the velocity.
Iām using a CB3 with sw version 3.7 (itās a bit dated, but alas)
Some more information.
I use 6 joint positions for the robot to move to, with movel(J_pos,a,v). the robot gets there, but at the wrong speed. changing to movel(get_forward_kin(J_pos),a,v) doesnāt help, and also movel(get_forward_kin(J_pos,p[ā¦]). (were p[ā¦] is the TCP pose) doesnāt help.
I changed the movel into movep() crashes, but movep(get_forward_kin(J_pos,p[ā¦]) works a lot better! I did, however noticed that with certain moves, movep() starts fine, does the move but then abruptly stops, causing the robot to go into itās safety limits. Iām guessing that the movep() runs into certain problems internally, but I get no error codes or other details giving me some clue.
The documentation is rather poor at best. Also, why doesnāt movel() move with the proper speed, even though the TCP has to make a lineair move? Some documentation regarding the proper operating conditions would be very helpful.
Hi,
You donāt specify whether you are indeed using set_tcp() to set the TCP to where you want it before the moveL ā¦ are you doing this?
If you are then the problem might be that some safety setting is inhibiting the joint speeds or TCP speed. Maybe you are trying to make a move the robot is physically incapable of too.
Hello,
Yes, I do use set_tcp(), just to be sure the robot uses the proper TCP. I only have one TCP defined and itās active. I also use the TCP parameter, so al versions use the same TCP. The move is well within the reach of the robot and the TCP speed is 6.3mm / sec, which is rather slow. The movel() can make the move just fine, but not at the right speed (it uses the 6.3mm/s to change its pose). Simply swapping movel() with movep(), does give me the proper speed at the TCP, the move starts gently, has a gentle cruise but then suddenly / abruptly stops at the end of the move, as if āsomeoneā slammed the breaks.
If I have a similar move, but with a much larger radius, you cans still notice the brute stopping, but is way less violent and actually acceptable. I make a circular move with the TCP on a 45 degree angle from vertical, so the robot tool head has to make a larger move then the TCP. The TCP distance in Z is 300mm, so there is a significant speed difference between the head and the TCP, but with a TCP speed of only 6.3mm/sec the robot should still be well within itās limits. This can be witnessed by nice ramp up and nice cruise, itās just the āhard stopā at the end of the move. Why does this happen? Why does it brake so violently? Can someone shed some light on the implementation of movep()?
Met vriendelijke groet,
With kind regards,
Mit freundlichen GrĆ¼Ćen,
Med venlig hilsen,
Con cordiali saluti,
Max van Rooij
OK, so then I have some more questions and a suggestion :
- How are you actually measuring the TCP speed to see if it is accurate? Are you using some external measurement sensor or using a timer within you program perhaps?
- Is this for a CB3 or e-series robot?
- IF you are just making a linear move only, and you are getting better results via moveP then to get rid of the abrupt stop at the end of the move use a stopl(decel) command where āādecelāā is something appropriate to stop but not jerk (requires experimenting).
- This TCP distance of 300mm is rather extreme and so I think this might be exacerbating the problem.
- If youāre really trying to do a circular move using moveP with nested moveC and you want to exit the circle in a smoother fashion then try something like this sequence shown below :
01 MoveJ
02 Start
03 MoveP
04 BeginningCircle
05 MoveC
06 ViaPt1
07 EndPt1
08 MoveP
09 TangentLeavingCircle
10 MoveL
11 ClearOfCircle
Hi,
Iām using a CB3. Measuring speed by measuring distance and using an external timer. I did some back of the envelope calculations and found that toeards the end of the move the robot is still speeding up, which would result in abrupt stoppage. I need to re-program my entire move to see if I can control the speed discontinuity. But this has to wait 2 weeks due to summer break. Iāll post morel details then, some pictures too, to clarify what Iām doing (I need permission for that)
Met vriendelijke groet,
Max van Rooij
As promised, I hereby give some additional information. Picture a shows the basic situation. We have a tool, with TCP 0,120,300 mm. Itās angled at 45 degree with the horizon (base of the robot is on a flat level, horizontal plane). Itās 3mm away from the reference corner as shown. Image B shows the desired target move location. The tool is again 3mm away from the reference corner, but now along the other edge of the object. The angle turned about the vertical is 90 deg.
Setting this target for a movel() works, but the robot moves at the wrong speed (the robot moves at the target speed, not the tool), so the move is performed very, very slowly. If I swap out movel for a movep, the robot literarily crashes. A shock move results and the robot safety kicks in. Weāve been lucky not to damage anything. However, if I change the target tool position to as shown in image C, movep() does work fine. Tool speed is ok, no shocks or safety limits being violated. It requires the move to be exactly at the reference corner (so not 3mm out) and the tool has to be 90 deg rotated about its Z axis.
However, victory is short lastedā¦ since doing this at a different location or with different tool orientations, it still crashes the robot. And we cannot have the tool āstand stillā at the corner location while the robot makes its moveā¦ (weāre dispensing something)
One āsolutionā was, however, successful, kind of. We now use movel() but instead of setting a and v we use the t parameter. The move is executed correctly in whatever way we want, total time used is spot on, butā¦ the acceleration / deceleration curve of this function is ridiculously slow!! Like it takes forever to speed up and it takes forever to come to a stop. The documents say a and v are ignored, but some control over this weird speed up / down would be niceā¦
So does anyone have a proper solution to this? How to make this move? Or how can we make movel(t=ā¦) behave in a more sane manner?