Some of you may have seen me asking questions around on other forums the past few weeks, but the short version is that the organization I work for is examining replacing an old Java 3D visualizer we use in a robotics simulation environment with jMonkeyEngine.
Part of this evaluation is looking at using Bullet Physics to replace our current physics model since it’s
a. Conveniently built in, and
b. Handles collisions much nicer than we currently do.
I’m having a tough time with a few things, and I wanted to make sure that there aren’t any ways to do what we want in a trivial manner before we go off writing subclasses or utilizing raw JBullet.
The first thing we’re a little stuck on is creating rigid links. Consider a pendulum, but instead of two nodes with magic space between them, the pendulum arm has mass. You would want the hammer of the pendulum kinematically linked to the bottom of the arm, but not on a joint. We’re currently doing this with a HingeJoint that is locked by setting the revolute axes to be zero vectors and making the pivot locations very tiny so that the hammer is in contact with the rest of the arm. Is there a better way to rigidly link two bodies?
Are there lower-level mechanisms for manipulating joints? As I mentioned above, we intend to perform robotics simulations. As such, we intend on utilizing advanced control strategies on the physical objects that we model in the system. This means that, frequently, we will wish to perform position control or torque control on our systems. This is especially true of revolute joints, or what seems to be called a HingeJoint in jME. While most people think of a shoulder as being some kind of 3DoF ball joint, they are often mechanically simulated and modeled as three disparately aligned revolute joints with intersecting axes. The fact that I can’t set a joint angle or a joint torque on a HingeJoint at the high level, but can only exert an “impulse” (which is poorly defined) and have the underlying solver apply a torque, is a little frustrating when looked at in the context of our goals. I want to make sure that there isn’t some lower level of abstraction in place that we can utilize before I go off and start creating custom joint classes.
@normen Regarding 6DoF: see my statement about how we model robots. This is especially true when we want out simulations to accurately model our real machines, which are also built using intersecting revolute joints. I did see the 6DoF class and intend to subclass it to make my own revolute joint if I need to. I just wanted to make sure that I needed to, first.
Thanks for the tip on handling rigid linking, though. I’ll take a look in to it. How good is bullet with handling inertias across weird mass distributions like that, though?
Regarding your robots: see my statements about SixDofJoints. Why subclass it if you don’t want to use its methods externally? I’d say it would be better to wrap the object, you have the example of two different physics systems at hand, it should be apparent why that is better. The center of mass is always at the center of the collision shape use a compound shape to give an offset.
@normen I suppose my inclination to subclass instead of wrap is because we would want a general purpose revolute joint with torque and position control exposed. It’s still conceptually and functionally a joint so to wrap it, we would be wrapping a joint in another joint and that seems odd. Subclassing the 6DoF and hard coding limits to create an implementation of a revolute joint just seemed more immediately intuitive to me. We are modeling four or five real robots right now so if we want to use jMonkeyEngine to handle the physics we can’t replace the models with simulated ball joints just because it’s “better”. Especially because the shoulder of one of our robots is built with one of the freedoms off-axis, so it’s impossible to model the physics correctly with a ball joint.
Regarding the compound objects, I just wanted to make sure that Bullet calculated the inertias across irregular shapes and mass distributions without doing things like bounding box approximations or assuming uniform density when determining the principle axes and angular momentum and other properties that result from inertia. I’m not well versed in the implementation. I’ll do my own research in to this.
@normen so for an irregularly shaped object I’d have to calculate the CoM and apply an offset manually? The CoM is not always at the geometric center. If this is the case I may stick with locked hinges in the general case and compound objects to implement specific reusable linkages/parts.
I agree that a 6DoF will do the trick. What I disagree on is that every time one of our engineers wants to implement a revolute joint, they should instantiate a 6DoF and set a bunch of limits. This is a design preference at our lab; we like our code to be very high level because most of our scientists are not programmers by trade. They are mechanical engineers. So I think we’re just debating coding style at this point. If I want to make a high level API on top of jME for our simulation suite, I will base the interface to a revolute joint on a six DoF joint. I just wanted to make sure that was indeed the best starting point.
Thanks for your time and attention. I know I’ve been taking a lot of it.
My suggestion was creating a completely different set of objects that your engineers use which internally use SixDofJoints they manage according to the requirements
By encapsulating 6dof rather than by subclassing it that means you can prevent people calling methods that you don’t want to expose. If you subclass it then every 6dof sub class exposes all the 6dof methods as well.
