You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 13, 2017. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: