Heading error at slow to stop speed. Roll filtering, and sway elimination.

[arwooldridge]

On stopping, the heading sticks at the last random value due to VTG. One advantage of dual antenna is to get correct heading on stop. I think the heading output should revert solely to RelPosNED values at dead slow to stop speeds and ignore VTG. Also maybe if antenna distance is extremely good say within 1-2cm maybe heading should not rely on VTG as much if at all. VTG is basically a derivative and can introduce unnecessary noise to the system. I am guessing VTG is just used to take out yaw due to crabbing? Roll is very severely filtered. One advantage of using roll is to correct instantaneous antenna sway due to roll when driving over ruts and bumps. This looks like noise, but it can be taken out by correcting to virtual antenna position rather than filtering, provided the roll is not first filtered. Again maybe if antenna distance is extremely good say within 1-2 cm ( should be so for dual f9p) use unfiltered roll and heading to get instantaneous virtual antenna position, then filter that position if absolutely necessary. I could play with the code a bit and test. Ideally a rapid roll ( due to bump) should give no lateral movement to the virtual antenna position. and heading should be true at stop. Another related question is if the IMU, if used, should it be integrated into the dual antenna system. If it was, and was fitted at the antenna this could help take out apparent noise due to lateral motion of the antenna during bumps. Just my thoughts.

[mtz8302]

the use of vtg heading was once added for a user having often fails of the RelPosNED. It brings more trouble than it solves, so I only use it in bad signal conditions. The roll is very sensitiv to bad Signal, or to rough terrain. So I use a Kalman Filter that reacts fast on large changes. For sending roll to AOG there is additionally a flir filter, to enable AOGs side hill draft gain. Please give a try on the actuall version and report again. My problem is, that I rarely drive with this tractor, so no possibilty to try

[arwooldridge]

Thanks for the feedback. I am only testing static at present, Hope to test on tractors once I see good data.
I found a bug in the struct NAV_RELPOSNED the res2 and res3 byte lengths should be four bytes not one. This was causing relPosHP's to be misaligned so giving random variations in precision data. I used int32_t (or long?) for res2 and res3 and int8_t for the relPosHP bytes ( stops serial.print from printing characters) I have not checked struct NAV_PVT properly yet but it may have a similar problem. A useful setup aid would be to measure actual Antenna distance averaged ( now its more accurate) over a few minutes instead of a tape measure to take into account antenna offsets, this can then be used to check more accurately the data quality based on length ratios. if the ratio is very good the filtering can be reduced dramatically I think. PS great project!

[arwooldridge]

I think reserved1 in struct NAV_PVT should be 5 bytes not 1, hence the comment in the code re magDec being out of sync. Could add an extra long reserved2 after u char reserved1 and change magDec and magAcc back to short and unsigned short

[arwooldridge]

Or better make reserved1 array of 5 char ie char reserved1[5] and change magDec , magAcc