Hi Iain,
Welcome to the Geez List. I'm surprised there hasn't been many responses to
your questions, but the traffic has been pretty slow on this list recently.
Byron pops in every now and then to help with the really difficult stuff.
Regarding how Geez works on low traction surfaces, it has been my experience
that the main effect is it looses accuracy on the speed calculations. This
affects how the course map is drawn in the map window. Other then that, it
has little effect.
Here's why the speed calculation is affected. In order to figure out the
speed, the program assumes you start at zero miles per hour. Then it
calculates the change in velocity for the next interval in time (0.1 sec for
the Palm program, 0.05 for laptops) by using dV = dA/dT. So adding the
amount you accelerated in that last 0.1 sec to the previous velocity gives
you the current speed. It steps through each data point doing this
calculation for the entire run.
Say you start at zero mph and accelerate to 30 mph into a nice flat constant
radius turn that opens up to a straight, and take it with a car that handles
neutral. The plot should show positive G's in acceleration up to the corner
entry, where they fall to zero (constant speed through the turn) and the
lateral G's go up to the maximum for the turn (say 1.1 G's) until you get to
the end where they fall back to zero and the acceleration G's go positive
again until you have to slow for the next course event.
I'm going to also put a coordinate system on the car for referance. The X
axis is side to side or lateral, and the Y axis is aligned with the
centerline of the car or longitudinal.
During the cornering phase, the acceleration vector is aligned with the X
axis and there should be no Y component - in this neutral handling car.
Now, add a big'ol honkin' rear sway bar to that car, or maybe a ground
pounding V8 so you can drift through the turn with oversteer. During the
constant speed cornering part of the course, the car coordinate system is
not aligned with the 'course' coordinate system as it was with the neutral
car. There is a Y component in the acceleration vector and the X component
is not as large as it was previously. The magnitude of the vector is the
same, it's just rotated a bit in the Y direction.
Even though the turn was taken at constant speed, since there was
acceleration in the Y direction, the program *thinks* that you accelerated
all the way through the turn, so the exit speed calculated is much higher
then it really was. The rest of the course will have this error in the speed
calculations, and it shows up in the course map as well. The course
following that turn will show up much straighter then it actually is.
Yesterday, we had a course with a turn at the beginning that was just as I
described. It was a relatively loose surface, and the constant radius turn
went over a hill slightly, so it set up a wonderful drift as I crested the
hill. I could keep the rear of the car in check by just countersteering a
bit and giving a bit more throttle (ESP FWD turbo Talon). The course maps
were just horrible. I got one somewhat close to reality by adjusting the
finish G's by -.07, but everything before that turn looked wrong.
The best way I can think of to correct this would be to use a yaw rate
sensor, so the G-Cube could tell the rate of the turn and figure out that
you were oversteering through that sequence. I'm sure that would make the
price of the G-Cube more then most of us are willing to pay.
Hope this helps, and sorry I didn't address the questions about the friction
circle. Maybe in another note...
-Brian Meyer
|