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

Link Wrench Estimation #11

Open
jeljaik opened this issue Jun 27, 2014 · 15 comments
Open

Link Wrench Estimation #11

jeljaik opened this issue Jun 27, 2014 · 15 comments

Comments

@jeljaik
Copy link
Contributor

jeljaik commented Jun 27, 2014

Still pending for Version 0.2

@jeljaik
Copy link
Contributor Author

jeljaik commented Feb 6, 2015

Any update on this @traversaro? Can I maybe help somehow?

@jeljaik
Copy link
Contributor Author

jeljaik commented Feb 10, 2015

c.c. @rbonghi This is the issue I was telling you about. We have to wait for @traversaro to fix/add this in the yarp-WholeBodyInterface.

@traversaro
Copy link
Member

Sorry guys, at the moment is a bit difficult to find the time to implement this, unless it is a top priority.
However if someone wants to tackle this issue, the necessary steps are to mplement a new estimate in yarpWholeBodyState, namely ESTIMATE_EXTERNAL_FORCE_TORQUE. The necessary information are already published in the contacts:o port of wholeBodyDynamicsTree, it is just necessary to parse them and translate them in the right frames.

@traversaro traversaro changed the title End Effector Wrench Estimation for Right and Left Arms Link Wrench Estimation Mar 3, 2015
@traversaro
Copy link
Member

All stakeholders interested in this feature (cc @rbonghi @DanielePucci ) can provide a description of what they would expect from this block (considering frame of expression issues and other technicalities)?
P.s. consider also this : robotology-legacy/codyco-modules#39

@DanielePucci
Copy link
Contributor

So, as you mentioned in robotology-legacy/codyco-modules#39, the method

get(ESTIMATE_EXTERNAL_FORCE_TORQUE, fake_link)

should return the force/torque expressed w.r.t. the fake_link, that is, point = origin of the fake_link, orientation = orientation of the fake_link. In the case "fake_link" is a "real link", the method should return the force/torque expressed w.r.t. it. What do you think @traversaro ?

@traversaro
Copy link
Member

So do you like the ESTIMATE_EXTERNAL_FORCE_TORQUE to return the force oriented as the local frame? Take into account that this could be an inconsistency with the velocity estimates and their jacobians , that are expressed with the orientation of the world frame and with the point of the "fake_link" frame.

@DanielePucci
Copy link
Contributor

No sorry, I confused fake_frame with a sort of additional frame. I think that the method should be something like

get(ESTIMATE_EXTERNAL_FORCE_TORQUE, frame)

and then it returns the force/torque expressed w.r.t. "frame". Probably, in most control applications, the orientation of this frame is going to be kept equal to that of the world frame, thus being consistent with velocities.

@traversaro
Copy link
Member

Sorry, how the get(ESTIMATE_EXTERNAL_FORCE_TORQUE, frame) is able to get the link of which you want the external wrench?

@francesco-romano
Copy link
Contributor

get(ESTIMATE_EXTERNAL_FORCE_TORQUE, linkID, frame) returns the wrench on link linkID w.r.t. frame specified in frame. Optionally If frame is null it returns the wrench w.r.t the link frame.

?

@jeljaik
Copy link
Contributor Author

jeljaik commented Mar 4, 2015

Sorry guys I can start working on this just tomorrow... you know why.

@traversaro
Copy link
Member

@francesco-romano The getEstimate signature is fixed in the wholeBodyStates, and it just accepts one numeric index. We can certainly change it, but it would adding a new non generic method to the wholeBodyStates interface. On the short term I would prefer to have something working with the existing interface.

@francesco-romano
Copy link
Contributor

@traversaro from the simulink point of view:
We can get the estimate of the wrench in the link reference frame and the frame transformation from the link frame to the required (user input) frame and apply it to get the final result

@traversaro
Copy link
Member

+1 .

Actually the frame of expression is quite prone to misunderstanding: when you mean wrench expressed in a frame (for example the world frame) you refer to both the point of expression and the orientation. For now (for example the jacobians and the velocities estimates) we are assuming (and the user can't change this, for now, at least at the WBI/WBI-Toolbox level) that the point of expression is the one of the frame, while the orientation is the one of the world/inertial. For this reason it may be more useful to specify both the point of expression and the orientation of the requested estimate.

@azadm
Copy link
Contributor

azadm commented Jan 5, 2016

any update on this? This block seems to be necessary for dealing with compliant contacts.

@traversaro
Copy link
Member

Hi @azadm , reading the estimate of the external wrench is definitely important at the moment.
I will provide you with an estimate on when this will be ready Thursday (tomorrow is holiday here in Italy).

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

No branches or pull requests

5 participants