Proper Stability Control Implementation

I have been thinking about some sort of properly implemented stability control system for some time now.
A while ago I had a very rough prototype working for the sunburst but it did not respect the steering angle at all so I will start again from scratch and will try to make it a bit more sophisticated.

For those that are unaware of how such a system works in real life, here's a quick rundown:

1. Detect the desired handling
2. Detect the actual handling
3. Calculate the difference between desired and actual
4. Apply breaking torque to specific wheels based on the difference

Actually quite a simple idea in it's most basic form, however implementing such a system is a totally different animal.

To achieve this, you need access to several things:

1. Something to measure the desired handling --> Steering angle (the drivers wants the car to go where the front wheels point)
2. Something to measure the actual handling --> A Yaw sensor which indicates the car's rotation + slip sensors for the wheels

As you can see, most stuff is already there however, I am struggling with the Yaw at this point. Is there any way to get the yaw momentum from the current car (in a somewhat quickly updated way)?

On another note: How often are the updateGFX methods from vehicle LUA files called per second?

 

This is a very nice idea. It is also a lot more complex than it looks, but it is doable.

Some notes:

To easily see what is called and when, look in main.lua. It has the central switchboard that calls all the other subsystems.

All the updates inside main's physicsStep happen at 2khz (so they need careful coding to not overload the CPU). The graphicsStep updates are split into 2. The synchronous (in sync with t3d), and asynchronous. Both of the graphicsStep updates happen on each graphics frame (anywhere from 1 FPS to 100 FPS).

There are two ways to implement stability control. The simplest one is to "cheat" and use external to the vehicle information (like its velocity vector and so on). This is information that a normal real life vehicle cannot have access to, except by using instruments external to it and transmitting the information to the vehicle. You could pull this of in a simplistic way (not so accurate) by using the direction vector of the vehicle and the velocity vector of it. AI uses something similar to that so you can look in ai.lua to see how it does that (obj:getDirectionVector(), obj:getVelocity()).

In general i avoid using external to the vehicle information for two reasons. First is that i want the simulation to be authentic (it is also great fun to learn how these things work in real life). Second is that i want people to be able to drive their simulated vehicles on top of a simulated moving aircraft carrier (this is my favorite example).

So, the correct way is to only use information local to the vehicle. This is information that you could acquire in real life by using on-board sensors. Someone (corey?) had pointed me to a document where they were describing how such a system works in real life. The whole system was very vehicle specific (calibration wise). I don't remember very clearly, but i think they integrated the g-sensor forces to find the velocity vector of the local reference frame (integral of acceleration is velocity) and the wheel rotation information to correct the drifting that arises from integrating acceleration.

To find where the driver wants to go they used the position of the steering wheel. For linear steering, the steering wheel has a 1-1 relationship with where the wheels point to.

Using above information plus the plane of the vehicle (obj:getDirectionVectorUp()) to project both of these vectors to the vehicle's plane you can find the difference between them. With the difference and information about the topology of the vehicle's wheels, you can then decide which one to brake.

SCS systems need careful and detailed calibration for each vehicle that they are integrated into. Considering that, my advice is to focus on only one vehicle and try to make that particular vehicle working. IMHO, something that will work across different vehicles is extremely hard to be coded. Nevertheless i have been surprised many times now by the ingenuity of the people, so it may happen one more time with the SCS .

- - - Updated - - -

A word of advice.

Completely avoid using trigonometric functions. Every cos,sin, tan, etc that you type in your code will only make your life a lot more difficult (and complex).

What you only need are 3 operations. Dot, cross and normalize. Dot for projecting a vector to another one (or a plane). Cross for finding the perpendicular vector of two other vectors. And normalize to make the vectors have a unity length:

http://en.wikipedia.org/wiki/Dot_product

http://en.wikipedia.org/wiki/Cross_product

http://en.wikipedia.org/wiki/Unit_vector

mathlib.lua provides functions for all of the above (and more). Use ai.lua (or t3d/map.lua) as a reference on how to use them.

 

Nice, thanks for the detailed answer.

For now I am working on the sunburst, as it has the basic logic for this already set up. My code so far looks fairly OK for a prototype that doesn't take into account how much it needs to corret, but only that it does need to correct.
The cheating solution sure sounds a lot easier and is probably for the scope of this project a better solution.

I am wondering about one thing right now though: How do I correctly brake a single wheel?
Looking at the ABS code it should be something like: (when iterating over all wheels)

Code:

wd.lastTorqueMode = 1
w.brakingTorque = wd.brakeTorque

This does not seem to work though. Did I miss something obvious?
I have to admit that I am a strongly typed language guy, so the whole LUA thing looks kinda horrible to me

 

w.brakingTorque (w = wd.obj) is the attribute that the physics core uses to know how much braking torque to apply. You set it to the brake torque that you would like the wheel to receive. It is fairly old code (that works), so it hasn't been converted to using a getter/setter yet. Depending on when your code is being run, it might be overwritten by drivetrain after your code runs. So this might explain why it doesn't work.

Concerning LUA. Yes it has quirks that i don't like too (local scope not being the default, arrays starting at 1). It also has qualities that are very nice. I have a lot more things that i dislike with C++ rather than i have with LUA..

The main reason LUA was chosen is because it has one of the fastest and smallest VMs (LuaJIT). This permits to have near C++ performance and many thread local VMs running at the same time.

To me personally, languages are tools. So i use the most appropriate tool for each job. Even languages that i dislike (C++) [*].

[*] IMHO, rust is an example of a nicely designed language in the same problem space as C++ is...

 

You are right, as soon as I change the main.lua to update the extensions from the physics step instead of the graphics step, braking wheels works.
Maybe you can somehow fix this behavior or introduce a new extension method which gets called each physics step.