Pacejka tire coefficients

[joevenzon]

Cool plots! Does the "slip ratio" plot just have no combining? One thing I've noticed is that in a discrete time simulation like VDrift with fairly large timesteps (greater than 1 ms seems like fairly large timesteps where tires are concerned), there's always a bit of oscillatory noise that goes into the tire model, and as a result you can get artificial peaks that break traction and also make it tougher to recover traction.

Anyway, to fix Beckman's method, all I need to do is zero any horizontal shift components, correct?

[orangutan]

Slip ratio is combining, and is similar to beckman in that it manipulates the combining ratio based on pre-friction force information (the slip rates). It is cruder than beckman.

For a dynamic contact patch sim, which you don't have at the moment, you do need to run a much higher frequency. The 600hz you run the tires at now gets you decameter resolution at speed. You need cm resolution for a good dynamic contact patch.

However, the problem you cite is not a really a tire friction modeling issue. It is a more general integration issue, made worse by the fact you are stuck with explicit integration. And you will continue to be stuck with it at the core chassis level since you are coupling to a third party MB solver (bullet). I don't think this is a problem though. At 600hz, at the frequency the tires react at the car level, you should actually be fine...if you had the amount of damping on your tires that real tires do. In my little refactor I added damping. You have 1e5 spring rate hardcoded. About 1e3 normal ol viscous damping does the trick for me.

Yes, the easiest way to fix beckman is to zero out the horizontal and vertical shift components in your Pacejka parameters. Honestly, those parameters are not worth much in the big picture given how much is already being approximated by using a steady state model in the first place.

[NaN]

Hi orangutan

The previous release has been running at 1kHz I think. Thus the simulation frequency is not a big deal. The coupling to bullet is rather loose, introduced as an external force/torque.

I been looking into lumped LuGre tire model some time ago but haven't found any papers accounting for wheel camber.

By the way, do you mind to share your dynamic simulation code?

[orangutan]

That loose coupling /is/ effectively explicit euler integration. Bullet only sees the tires as external forces, not any notion of the jacobians, and therefore they integrate purely explicitly wrt Bullet. So my point was not that you are stuck integrating like Bullet does (which you are not, because Bullet is not explicit internally), but simply because you are loosely coupling...as you sort of have to due to the complexity of tire friction. You /could/ model just the Fz force with a strong coupling, as constraint in Bullet, but I don't think you have to, unless you want to support stable Flintstones tires (super stiff, like rock).

600hz or 1000hz should be enough to just do the external force thing.

Lumped LuGre is basically one of the bristle-like models, which means camber is easy if you do a bristle style sim. Just simulate at least two belt ring positions, which means at least two patch elements side by side in place of usual one. IOW, simulate N tires of 1/N width, glued together, per real tire. That's the simplest way. You can of course model a relationship between these rings too.

The trick is doing this smooth and fast, without discretization lumpiness at real-time speed, and at a high enough patch frequency to be bothering with it in the first place.

I cannot share my code at the moment because part of it is using stuff that currently on a problematic license. I've taken care to keep VD code cleanly separate. I load the proprietary stuff at runtime with my own dlopen.

[NaN]

Trying to fix our curbs(large camber) issues. I've hit a problem in tire force calculation.

Code:

velocity_xy force_xy
13.5487 -14.2452 1287.78 -1891.49
13.5692 -4.59397 1266.35 -3615.22
13.4786 -14.3669 1228.81 -1456.22
13.4969 -4.72126 1457.89 -2805.46
...
10.0058 22.2708 -13462 5331.47
10.0983 22.1852 -10306.9 3558.35
10.2038 22.0911 -5625.35 2331.57
10.3204 22.0024 3855.31 1394.94

Given a positive lateral velocity, we are getting positive lateral tire force sometimes. This means the wheel is accelerating in lateral direction. That doesn't make any sense to me. Any ideas?

[fudje]

I'm noticing that fairly often the suspension is not travelling far enough for the tyre displacement, especially since you changed the force vector to straight up. Could the lateral acceleration you're seeing be a result of the contact point of the tyre being on the wrong side of the track surfce?

[NaN]

Could the lateral acceleration you're seeing be a result of the contact point of the tyre being on the wrong side of the track surfce?

Bullet has a tendency to return incorrect normals especially at triangle edges. Something we have work around somehow. Negative normals/forces are ignored by the tire code, will return zero friction.

I'm noticing that fairly often the suspension is not travelling far enough for the tyre displacement,

Right now suspension travel is directly linked to road displacements(tire displacement == suspension displacement). I am working towards simplifying the simulation as the more complex stuff doesn't work very well with the explicit integration we've got. We are way too stiff.

[NaN]

Looks like the camber is causing problems. On a left turn with large positive camber on the outer(right) wheels. The car will be accelerated in lateral direction, or eventually flip opposite to body roll. There are no issues with forced zero camber.

[NaN]

Replacing vertical shift equation with Pacejka89 seems to fix the problem. No idea what is wrong with the original one, was not able to find it online.