Harry's GPS Suite Forum

Yes. As they pointed out, slip angle is ignored so this won't work for drifting.

I've added the adjustment from radians/sec to degrees/sec (180/π). You might want to see how this is affected by the accelerometer sampling rate, i.e. the lateral acceleration filter time constant. And, of course, lateral g's have to be multiplied by 9.81 to get m/sec^2. This also depends on the device being oriented or the accelerometer being calibrated correctly so that lateral g's aren't mixed with lineal. Which also means that you could adjust the yaw calibration by comparing integrated yaw rate to measured heading. But a few degrees off isn't going to make much difference. Conversely, if the accelerometer is correctly calibrated for the vehicle frame of reference, you could, in principle, calculate the slip angle.

Or, you could add driving in a circle or figure 8 to the accelerometer calibration routine. I haven't tried that to see if parking lot speeds would give you sufficient precision.

From what I see, most users switched to automatic presets instead of calibrating their device individually. I will check the results from the model 4 formula. I assume some smoothing will be required for higher update rates. But tools to do this are available now.

Harry

Of course if you used the gyro data from the phone, you would have yaw rate directly. You already know the angle of the gravity vector with respect to the y axis or x axis in landscape. You could use that angle to transform the z and y or z and x rotation rates and you would have yaw rate directly without worrying about it blowing up at zero velocity.

I did some experiments with yaw calculation and the results from (measured) acceleration based yaw rate is indeed a lot smoother than the one deriving it from direction changes (click the picture, this should give you a iPad Pro resolution):



Acceleration based yaw rate is dotted, the old one is solid. In the snapshot shown averaging has been disabled for both.
Data shown is a recording sampled at 4 Hz.

- Harry

That looks like it doesn't need further smoothing.

Well - it is smoothed already during acceleration smoothing. But yes, I do not see further smoothing is necessary.
When using calculated acceleration, results are exactly like the former data.

- Harry

The acceleration smoothing was what I thought might be a problem. Was that data acquired with accelerometer update at 30Hz? If so, that looks like is isn't causing a reduction in peak yaw rate and peak shift for race track data. I would still want to use the maximum rate for autocross. The yaw rates are a lot higher, up to 60degrees/second,or so.

4 Hz GPS and 30 Hz acceleration

I am digging out the venerable thread after a splendind morning sliding around on an icy AX track this morning.

If there is a lot of drifting, handbrake U-turns involved, should I use GPS-based acceleration data to compute the yaw rate? I am using a 20hz GPS with a consistent 0.77 HDOP (3m accuracy?). The speeds involved are 15-80 km/h, so tick-to-tick distance difference is about 0.5m.

It looks that without some ultra strong filtering the acceleration chart is way too jagged. Does it still make sense if I filter high frequency GPS-based acceleration data very strongly?

Mateusz wrote:I am digging out the venerable thread after a splendind morning sliding around on an icy AX track this morning.

If there is a lot of drifting, handbrake U-turns involved, should I use GPS-based acceleration data to compute the yaw rate? I am using a 20hz GPS with a consistent 0.77 HDOP (3m accuracy?). The speeds involved are 15-80 km/h, so tick-to-tick distance difference is about 0.5m.

It looks that without some ultra strong filtering the acceleration chart is way too jagged. Does it still make sense if I filter high frequency GPS-based acceleration data very strongly?

What is your accelerometer acquisition frequency? If it's the default 30Hz, that's way too slow for a 20Hz GPS. IMO, even with a 10Hz GPS, 30Hz is too slow for accurate acceleration measurement for autocross because of the distortion caused by the internal filtering algorithm. Filtering causes distortion, more with some filter types than with others. HLT uses exponentially weighted moving average filtering for acceleration data. That means that the lower the acquisition frequency, the stronger the filtering. EWMA filtering introduces a phase shift in the data. For autocross, the difference between 30Hz and 90Hz is easily visible. The peaks are lower and shifted in time.

In my experience, calculated acceleration from GPS data is always noisier than measured data. That's because you have to differentiate position vs time data twice to get acceleration. Differentiation multiplies any noise in the original signal.