Craig's post here is excellent, and right on the money!
Map errors are not caused by speed, though good speed readings will help
eliminate a class of map errors. We start out tutorials on map
adjustments with this fact. Getting the end speed of the run right will
in the vast majority of cases give you a credible map. Not perfect, but
useful.
And that's the point. We aren't trying to map a scale drawing of every
inch of your drive. What we are trying to do is to help you relate what
the software is telling you to what you can do behind the wheel. It's
hard to wrap your brain around what you see in strip charts. Maps make
it easier to learn. Color coding maps, and we have dozens of ways to do
that, provide even more tools. Some of them will "click" for you, and
some of them won't.
In another post Dennis talks about how he determined he could go 1.5
seconds faster in one section by sketching out a map on paper that he
believed represented that part of the course, and which the lateral and
longitudinal traces backed up. We think the software should do that for
you.
The idea isn't to draw a perfect map with no assistance required. That
would be great, mind you, and I've love to have a product that would do
that. I know of a system built by real serious folks that used three
accelerometers and three yaw rate sensors which was accurate to this
level. (About 1 meter after 5 miles of travel I'm told.) That's really
cool stuff! But it's not gonna happen from a two pole accelerometer.
It's not even gonna happen with three poles, and a single yaw rate
sensor. It'll take the whole enchilada. At current, that would require
a system retailing in the area of about $3000 bare bones minimum...and
the software is pretty darned exciting, too!
The errors in maps come primarily from slip angle. Picture this. You
are driving your car (it's probably a CP car for reasons you'll see in a
minute) in a straight line. You are not speeding up, not turning, and
you travel this way for 10 seconds, when suddenly, for no reason at all,
the car rotates 90 degrees. The car slides to a stop traveling
perfectly sideways. It takes 3 seconds to come to a rest. The
accelerometers faithfully record, for arguments sake, 10 seconds of no
lateral and no longitudinal g's, followed by 3 seconds of 1 g left turn
accleration. The map shows 10 seconds of straight travel, followed by a
nice 1 g' left hand turn. Depending on the speed we started this could
be a 90 degree left, or it could be more or less. But the speed isn't
changed, and at the end of the slide, when the car is actually stopped,
the software still shows you motoring merrily along at the original
speed.
Now that illustrates a rather extreme example, but the fact is that all
turns include a certain amount of slip angle. And the cumulative errors
from slip angle have to be adjusted if you want perfection. But for
most cases, we don't need perfection. We just need a map that's good
enough to allow us to wrap our brains around the course and figure out
how to improve.
We believe GEEZ does that better than simple strip charts. For
instance, going back to Dennis' strip charts and his hand drawn map.
Dennis concluded that he could have shaved 1.5 seconds through better
braking entering a single turn, but he misses a simple point. And that
has caused him to mis-read how to execute that turn better. GEEZ would
have provided a better way to see that point, and he would have had a
better chance of not missng it.
The point? The car won't turn and brake at the same time at peak g's.
Either Dennis is about to draw a classic "cross" friction circle, (as I
described in NAP a couple of issues ago), or he is going to find his
plan very hard to execute. GEEZ would have given him a much better way
to view the car's performance envelope, and a better chance it actually
executing a plan that would result in faster times.
And that's the point, isn't it?
--Byron
Craig Blome wrote:
>
> Date: Thu, 5 Aug 1999 15:25:07 -0400 (EDT)
> From: "Mark J. Andy" <marka@telerama.com>Subject: Re:
> Software vs. Hardware
>
> Mark Andy writes:
>
> >Have you ever looked at two runs side by side using
> Geez? That course map isn't accurate at all. Don't
> get me wrong, it provides a handy reference to help
> you locate areas of the course, but using it
> to compare lines or anything that requires much
> accuracy is a waste of time. This isn't Byron's fault
> (I assume), its that the accelerometers have error
> like any other measuring device.
>
> #define DataAcquisitionGeek
> {
> Not quite. Modern 'chip' accelerometers are typically
> accurate to within hundredths of a g. The inaccuracy
> probably stems from the method used to compute the
> course position. The accurate way to plot course
> position would be to use an inertial navigation
> system, like aircraft use. That requires sensors for
> linear acceleration (which GEEZ, Edelbrock, etc. all
> have) and for rotational acceleration (which none of
> them have). Linear accelerometers are getting dirt
> cheap because every airbag module in the world uses
> one. Rotational sensors are *very* expensive,
> especially the ones that can sense enough degrees per
> second to keep up with a sharp turn or spin. (Lab
> exercise: Go out and spin your car and see if GEEZ
> can correct for it on the course map! :) I don't
> doubt Byron has come up with some clever
> approximations, but getting a true position plot with
> only two accelerometers ain't possible.
>
> In addition, course position and speed are calculated
> from the acceleration data by mathematical
> integration. (I almost said "derived" by integration,
> silly me...) Errors in the acceleration data will
> accumulate in the speed and position calculation.
> That would tend to make the numbers less accurate
> towards the end of the run. Might not matter in a 60
> second autocross, but I bet you'd start to notice
> after 20 minutes of track time.
> }
>
> > I wonder how much more accurate those maps would
> be if Byron had an independent measure of vehicle
> speed like the Edlebrock system apparenntly supplies?
>
> The speed data would obviously be improved
> (theoretically at least) but I doubt position would be
> affected, unless you could somehow use it to correct
> for the cumulative error in acceleration.
>
> I guess the point of my rambling is, it's silly to
> argue about which system is perfect; *none* of them
> are, because perfect costs too much. Try as many as
> you can and use the one that best helps you to go
> faster. YMMV...
>
> Cheers,
> Craig Blome
|