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

bullet-featherstone: F/T sensor reports incorrect values at fixed joint if joint forces are applied #565

Closed
Tracked by #545
shameekganguly opened this issue Nov 1, 2023 · 5 comments
Labels
bug Something isn't working Bullet Bullet engine

Comments

@shameekganguly
Copy link
Contributor

Repro steps:

  1. Create a model with a few revolute joints and links.
  2. At the last link, add another (payload) link with a fixed joint.
  3. Place an F/T sensor at the fixed joint.
  4. Add a joint position controller system to control the position of one of the revolute joints using joint force commands (PID).
  5. Start the simulation and wait for the model to reach steady state.
  6. Check published F/T sensor value.

Expected value of force: weight of the attached payload link in the sensor frame.
Actual value of force: different from above, and magnitude is larger than the weight of the payload link.

You can test this with this sdf file:
fixed_joint_ft_sensor_bullet.sdf.txt. Run gz sim and wait for steady state. Then check /ft_sensor/wrench topic for F/T values. Expected force is [0 0 -9.8], but the published value is [0 -0.34 -13.85].

Note that the bug only occurs when using bullet-featherstone and not for dartsim. Also, if a joint velocity command is used instead of joint force command to control the joint position (uncomment the second joint position controller plugin in the sdf), then the bug does not occur.

@shameekganguly shameekganguly added the bug Something isn't working label Nov 1, 2023
@azeey
Copy link
Contributor

azeey commented Nov 1, 2023

Is this related to bulletphysics/bullet3#4451? Perhaps we can use the python file there to test without gz-physics to see if it's an issue in Bullet or gz-physics.

@shameekganguly
Copy link
Contributor Author

Is this related to bulletphysics/bullet3#4451? Perhaps we can use the python file there to test without gz-physics to see if it's an issue in Bullet or gz-physics.

Its possible that this is a related issue in bullet. I'll try to test with the python file this week before I am OOO.

@iche033
Copy link
Contributor

iche033 commented Nov 4, 2023

looks like the bug could be related to bulletphysics/bullet3#2966. I tested bullet (master branch) with the patch posted in bulletphysics/bullet3#2966 (comment) and I now get reasonable values ([0 0 -9.8]) in the fixed_joint_ft_sensor_bullet.sdf world

@scpeters
Copy link
Member

scpeters commented Nov 6, 2023

I added this to the tracking issue in #545

@iche033
Copy link
Contributor

iche033 commented Apr 17, 2024

fixed upstream with bulletphysics/bullet3#4583

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Bullet Bullet engine
Projects
Archived in project
Development

No branches or pull requests

4 participants