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

Expose API to check what links moved #219

Closed
chapulina opened this issue Mar 3, 2021 · 3 comments
Closed

Expose API to check what links moved #219

chapulina opened this issue Mar 3, 2021 · 3 comments
Labels
enhancement New feature or request performance Runtime performance

Comments

@chapulina
Copy link
Contributor

chapulina commented Mar 3, 2021

A downstream application using Ignition Physics, such as Ignition Gazebo, likely wants to know at every iteration what links have moved after a step.

Currently, Gazebo goes over all links and gets their latest poses with FrameDataRelativeToWorld, because it doesn't have a way of knowing which ones changed.

Desired behavior

We should offer a mechanism by which Gazebo could know what moved and wouldn't need to iterate over all links at every step.

Implementation suggestion

The way Gazebo classic achieves this with the ODE engine is by registering a callback that ODE calls for each link that has moved. As a comparison, Gazebo classic doesn't have an equivalent mechanism for DART, and iterates over all links instead, which makes using DART slower than ODE.

We could take the same approach here. Ignition Physics could offer a Feature that allows registering a callback, and each physics engine may choose to provide that API. I don't know if DART offers such a function or if we'd need to add that functionality upstream. My understanding is that Bullet offers a callback API, but I did a quick search and couldn't find it, maybe @Lobotuerk knows what it is?

Alternatives considered

Instead of a callback, maybe providing a function that returns only the links that moved could also do the trick, but it may perform worse depending on how that structure is populated and passed around.

@chapulina chapulina added enhancement New feature or request performance Runtime performance labels Mar 3, 2021
@adlarkin
Copy link
Contributor

adlarkin commented Mar 4, 2021

Since implementing callback functionality is more of an involved task and may not work for DART, I have proposed a temporary workaround in the meantime: gazebosim/gz-sim#669

@adlarkin
Copy link
Contributor

I believe that gazebosim/gz-sim#678 resolves this issue for DART and TPE. Can we close this, or does something also need to be done for Bullet?

@chapulina
Copy link
Contributor Author

I'm ok closing this, the main target of the feature was the default engine, which is currently DART.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request performance Runtime performance
Projects
None yet
Development

No branches or pull requests

2 participants