Harry's GPS Suite Forum

I think there's a problem with calculating yaw rate. I calculated yaw rate by dividing the lateral acceleration converted to m/sec^2 by the velocity in m/sec and converted from radians to degrees. My plot looks only vaguely like the plot generated by HLT. The HLT plot looks to be shifted significantly compared to the course. HLT gets peak yaw rate not in the center of the corner but on the straight following the corner. I think you may be filtering too much and causing a phase shift.

Another obvious problem with the HLT yaw rate plot is the long stretch with only negative values of yaw rate. If I integrate my calculated yaw rate data to get heading, I find I have to add a constant to the lateral acceleration data to get close to the GPS heading. I assume that means the axis calibration is off. I'm going to try an angle shift around the z axis as well because I suspect I'm getting mixing of lateral and lineal acceleration as well as with gravity.

I have added that to my list. The shift on the time line is due to the (old) moving average I apply for smoothing. Maybe I can use the new smoothing capabilities introduced for lateral acceleration and GPS plots...

- Harry

Since you're not doing it in real time, I don't see why not. I believe that the cubic spline filter is acausal, i.e. it doesn't shift phase like a moving average can. The only filtering in my plot is whatever you use for the accelerometer readings and whatever the GPS uses for the velocity data. I have the accelerometer acquisition rate set to maximum. Correcting the axis calibration does improve the fit for the integrated yaw rate vs the GPS heading and the integrated lineal acceleration vs the GPS velocity. The static roll error appears to be ~5 degrees, pitch -0.8 degrees and yaw 3.5 degrees. The difference in the corrected accelerometer readings is small, but it makes a big difference when integrating to get velocity or heading angle. If I included vertical velocity and pitch because the course wasn't flat, it would probably be even better.

I've updated the calculated yaw rate plot with the yaw rate calculated from the uncorrected accelerometer data. It's a trivial calculation: lateral acceleration in m/sec2 divided by speed in m/sec times 180 degrees divided by pi radians. If the accelerometer and speed data are good, there is no need for any smoothing. This is far and away better than what you're doing now. There is no need to differentiate the heading data at all. If you want better accuracy, integrate the yaw rate and at each time step compare with the heading data. Feed back a fraction of the difference to the calculated yaw rate, step forward to the next reading and repeat. It's basically a proportional integral control algorithm.

Hi,

I do not disagree, but I have no room to go after this currently.

- Harry

Then I recommend that you eliminate the yaw rate chart until you have the time to fix it. Bad data is worse than no data.

I see the yaw rate plot is still over filtered in version 19, at least for autocross yaw rates of 40 degrees/second or more. It looks like the filter time constant is about 2 seconds when it needs to be less than 0.5 seconds.

Yes, still unchanged.

gplracerx wrote:I've updated the calculated yaw rate plot with the yaw rate calculated from the uncorrected accelerometer data. It's a trivial calculation: lateral acceleration in m/sec2 divided by speed in m/sec times 180 degrees divided by pi radians. If the accelerometer and speed data are good, there is no need for any smoothing. This is far and away better than what you're doing now. There is no need to differentiate the heading data at all. If you want better accuracy, integrate the yaw rate and at each time step compare with the heading data. Feed back a fraction of the difference to the calculated yaw rate, step forward to the next reading and repeat. It's basically a proportional integral control algorithm.

Hi,

I assume the formula is the one shown in http://www.vehicular.isy.liu.se/Publica ... 818_AW.pdf (Model 4, page 23)?

- Harry