Very small moves with ROS2/MoveIt and UR10e
I am setting up a UR10e with ROS2 to perform small incremental moves where an external process will occur at each location as the robot is moving. Eventually, I'd like to move the robot continuously and properly trigger that external process while the move occurs, but, in the mean time, I'm issuing commands to move to a position, run the external process, and then move to the next position. The step size we want to drive down as low as possible (definitely sub-millimeter -- hopefully approaching 100-500 um).
We are controlling this process from Python. Since there are not currently Python bindings for MoveIt on Humble, we have set up a simple C++ action server that passes the desired position to the MoveIt C++ API so that the Python code blocks until the move completes. We are currently using the cartesian path planner because it seems to do a better job at the moment of handling these small moves without flipping the end-of-arm tooling and also moving the joints of the robot the minimum amount possible while maintaining orientation.
However, when issuing a command to move a distance less than roughly 1 mm (I haven't measured it exactly), MoveIt immediately returns that the move was successful. My assumption is that this is a tolerance related issue (i.e., it is within the goal tolerance and therefore it's already in position and doesn't need to move). However, I am struggling to find the relevant tolerance setting.
I've called MoveGroupInterface::setGoalTolerance and set it to some crazy small value (currently 0.00005). It did have a marginal effect (maybe just slightly under 1 mm moves now inconsistently work), and decreasing it further has no effect. I'm only adding one point at a time to the waypoint vector, so, the jump and eef values given to computeCartesianPath shouldn't matter.
In the ur_controllers.yaml file, I've reduced the joint goal tolerance on both the joint_trajectory_controller and scaled_joint_trajectory_controller to 0.0001 with no effect (and no effect going smaller).
What am I missing? I'm pretty sure the robot is capable of making much smaller moves than this using the teach pendant. Is there anything I can do to troubleshoot the issue?
I'm using ROS2 Humble on Ubuntu 22.04 with the deb repo packages (except the UR driver and related dependencies which I'm temporarily building from source both to quickly edit the yaml file and because the packages that fix issue 677 only just made it through CI/CD and I haven't updated yet). The robot is the UR10e running the latest firmware.
Thanks!
Quick comment on this:
I'm not aware of any industrial robot that would be able to do this. Regardless of how it would be controlled (ie: natively, using the OEMs language, or externally, using whatever external control sw).
500 micrometres would be at least one order of magnitude below what a typical industrial robot could measure, let alone actuate its joints to (and linear motions would suffer even more from limited resolution, as the errors from the individual joints would combine until you get to the EEF/TCP).
could you describe how you've made sure of that?
I've done something similar a couple years ago (ie: try to move very short distances) and in my experience friction and other such effects basically just caused the joints not to move until the cumulative tracking error was so "large" that the servos "bumped" through the friction and moved the joint to the next measurable pose.
Reported position may be updated (although with micrometres I would be sceptical whether it's not just noise), but that's not a guarantee the physical robot has actually moved.
@gvdhoorn That's a great question. The teach pendant makes it look like it is incrementing, but perhaps it isn't. I have some tools I can use to attempt to measure this externally. Perhaps its time to actually get them out and check into this further.
@gvdhoorn Quick follow up. Just ran a test this morning with a high accuracy dial gauge attached to the end-of-arm tooling. I set up the robot so that I could just rotate the first joint for testing purposes with the distance between the axis of rotation and the dial gauge being about half the total possible distance (i.e. the arm is stretched to about half it's total reach). Using the teach pendant, I was able to consistently issue a command to move the first axis 0.005 degrees. This equated to a motion of roughly 5 mil -- or just over 100 um. Regardless, that is a distance that is quite a bit smaller than what I'm currently able to get MoveIt to move the robot. Obviously there are a lot of unknowns here still, but with all of the joints, it would seem like we should be ...(more)
Ok, good to hear. Joint motions != linear motions, but if you're happy, I guess we are.
Completely understood! I'm definitely very aware of the general limitations and know we are certainly pushing the limits. But, the current goal is to push the limits as much as possible.
And to be clear, this is a research application as opposed to something that is going to be going into end use. So, we really just want to get the best we can.
But, it does return to my original question if anyone has any thoughts. I'm going to start really digging in and trying to troubleshoot soon (and will update the thread if I figure it out), but, if anyone has any suggestions, they would be much appreciated!