search

JeroenDM / moveit_opw_kinematics_plugin

An attempt at writing a MoveIt! plugin for opw_kinematics.
http://wiki.ros.org/moveit_opw_kinematics_plugin
Apache License 2.0
7 stars 7 forks source link

How to tell IK that tool0 is upside-down #70

Open machinekoder opened 3 years ago

machinekoder commented 3 years ago

For better usability we flip the tool0 frame upside down in our application. Is there a way to tell OPW to use an additional offset for the forward/backward kinematics?

JeroenDM commented 3 years ago

No, I do not think there is. Which, now that you ask it, seems very strange to me. I feel like I'm missing something... @simonschmeisser How do you handle this?

Personally, I use the OPW solver without the this MoveIt wrapper. (You can see some leftover code of exactly your use case here).

gavanderhoorn commented 3 years ago

@machinekoder wrote:

For better usability we flip the tool0 frame upside down in our application. Is there a way to tell OPW to use an additional offset for the forward/backward kinematics?

How exactly is it "upside down"? Compared to what?

@JeroenDM wrote:

No, I do not think there is. Which, now that you ask it, seems very strange to me. I feel like I'm missing something...

Personally, I use the OPW solver without the this MoveIt wrapper. (You can see some leftover code of exactly your use case here).

Isn't the idea that the IK solver is to solve the IK for the chain defined by base_link -> tool0 (ie: the base robot kinematic chain)? That's a stand-alone and reusable piece of functionality.

Solving for different tool frames, which I believe the code you link to @JeroenDM allows, should not change the base IK solver. The planning software should adapt the queries such that they're suitable for a particular solver (ie: transform goals to tool0, or whatever the tip frame of the IK solver is).

This is of course only one approach -- and MoveIt has implemented the alternative (similar to what your commented code does @JeroenDM) but only if the transform is across a non-movable joint: ros-planning/moveit#1014 (and rebase ros-planning/moveit#1320). Personally I'm not a fan of this, but that doesn't matter, it's one approach that works.

I'd still be interested to know what @machinekoder actually means by "upside down": if it's a tool frame other than a default "all zeros" toolframe, imho it should not be the responsibility of the IK solver to "compensate" for that (and it's also not what tool0 is for: it's not a generic toolframe, but a special one: an all zeros or default one).

machinekoder commented 3 years ago

With upside-down I mean that tool0frame orientation is all zeros when point downward, it seems some industrial robot arms use this configuration and others have tool0 z point downward. See the screenshot attached: image

gavanderhoorn commented 3 years ago

I mean that tool0frame orientation is all zeros when point downward

Are you referring to tool0s orientation relative to some external origin?

Because the "all-zeros" in the description of the tool0 frame refers to it's transform relative to its parent. Not a global reference (sometimes called world or base).

machinekoder commented 3 years ago

@gavanderhoorn Yes, so the tool0 orientation is aligned with world. I've also seen other robots that rotate tool0 90 degrees, but well, the additional rotation/offset shouldn't affect the kinematics. all-zeros means all joint positions zero, right?

gavanderhoorn commented 3 years ago

Is your tool0 always world-aligned? That would seem strange to me.

all-zeros means all joint positions zero, right?

no. It refers to all the configuration entries of a toolframe definition being 0 (ie: unconfigured) or having their default values.

For most industrial robots, this would make the origin of the toolframe lie on the flange. For some robots, it would make tool0 coincident with flange (as they define their flange frame to be located "on the physical flange").