gazebosim / gz-physics Goto Github PK

Abstract physics interface designed to support simulation and rapid development of robot applications.

License: Apache License 2.0

CMake 0.84% C++ 97.87% C 1.12% Jupyter Notebook 0.16% Shell 0.01%

ignition-physics physics-engine ignition-robotics robotics gazebo robotics-simulation cpp physics physics-3d physics-interface

gz-physics's Introduction

Gazebo Physics : Physics classes and functions for robot applications

Maintainer: scpeters AT openrobotics DOT org

Build	Status
Test coverage
Ubuntu Jammy
Homebrew
Windows

Gazebo Physics, a component of Gazebo, provides an abstract physics interface designed to support simulation and rapid development of robot applications.

Motivation

Many physics simulation software libraries have been designed for different applications (gaming, robotics, science) and with different features (rigid or deformable contact, 2d or 3d). Gazebo Physics is designed on the premise that there is not a single physics engine that is universally best for all simulation contexts. It should be possible to support a different set of features for each physics engine according to its capabilities. A physics engine can then be chosen for each application based on its context.

Features

Gazebo Physics provides the following functionality:

Granular definition of physics engine features as optional API's.
Plugin interface for loading physics engines with requested features at runtime.
Features for common aspects of rigid body dynamic simulation
- Construct model from SDFormat file.
- Collision shapes (such as box, sphere, cylinder, cone, capsule, ellipsoid, mesh, heightmap).
- Joint types (such as revolute, prismatic, fixed, ball, screw, universal).
- Step simulation, get/set state, apply inputs.
Reference implementation of physics plugin using dartsim.
A custom physics engine focused on fast kinematics of large environments, the Trivial Physics Engine.
CompositeData structures for efficiently using native types in API.

Install

See the installation tutorial.

Usage

Please refer to the examples directory.

Documentation

API and tutorials can be found at https://gazebosim.org/libs/physics.

You can also generate the documentation from a clone of this repository by following these steps.

You will need Doxygen. On Ubuntu Doxygen can be installed using
```
sudo apt-get install doxygen
```

Clone the repository

git clone https://github.com/gazebosim/gz-physics -b main

Configure and build the documentation.

cd gz-physics; mkdir build; cd build; cmake ../; make doc

View the documentation by running the following command from the build directory.
```
firefox doxygen/html/index.html
```

Testing

Follow these steps to run tests and static code analysis in your clone of this repository.

Follow the source install instruction.
Run tests.
```
make test
```
Static code checker.
```
make codecheck
```

Folder Structure

Refer to the following table for information about important directories and files in this repository.

gz-physics
├── bullet                    Files for bullet plugin component.
├── bullet-featherstone       Files for bullet-featherstone plugin component.
├── dartsim                   Files for dartsim plugin component.
├── example                   Examples about how to use the library
├── heightmap                 Heightmap related header files.
├── include/gz/physics        Header files.
├── mesh                      Files for mesh component.
├── resources                 Model and mesh resource files used by tests.
├── sdf                       Files for sdf component.
├── src                       Source files and unit tests.
├── test
│    ├── benchmark            Benchmark tests.
│    ├── integration          Integration tests.
│    ├── performance          Performance tests.
│    ├── plugins              Plugins used in tests.
│    ├── regression           Regression tests.
│    └── static_assert        Tests involving compilation failures.
├── tpe
│    ├── lib                  Implementation of TPE engine.
│    └── plugin               Files for TPE plugin component.
├── tutorials                 Tutorials, written in markdown.
├── Changelog.md              Changelog.
└── CMakeLists.txt            CMake build script.

Contributing

Please see the contribution guide.

Code of Conduct

Please see CODE_OF_CONDUCT.md.

Versioning

This library uses Semantic Versioning. Additionally, this library is part of the Gazebo project which periodically releases a versioned set of compatible and complimentary libraries. See the Gazebo website for version and release information.

License

This library is licensed under Apache 2.0. See also the LICENSE file.

gz-physics's People

Contributors

Stargazers

Watchers

gz-physics's Issues

Integrate Bullet

Add support for the Bullet physics engine as an alternative to DART.

Past pull requests have started on this:

The latest code can be found on branches bullet and bullet_chapulina.

ign-physics getting-started tutorials

Some planning for getting-started tutorials:

Introduction:
- Overview and motivation of ign-physics
- What are ign-physics purposes and where it is in the Ignition Robotics framework (optionally draw a framework graph highlighting ign-physics)
- Currently supported physics engines and corresponding features overview (link to plugin description)
- Roadmap of future plans of ign-physics, a potential timeline of certain features.
Installation: Tweaking and improving current installation guide for Dome release.
Switching physics plugins tutorial
- Describe ways to switch physics engine from ign-gazebo

Clarify relationship between RemoveModelFromWorld and GetEntities features

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

Summary

As mentioned in pull request #61, the RemoveModelFromWorld feature doesn't reference GetEntities, but RemoveModelByIndex implies a dependence on the GetEntities feature, since that is the only thing that provides a model index. Should the RemoveModelFromWorld feature be included in GetEntities.hh?

Motivation

It is helpful to clarify the relationship between features.

Describe alternatives you've considered

Doing nothing; maybe it's fine as is.

Additional context

Collision between mesh and plane

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

Prerequisites

[ X ] Put an X between the brackets on this line if you have done all of the following:
- Checked the Q&A board for common solutions: http://answers.gazebosim.org
- Checked that your issue isn't already filed.
- Checked that there is not already an Ignition package that provides the described functionality: https://ignitionrobotics.org/libs

Description

Contacts don't seem to be generated between planes and meshes.

Steps to Reproduce

On this ign-gazebo PR, uncomment the <plane> and comment <box> for ground_plane and see how the ducks fall through the ground.

ground	ground

I don't know how to reproduce this just with ign-physics, an example quick-start program with the minimum code needed to load a couple of models and print out contacts would be helpful, maybe this can be extracted from some of the test cases.

Expected behavior:

I'd expect the ducks not to fall through the plane.

Actual behavior:

Ducks fall to infinity.

Reproduces how often:

Every time ducks fall.

Versions

Default branch (a99c99d)

Dartsim FreeGroupFeatures should account for model pose

Original report (archived issue) by Addisu Z. Taddese (Bitbucket: azeey, GitHub: azeey).

Prerequisites

[X ] Put an X between the brackets on this line if you have done all of the following:
- Checked the Q&A board for common solutions: http://answers.gazebosim.org
- Checked that your issue isn't already filed.
- Checked that there is not already an Ignition package that provides the described functionality: https://ignitionrobotics.org/libs

Description

The dartsim FreeGroupFeatures implementation uses the canonical link of a model to set poses. However, it doesn't take into account that the model can have a pose offset from the canonical link. See related ign-gazebo discussion

Steps to Reproduce

The problem manifests when the canonical link has a non-identity pose. For example:

<model name="test_model">
  <pose>0 0 0 0 0 0</pose>
  <link name="link1">
    <pose>1 2 3 0 0 0 </pose>
  </link>
</model>

Set the world pose of the model via the model's FreeGroup to 0 0 0 0 0 0. A failing test can be found here (74f5677)

Expected behavior:

We expect no change in the pose of the model when setting its pose to 0 0 0 0 0 0 because it's already there.

Actual behavior:

link1 moves to 0 0 0 0 0 0 and as a result, test_model moves to -1 -2 -3 0 0 0.

Reproduces how often:

100%

Versions

All

Add data structures for wrench, twist

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

To support getting the force/torque wrench applied at a joint, it would be convenient to return a wrench as a unified data structure. It could also be helpful to report linear and angular velocity as twist.

In dart these are expressed by a Vector6d. An alternative is a struct with two named Vector3d values, which is more obvious to interpret but perhaps less efficient for screw algebra.

cc @mxgrey @azeey

Extend contact data

Original report (archived issue) by Diego Ferigo (Bitbucket: dgferigo).

The GetContacts.hh features allows to extract some basic information from contacts, such as bodyA bodyB and contact point in world frame.

Is there any update to what discussed in PR67? The structure GetContacts.hh#74 seems the place where to possibly add normal and magnitude. @azeey @scpeters

‌

Speed up compilation

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

Summary

It takes a long time to compile the code.

Motivation

Speed up development by reducing compile time.

Describe alternatives you've considered

Deal with it (what we are currently doing).

Additional context

I think @mxgrey has some additional context.

Expose contact parameters

In our simulations with a humanoid robot we are noticing some funky contact detection behaviour. It's something similar to what was shown in robotology/gym-ignition-models#20. Particularly, when the feet look visually flat on the ground plane, the contacts detected by DART are quite noisy, they go on and off.

In Gazebo Classic, ODE could be tuned quite a lot using the /collision/contact/ode parameters. However, currently none of them are exposed for DART.

Some while ago @scpeters in robotology-legacy/icub-gazebo-legacy#30 (comment) mentioned that the min_depth parameter is quite relevant.

Is 1) setting the depth currently possible in DART and 2) did you ever had any internal discussion about these set of parameters? I suspect that they can become fundamental for any locomotion and manipulation applications.

cc @azeey @chapulina

Joint position and effort limits

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

Summary

We should add a feature for Joint limits (position, velocity, acceleration, effort). I would make them separate features in case a physics engine doesn't implement them all.

Motivation

This is needed for the MotionTimerLockJoints plugin.

Describe alternatives you've considered

none

Additional context

Compare performance between Cloneable+MakeCloneable and the upcoming std::any

Original report (archived issue) by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

The C++17 class std::any is able to perform the same role as the Cloneable + MakeCloneable classes in ign-physics. However, std::any has some type safety overhead which is not needed in ign-physics because type safety is already ensured by our implementation design.

When std::any is widely available, we should profile the performance difference between std::any and our own Cloneable + MakeCloneable to decide whether we should switch to std::any or stick to our own solution.

Fail to build ignition-physics

When building ignition-dome on Ubuntu 18.04 following this document, I got the following error
I am wondering how can this be fixed

--- stderr: ignition-physics3                                                
CMake Error at /usr/share/dart/cmake/DARTFindurdfdom.cmake:13 (set_target_properties):
  Property INTERFACE_LINK_LIBRARIES may not contain link-type keyword
  "optimized".  The INTERFACE_LINK_LIBRARIES property may contain
  configuration-sensitive generator-expressions which may be used to specify
  per-configuration rules.
Call Stack (most recent call first):
  /usr/share/dart/cmake/dart_utils-urdfComponent.cmake:6 (include)
  /usr/share/dart/cmake/DARTConfig.cmake:63 (include)
  /usr/share/dart/cmake/DARTConfig.cmake:123 (dart_traverse_components)
  /usr/share/dart/cmake/DARTConfig.cmake:171 (dart_package_init)
  /home/makinohara/ws_dome/install/share/cmake/ignition-cmake2/cmake2/IgnUtils.cmake:188 (find_package)
  CMakeLists.txt:63 (ign_find_package)


---
Failed   <<< ignition-physics3 [0.40s, exited with code 1]

Jenkins Windows CI is not installing DART

Windows CI is currently skipping the dartsim component:

-- Could NOT find DART (missing: DART_DIR)
-- Looking for DART - not found

-- -------------------------------------------

-- BUILD WARNINGS
-- 	Cannot build component [dartsim] - Missing: DART (Components: collision-ode, utils, utils-urdf, CONFIG)
-- END BUILD WARNINGS

We should make sure DART and its Ignition Physics bindings are installable and runnable on Windows.

API documentation

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

Summary

A lot of the API (most of it?) is not documented, so downstream developers need to come dig through the code to find out what functions are supposed to be doing.

For example, what does ConstructCollision do? Does it create and attach a collision to a link? How is that different from AttachMeshShape? If they do similar things, why are their names so different?

Motivation

It's difficult for downstream developers to use the API if it's not clear what it does.

Describe alternatives you've considered

Forcing everyone to dig through the code or test the API by trial and error? 😬

Additional context

Documentation is love 💟

Collisions fail depending on the number of entities in a world

Original report (archived issue) by Addisu Z. Taddese (Bitbucket: azeey, GitHub: azeey).

The original report had attachments: benchmark4x4.sdf, benchmark2x2.sdf, benchmark4x4_classic.sdf

Prerequisites

Put an X between the brackets on this line if you have done all of the following:
- Checked the Q&A board for common solutions: http://answers.gazebosim.org
- Checked that your issue isn't already filed.
- Checked that there is not already an Ignition package that provides the described functionality: https://ignitionrobotics.org/libs

Description

Collision between certain objects seems to fail depending on the number of entities in the world. Running the benchmark2x2.sdf in ign-gazebo behaves as expected.

However, benchmark4x4.sdf has more collision objects in the world and running that in ign-gazebo shows one of the cars falling through the ground.

I used a box instead of a plane for the ground.

The same problem exists in classic Gazebo with DART engine but with bullet set as the collision detector.

Steps to Reproduce

Run ign-gazebo -f benchmark2x2.sdf and ign-gazebo -f benchmark4x4.sdf
For classic gazebo gazebo -e dart benchmark4x4_classic.sdf

Expected behavior:

Objects stay above the ground

Actual behavior:

Objects fall through

Reproduces how often:

100%

Versions

ign-gazebo: default branch
ign-physics: default branch

Reopen pull request to reduce symbol load

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

Reopen pull request #136 once we're migrated to GitHub.

Upstream changes from our DART fork

We've been using a fork of DART on Ignition. This was originally done to add support for slip parameters and we used a fork because we had some lack of clarity on the units for the parameters and how they should be implemented in DART to behave the same way as they do in ODE.

Since the fork we have added the following changes:

We are starting to diverge a bit from upstream, so we should start upstreaming these changes soon.

More context:

Debs for our fork of DART are hosted on packages.osrfoundation.org and have versions with the pattern 6.10.0~osrf<version>~<date>...
We have already upstreamed a change that was part of the slip parameters work (Add secondary friction coefficient parameter #1424).
If an official release of DART 6.10 lands without slip parameter, it could potentially break ign-physics depending on whether the official version gets installed on a system.
We have added #ifdefs in ign-physics2 to allow using ign-physics with debs from the dartsim ppa, which are currently at v6.9.

Comparison with PAL?

Original report (archived issue) by Anthony Clark (Bitbucket: anthonyjclark).

Hello,

I would like to know how this effort compares to existing software. For example, how does it compare to how Gazebo currently handles physics engines? And how does it compare to PAL? This document only partially explains how this will be different than Gazebo's current approach.

Please let me know if there is a better forum for this sort of discussion.

[TPE] Return first link as canonical link

The SDF spec calls for the first link to be the canonical link if the attribute //model/@canonical_link is unspecified. However, TPE stores entities in an std::map which does not preserve order in which the entities are added.

pull request #86 attempted to workaround this by marking the first link added as the canonical link but the logic does not work when the model has multiple nested models and no top level links.

see this comment for more info: #86 (comment)

ign-physics usage tutorials (user side)

The planning for ign-physics usage consists of these tutorials:

A typical "hello-world" physics engines loading (we could use existing example here)
- Describe how to load custom physics engines as plugins (e.g. DART, TPE, etc.)
- Explain in general the most important functions call for loading plugins.
A comprehensive tutorial introducing physics simulation concepts, e.g. model, link, joint up to multibody dynamics, soft body, etc.
- They could be described using the top-down approach: using an SDF robot model.
A guide for how to try out the most important physics features.
- Personally, I prefer top-down approach as new users also have a top-down view, so that they could follow naturally :)
- Given an SDF robot model, users can zoom in onto joints, links to see how the forces, poses are set.

Add link offset to tpeplugin::KinematicsFeatures

Current implementation does not consider link position. Setting model pos also sets every entity within the model. We will need to consider the offset when there is a tag in , and adjust framedata accordingly. More info refer to discussion here #46 (comment)

[tpe] Add codecheck and fix style

as title says, filing ticket as a reminder.

Add tests for FreeGroup features

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

Several FreeGroup features were added in pull request #85 without test coverage; tests should be added.

Port ODE and Simbody integration from osrf/gazebo

osrf/gazebo has support for ODE and Simbody physics engines, so it would be nice to port those integrations to use ign-physics. We should consider putting them in separate repositories since I think we shouldn't intend for all plugin implementations to be hosted in ign-physics.

Segmentation Fault (ODE Internal Error)

Original report (archived issue) by Michael Carroll (Bitbucket: Michael Carroll, GitHub: mjcarroll).

Segmentation Fault (ODE Internal Error)

When trying to perform some benchmark work, I discovered a segmentation fault in ign-physics:

ODE INTERNAL ERROR 1: assertion &#34;bNormalizationResult&#34; failed in _dNormalize4() [odemath.h:42]

Steps to Reproduce

Create a world with a 5 x 5 x 5 cube of unit spheres, randomly perturbed slightly in the x and y axis.
1. (Or use this one: https://gist.github.com/mjcarroll/fab4c63ed3231c170ffdb549ff605770#file-spheres_5_5-sdf)
Execute with ign gazebo

Expected behavior: It shouldn’t crash.

Actual behavior: It does

Reproduces how often: 100%

Versions

ign-gazebo2 (blueprint) source build

Additional Information

I have a more complete backtrace here, snipped to the relevant bits: https://gist.github.com/mjcarroll/fab4c63ed3231c170ffdb549ff605770#file-backtrace

Test examples on CI

The examples are not tested on CI, so it's easy to forget to update them. We should be testing them on CI like other libraries do:

I think at least some of the libraries above require the library to be installed before running these tests, which is not ideal. I believe there are ways to work around this though, by setting environment variables, or installing, but to a local directory.

Ball rolling down an incline achieves warp speed

Original report (archived issue) by Addisu Z. Taddese (Bitbucket: azeey, GitHub: azeey).

The original report had attachments: rolling_shapes.sdf

As seen in the gif, the ball starts rolling on an incline (a large box inclined ~30 degrees) and after a few seconds, it shoots off in the process crashing ign-gazebo.

Nested model support

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

Summary

There's currently no API to construct nested models, which are supported on SDF.

Motivation

SDF supports an arbitrary number of <model> tags nested inside each other. This is helpful to compose models out of several parts.

I'm not sure how the physics engines will handle it internally, but it would be convenient if at least the sdf component would offer a Model::ConstructModel function. As a reference, there are currently functions like World::ConstructModel(sdf::Model) and Model::ConstructLink(sdf::Link).

Describe alternatives you've considered

If ign-physics doesn't offer nested model support, downstream libraries like ign-gazebo will have to find a way to work around this.

Restitution coefficients are ignored by the implementation of ConstructSdfCollision in dartsim-plugin

The dartsim plugin currently doesn't apply restitution coefficients when creating collisions using the ConstructSdfCollision feature, which is the feature used by ign-gazebo.

Features that use other Features without a pure virtual implementation?

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

I was just discussing with @iche033 about how to provide an API for a Link that computes an aggregate axis-aligned bounding box for all the shapes attached to that Link. This could surely be done in the typical way by creating a new feature with a new pure virtual Implementation function, but I believe this could be done using the API's from the GetShapeBoundingBox and GetShapeFromLink features without needing another pure virtual implementation function to be added to a plugin. I made an outline of what the API could look like in the following branch:

https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-physics/branch/link_bounding_box?dest=ign-physics1#diff

This type of feature would add useful API's without increasing the work required of those writing physics Implementation plugins, so I think it would be valuable, but I don't know if it is possible. @mxgrey, @azeey: what do you think?

Feature request: GetFreeGroupEntities

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

Summary

The concept of a FreeGroup was added in pull request #85 with API's for getting a FreeGroup from a Model or a Link. I would propose some additional API's for FreeGroups similar to the GetEntities feature:

std::size_t GetFreeGroupCount() const // get number of links with FreeJoints in this FreeGroup
FreeGroupPtrType GetFreeGroup(std::size_t) // get one of the embedded singular FreeGroups
// likewise with ConstFreeGroupPtrType
std::size_t GetLinkCount() const // get number of links in this FreeGroup
LinkPtrType GetLink(std::size_t) // get link by index
// likewise with ConstLinkPtrType

Motivation

If you want to introspect an existing FreeGroup, all you can do is get the CanonicalLink, but it won't tell you how many other FreeGroups or links are contained within. This would provide that functionality.

Describe alternatives you've considered

None

Additional context

Create ign-physics tutorials

Some tutorial ideas for ign-physics

Getting started

what is ign-physics, motivation of creating this library, where to find repo, versions released
currently supported physics engines and corresponding features overview
roadmap of future plans of ign-physics, potential timeline of certain features to look forward to
where to download debian, how to source build/compile

For users

how to switch between default and additional physics engine
chapters where users try out different physics features
- bottom up approach: step by step tutorials on how to set/add various models with different physics features like (rigid body dynamics, collision detection, kinematics to compose a world
  OR
- top down approach: given a world of various models, zoom in onto each model and see how forces are set, position is updated or any other physics features work

For developers

high level overview of how physics plugin work, explain user interface and implementation interface, key concepts/classes (Entities), link to API documentation and contributing guide
explain folder structure and where to add new custom features, potential restrictions on adding custom features
a step by step interactive tutorial teaching how to add a simple custom plugin, using the hello-world plugin example
a tutorial on how to define custom features in a plugin and request them when loading plugins using the dartsim RetrieveWorld feature in World.hh
use TPE as a more advanced example. Pick one FeatureList as step-by-step tutorial on how to implement features using external physics engine API.

Consider making the CompositeData query-tracking optional and configurable at compile-time

Original report (archived issue) by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

See here for more context.

Benchmark Performance

Run performance tests for TPE and compare against DART.

some ideas of what to measure:

time to run one iteration in physics system in ign-gazebo
time to step a world in ign-physics
time to perform collision detection
RTF
memory usage

ideas for test worlds

large world with simple shapes / meshes
large word with crowds of actors

We can consider using tools like the profiler from ign-common to get remotery graphs of cpu usage. To do this, we'll need to add profiling points throughout the code, see profiler tutorial

other useful tools include:

flamegraphs - cpu uage
heaptrack - for memory usage

Annoying GenericJoint::setRestPosition DART warning

I am running fairly long simulations (~days) and the log is flooded with warnings like the following:

Warning [GenericJoint.hpp:1473] [GenericJoint::setRestPosition] Value of _q0 [0], is out of the limit range [0.261799, 1.85005] for index [0] of Joint [Joint].

There is no way to suppress it since it's related to the DART logger. In dartsim/dart#869 (comment) some more details about the warning.

Anyway, this warning has been removed in the upstream repository in dartsim/dart#1418, but the DART packages in the osrf repository does not seem to include this fix. If I recall, you use the azeey/dart fork for packaging, that is a bit behind upstream.

Waiting #49, would it be possible to have this upstream PR merged in the next release? @azeey @j-rivero

Friction model feature / friction pyramid parameters

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

Summary

Expose an interface for setting a physics plugin's friction model (friction pyramid / friction cone) and add features for setting relevant friction model parameters as a physics feature:

Friction pyramid parameters

mu1/mu2
body-fixed friction direction fdir1
slip1/slip2

Motivation

Some skid-steer robots require tuning of friction parameters to drive smoothly in simulation, such as the X1 robot from SubT:

https://bitbucket.org/osrf/subt/pull-requests/70/improve-x1-turning-dynamics/diff

It would be convenient to expose some of these pyramid friction model parameters as a physics feature.

Describe alternatives you've considered

Additional context

Add Feature to allow runtime changes to joint limits

I'd like to change <limit><velocity> and <limit><effort> dynamically during the simulation. Currently, it seems that these values are only read when parsing the model.

I've tried this, but changing the component data has no effect:

auto axisComponent = _ecm.Component<components::JointAxis>(this->joint);
axisComponent->Data().SetEffort(2.0);

I also tried re-creating the component, but that also doesn't change the physics engine behavior:

auto axisComponent = _ecm.Component<components::JointAxis>(this->joint);
axisComponent->Data().SetEffort(torque);
components::JointAxis axis(axisComponent->Data());
*axisComponent = axis;

Feature request: set pose and velocity in FreeGroupFrameSemantics feature

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

Summary

The FreeGroupFrameSemantics feature was added in pull request #85, but it doesn't have any functions for getting or setting pose. It would be nice to have the following:

    FreeGroup::SetPose(RelativePose)
    FreeGroup::SetLinearVelocity(RelativeLinearVector)
    FreeGroup::SetAngularVelocity(RelativeAngularVector)

Motivation

The features SetFreeGroupWorldPose and SetFreeGroupWorldVelocity allow setting velocity in the world frame, but it would be nice to be able to use other frames too.

Describe alternatives you've considered

Just use the world frame features

Additional context

Generalize dartsim tests so they can run with other physics engines

The tests in dartsim/src directory could be generalized so we can use them for other engines like TPE.

Pipelines disabled for now

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

There is an issue with the dart6-data debian which is causing our pipelines to fail. I'm disabling them for now until that is resolved.

Reopen pull request to restore detached BodyNodes to original skeleton

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

We didn't finish revising pull request #104 before the GitHub migration freeze date, so this issue is to remind to reopen a pull request from branch detach_joint_feature_detach_to_skeleton. There are still some outstanding comments related to the naming scheme for detached joints and how to handle links with / characters in their names. Perhaps the original skeleton name could be stored in the dartsim JointInfo struct in Base.hh and the original name stored in a similar manner to the ShapeInfo class.

Unresolved comments:

engine-plugins folder needs to be added to debian metadata

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

Unversioned plugins are now installed to the engine-plugins folder as of pull request #121, but they haven't yet been added to the debian metadata, so the nightly builds are unstable.

dh_missing --list-missing
dh_missing: usr/lib/x86_64-linux-gnu/ign-physics-1/engine-plugins/libignition-physics-dartsim-plugin.so exists in debian/tmp but is not installed to anywhere
dh_missing: usr/lib/x86_64-linux-gnu/ign-physics-1/engine-plugins/libignition-physics1-dartsim-plugin.so.1 exists in debian/tmp but is not installed to anywhere
dh_missing: usr/lib/x86_64-linux-gnu/ign-physics-1/engine-plugins/libignition-physics1-dartsim-plugin.so.1.5.0 exists in debian/tmp but is not installed to anywhere
dh_missing: usr/lib/x86_64-linux-gnu/ign-physics-1/engine-plugins/libignition-physics1-dartsim-plugin.so exists in debian/tmp but is not installed to anywhere

Support of closed kinematic chains

Original report (archived issue) by Diego Ferigo (Bitbucket: dgferigo).

Doing some experiments with the SDF of Minitaur quadruped (taken from KodlabPenn/kodlab_gazebo), I noticed that the current state of the dart physics plugin does not yet support closed kinematic chains (parallel robot).

The four legs on Minitaur are composed of a five-bar linkage. The SDFs hosted in the GitHub repo work well in Gazebo 10 Classic. However, the simulation of the model in Ignition Gazebo does not apply the constraint to keep the linkage closed, and the links forming the legs fall apart as soon as they touch the ground.

I found this TODO in the code, therefore I open this issue to track the status of the missing support.

Consider moving plugins to a subdirectory

Currently we have both dartsim and tpe on the top-level of this repository. This means they're mixed with other top-level components like sdf and mesh. It would be good to group them under the same directory for discoverability. Maybe plugins or engines.

Consider thread safety of RemoveModel feature

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

Summary

As noted in pull request #61, the implementation of the RemoveModel feature in the dartsim plugin is not thread-safe. It will lead to bugs that are difficult to debug if used in multiple threads.

Motivation

Multithreaded programs may be used to call the ignition physics API, so we should consider making this feature more thread-safe

Describe alternatives you've considered

Don't try to make it thread-safe, but give loud warnings in the documentation about it.

Additional context

Test failures in arm64: FrameSemantics.FrameID2d, JointTypes.RevoluteJoint2f

When building packages for arm64 I found the following test failures:

[ RUN      ] FrameSemantics_TEST.FrameID2d
Scaled difference in linear acceleration: 2.00028e-12 | Difference: 2.00028e-12 | Scale: 1 | (Tolerance: 1e-12)
/var/lib/jenkins/workspace/ign-physics2-debbuilder/build/ignition-physics-2.1.0/test/integration/FrameSemantics.hh:329: Failure
Value of: Equal(J1_T_J1.RelativeToParent(), fs->Resolve(O_T_J1, J1), _tolerance)
  Actual: false
Expected: true
[  FAILED  ] FrameSemantics_TEST.FrameID2d (53 ms)

[ RUN      ] JointTypes_TEST.RevoluteJoint2f
Scaled difference in angle: 2.79141e-09 | Difference: 2.79141e-09 | Scale: 1 | (Tolerance: 1e-16)
/var/lib/jenkins/workspace/ign-physics2-debbuilder/build/ignition-physics-2.1.0/test/integration/JointTypes.hh:99: Failure
Value of: Equal(T, pose, _tolerance)
  Actual: false
Expected: true
Scaled difference in angle: 5.68705e-09 | Difference: 5.68705e-09 | Scale: 1 | (Tolerance: 1e-16)
/var/lib/jenkins/workspace/ign-physics2-debbuilder/build/ignition-physics-2.1.0/test/integration/JointTypes.hh:99: Failure
Value of: Equal(T, pose, _tolerance)
  Actual: false
Expected: true
Scaled difference in angle: 7.37315e-09 | Difference: 9.21644e-09 | Scale: 1.25 | (Tolerance: 1e-16)
/var/lib/jenkins/workspace/ign-physics2-debbuilder/build/ignition-physics-2.1.0/test/integration/JointTypes.hh:99: Failure
Value of: Equal(T, pose, _tolerance)
  Actual: false
Expected: true
Scaled difference in angle: -1.22641e-08 | Difference: -1.22641e-08 | Scale: 1 | (Tolerance: 1e-16)
/var/lib/jenkins/workspace/ign-physics2-debbuilder/build/ignition-physics-2.1.0/test/integration/JointTypes.hh:99: Failure
Value of: Equal(T, pose, _tolerance)
  Actual: false
Expected: true
Scaled difference in angle: -4.26041e-09 | Difference: -1.3064e-08 | Scale: 3.06637 | (Tolerance: 1e-16)
/var/lib/jenkins/workspace/ign-physics2-debbuilder/build/ignition-physics-2.1.0/test/integration/JointTypes.hh:99: Failure
Value of: Equal(T, pose, _tolerance)
  Actual: false
Expected: true
Scaled difference in angle: -7.78027e-09 | Difference: -2.09396e-08 | Scale: 2.69137 | (Tolerance: 1e-16)
/var/lib/jenkins/workspace/ign-physics2-debbuilder/build/ignition-physics-2.1.0/test/integration/JointTypes.hh:99: Failure
Value of: Equal(T, pose, _tolerance)
  Actual: false
Expected: true
[  FAILED  ] JointTypes_TEST.RevoluteJoint2f (67 ms)

Support primitive datatypes in CompositeData

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

Supporting primitive datatypes in CompositeData (ie. data.Get<double>()) was discussed in the following comment thread of pull request #5 but is somewhat controversial:

https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-physics/pull-requests/5/part-2-compositedata-specifydata/activity#comment-62868652

The controversial part is that it's not a recommended practice to use primitive datatypes in that way. You get more semantic information by wrapping primitive datatypes in named classes.

Still, people may want to be able to do it. If there is enough demand for this feature, we will consider implementing it.

Support scaling simple shapes

On Gazebo-classic, users could scale simple shapes (box / sphere / cylinder) at runtime and the changes would be immediately reflected into the physics of the simulation.

We should eventually support the same functionality in Ignition Physics.

Some follow ups to this would be:

Scaling shapes that are off-center
Scaling any mesh
Scaling entire models while maintaining their relative kinematics

Any plan for a Python interface?

Original report (archived issue) by Silvio Traversaro (Bitbucket: traversaro).

Python-based interfaces to physics engines (such as PyBullet for Bullet and mujoco-py and dm_control for MuJoCo ) are quite fashionable in this days for reinforcement learning applications.

There are any plans for a Python interface to the newly designed ign-physics library?

[Fedora] Compilation failed: Incompatibilities with DART

Original report (archived issue) by Til Hoff (Bitbucket: turakar).

Description

Ignition cannot be compiled because ign-physics fails.

Steps to reproduce

set up Fedora 29 system
install dependencies

sudo dnf install cmake freeglut-devel ffmpeg-devel freeimage-devel gflags-devel glew-devel gts-devel ogre-devel protobuf-devel protobuf-c-devel qt5 tinyxml2-devel tinyxml-devel pkg-config protobuf-compiler python qt5-qtquickcontrols qt5-qtquickcontrols2 qt5-devel qt5-qtdeclarative-devel qt5-qtquickcontrols2-devel ruby rubygem-ronn uuid-devel libzip-devel jsoncpp-devel libcurl-devel libyaml-devel czmq-devel cppzmq-devel sqlite-devel libwebsockets-devel eigen3-devel

compile DART from source
compile ignition from source

Expected behaviour

ign-physics compiles successfully.

Actual behaviour

Compilation gives errors:

--- stderr: ignition-physics1                                                                                        
/workspacepath/ignitionrobotics/ign-physics/dartsim/src/CustomMeshShape.cc: In constructor &#39;ignition::physics::dartsim::CustomMeshShape::CustomMeshShape(const ignition::common::Mesh&amp;, const Vector3d&amp;)&#39;:
/workspacepath/ignitionrobotics/ign-physics/dartsim/src/CustomMeshShape.cc:207:45: error: &#39;ai_real&#39; does not name a type
         mesh-&gt;mVertices[j][k] = static_cast&lt;ai_real&gt;(v[k]);
                                             ^~~~~~~
/workspacepath/ignitionrobotics/ign-physics/dartsim/src/CustomMeshShape.cc:211:44: error: &#39;ai_real&#39; does not name a type
         mesh-&gt;mNormals[j][k] = static_cast&lt;ai_real&gt;(n[k]);
                                            ^~~~~~~
gmake[2]: *** [dartsim/CMakeFiles/ignition-physics1-dartsim-plugin.dir/build.make:76: dartsim/CMakeFiles/ignition-physics1-dartsim-plugin.dir/src/CustomMeshShape.cc.o] Error 1
gmake[2]: *** Waiting for unfinished jobs....
/workspacepath/ignitionrobotics/ign-physics/dartsim/src/SDFFeatures.cc: In member function &#39;virtual ignition::physics::Identity ignition::physics::dartsim::SDFFeatures::ConstructSdfCollision(const ignition::physics::Identity&amp;, const sdf::v8::Collision&amp;)&#39;:
/workspacepath/ignitionrobotics/ign-physics/dartsim/src/SDFFeatures.cc:495:15: error: &#39;class dart::dynamics::DynamicsAspect&#39; has no member named &#39;setSecondaryFrictionCoeff&#39;; did you mean &#39;setFrictionCoeff&#39;?
       aspect-&gt;setSecondaryFrictionCoeff(odeFriction-&gt;Get&lt;double&gt;(&#34;mu2&#34;));
               ^~~~~~~~~~~~~~~~~~~~~~~~~
               setFrictionCoeff
/workspacepath/ignitionrobotics/ign-physics/dartsim/src/SDFFeatures.cc:499:15: error: &#39;class dart::dynamics::DynamicsAspect&#39; has no member named &#39;setSlipCompliance&#39;
       aspect-&gt;setSlipCompliance(odeFriction-&gt;Get&lt;double&gt;(&#34;slip1&#34;));
               ^~~~~~~~~~~~~~~~~
/workspacepath/ignitionrobotics/ign-physics/dartsim/src/SDFFeatures.cc:503:15: error: &#39;class dart::dynamics::DynamicsAspect&#39; has no member named &#39;setSecondarySlipCompliance&#39;
       aspect-&gt;setSecondarySlipCompliance(odeFriction-&gt;Get&lt;double&gt;(&#34;slip2&#34;));
               ^~~~~~~~~~~~~~~~~~~~~~~~~~
/workspacepath/ignitionrobotics/ign-physics/dartsim/src/SDFFeatures.cc:508:15: error: &#39;class dart::dynamics::DynamicsAspect&#39; has no member named &#39;setFirstFrictionDirection&#39;
       aspect-&gt;setFirstFrictionDirection(math::eigen3::convert(fdir1));
               ^~~~~~~~~~~~~~~~~~~~~~~~~
gmake[2]: *** [dartsim/CMakeFiles/ignition-physics1-dartsim-plugin.dir/build.make:154: dartsim/CMakeFiles/ignition-physics1-dartsim-plugin.dir/src/SDFFeatures.cc.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:2245: dartsim/CMakeFiles/ignition-physics1-dartsim-plugin.dir/all] Error 2
gmake: *** [Makefile:141: all] Error 2
---
Failed   &lt;&lt;&lt; ignition-physics1  [ Exited with code 2 ]
Aborted  &lt;&lt;&lt; ignition-rendering2

Versions

Fedora 29
tested DART versions: 6.9.2 (latest tag, not accepted by ign-physics), master, commit 45f8e776b7bbcd6b4e4b3ac91bfa45b2a9dfc861 (bump version to 6.10.0)
ign-physics 1.4.0

gazebosim / gz-physics Goto Github PK

gz-physics's Introduction

Gazebo Physics : Physics classes and functions for robot applications

Table of Contents

Motivation

Features

Install

Usage

Documentation

Testing

Folder Structure

Contributing

Code of Conduct

Versioning

License

gz-physics's People

Contributors

Stargazers

Watchers

Forkers

gz-physics's Issues

Summary

Motivation

Describe alternatives you've considered

Additional context

Prerequisites

Description

Steps to Reproduce

Versions

Prerequisites

Description

Steps to Reproduce

Versions

Summary

Motivation

Describe alternatives you've considered

Additional context

Summary

Motivation

Describe alternatives you've considered

Additional context

Summary

Motivation

Describe alternatives you've considered

Additional context

Prerequisites

Description

Steps to Reproduce

Versions

More context:

Segmentation Fault (ODE Internal Error)

Steps to Reproduce

Versions

Summary

Motivation

Describe alternatives you've considered

Summary

Motivation

Describe alternatives you've considered

Additional context

Summary

Friction pyramid parameters

Motivation

Describe alternatives you've considered

Additional context

Summary

Motivation

Describe alternatives you've considered

Additional context

Summary

Motivation

Describe alternatives you've considered

Additional context

Description

Steps to reproduce

Versions

Recommend Projects

Recommend Topics

Recommend Org

Jobs