My drivetrain is done in an OO way, each part of the drivetrain (engine, differential, wheel etc) deriving from a base class. In my Vehicle class, I maintain a std::vector of components, which in theory will eventually be added from reading an XML file but are currently hard-coded. The idea being that I do Vehicle::RegisterDriveTrainComponent(...) for each component. While this is working at the moment, my simulator has never been particularly stable - even using RK2 with a 2ms timestep the wheels start to judder when the car is stationary with the brakes off. This may or may not be related to my setup, but I'm wondering about it because imagine this setup: My Vehicle::Update(dt) method iterates through every componet, calling its Update(dt) method. In the first update, the diff will be updated from the wheels, the clutch from the diff etc (looking only in one direction). The next update, the diff gets a new state and the clutch is updated from the previous state of the diff. The next update, the engine is updated from the clutch, which is now based on information which is 3 updates old. Essentially I'm wondering if this propagation issue makes the whole component system flawed. One other implication is that with my current setup, the components have to be loaded in the right order, else the updates for componets don't work properly. I don't want to hard-code and engine, a diff, 2 wheels etc - this would be one way around it. But looping through each calling Update(0 for each component just seems a bit lame.... ... any suggestions for a flexible system without these propagation issues - I get the impression that while my current model is actually quite realistic, it's only just holding itself together hence the requirement for a tiny timestep.

Quote:Original post by d000hg
While this is working at the moment, my simulator has never been particularly stable - even using RK2 with a 2ms timestep the wheels start to judder when the car is stationary with the brakes off. This may or may not be related to my setup, but I'm wondering about it because imagine this setup:

In what way are the wheels juddering? Is it an up/down motion or a rotation?

If it's an up/down motion then I'd look more to your collision system first, if it's rotation, then you may have some sort of feedback effect going on. If it is feedback then you may be able to add some damping in to the system somewhere.

I don't see how can it be done using simple one-way propogation anyway - surely the engine drives the wheels, but also friction on the wheels (e.g. when the chassis is moving) drives the engine too.

Are you sure what you're doing isn't just one iteration of a relaxation step that attempts to solve the system simultaneously? If so, it may work if you're able to do a couple more iterations of this step per physics update (some iterations going one way through the system one way, other iterations going the other way).

It does go both ways, but for simplicity I focused on a one-way situation. The effect of the engine on the wheel will actually be 6 updates behind the current situation at the wheel since the wheel effect has to propagate to the engine and then the engine effect propagate back to the wheel.

If I hard-code things or make sure my components are ordered correctly, then I think this problem is removed, at least in one direction - wheel gets updated, then diff, then clutch, then engine. The engine will actually be updated correctly, but going the other way will be incorrect. Unless I iterate through the components, then iterate back again! But the whole point of an integrator should be discrete states - the derivatives calculated on each component should be from the last state, not what has already been calculated of the new state. RK2/4 get confusing unless you separate state and derivative...

Oh and the juddering is a rotational one. It has no effect to make the car move. After releasing the brakes on a flat surface, a few seconds later the wheels start to oscillate. Changing the timestep reduces/increases the effect, but RK2 at 500fps should be rock-solid.

make sure you code in a clutch or stall converter is its auto could help

Cant you update each object's angular velocity each frame, then apply the necessary torques to each 'joint' every frame to 'connect' them? Is that how you do it and maybe I misunderstood? It sounds like each frame you are solving one object based on the physics, then passing that velocity down the line (altering by gears and such?)
A small detail, is that when you do RK2 or 4 or whatever that is superior to Euler, you need to apply that to all the values that integrate. This includes the slipRatio calculation which I assume you have for your tires. It's easy to do the angularVelocity integration with Rk4, but overlook other things. The end result: wobbly wheels.

I do update each component each frame, but the problem is that each component's state is calculated from inputs from its neighbours. If these values aren't the most recent then I would think that would reduce stability.

IIRC my slipRatio is done by the RK2 - I'm using the differential equation formulation of slipoRatio rather than calculating it from scratch each frame (which is more stable but has its own problems).

That was me by the way!

Do you take into account the rotational inertia of the wheels? Or do you have any sort of internal dampening to cancel out miniscule forces?

It might be that you have very small residual values that add upp over the frames and build up an oscillation.

note: I suck greatly when it comes to physics and iterators, but I have seen similar effects in a simulator i used to work with.