I updated my Matek405 with 4.0.4RC1 the other day. During autotuning I got GPS glitch error and I had to force it back to the field. Tonight I tried again and after a few minutes flying I got EKF variance error and after that GPS glitch error that ended in failsafe landing. In the log it seems like the GPS is making big jumps, could it be the fc fw or is it more likely the GPS or its wires?
Is this something that might be fixed in 4.0.4RC2 or is it more likely a hardware issue on my side?
Link to tonights flight log:
Just realized that the fc log gives a little different result compared to that from QGroundControl
We can look at the times on the messages from the GPS to see if it’s not regularly sending data. From the logs it looks like the UBlox GPS is updating at 10hz actually which is odd. Normally it’s 5hz and many GPSs cannot actually keep up with a 10hz update rate especially if many constellations have been enabled.
Normally AP configured the GPS and will trigger a pre-arm check if it’s unable to configure the GPS…
Ok, I will check my configuration and set it to auto config. I think I read somewhere someone having issue with the gps data getting out of sync with the other sensors and by that messing up the calculations.
If this isn’t anything someone else seen it’s probably something on my end. What would happen if the communication between the gps and fc get interrupted?
Looking at the bin log the gps data seems to be accurate of how it moved, looking at he log from QGroundControl on the other hand seems to have position values that is incorrect. Could it be any of the other sensors that doesn’t work correct? Like the compass.
I guess the bin log is the raw gps position, is it the same that I see in QGroundControl or is that the fused version of position?
Yes, another sensor could be the issue, the most likely candidate are the accelerometers and it could be high vibration. The vibration levels in the logs though are mostly under 30m/s/s although they are a bit higher than average for the X (forward-back) and Y (left-right) axis.
There’s normally a POS message that shows the EKF’s position estimate and then a GPS message showing the raw GPS sensor’s reported position. POSis missing in this log as is the very useful CTUN (for viewing altitude hold performance) so it might be good to turn these back on.
Thanks for the feedback
What is a reasonable level of vibration for x and y?
This is a quad made of plywood with 10” props.
I found out recently that loose cables, especially battery connector, was giving a lot of vibrations.
I will figure out how to turn on more log info
Short term increases to 30m/s/s are ok but the average is best down around 15m/s/s (or lower of course). I’m really not sure it’s vibration though, it could also be the GPS update rate of 10hz. In general a faster update rate is better but if the GPS can’t actually do it (which most cannot) then it’s counter productive.
Have now lowered GPS rate to 5hz and added more data to the log. I’m also suspicious on the compass so I will do a “learn in flight” calibration as a first step.
Heading out testing
New logs from todays testflight, very windy and the drone have issues in Loiter mode, ending in increasing toilet bowling. In stabilized and alt hold it works pretty good
Ok, the learn-in-flight is definitely not a good choice for multicopters. It’s best to stick with the onboard calibration. I’ll have a peek at the logs now but toilet bowling is normally a compass issue…
Hi again, did another try of auto calibration tonight.
Apart from missing the procedure to save after it all was done I catched another strange GPS glitch error.
At time 22:49 you can see that GPS position is moving away from POS for a short period, what can have triggered that? The GPS position seems to be the correct one.
At the same time altitude seems to have changed, looking at the barometer. I was doing autotune in alt hold but had to adjust height once, might have been at this point, can also see in the message log that I was doing manual adjustment.
Any help to what to look at would be very much appreciated
Thanks!
Have investigated some more and my conclusion is that this happens when GPS status becomes 4, help from SBAS.
Does SBAS interfere with the position calculations?
Hi Javier,
Thanks for you advice, I will give that a try tomorrow.
I was running 4.0.4 dev (which I think I read is more like 4.1) for avail without issues but when 4.0.4 rc1 and rc2 came out I changed to them as I thought it would be better. But have had a lot of strange behavior with these. Latest tonight where I have vibration that peaks at 20 and average around 10 or lower and still get GPS glitch and vibration compensation ON. Thought my FC sensors are getting sick…
Have you tried to turn SBAS off?
No other sensors. It’s Beitian-880 GPS with compass.
What I have is OpenHD system running on 2.4GHz, raspberry pi with camera v2.
I have tried to shield camera cable, rpi and the WiFi unit and now get 5-6 sattelites even indoor.
What I think is strange is that in the log gps position look good but the gps speed and heading sometimes looks strange. I wonder if the system uses gps speed to estimate position.
In the last log it happens during auto tune.
Comparing gps latitude and the fc pos estimation you can see how they drift apart. The correct one is the gps.
Didn’t get time to test today, I was looking for V3.7 But couldn’t find it for Mastek 405 ctr. Do you think 3.6.9 I good enough?
Yes Patrick, give it a try. It says 3.6.9 but this will actually take you to 3.6.7. this is what actually meant. In my years of experience I have strangled with situation I could not find a proper explanation. One of those led me to take this way out and worked.
The ArduPilot FW is capable of doing parameter upgrade (when you update the Firmware the parameters get upgraded automatically as well).
But it does not do parameter downgrade at all. If you downgrade the FW you should load a parameter file that was saved with that particular FW version.
For example
Upgrading from 3.6.x -> 4.0.x … no extra user action required.
Downgrading From 4.0.x -> 3.6.x … user needs to (after the downgrade) manually load a parameter file that was saved using a 3.6.x version.
