Another update. I have things looking better on the lawnmower. Still fighting the no speed and no heading situation with AOG. See the video for more information.
I added in a mass damper to help with vibrations on the IMU and I added in averaging for the roll and pitch values. They are averaged over 50 samples at 100hz giving an average over 0.5 seconds. This takes out all of the crazy spikes from the vibration.
Without knowing board firmware ect I would say you have a communication error somewhere, as you can see in the bottom left you lost message count is jumping by around 200 every couple seconds. This may be the issue behind heading/speed issues.
Firmware is Panda2 A_Teensy_v56.ino. This is modified for my IMU but I have not changed the code for anything other than IMU related stuff. I am connected via UDP.
When I was using the F9P direct via usb speed and heading worked fine. Using Panda it is not working.
I knew that speed and heading was working before when connected via USB to the F9P directly. I reconnected and looked. The speed and VTG was being sent to AOG via the GPS. This data is not transmitted in the panda code.
In the main .ino it is commented out to call the VTG_Handler
// Disabled VTG for now because speed is calculated by AOG
parser.addHandler("G-VTG", VTG_Handler);
I uncommented that code.
In the NMEA file I uncommented the following code.
void VTG_Handler()
{
// vtg heading
parser.getArg(0, vtgHeading);
// vtg Speed knots
parser.getArg(4, speedKnots);
//
// if (!isLastSentenceGGA)
// {
// if(useDual)
// {
// dualReadyGGA = true;
// }
// else
// {
// if (useBNO08x)
// {
// BuildNmea();
// }
// else if (!useBNO08x && !useCMPS) //To do maybe add No IMU option, may also be handy for IMU with dual
// {
// itoa(65535, imuHeading, 10); //65535 is max value to stop AgOpen using IMU in Panda
// BuildNmea();
// }
// else
// {
// gpsReadyTime = systick_millis_count;
// isTriggered = true;
// }
// }
// }
}
Now heading and speed work fine in AOG.
Why do the sketches say AOG calculates it. It apparently does not unless there is another setting somewhere.
Anyway with this all done the results look favorable. I am getting some issues when incorporating the IMU heading. Sometimes it just goes crazy. Otherwise it helps to stabilize the heading from the FIX. My setup on the mower has a roll cage that is not super stiff so it flexes around a little causing my heading to jump around. A mount to the cab of a tractor would be much better.
I can confirm AOG does calculate the heading from the fixes as it works for my wireless system which only sends GGA. If you donāt have a handler for VTG but your f9p continues to send it you run the risk of overrunning the buffer.(which would explain your lag) I would try to disable VTG message from f9p and re-comment the lines you just uncommented.
There is no data being transferred on VTG Heading just the speed is added by uncommenting these lines from the .inoās
Looking at the code in AOG. it looks like it uses āvtgSpeedā unless the value in āvtgSpeedā is greater or equal to āfloat.maxvalueā
I donāt see anywhere in AOG where āvtgSpeedā is set to be equal to āfloat.MaxValueā.
As per Patās comment when panda is used it is receiving a speed of 0. Since speed is 0 then heading is never calculated. as avgSpeed has to greater than 1.5kph for it to start calculating a heading.
Am I correct in what I am seeing here. So for Panda to work I have to have the VTG speed passed into the panda string by uncommenting the code above.
This is all pretty high level code overview by me at this point. I am sure someone with more intimate knowledge can advise further.
Had a read through the code for AGIO and the your Panda firmware, I think you are correct with passing the VTG speed to the panda string by uncommenting the VTG parser as well as the speedKnots but keep the heading and everything else in the function commented out. Hope this helps
I received a notification from Digikey today that the SparkFun 9DOF sensor stick is End of Life and discontinued.
I am going to finish working on this as I want to use these sensors in my installations, at least for now. Maybe there will be other boards that remain available that use the same LSM9DS1 sensor then it could be substituted in itās place.
More testing done. I have a good heading reading now. It still drifts but it is much slower drift and it is more consistent. Only problem is the heading is rotating the opposite way as it should.
Roll is good now also. Need to work on the timing for the Panda a little bit. I will grab some video of it working. There is a strange woggle in the correction. It starts correcting the opposite way and then is behind. Not sure why. I would like to see the roll angle on the easting chart so it could be compared also.
I guess I can look at the code and add that in.
Put the system on the mower and things worked pretty good. Vibrations did not seem to affect the system much. My non rigid roll structure that I added for the antenna mount causes more issue than the IMU at this point.
Put it in the 8220 tractor and things look very promising.
I will report back with some more video updates. Once I clean up the code from all the testing I can make it available if anyone else wants to try it.
What is the main way to contribute to the project code wise?
Has anyone worked on the WT901 IMU module? It has a little ARM processor doing sensor fusion and filtering from a MPU9250 IMU chip. There is software to configure it, perhaps to disable the magnetometer.
Some more testing results. I have the AHRS calculations in for the 9DOF sensor stick and I am getting some strange results on the roll. See the video below. I was able to purchase some BNO085ās thanks to the heads up posting of the guyās on the forum. I will use them at this point as I want to get my first autosteer and rate controllers up and running. Then I will come back to this sensor for more testing.