Home› Programming
Discussion
Back to discussions page
Pythag
Posts: 5 Apprentice
MoveP with CircleMove Deviating Significantly from Second Waypoint |
263 views
|
Answered | |
/ Most recent by Pythag
in Programming
|
8 comments |

in Programming
I wrote a program that has a MoveP with a CircleMove with three waypoints.
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:
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:
- 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?
- 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.
Tagged:
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?
Would it not try to follow the green line? (Ignore green dashed section; it just shows the rest of the circle).
https://www.universal-robots.com/how-tos-and-faqs/how-to/ur-how-tos/circle-using-movec-16270/
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.
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?