bullet dynamics

[joevenzon]

Good idea.

[NaN]

I started to work on the suspension and found a rather interesting bug in the current implementation.

We are applying the suspension force along the chassis normal. Guess what happens if there is a difference between front and back ride heights.

[NaN]

I think I am going to replace the current hinge suspension by a double wishbone.

So instead of:

Code:

[ suspension-front ]
spring-constant = 23000
bounce = 5000
rebound = 4500
travel = 0.24
max-compression-velocity = 10.0
camber = -1.0
caster = 1.0
toe = -0.5
anti-roll = 15000

[ suspension-FL ]
position = -0.66, 1.14, -0.15
hinge = 0,0,0

We will have:

Code:

[ suspension-FL ]
anti-roll = 15000
spring-constant = 23000
bounce = 5000
rebound = 4500
travel = 0.24
camber = -1.0
toe = -0.5
frame-joint-upper =  -0.30, 1.10, 0.10
frame-joint-lower =  -0.20, 1.20, -0.10
hub-joint-upper = -0.55, 1.10, -0.30
hub-joint-lower = -0.65, 1.20, -0.60

The joint placement will define caster angle, kingpin inclination angle, scrub radius.



PS: Someone will have to fix the car files. :o

[joevenzon]

Hmm, yes you're right, with the current implementation, we shouldn't be applying the suspension forces along the chassis normal. Which direction is correct, then?

Regarding double wishbone, isn't the hinge approach more general than modelling a specific suspension type?

[NaN]

The problem with the suspension force is that we are mixing internal and external forces. The suspension force is an internal force acting between car chassis and wheel. It should not change the kinetic energy of the car(like car accelerating with zero driving torque). The only external forces acting on the car are the gravity, normal/friction forces at the tire contact patches and the aerodynamic drag. I've fixed it in the bullet branch. Should I patch the trunk too?

I'd like to have the wheel camber depend on suspension geometry given a vertical wheel displacement. I don't know how to achieve it with the hinge model. I am not a Mechanical Engineer, so maybe I am missing the mark here. I will look for some suspension model papers.

[joevenzon]

The problem with the suspension force is that we are mixing internal and external forces. The suspension force is an internal force acting between car chassis and wheel. It should not change the kinetic energy of the car(like car accelerating with zero driving torque). The only external forces acting on the car are the gravity, normal/friction forces at the tire contact patches and the aerodynamic drag. I've fixed it in the bullet branch. Should I patch the trunk too?

Only if it's a really quick fix.

I'd like to have the wheel camber depend on suspension geometry given a vertical wheel displacement. I don't know how to achieve it with the hinge model. I am not a Mechanical Engineer, so maybe I am missing the mark here. I will look for some suspension model papers.

Just thinking out loud here. There are a number of properties that change as the suspension is deflection: wheel position, spring force, camber, toe, damping, etc. Defining a hinge point makes it possible to model some wheel position change as suspension is displaced, but it's limited to an arc path. We allow changing spring force and damping with displacement by using linear interpolation (see the XS.car's spring-factor and damper-factor settings). We treat the camber and toe as constants. Since these are all functions of suspension displacement, it'd be easy to model camber, toe, and even wheel position by defining points and linearly interpolating over them, like we do with spring force and damper force. Using this I think we could simulate the widest possible range of suspension configurations.

[NaN]

Hey, I like that idea (as we are not modeling suspension geometry loads). But where to get the parameters from? One would need a suspension editor or something.

The double wishbone suspension on the other side would allow to setup the geometry based on car photos/drawings. As a great number of sports/racing cars are using double wishbone or multi-link suspension.

Here the XS:

[joevenzon]

Hmm, would it be too hard to internally model the suspension as I suggested on a frame by frame basis, but allow the user to specify values in terms of suspension geometry? At load time you could construct the suspension and move it through its displacement while taking a handful of samples of camber, etc, then putting that into a table for lerp lookup each physics frame.

The reason I like doing that is because it keeps open the option of putting in other suspension types later... although now that I think about it that could be done with your method as well as long as you write it in a way that it's possible to add in other suspension models later.

[portets]

i have no knowledge of suspension models or suspension mathematics. but what i do know is that i want to make a 57' vw bug and i'm pretty sure the suspension/axle goes something like:




would it be very hard to code that? i might even have enough coding skills to make something like that by the time i make the model.

[NaN]

@portets
Don't worry the implementation is not the problem.

@joe
The lookup table would be certainly faster than having to calculate it directly.
What about allowing multiple link elements in the suspension definition. It would allow to implement any kind of suspension out there and switch to a constraint based(bullet) simulation if necessary.

Here a MacPherson strut suspension:

Code:

[ spring-rear ]
spring-constant = 51137.3
spring-factor-1 = 0.085, 1.0
spring-factor-2 = 0.088, 1.2
bounce = 2788
rebound = 2912
damper-factor-1 = 0.08,1.0
damper-factor-2 = 0.1, 0.7
travel = 0.19
anti-roll = 6000.0

[ wheel-RR ]
position = 0.76, -1.28, -0.48
camber = -0.45
toe = 0.0
roll-height = 0.2935
mass = 18.14
restitution = 0.1

[ suspension-RR ]
spring-start = 0.5, -1.28, 0.0
spring-end = 0.6, -1.28, -0.4
link-1-start = 0.3, -1.28, 0.0
link-1-end = 0.7, -1.28, -0.5

The rotation axis is the link plane normal at the start of a link. A spring(coilover) is a link allowing compression(travel).

[joevenzon]

I like that idea a lot (defining the suspension geometry in the car file). Let's go with it!

[sebiastisch]

@NaN: When are you going to merge the branch back?

Do you think it makes sense to take your new car class and use it as base for the simulation?

Another Question: you are not going to model the unsprung masses, which would make the raycast superfluous, right?

[NaN]

Do you think it makes sense to take your new car class and use it as base for the simulation?

Please don't do it. It is very wip.

When are you going to merge the branch back?

My todo list:
- move physics into cardynamics (done)
- run cardynamics at 60/600Hz (almost done)
- run suspension simulation at 60Hz (wip)
- implement wheel cylinder collision shapes
- implement suspension geometry
- run cardynamics(bullet) in a separate thread

The unsprung weight thingy should be easy to hack into current suspension code neglecting chassis wheel coupling(that is OK as the chassis is like 60 times heavier than the wheel).
What I could do is to stabilize the branch, add unsprung mass and merge to trunk this weekend(cylinder wheels, suspension geometry would be missing). If Joe is OK with it?

[sebiastisch]

Wow, I really appreciate your work there!
I know from my own experince that it is not easy to mess around with that physics stuff

I'm sorry, that I cannot help you as promised, but as this is my job I cannot always chose what work to do and at the moment, this is more a hobby in my spare time (AND coding at work and at home is no good at all ....)

[NaN]

Well, I've got the suspension to run at 60Hz. The cars with a stiff suspension(F1-02, 360) are oscillating badly. I think 60Hz is too low for our suspension model. Not sure what to do next. Go back to 600Hz or try to simulate the suspension in bullet.

Edit:
And the autoclutch is broken. Need to move it into the fixed time step code I guess.