When the blend radius on a waypoint is too large, the robot skips that waypoint, or possibly several, and continues running.
My feature request is that instead of skipping the waypoint, it should skip the blend and convert the waypoint to a “stop at this position” instead of a blended waypoint.
Details: I’m running Polyscope 3.13.1.10297. I have a picking and placing program integrated with an inspection system that picks parts off a conveyor belt, inspects them, and then places them in either a shipping box or a disposal bin based on the results of inspection.
I did have blended waypoints to make the motion smoother and avoid hard stops, but kept getting the “Overlapping Blends in a [MoveJ or MoveL], a waypoint was skipped” errors. This would happen intermittently when it was picking up the part after inspection, and would manifest as missing the part and either flinging it randomly across the inspection surface or missing it altogether, which would result in a collision when the next part was placed.
First I tried reducing the blend radii, then tried changing from MoveL to MoveJ, and finally I resorted to removing all the blend radii associated with picking up the part from the inspection surface…ALL of them. Now every single point in the program that has to do with picking the part up and delivering it to a shipping box has been changed to a “stop at this point” waypoint…and this “Overlapping Blends” error is STILL HAPPENING. Intermittently.
The only blends left are applied to two waypoints on the way back to the conveyor belt, which are there to control the direction the wrist turns and prevent cord wrap on the way back to the picking position; and a couple blends as the part is picked and is on its way to be placed on the inspection table. These are the only blended waypoints left in the program. They are quite far apart and the blends are not large. If they are the cause of this error, then it is not just skipping a single blended waypoint. It is skipping multiple waypoints on the way to the blend. So I am very confused by this intermittent error.
In any case, it would be a better approach if instead of skipping a waypoint altogether, Polyscope would instead remove the blend and convert the waypoint to a “stop at this point” type. Safer too, as in less likely to cause collisions.
-Then the error code could read “Overlapping blends in a [MoveJ or MoveL], blends removed.”
-Troubleshooting would be easier too, because the user would be able to tell by watching which specific movements were ignoring blend radii and generating error messages. As it is now, finding the problem waypoint is difficult.
-It would be REALLY great if the problem waypoint could be highlighted in the program.
Hello Anna,
having the Overlapping Blend error without any blend radius in this part of the program seems weird. Have you tried debugging the program using the Support Log Viewer? This could help finding the root cause.
A lot of Skipped Waypoints often indicate there is potential improvement of the overall trajectory for the robot. The robot should indeed be able to run through the program without needing to skip a waypoint due to an overlapping blend radius. Otherwise the waypoint parameters or the overall path should be adjusted.
If this behavior is still present, after you have removed all blend movements, this could be a bug. With a minimum example of the behavior we can try to reproduce it and create a bug-report.
Hi Stefan,
I removed all the blends from the part of the program where it was skipping, but I still had blends on the way to and from the conveyor belt, and those were the only two places. So it wasn’t doing it with no blends in the program at all, but was rather skipping several stop waypoints before a blended one. I mean at least 4 or 5 of them. (I did use the log viewer, and it was helpful in tracking down when this problem was occurring.)
Some more pertinent details, because I think I finally found the problem: The robot is placing parts in one of two shipping boxes. When it receives feedback that one is full, it begins filling the other one, and triggers an alarm so an operator can remove the full box and replace it with an empty one. That means that mid-program, there are changes to the trajectory every few hours. I noticed that
A) these waypoint issues have only popped up since I introduced the two-box system…I had been running this program with many blended waypoints for a couple years, using a single drop point for inspected parts, and never saw this error before.
B) the skipped waypoints occur right after a box fills and the robot changes to the other box.
Since the waypoint on the way back from dropping the part in either box was one of the only remaining blended waypoints, I changed that single one to a stop point and I haven’t seen the problem again. (At first I didn’t think that waypoint could be the problem, because the robot was not skipping that point, but several others before it that were previously blended, and now changed to stop points)
It will be hard to reproduce because it is intermittent, but I can try to make a smaller program that will have this problem. It does seem problematic that it would skip so many waypoints and not just one, especially waypoints that weren’t blended. But at minimum, if the robot were to remove/ignore problem blends instead of skipping waypoints when the blends overlap, the problem would be less likely to cause collisions.
Further update on this problem:
I’ve discovered that the blended waypoints were not the root cause of multiple skipped waypoints. The skipped moves were inside of an if statement which was checking an input for high or low signal, and there is a problem with that input being interpreted as low even though it is high. Because this program started off working, began having this problem intermittently, and now has it all the time, I suspect hardware failure or damage of some sort. I will make a new topic describing that problem in more detail and link it to this one.