Movep not reaching target TCP orientation

Technical Questions
,
1

Hi,
I am trying to create paths with tightly controlled TCP velocities. In general movep has been working well for this. However, I have recently realized that movep does not seem to respect the target TCP rotation vector. At least not in the way I would expect.

As an example you can try the following commands one at a time on a UR10 (reproducible in simulator).

movep(p[0.6,-0.1,0.2,0.0,1.6,0.0], a=0.5, v=0.3, r=0.0)
movep(p[0.6,-0.2,0.2,0.0,1.4,0.0], a=0.5, v=0.3, r=0.0)

Try going back and forth a couple times and note that it reaches the end positions correctly but it does not reach the target rotation.

Screenshot from 2017-09-28 21-10-36
Screenshot from 2017-09-28 21-10-361812×1620 47 KB

If you call a subsequen movep command with a different position but the same orientation, it then gets closer to the target orientation.

The next plot is the result of these three moves
movep(p[0.6,-0.1,0.2,0.0,1.4,0.0], a=0.5, v=0.3, r=0.0)
movep(p[0.6,-0.2,0.2,0.0,1.6,0.0], a=0.5, v=0.3, r=0.0)
movep(p[0.6,-0.1,0.2,0.0,1.6,0.0], a=0.5, v=0.3, r=0.0)

Screenshot from 2017-09-28 21-17-46
Screenshot from 2017-09-28 21-17-461741×1622 41 KB

I find this really strange. I’m hoping someone will have some insights.

Thanks,

Gabe

1 Like
2

You cannot realistically expect constant speed when blend radius is set to 0. It might be an artifact resulting from that limitation. Try 3 points with non zero blend radius instead.

3

Thanks @mmi but that doesn’t really explain what is going on here. A blend radius of zero is supposed to indicate that you should stop at the waypoint - which is what I want. In my actual application this is occurring at the last waypoint in a sequence. I use a blend radius of zero because it is the last waypoint and I want to stop there.

The robot is coming to a stop and, as I said before, the translational goals (x, y, z components of the target pose) are being met just fine. It is just the rotational portion of the pose that is not being reached. The TCP comes to a stop at the correct x, y, z position but not the correct orientation, which is a problem.

4

You’re right I verified this behavior.
Rotation error is reduced if you add waypoint that continues along path without tool rotation, or when you insert waypoint between last two, close to the last one.

5

I’ve noticed a similar problem. When you have three waypoints that you travel through using moveP, you never reach the last waypoint. This is with only translation, and no rotation vector. If you have three waypoints in only the x-axis, with a 50mm blend radius, you’ll stop roughly 45mm from the last waypoint. if you use an 80mm blend radius, it’s closer to 73mm. It seems the moveP command also needs a deceleration value for the last waypoint because the physical body can’t come to a stop instantly so there is some non-zero deceleration value. I can get the robot to safety stop if I end in a moveP command. If you try delivering moveP commands via scripting, you can get the robot to safety stop because it jerks so bad at stop points even with 40% waypoint pitch blending.