6DOF motors' forces and velocities depend on used timestep?

[Kulik]

I stumbled upon something I wasn't expecting. When I changed used timestep, the motors' behaviour changed drastically. I am just wondering whether this is expected behaviour or perhaps something amiss in 6DOF constraint?

The video showing this behaviour http://www.youtube.com/watch?v=VFR4mwmWa-M

From IRC:

Code: Select all

(8:36:33 PM) Kulik: Hi, I just found out that 6DOF motors and springs are very sensitive to changes in timestep. the smaller the timestep, the stronger the motors get. Is that expected or is there perhaps something wrong with my integration? Thanks for any pointers :-)
(8:38:19 PM) Kulik: I will do a small comparison video to demonstrate this, give me a few minutes :)
(9:08:36 PM) Kulik: Ok, this is how it looks: http://www.youtube.com/watch?v=VFR4mwmWa-M
(9:08:51 PM) Kulik: if the source is relevant, I can commit and post the repository URL

I am using bullet 2.76 and I use the motors like this:

Code: Select all

btRotationalMotor* motor = rearLeftWheel->getRotationalMotor(0); // I have "reordered" the 6DOF to allow suspension, steering and wheel rotation using just one constraint
motor->targetVelocity = -300;
motor->maxForce = mTransmission->getOutputPower(); // this changes as the throttle changes

Maybe I am using them wrong? This section of bullet really lacks documentation so unfortunately I don't know any better

I have also observed another really weird behavior. When the car is on the "roof" and the throttle is pinned the wheels spin up to targetVelocity and then suddenly stop and spin up again. I think my naive idea of how motors work is wrong

[Flix]

Do this test: try to use a motor force proportional to the timestep: i.e. 10 times bigger at 60 Hz and see.
Maybe the motor force is applied at inner timesteps (like impulses).

// I have "reordered" the 6DOF to allow suspension, steering and wheel rotation using just one constraint

How did you manage to allow vertical suspension ? I ask because I did the same (http://bulletphysics.org/Bullet/phpBB3/ ... 60&start=0), but was only able to apply a constant vertical force to the constraint

[Kulik]

These are the settings I used to make the video http://pastebin.com/CgdEfg8Z, they work for 1 / 600.0f timestep. I use a thin wrapper around Ogre, Bullet and OIS/OISB but the values should be apparent from that. It's a little messy at the moment, needs a lot of refinement.

You can probably see it better in action here http://www.youtube.com/watch?v=Na4IEa5zWwo

I will try your suggestion later this day, thanks. Unfortunately not only motors are sensitive but even the springs in bt6DofSpringConstraint are sensitive to timestep. And spring rate definitely should be universal.

[Flix]

Thank you for your code
Your suspension system seems very good from the video (and I hope I'll be able to improve mine too ).

Code: Select all

Unfortunately not only motors are sensitive but even the springs in bt6DofSpringConstraint are sensitive to timestep. And spring rate definitely should be universal.

Well, so it seems we need to scale almost everything if we want to make an application timestep independent...

[Kulik]

Thanks for the bump Flix

I have actually improved it by moving the attachement points higher, thus lowering the chassis. I will probably raise it a bit because it became a super car If you find more improvements, I would be glad if you sent them to me. It's all in the const numbers it seems but it needs hours and hours of experiments till you tune it just right (which I haven't done yet)

[reptor]

it needs hours and hours of experiments till you tune it just right (which I haven't done yet)

I thought about this problem when I was planning a car racing game.

We would need to have an automated process to find good parameters. So we would leave a simulation running. We would have given it some real-world known-good values for how the car should behave given certain input values. Then we would have the simulation tune the physics parameters until the output of the simulation sufficiently matches the values received from real-world tests given the same input data.

This would be extremely useful to have. I thought it's a bit crazy that people are trying to do it by tweaking the values 'blindly'. I would have to do that too if I would start such a project now without creating the tool to find the parameters first.

You could have a computer program test all possible combinations of parameters if you like. Just let it run and find the good parameters for you. You could even shorten the iteration time the more data you have accumulated because then you can give the simulation 'guess' values so it can find to the good values more quickly.

Just something I was dreaming about - I've not coded such a thing at all yet (and didn't even start the car racing game) but I can see the value of it. This could even be a successful commercial project I think.


On a related note. There are car racing companies around the world using computer simulations to simulate their race cars before they hit the real tracks. They have laser-scanned the real tracks and brought them into a virtual world on their computer. Some of the F1 teams have very accurate simulations, the lap-time predictions are off only a little bit. Of course these teams have accumulated a lot of real-world data on how such a car behaves. With that data it is easier for them to create a "find physics parameters" program because they know what the good expected output values are.

[Kulik]

Sorry sorry sorry for bumping. Thanks for all the kudos but I still don't have the answer

reptor: I think this is even more work than actually hand tuning it, perhaps not by much though. To be honest I have no idea how racing games do that.

[Erwin Coumans]

I'll ask Roman for further information, he developed the motors.

Stay tuned,
Erwin

[Kulik]

Thanks a lot! Here is the repository with full source of everything involved.

svn://svn.czenet.com/Tenuity

The code from the video is in Samples/Buggy, the bullet integration code is in Tenuity/SceneAspects/DiscretePhysicalSceneAspect and Tenuity/Component/RigidBody Generic6DOFConstraint StaticBody Component

[rponomarev]

Hello,

The maxMotorForce value is actually sets a limit for impulse, applied during one timestep.
So if you scale timestep dt you should scale maxMotorForce as well, e.g.
if you had maxMotorForce == 0.1 for dt == 1/60 sec, you should set it to 0.01 for dt == 1/600 sec

This maybe confusing, we'll think how to make this parameter independent from timestep.

Hope this will help,
Roman

[Kulik]

Thanks for the reply! I guess I was confused because this is inconsistent with the rest of bullet where impulse is sort of per timestep whilst force isn't. If this is sorted even springs will get timestep independent.

Should I roll a patch? Any ideas about how the parameters should be called?