• 0 Vote(s) - 0 Average
• 1
• 2
• 3
• 4
• 5
elchtest mod :)
02-27-2010, 03:24 PM,
 NaN Posting Freak Posts: 2,024 Threads: 120 Joined: Jan 2010

Quote:as it needs a high update rate, although i didn't understand why exactly
Vdrift is using a steady-state tire friction model(Pacejka).

slip = 1 - v / r*w for v < r*w and slip = 1 - r*w / v else
dw / dt = inverse_inertia * torque

To accelerate/decellerate a car you have to apply torque to the wheels. The real world wheel inertia is about 1-2kgm2. Your wheel is going to get an angular velocity delta dw ~ inverse_inertia, torque, dt.

So slip is proportional to dt. And with slip values beyond 0.5 each time you accelerate/decellerate you can actually forget about the whole tire friction simulation. A way to fix this is to increase wheel rotational inertia(vdrift is using 10kgm2) and/or to increase your simulation rate(vdrift runs at 1000Hz).

Quote:cylindershape wheel contact calculation
Do you plan to simulate the wheels as a rigid body? If you can afford to run bullet at 600-1000Hz in you simulation I would propose to create the whole vehicle/suspension in blender/maya. Export it as .bullet and load it into your bullet world.

I could adapt wheel forces function to return tire force/wheel torque dependent on normal_force, wheel orientation and wheel angular velocity. You would apply them to your bullet car model. The only other problem is steering. But I think you could solve it easily using constraints.

This was my initial idea for vdrift. But I think we would have problems to simulate >10 "bullet" cars at 600Hz in real time on commodity hardware(still I haven't tried it ).
02-28-2010, 08:24 AM,
 sebiastisch Junior Member Posts: 30 Threads: 3 Joined: Feb 2010

The problem is, that the center of mass wheel speed v is actually updated one step after the torque was applied to the wheel?
Is that the reason for the discrepancy between the linear from rotational speed r*w and the linear speed v?

In other words: When accelerating, vdrift calculates the new rotational speed, uses that and the old linear velocity to calculate the slip and then uses this to calculate the new linear forces (and speeds). Thus the resulting forces depend on the timestep, although they shouldn't.
Doesn't raising the wheel inertia change the whole car behavior?
There is no way to calculate that in a closed formula?

Quote:Do you plan to simulate the wheels as a rigid body? If you can afford to run bullet at 600-1000Hz in you simulation I would propose to create the whole vehicle/suspension in blender/maya. Export it as .bullet and load it into your bullet world.

We could do this in our simulation, as the computers we are using here, are probably not comparable to the normal vdrift players equipment. But it sounds like a lot of work and I don't see the benefits, as in our research the higher abstraction level (decision making and A.I Stuff) is in the foreground it is a little over the top. Additionally, I think the susppension does not need so high framerates. Just like the chassis does not need as high framerates as the suspension. nevertheless the wheels are already in our bullet world (as dynamic objects without mass). but their state is completely managed by vdrift. what i can already do is check for collision with the world (this is no problem, even with the high update rates, as vdrift runs on something like 1/480s^-1 and bullet uses 1/60 at the moment).
Which means, at the moment the car moves/"rolls" 8 steps in a static bullet world, then the bullet update checks for chassis crashes and sets the bullet world forward. i will upload a video, if i find the time and if you are interested.

i guess i will just set the wheel contacts with the cylinder collision instead of the raycast. this should do the thing for us.

Just an off topic question: Are there different kinds of suspensions modeled in vdrift?

BTW: forget about the inheritance stuff, I was writing about in my last post. The btActionInterface does give enough access (although not very much). You can model the rigid bodys (wheels and chassis) in your special action interface.
02-28-2010, 01:46 PM,

sebiastisch Wrote:When accelerating, vdrift calculates the new rotational speed, uses that and the old linear velocity to calculate the slip and then uses this to calculate the new linear forces (and speeds). Thus the resulting forces depend on the timestep, although they shouldn't.
Doesn't raising the wheel inertia change the whole car behavior?
There is no way to calculate that in a closed formula?

Maybe I don't quite understand, but isn't what you're describing basically the shortcoming of numerical integration? I'm not aware of any way to analytically integrate the car's physics response, but that would be cool!

Quote:Additionally, I think the susppension does not need so high framerates. Just like the chassis does not need as high framerates as the suspension.

I agree, it's really just the tire/wheel sim that needs the smallest delta-time. There are a few racing sim engines that indeed use their highest framerates for the tire/wheel rotation only, and lower framerates for everything else.

Quote:what i can already do is check for collision with the world (this is no problem, even with the high update rates, as vdrift runs on something like 1/480s^-1 and bullet uses 1/60 at the moment).
Which means, at the moment the car moves/"rolls" 8 steps in a static bullet world, then the bullet update checks for chassis crashes and sets the bullet world forward.

That's actually similar to how the current system works, in a way. Even though the car's physics are updated at 1000 Hz, collisions with other vehicles are only checked and added as impulses at 100 Hz. Also, the raycast to the actual ground geometry (bezier and triangle mesh) is only run every 100 Hz -- a plane equation from the collision is stored, and then for the other 9 frames we do cheap ray/plane intersection tests.

Quote:Just an off topic question: Are there different kinds of suspensions modeled in vdrift?

The suspension is modeled as a fixed instant center (IC) that the wheel rotates around:
http://en.wikipedia.org/wiki/Suspension_...ant_center

This is a generic simplification of a suspension that can approximate various kinds of real suspensions (different suspension types have ICs at different locations). Real suspension systems however will have their IC change somewhat as the suspension goes through its range of motion.

Unfortunately, the suspension model VDrift uses (like with the tire model) isn't conceptually easy to think about and tune with respect to a real vehicle that you're trying to emulate. I was thinking it'd be nice to have a number of real life suspensions (and tires!) defined somewhere so in the .car file someone could just point to one and say "yes, that" or "yes, 70% that, 30% the other" without having to think about the IC points or pacejka coefficients.
02-28-2010, 01:56 PM,

Also, the wheel's camber is (if I remember correctly) the same through the suspension travel, which is another approximation -- a real suspension would change the camber of the wheel somewhat as it moved through its range.
02-28-2010, 02:04 PM,
 NaN Posting Freak Posts: 2,024 Threads: 120 Joined: Jan 2010

The discrepancy between rotational speed r*w and the linear speed v comes from the way tire friction is generated. Because of the elastic properties of the tire rubber it creates friction/traction dependent on tire slip. There is no traction if there is no difference between r*w and v. The above friction(slip) graph corresponds to experimentally measured real world tire data (on such tire test stations: http://www.calspan.com/transportation/tireTesting.php ).

The change of w depends on the timestep so the slip/friction.

Raising wheel rotational inertia changes car behavior(acceleration/deceleration). But it's like choosing the lesser evil.

Could you point me to the code section where new angular velocity us used with old linear velocity.
02-28-2010, 05:57 PM,
 NaN Posting Freak Posts: 2,024 Threads: 120 Joined: Jan 2010

Quote:There are a few racing sim engines that indeed use their highest framerates for the tire/wheel rotation only, and lower framerates for everything else.

I like this idea. This way we could model the car+suspension in bullet. The only thing that bugs me is the fact that tire slip depends on wheel velocity(chassis velocity). So we would have to assume it to be constant during the tire simulation cycle? I think this would be OK for heavy vehicles. But think of a F1 or motorcycle(high grip low weight). I wonder how they solve it.

What about running chassis+suspension at a slow rate. But to update chassis velocity(depending on tire forces) during tire simulation cycle(at a high rate). I am not sure if it's possible with btRigidBody though.
02-28-2010, 07:20 PM,
 sebiastisch Junior Member Posts: 30 Threads: 3 Joined: Feb 2010

Thanks again for the information.

The suspension approximation seems reasonable, although many nuances of suspension behavior are impossible to be simulated.
I'm thinking for example of a Weissach rear axle, where not only the deflection of the wheel influences the toe in and other parameters (sorry for the maybe wrong words, but I've learned that stuff in a different language...), as it is influenced by more than just kinematic constraints.
But even in terms of kinematic behavior this is not enough.
With a modern multi wishbone suspension (not sure on that name either) you can modify the axle behavior almost as you wish. What you need for that is a complex suspension model. And that does not make tuning the cars easier, because you need a lot of knowledge to get the parameters right..

The only real axis i can think of, which you can describe by one fixed IC is the swing axis (used in the old VW KÃ¤fer). And that axis had real bad behavior when cornering (the center of mass goes up) and the KÃ¤fer tended to fall over (makes me think of your elchtest mod . It is also very unsteady on non-flat roads, as the car reacts with negative camber when deflecting, which creates cornering force.

The problem with all the racing games is, that although they have different suspensions, the car behavior comes not very close to reality (at least I don't know a game, that does).

Quote:Could you point me to the code section where new angular velocity us used with old linear velocity.
I was just guessing, how it works (waiting for you to correct me, if it is wrong ).

Quote:What about running chassis+suspension at a slow rate. But to update chassis velocity(depending on tire forces) during tire simulation cycle(at a high rate). I am not sure if it's possible with btRigidBody though.
When using the btActionInterface, btRigidBody allows you to interfere the bullet physics pipeline once between two cycles. At that point you can f.e. add an impulse due to friction between the tires and the ground. this impulse can be calculated with a higher frequency when the updateAction callback is executed (at that point between two cycles). you are able to set any motion state (including the linear and angular velocities) you want, that is defined in your class inheriting from btActionInterface.
what could work is to calculate the friction and its effect on the wheel velocity with high frequency in your subclass and the applying the new wheel speed to the wheel motion state. suspension (modeled by constraints) would then handle the changes and calculate the influences on the chassis. therefore a timestep of 120Hz should be ok, because even a F1 chassis is pretty heavy (compared to the wheels).

One last thing in terms of frequency:
I think i remember from my lectures, that the natural oscillation frequency of an axis is about 15Hz and that the chassis frequency is about 1.5Hz. Misusing nyquist-shannon in a creative way, one could conclude, that you need 30 Hz for the suspension and 3 for the body. indeed this is encouraged by the frequency active/adaptive suspension systems have (which is 3Hz for slow and 30 Hz for fast systems. the latter being able to cope with suspension oscillation). So i guess 60Hz is ok for a suspension simulation.
03-03-2010, 10:10 AM,
 sebiastisch Junior Member Posts: 30 Threads: 3 Joined: Feb 2010

We were able to integrate a real collision test and set the contact properties. looks pretty good, but we still have a lot of problems with it:

1. Bullet gives several collision points+normals of the cylinder and the ground. currently i am averaging them all out. but using the normals doesn't work.
i am calculating a fake normal pointing from the hit point to the center of the wheel.

2. force feedback is totally messed. it always drags the wheel to the left and the values are extremely noncontinuous.

3. there is not much grip. although the wheels do not collide with the surface (i mean not dynamically in bullet), they seem get a lot of traction.

4. driving is totally different. i have to give you a video with this!

5. when letting the car fall down on the surface, there is hopping/jumping around. I am not sure whether that is caused by the suspension or the contact calculation.

So, another update for the update:
I can fix that force feedback issue and pretty everything but the hopping issue by doing a simple hack:
The contact normal is set to 0,0,1 and the collision point set to the center of the wheel.
There seems to be a problem with the setContactProperties, as the behavior reminded me to the behavior of the elchtest mod.
03-03-2010, 11:39 AM,

Regarding what you pass into SetWheelContactProperties(): even though bullet returns several contacts, you should only pass in the contact point that's closest to the center of the wheel. You want to set the contact normal equal to the normal of the ground at that point.
03-03-2010, 12:43 PM,
 sebiastisch Junior Member Posts: 30 Threads: 3 Joined: Feb 2010

I have tried that too, but it didn't change very much.
There hast some bugfixing to be done
03-03-2010, 11:29 PM,

Well, but, the data that you feed into the function from raycasts should be pretty similar (identical for a mostly flat surface, like most roads) to the data you feed into it from cylinder collision tests. Since it works correctly with the raycast data I think the problem may be with bullet or with the way you're sending it collision information.
03-04-2010, 05:08 AM,
 sebiastisch Junior Member Posts: 30 Threads: 3 Joined: Feb 2010

Well, you say it works "correctly" with the ray.
Let's say it works. I noticed, that the impact on the way the car drives and feels changes extremely with the point and the normal.

The reason for the cars rolling over very easy in the elchtest version is probably also because of that. When you do the raytest down the car vector and the car is already rolled a little (due to lateral acceleration and the suspensions deflecting) the collision point will move to the center line of the car. which means, the cars toe is artificially lowered and thus it will roll over very easy.

The tires are the only contact point the car has to the world. Therefore that point should be calculated thoroughly.
03-04-2010, 11:42 AM,

I agree. It just sounded like maybe the point and normal wasn't calculated thoroughly with the cylindrical collision testing, if you're getting much better behavior when you send a constant normal.
03-04-2010, 12:43 PM,
 sebiastisch Junior Member Posts: 30 Threads: 3 Joined: Feb 2010

In the meantime I probably tried every thinkable combination...
It works a little bit when just averaging all points, normals out and using a virtual collision depth, which is just the distance to the center of the wheel.
I have no idea, why the real depth doesn't work, as the values seem to be very similar.
The car always starts bouncing (getting higher every jump, which somehow contradicts my understanding of energy conservation ).
03-05-2010, 09:17 AM,
 NaN Posting Freak Posts: 2,024 Threads: 120 Joined: Jan 2010

@sebiastisch
I hacked btRigidBody into vdrift http://svn.vdrift.net/viewvc.cgi/branche...oot=VDrift

Raycasting works, cardynamics also. But collisions don't. My way to synchronize btRigidBody with cardynamics must be incorrect. I am quite a noob regarding bullet. Could you elaborate how you are doing it in your simulation. Are you using btMotionState?

PS: How are you implementing car inertia? As bullet assumes that the principal inertia axes coincide with body axes.

Forum Jump:

Users browsing this thread: 1 Guest(s)