Questions about design of the new API and project direction

[JayFoxRox]

Bullet is a great piece of software; but this issue is motivated by frustration with using the PyBullet API (after having used the old Bullet API a couple of times in the past decade).

One of the issues I'm having is described in #2005, and I'll use it as basis for my argumentation. I'd also like to know why this isn't possible ("Why no revolute joint?"), but extend it with: "Why is this feature reachable through URDF or MultiBody".

I consider this a design issues in PyBullet or a lack of documentation (I'm not sure which of those it is, yet).

The root cause of that issue is that the PyBullet API doesn't expose many features that it exposes through URDF. Many of the features in PyBullet (and by extension, the new API) appear to be oddly implemented:

• Why can I create a revolute joint in createMultiBody, but not using createConstraint?
• Why can't I setup limits on constraints using the PyBullet API, but it works from URDF?
• Why isn't createMultiBody part of a higher-level library outside of Bullet (guaranteeing feature-completeness of the lower-level Bullet API)?
• Why is it so much focused on URDF (file-loading from disk) or even rendering instead moving this into libraries outside of Bullet (PyRobot / PyBulletRobot / PyBulletVisualizer / ..)?

That's where I see a possible documentation issue: why is this design like it is?

• Is the C-API that PyBullet uses really the new general-purpose Bullet API or is it meant for special purposes (robotics?)?
  • Should other users continue with the old API (even from Python)?
• Is there some inherent difference between creating 2 MultiBodies and adding a constraint between them versus creating a MultiBody with 2 links using a joint?
• Is there a difference between using a MultiBody with base shape and 0 links - or - using no base shape with 1 link?

I tried to find answers to these questions, but wasn't able to in existing issues, the README, or the quick-user guide. If this is documented elsewhere, please nudge me in the right direction.

---

My personal take on it is that the new API appears to suffer from feature-creep.

Issues like #2151 hint that Bullet is suddenly meant to handle things outside of physics simulation. These might be fine applications / use-cases of Bullet, but I feel like they shouldn't be part of the Bullet project (where they appear to strongly impact unrelated API design decisions).

I struggle to understand why a Physics SDK requires support for Robotics and rendering (including VR), outside of sample-code.

PyBullet, to me, should be the Bullet (Physics related tasks only!) C-API reachable from Python. I don't need a renderer as part of the API (like pybullet.GUI), and I don't need an URDF loader either - I need lower-level primitives (in a stable API) to construct my physical simulation and integrate it with, for example, a renderer / my own application-specific loaders / network system.

Note: I realize there's a backend-system in the PyBullet API, but I don't want to abstract my own software / renderer (component) for use in Bullet (system). I want to use Bullet Physics (component) in my software (system). The API should reflect this.

[erwincoumans]

PyBullet is primarily for robotics and deep reinforcement learning, and some VR experiments. For these purposes PyBullet (and the BulletRobotics C/C++ API) needs a basic renderer, inverse kinematics, inverse dynamics and URDF/SDF support. PyBullet has similar features to MuJoCo and Gazebo-sim. PyBullet is documented here. For robotics it helps to connect to ROS and for deep reinforcement learning it helps to use TensorFlow etc. At some stage, we may move PyBullet to its own separate repository, but since I am the main developer and maintainer separating things just adds extra hassle for me, which is not worth it.

Reduced coordinate Multibody joints are different from constraints indeed. You can browse some old slides that explains maximal coordinates versus reduced coordinates here.

If you just need a C++ physics engine, you can keep on using the underlying Bullet C++ API. That API is still there, under Bullet/src/BulletDynamics and Bullet/src/BulletCollision.