Integrate Bullet

[chapulina]

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

Past pull requests have started on this:

• https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-physics/pull-requests/97
• https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-physics/pull-requests/98
• https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-physics/pull-requests/99
• https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-physics/pull-requests/134

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

[Blast545]

@Lobotuerk and I moved and tested part of this implementation to devel_bullet branch. This is a summary of some things we have tested at the moment with bullet's Featherstone implementation:

• Problems with bullet 2.87 (the one available with Ubuntu’s installation) were found, so it was manually installed the 3.05 version (latest development one). We moved to 3.05 based on a commit showing fixes after 2.87 on memory access errors.

• Currently, there is a problem with memory that causes the corruption in the classes used to save information about the simulation worlds, models and links. It occurs after a few iterations of the program running normally, and at the moment we think it may be related to memory management of the threads.

• To track the memory leaks, we tested the following:

  • Version 2.87 and version 3.05: the problem occurs in different places, but shows similar results.
  • Testing custom_server.cc standalone server gazebo example. This one corrupts the model's memories and closes early.
  • As there were problems found with memory, bullet’s aligned allocators were disable to test if the problem persisted. Bullet works properly without those, but the same problem occurs with ignition + bullet. The bullet modifications used can be found in this fork.

At the moment, we will open move away from Featherstone and start using btRigidBody

[scpeters]

• Currently, there is a problem with memory that causes the corruption in the classes used to save information about the simulation worlds, models and links. It occurs after a few iterations of the program running normally, and at the moment we think it may be related to memory management of the threads.

At the moment, we will open move away from Featherstone and start using btRigidBody

That's too bad about the memory issues. I haven't had much experience with btMultibody (Featherstone), but there are some trade-offs between the use of generalized coordinates (Featherstone) and maximal coordinates (btRigidBody). I think it's most important to get something reliable working first, and then we can expand on it to support other features of bullet after that point

[chapulina]

Addressed in #208

[Blast545]

Current status

PR #208 : The following elements are available:

• Creating shapes and meshes, with their associated collisions
• Step simulation
• Revolute joints with their getter/setters
• Diff drive plugin integration
• joint_controller and joint_controller_position integration
• Fixed joints
• Basic friction model (mu + mu2)

Known issues

Issue with inertia diagonal values: When inertial matrix values that represent objects with a center of mass different than its geometrical one are used with bullet objects, they cause erratic behaviors with the simulation. This issue was found when testing models with a gimbal assembly, an inertia matrix with low inertia values is present in a cylinder inside the assembly. A cylinder equivalent to the one found, with the same inertia matrix was tested using gazebo11, ign-gazebo4 and the bullet libraries standalone, and it fails. However, this works fine with pyBullet by loading the world from the sdf file.

Torque limitation: * The angle getter from bullet resets its initial count if the angle difference between two consecutive readings is higher than a hardcoded threshold. To address this issue, a threshold in the max torque was added in the joint controllers. (An extra eyes into the best approach to address this would be appreciated). This is the code we implemented <https://github.com/ignitionrobotics/ign-physics/blob/af978795a077165d91067d11c10912b011b50d4b/bullet/src/JointFeatures.cc#L291> and this is the limitation addressed <https://pybullet.org/Bullet/BulletFull/btHingeConstraint_8cpp_source.html#l00318>. As this issue does not affect ground vehicles as it would aerial ones (higher speeds), the code addressing this was removed from the current PR.

Features available:

• EntityManagementFeatures
  • MinimumFeatureList::RemoveModelByName
  • MinimumFeatureList::RemoveModelByIndex
  • MinimumFeatureList::ModelRemoved
  • MinimumFeatureList::RemoveModel
  • MinimumFeatureList::ConstructEmptyWorld
• FreeGroupFeatures
  • MinimumFeatureList::FindFreeGroupForModel
  • MinimumFeatureList::FindFreeGroupForLink
  • MinimumFeatureList::GetFreeGroupCanonicalLink
  • MinimumFeatureList::SetFreeGroupWorldPose
• JointFeatures
  • JointFeatureList::GetJointPosition
  • JointFeatureList::GetJointVelocity
  • JointFeatureList::GetJointAcceleration
  • JointFeatureList::GetJointForce
  • JointFeatureList::GetJointTransform -> Dummy
  • JointFeatureList::SetJointPosition -> Dummy
  • JointFeatureList::SetJointVelocity -> Dummy
  • JointFeatureList::SetJointAcceleration -> Dummy
  • JointFeatureList::SetJointForce
  • JointFeatureList::SetJointVelocityCommand
  • JointFeatureList::GetJointDegreesOfFreedom
  • JointFeatureList::GetJointTransformFromParent -> Dummy
  • JointFeatureList::GetJointTransformToChild -> Dummy
  • JointFeatureList::CastToFixedJoint
  • JointFeatureList::CastToRevoluteJoint
  • JointFeatureList::GetRevoluteJointAxis
• KinematicFeatures
  • MinimumFeatureList::FrameDataRelativeToWorld
• SDFFeatures
  • MinimumFeatureList::ConstructSdfWorld
  • MinimumFeatureList::ConstructSdfModel
  • MinimumFeatureList::ConstructSdfLink
  • CollisionFeatureList::ConstructSdfCollision
  • JointFeatureList::ConstructSdfJoint
• ShapeFeatures
  • CollisionFeatureList::AttachMeshShape
  • CollisionFeatureList::CastToMeshShape
• SimulationFeatures
  • MinimumFeatureList::WorldForwardStep

[nkoenig]

Remember to utilize a custom motion state along with ChangedWorldPose in main. The goal is to capture only link that move during a step. Here is the BulletMotionState from Gazebo Classic: https://github.com/osrf/gazebo/blob/gazebo11/gazebo/physics/bullet/BulletMotionState.hh

Here is the PR related to ChangedWorldPose: https://github.com/ignitionrobotics/ign-physics/pull/238

[nkoenig]

Another known issue is related to the diff_drive_skid example in ign-gazebo. More information here: https://github.com/ignitionrobotics/ign-physics/pull/208#pullrequestreview-657257121

[chapulina]

Another known issue: Bullet does not support the self_collide tag, causing issues like this:

ign gazebo -v 3 track_drive.sdf --physics-engine ignition-physics-bullet-plugin --force-version 4

[chapulina]

Another missing feature from Edifice: capsules and ellipsoids. :pill:

[danielpmorton]

Hi there, I know Bullet supports soft bodies / deformables, but I haven't been able to figure out through your documentation if this is supported within Gazebo. I also noticed this thread here (https://github.com/gazebosim/gz-physics/issues/222), not necessarily for Bullet, but still soft-body related. Has there been any progress here? If not, what would be needed for this to happen? -- Thanks

[ahcorde]

Hi @danielpmorton,

Right now there is no support for soft bodies / deformables within Gazebo. There's nothing preventing adding support for soft contacts in the future, someone just needs to put some time into it.

The Bullet supports is pretty decent right now check these two PRs: https://github.com/gazebosim/gz-physics/pull/373 and https://github.com/gazebosim/gz-sim/pull/1560.

Let us know if you want to put some time in to add this feature to Gazebo and we can start a discussion about the details.

[danielpmorton]

Hi @ahcorde, thanks for the response! Yes, I'd be interested in putting in some time and adding this feature. Send me an email (danielpmorton@gmail.com) and I'd be happy to chat some more about this!

[danielpmorton]

@ahcorde Just wanted to check in again after the holidays, are you free for a quick call sometime? It would be super helpful to get a better feel for what would need to get done

[ahcorde]

I will add here @scpeters and @azeey that probably can help and give more directions than me, anyhow happy to join the call

[danielpmorton]

Thanks Alejandro. I sent Steve an email yesterday, I figured that would be a better way to keep in touch than over Github. Will keep you posted depending if I hear / don't hear anything

[scpeters]

hi @danielpmorton, I'll reply here so everyone has the benefit of the information

Hi there, I know Bullet supports soft bodies / deformables, but I haven't been able to figure out through your documentation if this is supported within Gazebo. I also noticed this thread here (#222), not necessarily for Bullet, but still soft-body related. Has there been any progress here? If not, what would be needed for this to happen? -- Thanks

Right now there is no support for soft bodies / deformables within Gazebo. There's nothing preventing adding support for soft contacts in the future, someone just needs to put some time into it.

The Bullet supports is pretty decent right now check these two PRs: #373 and gazebosim/gz-sim#1560.

Let us know if you want to put some time in to add this feature to Gazebo and we can start a discussion about the details.

I think the way we'd want to expose the Bullet soft-body support is to add parameters to SDFormat so that gz-physics can pass those parameters into the btSoftBody API. I haven't seen thorough documentation of Bullet's APIs, but there are some useful examples in SoftDemo.cpp that I would draw from.

The first steps that I would take:

• [ ] compile the bullet SoftDemo example and run it interactively to see what the general behavior is like
• [ ] decide which features to pursue (1-D ropes, 2-D cloths, or 3-D gelatin solids)
• [ ] identify the parameters used in the Bullet API
• [ ] figure out how to express those parameters in SDFormat, including deciding whether the parameters are part of a <link> element or a <collision>
• [ ] write the gz-physics interface

[danielpmorton]

Hey Steve, great to hear from you! Thanks for the response – I have a couple more questions if you don’t mind. I can give an overview of the goal of the project as well, just for some context and to see if you have any suggestions on anything else.

So very broadly, the goal of what we’re trying to do is that we have an existing repository which was built in ROS Kinetic and Gazebo Classic, and we’d like to include deformable objects for the robot to interact with. These deformables will be 3D meshes rather than a rope or a cloth – basically a duffel bag. Ideally, we’d be able to interface directly with the old ROS version and Gazebo Classic, but I know some of these aren’t really supported anymore. There might be some workarounds here though – the repo has some support for Ubuntu 20 / Ros Noetic through Docker, and as a last resort, we can always import the URDFs/SDFs into Bullet and work exclusively there. We’ve also considered modeling the physics of this object in Bullet and sending it to the older ROS version through a ROS node, but I’m unsure if this is adding another layer of complexity that isn’t necessary if we can get this working in Gazebo.

With Bullet so far, I’ve been able to mess around with both the Python and C++ interfaces, having successfully built their demos and created my own demo within their “ExampleBrowser”. I got this to build and run, but when working outside of the Bullet directory, I had some difficulty with Cmake – though, I’m sure Gazebo has the Cmake configured well for the Bullet integration, so maybe this is a non-issue.

So for the main Gazebo questions:

• If I need to write the gz-physics interface, will I also need to write an interface for gz-sim? (Or any of the other gz packages)?
• Within gz-physics, I’m sure I’m going to need to modify/add a number of files within various locations. Can you point me to the main areas to start looking?
• Building on that last question, Alejandro linked some PRs in an earlier message – if you have any additional suggestions on good example PRs, it’d be great to see more for reference. The bullet-featherstone PR is quite large (and a bit tricky to understand how it all fits together). I’m hoping this addition won’t require such a dramatic change, so any specific places to focus on in that PR, or in other PRs, would be quite handy.
• I saw that gazebo-classic can also change the physics to use bullet – do you feel this would be equally doable between gazebo-classic and GZ-Garden? (Asking because of the integration with the older repository I mentioned earlier, but I know gz-physics isn’t a part of gazebo-classic). Also, are there any other dependencies / versioning requirements I should be aware of that might affect compatibility here (such as with Gazebo/GZ, ROS, or Bullet)?

Thanks! Dan