Investigation of a Bullet enabled engineering toolchain

[Joe Hays]

Hello all,

I'm a newbie to Bullet and am investigating whether it is a tool I should seriously consider using for some of my personal research as well as to introduce it into the lab as a resource to a large team of robotics/mechatronics mechanical engineers. Our lab focuses on robotic locomotion which is frequently legged locomotion.

I am very interested in finding tools that will help in the engineering analysis and design of the robot's motion control systems. One primary need is improved simulations that account for impact and friction. I've found a number of rigid-body simulation tools that account for these discontinuities, however, most of these tools suffer from immature modeling interfaces (i.e. how to specify the geometry, kinematic relations, mass properties, friction & impact coefficients on a per body basis, etc...). From a mechanical design perspective, most mechanical engineers are trained with solid modeling CAD systems such as SolidWorks, UGS NX, CATIA, Pro/Engineer, etc... However, my impression is most of the physics engines cater more to the game industry than to the engineering industry. Therefore, they typically provide software APIs to build up the dynamics system to be modeled. This is a scary nightmare for most mechanical engineers. They are typically not educated in software development practices. So, a none software API based modeling process is desired. Ideally, this modeling process will be directly integrated with the physics engine somehow. Bullet is the only tool I've seen that integrates with a third party modeling tool (i.e. Blender) to facilitate this modeling step. While Blender is not ideal from a mechanical design perspective there appears to be facilities that allow SolidWorks models to be imported into Blender and then subsequently used with Bullet. Therefore, IF a user can:

1) Create two independent robots in a mechanical CAD package; such as SolidWorks.
2) Import these independent robots into Blender with relative ease.
3) Simulate the independent robots motion with Bullet; again with relative ease

then, a majority of my needs appear to be satisfied. Two needs remain.

First, our lab uses LabVIEW software from National Instruments for the actual control system implementation. It reads sensors, allows us to write feedback control system logic, and command actuators in hard real-time (i.e. timing is deterministic down to micro-seconds). This is great for physical realization of the controller. We'd like to use our LabVIEW based controller software in a virtual high-fidelity simulation of our robots interacting with a virtual world. Once this is possible the controller code developed in the virtual world will be reused in the physical world; hopefully with minimal tweaking/tuning.

As such, a primary need from a physics engine for our use case would be to provide 'sensor' and 'actuator' interfaces such that the state data, or 'sensor' data, can be read from Bullet through some API every time-step of the simulation. Subsequently, the feedback control law is calculated outside Bullet (by LabVIEW in this case) and then "actuator" command signals are passed to Bullet for use in the subsequent simulation step. As long as Bullet can be compiled into a DLL and provide the above interfaces we can call it from LabVIEW.

Therefore, do 'sensor' and 'actuator' interfaces exist for an arbitrary model being simulated by Bullet? In other words, can an arbitrary kinematically constrained rigid-body system be loaded/defined in Blender and Bullet be able to provide access to appropriate sensor output and actuator input data for that given system in a step-by-step, or point-by-point, fashion?

The last need appears to be implicitly available from that fact that Bullet is open source. Given our efforts are academic research oriented some of us will need the freedom to investigate novel algorithmic techniques for the rigid body system simulation as well as the control system design/implementation. The open source nature of Bullet satisfies this.

In summary, can I,

1) Create an arbitrary kinematic constrained rigid-body system in mechanical CAD package (e.g. SolidWorks) and import "reasonably easily" import this into Blender ready for use with Bullet?
2) Does Bullet provide 'sensor' and 'actuator' interfaces for an arbitrary system for point-by-point access external to Bullet (i.e. for closed loop control purposes)?
3) Can point-by-point 'camera' images be made available from Blender for a few of our vision based sensors? (This might not be appropriately ask in this Forum but given the tight integration of Bullet and Blender it might be relevant here.)

Thank you for helping me investigate the feasibility of this Bullet enabled toolchain.

Best Regards,

Joe
Robotics & Mechanisms Laboratory, RoMeLa
http://www.me.vt.edu/romela
Virginia Tech

[Erwin Coumans]

1) Create an arbitrary kinematic constrained rigid-body system in mechanical CAD package (e.g. SolidWorks) and import "reasonably easily" import this into Blender ready for use with Bullet?

Blender and Bullet support the COLLADA file format, including physics information. Blender also has several other file formats, but they don't support rigid body and collision information, so you will need to author/add this within Blender. Or perhaps someone can develop an exporter for SolidWorks to COLLADA, with physics information.

2) Does Bullet provide 'sensor' and 'actuator' interfaces for an arbitrary system for point-by-point access external to Bullet (i.e. for closed loop control purposes)?
3) Can point-by-point 'camera' images be made available from Blender for a few of our vision based sensors? (This might not be appropriately ask in this Forum but given the tight integration of Bullet and Blender it might be relevant here.)

Not sure what is meant by 'sensor' and 'actuator' or 'point-by-point'. Can you explain what this means in the context of physics engines? Does it refer to a collision sensor? And actuator is powering a motor?

Thanks,
Erwin

[Joe Hays]

Blender and Bullet support the COLLADA file format, including physics information. Blender also has several other file formats, but they don't support rigid body and collision information, so you will need to author/add this within Blender. Or perhaps someone can develop an exporter for SolidWorks to COLLADA, with physics information.

Thanks for the info. Wish this exporter already existed... Looks like this path might be a bit more involved than I had hoped. I'll have to play with it a bit and see how involved it is...

Not sure what is meant by 'sensor' and 'actuator' or 'point-by-point'. Can you explain what this means in the context of physics engines? Does it refer to a collision sensor? And actuator is powering a motor?

The physics engine manages all the state data of the system during each simulation step. However, from a feedback control perspective physical sensors (such as encoders, LVDTs, thermocouples and the like...) may, or may not, coincide with the generalized coordinates/states the physics engine has selected. Therefore, a mapping (either linear, or nonlinear) from the engines generalized coordinates to the sensor 'coordinates' needs to be provided. Stated another way, the engine solves,

x' = f(t,x,u)

where the controller needs the outputs,

y=g(t,x,u)

Additionally, the actuators are generally functions of these outputs,

u=h(t,y)

and coincide with motors, hydraulics, pumps, etc... They simply are sources of force, torque, etc...

Regarding the 'point-by-point' comment. The feedback controller needs sensor updates at a consistent dT rate. This dT typically coincides with the physics engine's dT for each step (although it doesn't have to). The physics engine's dT must be equal to or less than the dT for the controller. When I requested 'point-by-point' support I was referring to an interface that would allow and external piece of code to in essence throttle the execution speed of the physics engine. For example, an external controller software would calculate an initial actuator input, u(t), and call Bullet's Step function providing this input, u(t). The Step function ideally would then return the outputs, y(t+dT) which the controller would use to determine u(t+dT) and the cycle starts again. This is what I meant by 'point-by-point'. I presume such an interface exists in Bullet but wanted to check...

I hope this helps clarify. Thanks again for your feedback. I appreciate it.

Joe

[medic]

Hi Joe,

It depends on what you need to simulate. For rigid body mechanics Labview has a interface to COSMOSMotion which allows you to interact with rigid body mechanics in Solidworks:

Code: Select all

http://zone.ni.com/devzone/cda/tut/p/id/6183

I like this method as it keeps the graphics and CAD models in the CAD environment so you only have to mantain the Labview Hooks.

Alternatively take a look at Mathworks SimMechanics

Code: Select all

http://www.mathworks.com/products/simmechanics/

You can get your actuator and sensor models completley described using this package. However the CAD models will be brought in as XML files and your mechanism will animate in a Virtual VRML world in Simulink. This takes quite a lot of setting up and if you change your CAD model you have to do some of the work again.

The limitation of both these methods is that you cant have contraint or collision modeling so you cant see your robot pick something up and move it to another place.

For that you'll need a physics engine like bullet and for that this is no examples or previous successes to learn from.

Good luck.

Mark.

[Joe Hays]

It depends on what you need to simulate. For rigid body mechanics Labview has a interface to COSMOSMotion which allows you to interact with rigid body mechanics in Solidworks...

Alternatively take a look at Mathworks SimMechanics...

The limitation of both these methods is that you cant have contraint or collision modeling so you cant see your robot pick something up and move it to another place.

Thx Mark,

I'm aware of both of the options you mentioned. My greatest interest/need is to incorporate the collision and frictional effects (the forte of the physics engines) in the simulations. This is why I began to investigate Bullet.

Oh well, I guess all the fun would be lost if it was easy... I appreciate your pointers.

Joe