Problem Setting Friction Coefficients & Brake Issues and Suggestions

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
4,327
Reaction score
3,248
Points
138
Location
Massachusetts
I'm not sure what the development status of Orbiter is at the moment, but I wanted to bring some issues with the current surface friction models and the effect on braking to light, things with which many add-on developers seem to struggle, and maybe kick off a discussion on how it might be improved. I don't have all the answers but I do have some suggestions.

Surface Friction

The friction force F exerted by the contact points is equal to mu * F_n, where mu is the friction coefficient and F_n is the total normal force. mu is set for longitudinal and lateral frictional forces using SetSurfaceFrictionCoeff(mu_long, mu_lat).

There are several problems with this particular model, especially in the context of trying to model sensible behavior of wheels and brakes (as there isn't another mechanism to try to implement wheel and brake physics in Orbiter that I am aware of).

1. The friction coefficients apparently are dynamic friction coefficients, which define the friction force on an object that is sliding relative to another surface. This means that any thrust or other force, or even having the vessel on a side of a hill with a gravity acceleration vector parallel to it (as is now possible with the new terrain model) the vessel will begin to slide and accelerate. Any attempt to try to mimic holding brakes while doing engine run-ups before take-off can't be implemented.

What is needed is the ability to provide a second static friction coefficient mu_static to the model, where mu_static * F_n defines the minimum force required to overcome friction such that the object just begins to slide. Once the vessel starts to slide, then the dynamic friction coefficient goes into effect.

This would likely require Set SetSurfaceFrictionCoeff(mu_long, mu_lat) to be modified to take 4 arguments: mu_static_longitudinal, mu_dynamic_longitudinal, mu_static_lateral, mu_dynamic_lateral. Additionally, the coding logic to implement it would need to look like (in each direction):

Code:
F_static = mu_static * F_n; //minimum force required for a force acting on the object parallel to the local surface to start moving the vessel.


if (sum_of_forces_parallel to surface_on_vessel < F_static)

         vessel doesn't move along surface

else

         friction = mu_dynamic * F_n;

         make friction_vector act opposite in direction of vector sum of applied parallel forces

Implementing Wheels and Brakes

2. If the above changes to the friction coefficient definitions were made, wheels and brakes could me modeled a bit more realistically. Right now, wheels and brakes are rather ad-hoc and the current braking model seems to be hamstrung by the surface friction coefficient definitions.

The maximum braking force seems to be limited to mu_dynamic * F_n, regardless of the argument of SetMaxWheelbrakeForce(). In order to mimic a freely rotating wheel, it is conventionally done by setting the longitudinal friction coefficient to a small number (to mimic free rolling) and setting the lateral coefficient to a high value (to prevent lateral skid), maybe like this:

Code:
SetSurfaceFrictionCoeff(0.01, 1.0);

This is fine until you want to apply the brakes. Unfortunately, due to the low longitudinal coefficient, the braking force is miniscule. The only fix to this is to temporarily set the longitudinal coefficient to a high value before apply the brakes. Also, if you want to enable differential brake steering, you need to lower the lateral coefficient to allow left/right motion of the wheel, something like this:

Code:
SetSurfaceFrictionCoeff(1.0, 0.01);

This sort of works, but getting realistic turning behavior is more artistic than physical.

Fundamentally, I think taking the old 3-point contact model (meant to implement landing contact) and incorporating it into a N-vertex collision model where the first three contact points get vaguely special handling as landing contact points really is combining two different concepts that need to be kept separate. Having a vertex cloud defining the contact forces of the vessel hull against the surface should be one thing, and landing contacts need to be a separate thing to enable dedicated wheel and brake models, as well as retraction. Retracted landing gear should essentially disappear from the contact model.

Thoughts?
 
Last edited:
Top