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

Add Gravity Feature, fix LinkFeatures_TEST #275

Merged

Conversation

scpeters
Copy link
Member

@scpeters scpeters commented Jul 9, 2021

🎉 New feature

This adds a feature for getting and setting the gravity vector in a World. This was motivated by a failing test in #261.

Summary

The LinkFeatures_TEST currently loads an sdf::World object then copies it in order to modify the <gravity/> SDFormat element, with a comment noting "// TODO Add a world property feature to set gravity instead of this hack". In ignition-physics3 and earlier, this was a useful hack, but it doesn't work in ignition-physics4 due to an internal change in libsdformat11. I've illustrated the problem by adding some failing test expectations in e270f65 that call sdf::World::ValidateGraphs. Loading the sdf::World from an sdf::ElementPtr does not work anymore; you have to load an sdf::Root in order for the FrameAttachedToGraph and PoseRelativeToGraph to be properly loaded. I believe this is also related to the test failures observed in #261.

To fix the issue, I've added World::GetGravity and World::SetGravity APIs in a new Gravity Feature in World.hh (
94048ea). The APIs use FrameSemantics.hh so you can specify the FrameID for the coordinates in which the gravity vector is specified. I then updated the LoadWorld function in LinkFeatures_TEST in ec232ac so it can load the world properly. I removed the LoadWorld function from ShapeFeatures_TEST in 573f001 since it has the same flaw but is unused.

Test it

Compile the code as of e270f65 and observe the failure of UNIT_LinkFeatures_TEST, and then observe that the test passes with the tip of the branch.

Checklist

  • Signed all commits for DCO
  • Added tests
  • Added example and/or tutorial
  • Updated documentation (as needed)
  • Updated migration guide (as needed)
  • codecheck passed (See contributing)
  • All tests passed (See test coverage)
  • While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge

@scpeters scpeters requested review from azeey and chapulina July 9, 2021 07:45
@scpeters scpeters requested a review from mxgrey as a code owner July 9, 2021 07:45
@github-actions github-actions bot added the 🏢 edifice Ignition Edifice label Jul 9, 2021
@codecov
Copy link

codecov bot commented Jul 9, 2021

Codecov Report

Merging #275 (af2023e) into ign-physics4 (5b5207d) will decrease coverage by 0.10%.
The diff coverage is 100.00%.

❗ Current head af2023e differs from pull request most recent head 9ce8fd5. Consider uploading reports for the commit 9ce8fd5 to get more accurate results
Impacted file tree graph

@@               Coverage Diff                @@
##           ign-physics4     #275      +/-   ##
================================================
- Coverage         75.40%   75.30%   -0.11%     
================================================
  Files               125      125              
  Lines              5433     5463      +30     
================================================
+ Hits               4097     4114      +17     
- Misses             1336     1349      +13     
Impacted Files Coverage Δ
dartsim/src/WorldFeatures.cc 85.18% <100.00%> (+2.20%) ⬆️
include/ignition/physics/detail/FrameSemantics.hh 100.00% <100.00%> (ø)
include/ignition/physics/detail/World.hh 100.00% <100.00%> (ø)
dartsim/src/SDFFeatures.cc 63.72% <0.00%> (-2.67%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5b5207d...9ce8fd5. Read the comment docs.

Copy link
Contributor

@chapulina chapulina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about adding unit tests to WorldFeatures_TEST?

dartsim/src/WorldFeatures.cc Show resolved Hide resolved
Copy link
Contributor

@azeey azeey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thanks for adding this feature.

/// \brief Implementation API for setting the gravity vector, which is
/// expressed in the World frame..
/// \param[in] _id Identity of the world.
/// \param[in] _gravity Name of gravity.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: "Name"->"Value"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/// (a quantity that contains information about the coordinates
/// in which it is expressed).
/// \return Relative Gravity vector.
public: RelativeGravityType GetGravity() const;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it now occurs to me that the two GetGravity functions will be confusing for compilers since they can both be called with no arguments and have different return types. I'm inclined to remove this one that returns RelativeGravityType

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's weird that the compiler doesn't catch this. I'd also vote for removing the function that returns RelativeGravityType.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed in 7fa6ab2


TestWorldPtr world = _engine->ConstructWorld(*sdfWorld);
EXPECT_NE(nullptr, world);
world->SetGravity(_gravity);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add an expectation on GetGravity just to exercise the API?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had intended to do that, but then I realized that I would need to move the AssertVectorApprox class definition up above this function in order to use it in the expectation. So I stalled out on doing it. I'll do it now though

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done in ef1012d

@scpeters
Copy link
Member Author

How about adding unit tests to WorldFeatures_TEST?

done in 315424c

Requires moving definition of AssertVectorApprox

Signed-off-by: Steven Peters <[email protected]>
// Get default gravity in link frame, which is pitched by pi/4
EXPECT_PRED_FORMAT2(vectorPredicate10,
Eigen::Vector3d(6.92964645563, 0, -6.92964645563),
world->GetGravity(linkFrameID));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

somehow this call to GetGravity is causing an assertion in KinematicsFeatures.cc

https://github.com/ignitionrobotics/ign-physics/blob/e21c8c9f94d364a10f0671ec1eb347f2c32c3348/dartsim/src/KinematicsFeatures.cc#L33-L40

related to call to detail::Resolve in detail/World.hh:

https://github.com/ignitionrobotics/ign-physics/blob/ef1012d9170f962756d8dfa7668d6a43a099eea9/include/ignition/physics/detail/World.hh#L82-L100

I think we should relax the assertion, unless I'm going something wrong here

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've disabled the assertion in 37d09ae

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if it hurts to ask the world frame what it's frame data is. Could be a problem for some physics engines? Looking at the code https://github.com/ignitionrobotics/ign-physics/blob/37d09ae717292623e6c1345efb26f66e458b0275/include/ignition/physics/detail/FrameSemantics.hh#L58-L62, maybe we should set currentCoordinates = RotationType::Identity(); if the _relativeTo is the world frame, as is done a couple of lines below.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ooh, that's smart. I could leave the assert unchanged that way

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've reverted the removal of the assert and followed your suggestion in 12b4cd4

@scpeters scpeters mentioned this pull request Jul 15, 2021
7 tasks
scpeters added 2 commits July 15, 2021 12:24
This reverts commit 37d09ae.

Signed-off-by: Steven Peters <[email protected]>
Avoid calling FrameDataRelativeToWorld for quantities relative
to the world frame but expressed in different coordinates.
This prevents an assertion in KinematicsFeatures.cc

Signed-off-by: Steven Peters <[email protected]>
@scpeters scpeters merged commit 164f088 into gazebosim:ign-physics4 Jul 16, 2021
@scpeters scpeters deleted the link_features_validate_graphs_4 branch July 16, 2021 03:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🏢 edifice Ignition Edifice
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants