Using Descartes with tool changing

asked 2019-09-19 14:12:35 -0500

Julien Audet gravatar image

Hello there,

I've been using Descartes quite a lot with no problem, using a generated IKFast plugin for my own UR10+tool setup (where the tool is pointing in the Y axis of the tool0 frame of the robot). I've seen in multiple posts that it's relatively difficult to integrate tool changes in ROS (modifying the robot_description during run-time doesn't seem a good idea). So I decided to use an attached collision object for the tool and use a generated IKFast plugin with a bare UR10 (base frame to flange) with Descartes. For path planning, all I need to do is transform the poses from tool tip to flange and let Descartes figure it out.

Unfortunately, I didn't think about the tool axis redundancy, which, normally, Descartes takes into account for figuring the joints values (when using AxialSymmetricPt). Because I use a bare UR10, the tool axis is not available, only the flange X, Y or Z axis. If there wouldn't be an offset between the tool axis and the flange, I could simply use the flange Y axis, but this is not the case. I've made a figure showing my problem (robot polishing a workpiece where the tool axis doesn't matter for example).

image description

So, my question is : is there a way to use Descartes with tool changing and still use that very useful tool axis redundancy management from Descartes? If this is not possible, instead of using an attached collision object as a tool, could I maybe use multiple IKFast files and multiple robot_descriptions for each robot+tool setups?

Thank you for your time,

Julien Audet

edit retag flag offensive close merge delete

Comments

An ugly solution is to create a new frame in the robot urdf and place it where my tool axis would be, although all my tools would need to be aligned with this axis, which doesn't make it a brilliant solution..

Julien Audet gravatar image Julien Audet  ( 2019-09-20 14:22:46 -0500 )edit

As long as something makes sure the TF frame that you'd like to use as a toolframe broadcasts the frame, it probably won't matter where it comes from -- or when it appears. So you may be able to just broadcast the frame when needed. And you can broadcast whatever frame is needed, no need to hardcode a particular pose.

gvdhoorn gravatar image gvdhoorn  ( 2019-09-21 11:27:39 -0500 )edit

Thank you, that makes sense! However, I think the IKFast plugin must be generated for a particular frame (therefore a particular pose), is that the case? Maybe I could just modify the inverse kinematics function in Descartes robot model (keeping a bare robot IKFast) and add a static transform to the tool tip so that it searches correctly through all the solutions? I wouldn't want to break Descartes though!

Julien Audet gravatar image Julien Audet  ( 2019-09-23 08:46:46 -0500 )edit

IKFast solvers are indeed generated for a particular kinematic chain, so using them with changing tips is not supported (or at least: I don't believe it is). The MoveIt wrapper for IKFast plugins has changed a bit with some recent PRs, so you may want to check that (but you'd also have to check whether Descartes' use of those wrappers is compatible with that new behaviour).

Performing lookups in inner loops of the IK solver is not something I'd recommend, as it's a very slow process (compared to the rest of the IK code).

It may be that the improved IKFast integration in MoveIt already does what you describe, that would be something to check.

gvdhoorn gravatar image gvdhoorn  ( 2019-09-23 10:08:20 -0500 )edit

I would only be performing a single lookup since it is a static transform between the flange and the tool tip, so it wouldn't really slow down the IK process (apart from the simple matrix multiplication), right? I'll go check the most recent MoveIt wrapper, thanks for the tips!

Julien Audet gravatar image Julien Audet  ( 2019-09-23 12:14:17 -0500 )edit