Open Jmeyer1292 opened 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.
@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.
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.
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.
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 @jrgnichoThe scenario is this:
We generate an IKFast solution for a given kinematic chain, say
base_link
totool0
. This plugin will work for planning with respect totool0
. Now let's say that I will add a new frametool_tip
with a fixed transformation relative totool0
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 iftool0
was the active point. The plugin remains blissfully unaware of this discrepancy and will tell you that the solver tip frame istool_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.