search

moveit / moveit_ikfast

THIS REPO HAS MOVED TO https://github.com/ros-planning/moveit
12 stars 20 forks source link

Encoding the Base & Tool Frames of the IK Solver Into the Plugin #60

Open Jmeyer1292 opened 8 years ago

Jmeyer1292 commented 8 years ago

I've recently run into an issue that I wanted to put to the greater moveit_ikfast audience in the hopes of guidance on the best path to fix my issue: @gavanderhoorn @davetcoleman @jrgnicho

The scenario is this:

We generate an IKFast solution for a given kinematic chain, say base_link to tool0. This plugin will work for planning with respect to tool0. Now let's say that I will add a new frame tool_tip with a fixed transformation relative to tool0 and I wish to plan for this. I change the URDF and MoveIt SRDF configuration to add this new link to the move group, but I do not regenerate the IK. The kinematics will still solve poses as if tool0 was the active point. The plugin remains blissfully unaware of this discrepancy and will tell you that the solver tip frame is tool_tip.

Can you confirm that this behaviour is expected? If so, what do you see as the proposed solution.

It seems as if there is some need to encode the underlying IKFast's base & tool frames into the plugin and perform relevant translations there.

gavanderhoorn commented 8 years ago

Just a quick comment:

It seems as if there is some need to encode the underlying IKFast's base & tool frames into the plugin and perform relevant translations there.

I'm a bit of a minimalist, and I'd rather not have an IK plugin do transforms actually.

I agree there should be some checking somewhere, but it'd be better to extend the plugin(s) to return a specific error code whenever they are asked to solve for something they were not created/configured for: I consider it the callers responsibility to satisfy the pre-condition of expressing the query in the frame(s) the plugin was generated for.

Jmeyer1292 commented 8 years ago

@gavanderhoorn I think I agree with you. I'm just wondering if there's some way that we can encode the frames that the plugin was generated for. The solver will currently (incorrectly?) return the MoveGroup's frames as its reference frames.

gavanderhoorn commented 8 years ago

Storing the frames the plugin was generated for would be a requirement in any case, so we should add those no matter what solution we end up with.

That should also not be too difficult, as that information is available at the time the plugin is generated.

jrgnicho commented 8 years ago

I agree in that the base and tip links used to generate the plugin should be encoded into the plugin, however the initialize method will have to be changed accordingly in order to avoid having conflicting information about the kinematic chain (joint and link names) that the plugin is meant to support.