New sim code

[NaN]

One thing that seems to help with the grip/control is to clamp tire slipratio to [-1, 1] and slipangle to [-60, 60]. This might be a good idea in general. I am not sure if there is any tire data that goes beyond this ranges. The hankook values have been measured within [-0.8, 0.8] and [-30, 30].

[NaN]

OK, I am starting to experiment again, not good. Will revert master to the old sim implementation.

I think I'll keep the new code in a separate fork.

[charlieg]

OK, I am starting to experiment again, not good. Will revert master to the old sim implementation.

I think I'll keep the new code in a separate fork.

What's not good? That you're experimenting? Or the results?

Forks aren't bad things though.

[NaN]

What's not good? That you're experimenting? Or the results?

Forks aren't bad things though.

The new sim has a more correct suspension, driveline and tire contact model but can't keep up with tire response of the old implementation as it is low frequency (90Hz, old code is running at 900Hz). This is noticeable in the handling of high powered cars, to be more exact cars with high torque engines. The solution to run new sim at higher frequency is too demanding if you want to run more than 1-2 cars at 60fps. I've been looking for ways to simplify, speed up the code. But it looks like it might take some time and experimenting (with negative effects sometimes), thus the revert to the old code.

I still would like to mess with the new code as it works great within certain limits.

Edit:
To be honest up to now I've struggled with the tire model (pacejka+beckman). It felt kinda wrong sometimes and I had no idea about the origin/correctness of the parameters.

Now with the real tire data and the more complete pacejka model there is a reference. I feel I should start with the tires and build the simulation around them. Something high frequency with maybe a minimal iterative solver (3 - 4 iterations per simulation step) for the components. It should be fast enough to run 4-6 cars at 60fps on a 2GHz core (16ms per frame).

[ghiboz]

but the new code that you reverted there's the tire model with the real data or only some fixes and cleans?

[NaN]

but the new code that you reverted there's the tire model with the real data or only some fixes and cleans?

The tire data and paceka96 code is in a local branch. I've never pushed it. It is more complex and I wanted to compare/profile it against current implementation first to see how much performance it costs.

Additionally the new tire editor script has to be finished and the existing 4? tire configs converted. The parameters are not compatible.

[joevenzon]

Can you run just the tire contact part of your new sim at a higher frequency?

Also, I wonder if there are ways to speed it up by using the GPU...

[NaN]

Can you run just the tire contact part of your new sim at a higher frequency?

Also, I wonder if there are ways to speed it up by using the GPU...

Maybe something like:
1. bullet rigid body collision/physics step 90Hz
2. suspension response step 90Hz (no contact friction)
3. calculate impulse delta since last step (like in the old sim code)
4. solve driveline and tire contacts at 900Hz, feed impulse delta / 10 as external impulse (like in the old sim code)

Driveline and contact constraints are operating in velocity space, so it might work and should save quite a few body + wheels transform updates and wheel ray interpolation.

The issue I see atm is the separation of suspension response and contact friction. Think of car body roll due to contact friction. There would be a delay by one step(90Hz) till the suspension "notices" the friction effects. But then car mass/inertia might help here. I need to compare it to a full 900Hz version.

[NaN]

I rewrote the new sim code as described in previous post and ran a few comparisons on ruudskogen with 350Z, ABS/TCS disabled. Old code still wins in tire response (handling/grip).

I think I'll do some telemetry comparisons, especially wheel forces and torques.

[NaN]

Looking at the telemetry showed that the old code is running with a wrong weight distribution for the 350Z 47/53 while the correct one in the new sim(with substeps) is 53/47. Which also explains the grip issues. After feeding the same car data into both sims the new one is actually more stable. I need to test both sims with a few more cars but I hope for similar outcomes so that the new code can be "re-reverted".

Just for fun a snippet of engine + wheel friction torques of both sims:

old(10 substeps):

47.8968
50.1497 w -129.877 -134.324 -320.931 -321.354
49.4877 w 129.619 134.153 331.809 332.474
51.7235 w -128.938 -133.477 -331.263 -331.948
50.9522 w 129.224 133.975 341.636 342.303
53.1722 w -128.478 -133.159 -341.065 -341.664
52.2995 w 128.68 133.542 350.682 351.343
54.5049 w -127.885 -132.424 -350.122 -350.44
53.5393 w 128.573 133.515 359.017 359.649
55.7313 w -128.154 -132.91 -358.943 -359.382
54.6771 w 128.205 133.183 366.662 367.278
57.0

new (10 substeps):

47.4184
51.6482 w -50.2377 -47.6083 -355.091 -349.725
51.6482 w 43.8085 43.861 -216.299 -210.362
51.6482 w -13.8166 -12.9071 -305.447 -295.342
51.6482 w 18.1025 17.5345 -256.7 -249.294
51.6482 w 2.99534 -0.33031 -274.576 -281.526
51.6482 w 6.95784 10.0478 -270.359 -263.997
51.6482 w 4.61346 1.61523 -272.124 -278.665
51.6482 w 12.4322 15.5022 -262.111 -255.427
51.6482 w -7.19947 -10.3066 -290.224 -296.928
51.6482 w 11.8116 14.9467 -289.785 -127.92
55.8798

The engine torque is updated every full step in the new sim. Please note the oscillations in the old sim which have been one of the reasons for the rewrite and are greatly reduced in the new implementation. Ideally we would want an even more smooth behavior but that would require running the complete sim at high frequency.

[NaN]

Found an error in the substep implementation. This is how the new sim with substeps looks like:

95.9891 w 7.78311 7.77519 -461.869 -461.878

100.107 w 7.73229 7.7236 -494.101 -494.111
100.221 w 8.32559 8.32098 -495.807 -495.812
100.335 w 8.32951 8.35873 -495.803 -495.771
100.449 w 8.33974 8.34596 -495.792 -495.786
100.565 w 8.34527 8.3402 -495.786 -495.792
100.68 w 8.34627 8.3392 -495.785 -495.793
100.796 w 8.34666 8.33866 -495.785 -495.794
100.913 w 8.34681 8.33858 -495.784 -495.794
101.031 w 8.34696 8.33843 -495.784 -495.794
101.148 w 8.34704 8.33843 -495.784 -495.794

105.318 w 8.29345 8.28437 -529.278 -529.288

Completely smooth during substeps. Now if I could get rid of the jumps form one full step to the next... not yet sure where they are coming from(I've already pulled engine updates into substep loop).

[NaN]

The jumps are caused by the auto clutch (anti stall) logic at low rpm when the clutch is slipping. The clutch and shift logic runs with 90Hz thus this step like signal. Beyond the anti stall area the values are smooth as expected.

[NaN]

Huh, December already. Progress has been slow in the last months. Just to show that the project is still alive I've upped a AI test video.

http://www.youtube.com/watch?v=3noQ8aSaePs

I am using this ai for sim code testing. It is based on an idea I had for some time already, just never got to implement it. The ai estimates a velocity profile form racing line curvature (up to a minimum/maximum) and uses this information for brake/throttle control. I am using the old(simple) steering logic, so there is still room for enhancements. But it work surprisingly well already.

[charlieg]

That is pretty awesome.

[GunChleoc]