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.

Sign up for GitHub

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

Jump to bottom

iDynTree::KinDynComputations getFrameBiasAcc() returning slightly wrong data with FrameVelocityRepresentation = MIXED_REPRESENTATION #370

Closed
traversaro opened this issue Sep 6, 2017 · 11 comments
Closed

iDynTree::KinDynComputations getFrameBiasAcc() returning slightly wrong data with FrameVelocityRepresentation = MIXED_REPRESENTATION #370

traversaro opened this issue Sep 6, 2017 · 11 comments
Assignees
@traversaro
Labels
Severity: Major Type: Bug

Comments

@traversaro
Copy link
Member

See #368 .
@traversaro traversaro mentioned this issue Sep 6, 2017
Closed
@traversaro traversaro self-assigned this Apr 19, 2018
@traversaro
Copy link
Member Author

This is probably affecting your work @gabrielenava @S-Dafarra @GiulioRomualdi , but you are probably not seeing it because the base velocities are sufficiently small.

traversaro added a commit to traversaro/idyntree that referenced this issue Sep 12, 2018
@traversaro
Fix KinDynComputations::getFrameBiasAcc
5eec4d4 
Bug Fixes
---------
* Fixed cache invalidation bug in the getFrameBiasAcc method of KinDynComputations. The internal
  cache used by getBiasAcc was never updated even if the method setRobotState was called, so the
  getFrameBiasAcc method always returned the bias acceleration corresponding to the first call to setRobotState.
* Fixed getBiasAcc method in KinDynComputations to take into account the effect of non-zero and non-parallel
  linear and angular base velocity, described in robotology#370 .

New features
------------
* The getFrameAcc method that returns the acceleration of a frame was added to the KinDynComputations class.
  As this method takes in input every time the robot acceleration, it is computationally expensive and
  is not suitable to be used for multiple frames in a tight loop. If you need a computationally convenient
  method to access frame accelerations, please open an issue.
* It is now possible to specify a non-zero bias base acceleration as input of the ForwardBiasAccKinematics function.
  This is convenient if the bias acceleration that is being computed is the bias acceleration obtained with the
  MIXED velocity representation.
@traversaro traversaro mentioned this issue Sep 12, 2018
Merged
@ahoarau
Copy link
Member

ahoarau commented Sep 12, 2018 •
edited
Loading

@traversaro The default representation is mixed representation i assume ?

@traversaro
Copy link
Member Author

traversaro commented Sep 12, 2018 •
edited
Loading

Yes, anyhow there was actually a much more critical bug, see #482 .

@ahoarau
Copy link
Member

ahoarau commented Sep 12, 2018

Anyway to backport to iDynTree version < c++14 ?

@traversaro
Copy link
Member Author

traversaro commented Sep 12, 2018 •
edited
Loading

Agh, it should be doable. Which version is the latest < C++14?

@ahoarau
Copy link
Member

ahoarau commented Sep 12, 2018

I have 0.8.1

@traversaro
Copy link
Member Author

Just to understand, which OS+Compiler are you targeting? Are you planning to eventually move to some newer version or is some external constraint, i.e. robot with a fixed version of an OS?

@ahoarau
Copy link
Member

ahoarau commented Sep 12, 2018 •
edited
Loading

I'm just being lazy/scared to try the new version.
I had to make a few adjustments to embed it :

if (POLICY CMP0048)
    # cmake warns if loaded from a min-3.0-required parent dir, so silence the warning:
    cmake_policy(SET CMP0048 NEW)
endif()

Basically I'm lazy to do that all over again.

traversaro added a commit that referenced this issue Sep 12, 2018
@traversaro
Fix KinDynComputations::getFrameBiasAcc
5e25d54 
Bug Fixes
---------
* Fixed cache invalidation bug in the getFrameBiasAcc method of KinDynComputations. The internal
  cache used by getBiasAcc was never updated even if the method setRobotState was called, so the
  getFrameBiasAcc method always returned the bias acceleration corresponding to the first call to setRobotState.
* Fixed getBiasAcc method in KinDynComputations to take into account the effect of non-zero and non-parallel
  linear and angular base velocity, described in #370 .

New features
------------
* The getFrameAcc method that returns the acceleration of a frame was added to the KinDynComputations class.
  As this method takes in input every time the robot acceleration, it is computationally expensive and
  is not suitable to be used for multiple frames in a tight loop. If you need a computationally convenient
  method to access frame accelerations, please open an issue.
* It is now possible to specify a non-zero bias base acceleration as input of the ForwardBiasAccKinematics function.
  This is convenient if the bias acceleration that is being computed is the bias acceleration obtained with the
  MIXED velocity representation.
@traversaro
Copy link
Member Author

Fix cherry-picked on the top of v0.8.1: https://github.com/robotology/idyntree/tree/v0.8.1_fixes (don't worry for the Travis failure, it is related to the YARP part). We will try to handle your pan points so you can eventually use a modern version of iDynTree.

@ahoarau
Copy link
Member

ahoarau commented Sep 12, 2018

@traversaro I owe you many birras. Thanks Silvio !

@traversaro traversaro mentioned this issue Sep 12, 2018
Closed
@traversaro
Copy link
Member Author

Fixed by traversaro@5eec4d4 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@traversaro traversaro

Labels
Severity: Major Type: Bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ahoarau @traversaro