Gaming Car simulation and Orbiter

[tblaxland]

BTW, I found something that could be an Orbiter bug: when I created a 1400kg vehicle, landed at KSC, with no forces acting on it (no explicit AddForce, no thrusters, wings etc.), and I set the friction coefficients to 0.0, then the vehicle accelerated with about 0.03 m/s^2. I guess this effect was never noticed before, because it tends to be hidden by using larger friction coefficients.

Did you have non-spherical gravity enabled, perchance?

 

[Quick_Nick]

The Earth's rotation might be a factor. Maybe the earth is moving underneath the frictionless DG.

 

[tblaxland]

The Earth's rotation might be a factor. Maybe the earth is moving underneath the frictionless DG.

But what would make it accelerate (ie, increase it kinetic energy)?

In addition to my earlier question, in what direction does it accelerate? If it is non-spherical gravity it should be easy enough to test. Beside turning off that option, on the equator the gravitational force should perpendicular to the local horizontal plane and you should have no acceleration. Elsewhere, non-spherical gravity should accelerate you towards the equator.

 

[ar81]

I made a first start for creating 'car.dll' for Orbiter.

I first wanted to model the car in 'landed' state, but it turns out that Orbiter tends to kill all rotations in this state.

So, now I made a car that 'hovers' on top of its suspension springs. It seems to work nicely, especially for Ar81's racing needs, but unfortunately the system tends to become unstable at large time accelerations, which is of course unacceptable for simulating crawler-like vehicles.

If you release the addon, it would be nice to add some advise to your manual. Driving cars at high speed is a matter of control, precision, concentration, not speed. Many accidents take place and many people die because people take their cars to speeds where they lose control under unsafe conditions.

A good racer knows how to respect danger, and he tries to make it as safe for himself and others too.

In the name of those who have died in car accidents, I might like to request that.

 

[cjp]

Did you have non-spherical gravity enabled, perchance?

I always have non-spherical gravity enabled. So that could be it.

I think in real life (e.g. on ice) you wouldn't have this acceleration, because flat surfaces like ice typically form themselves according to the local gravitational field.

Coriolis forces from the earth rotation shouldn't exist when you don't move w.r.t. the surface.

Wind doesn't exist yet in Orbiter.

 

[Hielor]

I think in real life (e.g. on ice) you wouldn't have this acceleration, because flat surfaces like ice typically form themselves according to the local gravitational field.

That, and no surface is entirely frictionless...

 

[ar81]

Air use to flow towards equator due to Earth rotation.
http://en.wikipedia.org/wiki/Coriolis_effect
Same forces might be acting on your vessel.

 

[Andy44]

With a perfect frictionless surface on a spherical Earth I would expect you to accelerate towards the equator as the planet rotates, nevermind the nonspherical option. Remember that the Cape is moving east at ~400m/s, but it's moving in a small circle, as opposed to a great circle (orbit). The Cape is constantly being accelerated to the north by the Earth's crust, so any frictionless object on the surface would tend to start sliding south, just like an ice cube on a spinning carousel.

Shouldn't be too hard to work out the math of what the Cape's acceleration is, and see if it's 0.03 m/s^2. Or just park a DG facing north with the brakes on and measure it with Acclerometer MFD or Surface MFD.

 

[tblaxland]

With a perfect frictionless surface on a spherical Earth I would expect you to accelerate towards the equator as the planet rotates, nevermind the nonspherical option. Remember that the Cape is moving east at ~400m/s, but it's moving in a small circle, as opposed to a great circle (orbit). The Cape is constantly being accelerated to the north by the Earth's crust, so any frictionless object on the surface would tend to start sliding south, just like an ice cube on a spinning carousel.

Shouldn't be too hard to work out the math of what the Cape's acceleration is, and see if it's 0.03 m/s^2.

You are right, of course. I did the math for latitude 28 deg and I get 1.919e-5 m/s^2. I also did the math for the non-spherical gravity and I get 0.013 m/s^2.

 

[cjp]

The first pre-release of Car.DLL is attached to this post.
Is this usable? If so, I'd like to have some artwork which I'm free to add to this add-on.

 

[liber]

The first pre-release of Car.DLL is attached to this post.
Is this usable? If so, I'd like to have some artwork which I'm free to add to this add-on.

MSVCRT.dll missing...Orbiter don't crash but there's no mesh and no control.

 

[cjp]

MSVCRT.dll missing...Orbiter don't crash but there's no mesh and no control.

Weird.. I used the same settings as in some other add-ons. I'll have a look at this. In the mean time, maybe you can try to find MSVCRT.dll somewhere. I used MSVC 6 for building this add-on.

For no mesh, please read the documentation. No control surprises me. Maybe related to the DLL issue.

 

[liber]

Weird.. I used the same settings as in some other add-ons. I'll have a look at this. In the mean time, maybe you can try to find MSVCRT.dll somewhere. I used MSVC 6 for building this add-on.

For no mesh, please read the documentation. No control surprises me. Maybe related to the DLL issue.

Sorry didn't see that there is no mesh...

 

[Tommy]

MSCVRT is the Microsoft Visual C runtime library, and it's a good idea to have it installed - many add-ons and apps require it. For use in Orbiter, placing a copy in the Orbiter root folder will suffice.

 

[liber]

MSVCRTD.dll with D missing not a MSVCRT.dll

Get it here if is mising to anyone: link

add to windows\system32

Now all working...no animation for wheels

,but nice add...

 

[mjessick]

Larger friction coefficients just make some problems worse. Stopping reasonably is (strangely) a difficult problem.

As the velocity of a wheel goes to zero, it usually overshoots zero to the other side a bit. This means the force instantly reverses. You end up with oscillations that need to be damped out or otherwise handled (e.g.: change the equations of motion to a set that has a fixed position for the wheel that should have stopped). The higher the friction coefficients, the higher the frequencies if you don't work this out. I like to call this problem "friction reversal."

Cars have 4 supports. This means they are "statically indeterminant." You would think that when stopped, you will have zero lateral and longitudinal forces on the tires and just normal forces. Practically, you will often get oscillating forces in the ground plane. Once you fix that, the normal forces can still end up different from what you would expect because (for example) you can get a forward force on the left rear tire and a backward force on the left front tire. All the forces and moments sum to zero in this situation (assuming the wheels are in line with each other) but you still have a lot of forces playing around and in a worst case the car can sit slumped at some odd angle on its springs.

Wheel modeling is a pain. The wheel model above has 5 planes of symetry, which is better than most. That means that you can show a higher speed for a particular graphics frame rate before the speed you can display reaches a maximum. Above that speed, the wheel will actually appear to slow down as the speed increases. This is the "aliasing" that you see in Hollywod Western themed movies when you see the stage coach wheels turning forward and backward seemingly randomly as it moves. The maximum displayable speed is suprisingly small. (Only a few miles per hour for 30 frames-per-second graphics.) One way around this annoyance is to change the wheel textures when over the critical speed to ones with a blur.

Lots of interesting modeling problems with cars. Aircraft are much easier, and spacecraft even more so.

 

[Andy44]

ots of interesting modeling problems with cars. Aircraft are much easier, and spacecraft even more so.

I'm assuming that's why reliable robotic spacecraft came first, followed by aircraft and then by ground vehicles, even though these vehicles were invented in reverse order?

 

[cjp]

I'm assuming that's why reliable robotic spacecraft came first, followed by aircraft and then by ground vehicles, even though these vehicles were invented in reverse order?

There is no clear relationship between how easy it is to make something in real life, and how easy it is to simulate. Of course, both become more difficult with increasing complexity, but in a simulation you can often leave out most of the complexity, and simulate only the most essential. On the other hand, many things that work "automatically" in real life, driven by laws of nature, have to be modeled explicitly when making a simulation.

In many simulations, the problem is that some phenomena have really high frequencies. If the simulation frame rate is lower than the natural frequency of the simulated system, then the result can be an 'exploding' simulation.

One example is a spring with a mass attached to it. Such a system has a tendency to oscillate with a certain frequency. When the spring is stretched, and you calculate its movement for a too large time step, you 'overshoot' the position it should have in reality. The position in the next time step is where the spring is extremely compressed. In the following time step, you end up on an even more stretched position, and so on.

Another example is a spacecraft/aircraft in atmospheric flight. Most of you know from experience: if you set time acceleration too high, your position, velocity and/or angular velocity will 'explode'. This problem does not appear in unpowered interplanetary flight, because that system doesn't have very high frequencies.

A car, on the other hand, has even higher frequencies than a spacecraft/aircraft in atmospheric flight. In the 'suspension mode' of my model, the car is actually 'hovering' on its suspension system (so it is not landed). Simulating the 'floating' of the car body on top of the suspension system could be done at 1x acceleration, but (at 30FPS) it already failed at 10x acceleration. To fix that, I disabled simulating the suspension system at high time steps. For the interaction between the rotations of the wheels and the forward motion of the car I used a different trick: I let that part of the simulation run at a much higher frame rate than the rest of Orbiter. This because otherwise it failed even at 1x acceleration.

I already noticed in Ultimate Stunts that this part of the simulation needs at least 400 Hz, while e.g. the graphics usually works at typically 60 Hz at most. 60Hz is sufficient for aerodynamic flight, but not for cars.

So, from a simulation point of view, the order 'robotic spacecraft, aircraft, ground vehicle' absolutely makes sense. Besides that, there also is a coolness factor involved, of course.

 

[ar81]

So the next step in Orbiter evolution: Orbiter racing...?

 

[Andy44]

In many simulations, the problem is that some phenomena have really high frequencies. If the simulation frame rate is lower than the natural frequency of the simulated system, then the result can be an 'exploding' simulation.

I believe this is the "Nyquist Frequency".