Havok: motorized constraints

Hi all,

I am very excited at the idea of using the Havok engine in my video game where my performance bottleneck is precisely related to Ammo.

I did not find any information on the motorization of physical constraints. I would need to induce velocity on a hinge-like and slider-like constraint as is possible in Ammo and Canon.

Is it possible? Is there an example or related documentation?

Thanks in advance.

Probably that PhysicsConstraint.setAxisMotorTarget() does the job. I will test this asap and keep you updated.

1 Like

Motorized constraint is not well documented. If you can provide a good sample playground, Iā€™d be happy to add it to the documentation.

1 Like

First of all, it seems that the API is only open for 6DOF constraints, which makes using motors difficult from the very beginning. Indeed, I would have expected to be able to simply do a setTargetVelocity() , setTargetPosition() or setForce() on simpler constraints such as a HingeJoint or a PrismaticJoint.

  • Is there a way to call native Havok functions to try this?
  • Is there an online API for Havok?

Iā€™ve done a few tries starting with the main Havok example and the constraints example, but I canā€™t get the second solid to move using the motor related functions.

Here is my result on a 6DOF joint which looks like a distance constraint:

I wonder if anyone has a starting point that would allow me to start with this topic?

Indeed, I canā€™t get it to work with 6DOF or other constraints when using directly the plugin. Is there something we are missing here @eoin?

1 Like

Weā€™ve got a bug in HavokPlugin.setAxisMotorType() - weā€™re passing the motor type straight into the WASM; it needs to be converted to the ā€œnativeā€ type, like we do for the axis ID.

I was able to workaround it in the playground by passing in the native type directly. Hereā€™s a playground that I based on the above which shows how. I also modified the joint and shapes to make it a bit easier to see the effect of the motor. Iā€™d definitely like to add some more interfaces to the simple joint types. As it is, they use the 6DOF interface under the hood, but in a limited way, to make them easier to setup.

3 Likes

Thank you very much for taking my issue into consideration.
I can now progress a lot with your workaround.

I worked several years in robotic simulations and I recommend you to open APIs to control prismatic and hinge constraints, in force, velocity and position modes. This covers 95% of the robotic cases. PID control would also be sugar.

If at some point I have a good sample to share, I will post it there.

Iā€™ve open an issue to keep track [Physics] setAxisMotor native parameters Ā· Issue #13801 Ā· BabylonJS/Babylon.js Ā· GitHub

1 Like

Fwiw i saw ms iot os using babylon in the vscode plugin and also made a collada loader. Not associated with it in any way, just saw it on github. GitHub - ms-iot/vscode-ros: Visual Studio Code extension for Robot Operating System (ROS) development

.babylon_ros/Joint.ts at main Ā· polyhobbyist/babylon_ros Ā· GitHub

Hopefully a good reference for cedric and havok friends

1 Like

I progress a lot with linear and angular constraints in my project, and itā€™s working like a charm (even if 6DOF anchors and axes are a nightmare to setup).
Linear and rotational control in velocity and position seems to work well too.

I have now another issue: is there a way to retrieve the actual angle or position of a constraint? I need this feeedback to implement PID control.

Physics6DoFConstraint.getAxisMotorTarget() allow to get the last command, but not the actual position or angle feedback.

@eoin I probably have to call some Havok API directly?

Thank you in advance.

If you keep track of bodies using that constraint I guess you can get the angle using a simple dot product of one of their axis?

Yes, this is what Iā€™m doing now, so Iā€™m not blocked with this.

But I expect that the physics engine has this data internally. So recomputing it is not efficient, and not so obvious. For example, a motor controlled in position can do several turns and can have values above 2*Pi. There are also issues with signs, etc. This is not simply a crossproduct.

Every physics engine I worked with have an access to this value, for example AMMO:

We donā€™t actually store those values in the engine (except in some special cases), so calculating it is definitely the way to go. I agree we should put in methods in the joints to calculate these so you donā€™t have to write that code.

As an aside, Ammo seems to sometimes calculate it, and sometimes use a stored value:

I donā€™t know anything about the Ammo implementation, but my gut feeling is that using a stored value is likely to give slightly incorrect results. I guess that sliderā€™s stored value is set inside the solver; in a PGS solver, other constraints are able to modify the bodies after that value would have been computed, so it can be slightly wrong. It also probably doesnā€™t account for modifications to the body transforms after the solving has completed. Could be wrong on either of these, obviously, but just looked like something Iā€™d be concerned about.

Also I see you said the 6DoF constraint was difficult to use. I spotted a bug last week where the ā€˜perpAxisā€™ parameter was ignored, which might have been the cause of that? (Fix bug where constraint perp axes were ignored by eoineoineoin Ā· Pull Request #13859 Ā· BabylonJS/Babylon.js Ā· GitHub) If so, Iā€™m real, real, REAL sorry. Very embarassing bug :pensive:. If you had any ideas for how we could improve the documentation here, Iā€™d love to incorporate them. All those constraint setup parameters feel quite natural to me, but Iā€™ve been doing this fo a long time :wink:

Thank you very much for your answer.
I have to digest it, and I will come back later with this.
The bug you solved with the perpAxis may explain lot of my issues. Currently, I think there are bugs with 6DOFConstraints, when there are more than 4 DOF that are locked. I bet that itā€™s precisely linked with perpAxisā€¦

OMG, I confirm that the perpAxis bug was causing lot of issues in my project. Upgrading @babylonjs/core and using perpAxis properly allow me to do what I want with 6DOF constraints.

2 Likes