What is the "proper" way to compensate for a (possibly) variable offset?
I have a robot arm -- Universal Robots UR5 & UR10 -- and I'm looking for the most natural way to compensate for the mounting location and angle of various grippers. Most grippers are not mounted in alignment with the tools own axis, so I have to adjust any Cartesian coordinates to ensure the gripper is in the right position. I need a solution that is flexible and simple, something that can be performed by a simple external node:
broadcast(transform(offest ... ) );
something like this. Is there any built in function that allows a different node to translate cartesian coordinates automatically to reflect the offset? Or do I need to make a small subroutine that calls:
transformpoint();
Asked by paturdc on 2014-09-08 05:02:04 UTC
Comments
The proper way depends a bit on the setup. Are those things changing during operation like a joint or is this something that you change the robot setup and want to easily reflect this when running?
Asked by dornhege on 2014-09-08 07:56:48 UTC
It doesn't change during operations, exactly, but I'd rather not put the data in the model, since some of the offsets are manually measured, with FK operations. So I prefer a solution where I can either broadcast or publish or something similar, in C++.
Asked by paturdc on 2014-09-08 08:29:38 UTC
Should this be variable during operation? Otherwise a simple static transform publisher with a config file might do.
Asked by dornhege on 2014-09-08 09:08:33 UTC
And calculate results using transformPoint ? That was my first idea, but the math gets a little tricky when the tool rotates, and my reference frame is static, because that changes the orientation of the offset. I gather there is no way to use an external transform a the ee_link?
Asked by paturdc on 2014-09-08 09:14:13 UTC
I would only publish the transform that you change and leave the rest that is fixed to TF.
Asked by dornhege on 2014-09-08 09:20:12 UTC
My question was more along the lines of how to utilize the data, once it is obtained. The coordinates passed to group.plan() still work with the center of the tool. I'm wondering if there is a built-in way to compensate, rather than manually work out new coordinates.
Asked by paturdc on 2014-09-08 09:52:32 UTC