Should I expect a crash at some point?
Nervously I took the Spy 750 Y6 up for the first time in over 3 weeks (had a warm spell of 25F today).
In stab it flies great, then switching to poshold it seemed fine, but did the twitchy thing again for a few seconds here and there, then seemed to smooth out (subjective). I brought it down and hovered nearby where it stayed rock steady for a minute or so and landed.
So, what does it mean when INAVerr goes to 255 and stays there? From what I understand it is the FC not receiving data from the GPS properly. Apparently this copter has done it from day one since transplanting the PIxhawk and running on AC3.2 and 3.2.1, with the 3DR GPS and the current CSGShop Neo-M8N. These errors did not exist on the Y6B with 3.1.5 and the 3DR GPS.
Any help is appreciated.
I am getting similar behavior, which i posted about here:
I've been flying with a 3dr Pixhawk with 3dr GPS for a while without any INAVerrors and yesterad I made two flights with my newly built F450, on this one I have a M8N gps FrSky X8R receiver and during my two first flights yesterday I didn't have any INAVerrors.
My maden flight
This error is also reported with 3DR ublox LEA 6H
some users have also seen with it INAVERR going to it max value of 255
Normal you don't know what INAVERR is as it is not documented anywhere
Randy , aswered that
The Inav errors mean The Inav errors mean that inertial nav has not received a GPS update within 0.3 seconds
Three discussions are discussing about this error reported in Performance Monitoring
occuring with 3DR GPS and M8N
giving details, logs, description of errors
Thorsten in one of them, who did use GPS's for Geomapping described two problems he observed :
-timing jitter (missing samples)
- clock drift or communication latency between the GPS module and the Pixhawk.
But no reactions for any Dev ...I don't know why :(
If it is a false problem please tell us !
Well, this might explain why the error climbs linearly but if this a not a problem then why log it as an error and if this error has such predictable characteristics then it should be reasonably easy for the devs to mitigate this by appropriate changes in the code....
This information is quite valuable, for instance, if the GPS dies, this counter will suddenly skyrocket, or if the GPS UART connection is flakey, you may get sudden intermittent increases, or if you lose lock at high attitude you could use INAVerr to confirm this. I think the first thing to do is to play with the M8N by itself, log the output and check the timestamps. Then, play with the configuration using the ublox tools to see if its a config issue. Then, if it seems like its just a quirk of the M8N, you could look at ignoring the consistent missed measurements in the code, but in doing so, you would risk detecting 'real' missed measurements.
I certainly wouldn't be disregarding the M8N though, csgshop have made a great product, I often get 15+ satellites during flight.
" if these issues are interfence based that may be a reason"
interferences / EMI flag was raised by 3DR about the M8N
that 3DR didn't want to use M8N because of that ....
INAVERR is also reporterd with LEA 6 3DR GPS
Today, nobody prooved that INAVERR are caused by interferences ...
"Might be hard coded or something...hard to judge on a beta."
Yes, I agree
We will need to get a released version of this new "variance" reporting
We will need also explanations about their meaning and how to analyze this (these ?) numbers...
Hoping we can still know if GPS updates are missed or not in the 200ms loop
Yes, as you say very interesting :-)
Was it using 3DR GPS LEA 6H ?
I read the answer of Tandy in Ticket 172
This ticket was asking to go to from a 8 bits to 16 bits counter (ie max value 255 to 65535 for INAVERR)
Answer from Randy
"This is a bit unlikely to get done (at least as stated) because we're moving to the EKF for AC3.3 and errors are reported very differently. Instead of a simple INAV error counter there's extensive (but perhaps not yet well understood by the community) reporting on "variances" which are a 0.0 ~ 1.0 representation of how good the EKF thinks it's various attitude and position estimates are."
Two question I have:
1)INAVERR was indicating clearly "Missed Gps updates"
Now this "Variances" will vary from 0 to 1 , and characterize EKF results about attitude and position estimates
Today we can say :" we have a high occurance a missed GPS updates " impacting EKF results
Tomorrow with 3.3 code: will it be possible to know that the position estimate max variance of 1 will be caused " by missed GPS updates" ...?
2) And more important
Why the missed GPS updates occuring with 3DR GPS ie INAVERR problem has not been investigated in a proper way
Is it caused by GPS or FC or neither?
Has somebody looked at NMEA messages on the UART bus between GPS and Pixhawk to see if this NMEA messages are missing, or bad, or altered ?