Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
machinekoder opened this issue Oct 16, 2020 · 6 comments
Open

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

machinekoder opened this issue Oct 16, 2020 · 6 comments

Comments

@machinekoder
Copy link

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
Copy link
Owner

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
Copy link
Contributor

gavanderhoorn commented Oct 16, 2020

@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: moveit/moveit#1014 (and rebase moveit/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
Copy link
Author

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
Copy link
Contributor

gavanderhoorn commented Oct 19, 2020

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
Copy link
Author

machinekoder commented Oct 23, 2020

@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
Copy link
Contributor

gavanderhoorn commented Oct 23, 2020

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").

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants