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

Feature: Calculate wrench in end effector frame. #46

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

matthias-mayr
Copy link
Contributor

I want to put this up for discussion. If there is interest, I can add a service for it.
Things to discuss are:

  • relevance for other people
  • double-check the math
  • pseudo_inverse is only copied, so it appears twice in the code if this PR is not changed
  • sign convention: our UR outputs wrench values with opposite sign

I also do have an executable that fetches joint states and external torques and publishes the wrench. I can make this a part of iiwa_tools as well if there is interest.

For reference: #19, #27

@costashatz
Copy link
Collaborator

  • relevance for other people

I think this is good to have! Thanks!

  • double-check the math

I think the math is OK, but the naming conventions not that much. Can you explain in 3 sentences what ee_wrench is computing? What is the input (type, and vector dimensions)? What is the output?

  • pseudo_inverse is only copied, so it appears twice in the code if this PR is not changed

This is OK since we would need another library to be able to port this to all packages. Except if we make this function part of iiwa_tools, since CustomEffortControllers already depends on iiwa_tools.

  • sign convention: our UR outputs wrench values with opposite sign

This is just a convention. We should follow KUKA's convention. Which sign are they using in their packages for this?

I also do have an executable that fetches joint states and external torques and publishes the wrench. I can make this a part of iiwa_tools as well if there is interest.

I am not sure if this is necessary...

@matthias-mayr
Copy link
Contributor Author

I think the math is OK, but the naming conventions not that much. Can you explain in 3 sentences what ee_wrench is computing? What is the input (type, and vector dimensions)? What is the output?

Should be done with 574a76a.

  • sign convention: our UR outputs wrench values with opposite sign

This is just a convention. We should follow KUKA's convention. Which sign are they using in their packages for this?

The easiest way I see to verify this is to run iiwa_stack since they forward it to ROS.
Is there an easier option?

I also do have an executable that fetches joint states and external torques and publishes the wrench. I can make this a part of iiwa_tools as well if there is interest.

I am not sure if this is necessary...

I guess, I could just put it in some repository in my Github account. I just want to avoid that people need to write the same code again.

@costashatz
Copy link
Collaborator

The easiest way I see to verify this is to run iiwa_stack since they forward it to ROS.
Is there an easier option?

No idea. We can just clarify it in the docs. Can you write it somewhere?

I guess, I could just put it in some repository in my Github account. I just want to avoid that people need to write the same code again.

Sure! Feel free to do anything of that sort! Sharing code is always good. ;)

@costashatz
Copy link
Collaborator

@matthias-mayr any news on this? This seems ready to be merged, no?

@matthias-mayr
Copy link
Contributor Author

Not quite. If I am not mistaken the naming and documentation is wrong. It says:
// Calculates the external wrench in the end effector frame.
But iirc, the Jacobian is in "world"/"URDF root" coordinates, so my understanding is that it should say "external wrench in the root frame", is that right?
I can push a subsequent commit then.

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

Successfully merging this pull request may close these issues.

2 participants