MoveP with CircleMove Deviating Significantly from Second Waypoint

Pythag

I wrote a program that has a MoveP with a CircleMove with three waypoints.

     MoveP

       corner1_start

       CircleMove

         corner1_mid

         corner1_end

The three points are variable waypoints that are defined by dimensional inputs, some math, and a pose_trans function from a manually define starting waypoint. I have no problem moving between these waypoints with a MoveL command, so I know my math is correct. However, I run into two issues when I try to use the MoveP with the CircleMove:

1. The TCP  does not pass through the second waypoint (cornern1_mid) as I intend. Also, it seems to deviate more noticeably when the corner radius decreases. I do not have this issue with MoveL commands. What could be causing this issue?
2. Wrist 3 over-rotates a consistent amount. As part of the pose_trans function, I specify a 90 degree (1.5708 radian) turn (e.g. p[x,y,0,0,0,-1.5708]). However, it will over-rotate about 10 degrees, so I have to set the last value to -1.4 radians to compensate for the over-rotation.

Again, I have no issues hitting those three way-points with a MoveL command, so I am highly confident that there is nothing wrong with the math. There must be something that I don't understand about the MoveP function that I am missing.

matthewd92

Are you confident that the three points lie on a circle and not an ellipse?  That has been an issue I have seen in the past, when I did not have the points on an actual circle it did some funny stuff.  Have you tried just teaching 3 known points that lie on a circle and see if the issue remains?

Pythag

Teaching the waypoints would not work for this particular application. It needs to be a variable waypoint.

Let's momentarily ignore the first issue that I mentioned in my initial comment, and focus on the second.

My MoveP is defined by three variable waypoints in the XY plane as a pose_trans from an initial position. Even if we assume the math behind the waypoints is flawed in a way that would cause any of the waypoints to fall slightly off from the expected/intended position, it still must be a circle. Because, a circle can be defined by any three non-collinear points. Right? So, I don't think it could possibly be an ellipse since there is only three points used in the MoveP.

Therefore, an improperly defined circled should not explain the over-rotation of wrist 3 during the MoveP. What else could cause this?

matthewd92

The thing to remember is that you are not defining a full circle, only half a circle, it takes two circle moves to create a full circle, so no, 3 points on a half circle do not guarantee that you will have a circle and not an ellipse.  As you can see in the example below, an arc passing through points 1, 2, 3 would create a circle, however, the arc passing through points 1,4,3 would create an ellipse.  I could move to any of these points though using a movel. 

Pythag

Would it not try to follow the green line? (Ignore green dashed section; it just shows the rest of the circle).

matthewd92

Basically, no it would not try to follow the green line, it would try to follow the black line, maintaining tangency to the 3 points.  I recommend reading this UR support site topic about using a circle move to create a 360 degree circle, maybe it will provide some clarification.

https://www.universal-robots.com/how-tos-and-faqs/how-to/ur-how-tos/circle-using-movec-16270/

Pythag

Thanks for the link, but I am not trying to do a full circle. I am looking to only do a small section of a circle with a 90 degree (1.5708 rad) turn on wrist3.

I am very confident in my numbers that define the variable waypoints. If I calculate the numbers by hand and plot them, the circle those points create plots my desired path almost exactly. In the screenshots below, my goal is to keep the vertex of that corner on the center of the circle, and as you can see it tracks pretty much identically. In theory, it should be even better than manually teaching the waypoints since the points are mathematically calculated.





I compare this to the actual waypoints on the robot with the same values (but using MoveL commands), and it looks almost identical. The dots shown on the paper are approximations with me trying to plot the tcp by hand on the tabletop with a marker. Note: the graph view is oriented where you would be looking up through the paper, but the points are the same otherwise.


I am 99% confident my XY coordinates are fine. It is the movement between those coordinates and the rotation on wrist three that is giving me issues when I use the MoveP with a circle move.

I am about ready to throw in the towel on the MoveP approach. Would it be possible to break this curve up into a series of MoveL's without pauses? I really do need it the movement through the curve to be as continuous/steady as possible.

matthewd92

Are your approach and departure angles tangent to the approach and departure point?  Yes, you could break up the move into a series of small movel moves, blend between them and you shouldn’t see stops. Another trick is to use a servoj script call and feed it coordinates off of your circle. If you know the formula of your circle so that you can find points along it you just need to feed a point every 8ms to the command. You will need to determine the arc length that you would cover at the speed you want to cover in 8ms and then that’s the new point. We do this on some arcs where we want to control the motion very precisely and the tcp orientation and it works well. Just be careful as whatever point you put in for the next point the robot will try to get there in 8ms. 

Pythag

Are your approach and departure angles tangent to the approach and departure point?

No. Do they need to be? The approach and departure is a linear move parallel to the Y axis in the positive direction, so it is a relatively sharp change in direction.

I have read about the servoj move, but I do not understand how to format the code.

Could you provide an example move, so I can see how it is supposed to be formatted. Or, point me to a resource to learn more about it?