Add bullet-featherstone plugin #373
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Louise Poubel <louise@openrobotics.org>
Signed-off-by: Louise Poubel <louise@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
That's an exciting failure mode... |
azeey
reviewed
Jun 30, 2022
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
|
I compiled the code in nao.mp4 |
Signed-off-by: ahcorde <ahcorde@gmail.com>
Codecov Report
@@ Coverage Diff @@
## gz-physics6 #373 +/- ##
===============================================
+ Coverage 73.69% 75.36% +1.66%
===============================================
Files 128 140 +12
Lines 5787 7068 +1281
===============================================
+ Hits 4265 5327 +1062
- Misses 1522 1741 +219
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
ahcorde
requested changes
Jul 6, 2022
ahcorde
requested changes
Jul 6, 2022
Signed-off-by: ahcorde <ahcorde@gmail.com>
ahcorde
requested changes
Sep 13, 2022
Signed-off-by: Michael Carroll <michael@openrobotics.org>
* Added Shapes Features to bullet-featherstone * make linters happy * Improve implementation * make linters happy * Fix bullet-featherstone collisions (#387) * Fixed collision issues * Improved joints in bullet featherstone Signed-off-by: ahcorde <ahcorde@gmail.com> Signed-off-by: Michael X. Grey <grey@openrobotics.org> Signed-off-by: Michael Carroll <michael@openrobotics.org> Co-authored-by: Michael X. Grey <grey@openrobotics.org> Co-authored-by: Michael Carroll <michael@openrobotics.org>
* Improved joints in bullet featherstone (#404) * Fixed ExamplesBuild * Fixed world test * Fixed joint test * Fixed kinematic features common test * Fixed kinematic test Signed-off-by: ahcorde <ahcorde@gmail.com>
Signed-off-by: ahcorde <ahcorde@gmail.com>
Signed-off-by: Michael Carroll <michael@openrobotics.org> Co-authored-by: ahcorde <ahcorde@gmail.com>
* Fixed bullet-featherstone mesh collisions Signed-off-by: ahcorde <ahcorde@gmail.com>
Signed-off-by: ahcorde <ahcorde@gmail.com>
* Bullet-featherstone Added detachable joints * decrease expectation joint_features attach/detacth Signed-off-by: ahcorde <ahcorde@gmail.com>
Signed-off-by: ahcorde <ahcorde@gmail.com>
Bullet featherstone: Added contacts and improved simulation tests Signed-off-by: ahcorde <ahcorde@gmail.com>
* Added FreeGroupWorld Velocities and minor fixes * If there is no CMD commands then I don't attach the motor to move the joint, because this will block the joint. Signed-off-by: ahcorde <ahcorde@gmail.com> Co-authored-by: Michael Carroll <michael@openrobotics.org>
* Add infrastructure for LinkFeatures * fix some issues * Added test * Fix joint attach test and tighten test constraints * Initialize to something to suppress compiler Signed-off-by: Michael Carroll <michael@openrobotics.org> Signed-off-by: ahcorde <ahcorde@gmail.com> Co-authored-by: ahcorde <ahcorde@gmail.com>
* Add some debug output for focal * Comment out flaky test Signed-off-by: Michael Carroll <michael@openrobotics.org>
mjcarroll
approved these changes
Oct 14, 2022
ahcorde
approved these changes
Oct 14, 2022
scpeters
reviewed
Oct 17, 2022
| @@ -34,13 +36,18 @@ class ConstructSdfCollision : public virtual Feature | |||
| public: using ShapePtrType = ShapePtr<PolicyT, FeaturesT>; | |||
|
|
|||
| public: ShapePtrType ConstructCollision(const ::sdf::Collision &_collision); | |||
|
|
|||
| public: ShapePtrType GetCollision(const std::string &_collisionName); | |||
There was a problem hiding this comment.
why was this API added instead of using GetShapeFromLink::GetShape?
Open
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🎉 New feature
Summary
This PR adds a
gz-physics-bullet-featherstone-pluginwhich wraps the Featherstone API of the bullet physics engine. This is created as a separate plugin fromgz-physics-bullet-pluginbecause the API of Bullet's Featherstone dynamics is different enough that there isn't really feature parity or easy interchangeability between them. Users will need to choose whether they are willing to settle for fewer features in exchange for the better performance of Bullet's Featherstone implementation.This PR depends on gazebosim/gz-sim#1560
Test it
I have been testing the plugin using the NAO demo world. Just download, unzip, and run
However, I have been noticing an inexplicable bug... The
bullet-featherstoneplugin works perfectly fine whengz-physicsis compiled inDebugmode, but fails to respond to changing joint force commands whengz-physicsis compiled inReleaseorRelWithDebInfomode. I don't have an explanation for this at the moment. I've tried compiling bullet from source in both single and double precision mode, but the effect is the same either way.The strangest part is that the initial joint force commands seem to be respected because the arms manage to remain pointing straight outward. Also if you adjust the position slider before starting the simulation, then the joint will manage to reach that position, but it stops responding to any changes after the simulation begins.
Checklist
codecheckpassed (See contributing)Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining
Signed-off-bymessages.