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.
Replies
Hi
Yes it is with the 3DR GPS LEA 6H, if these issues are interfence based that may be a reason, as on a 200mm diagonal quad there isn't much scope for getting the gps away from the FC, its about 50mm above the FC.
Randy's wording you quoted is the wording I was referring to.
But, the way I assume it...an variance reading would work it would go up and down, but it just stays at 1 all the way though the files I looked at. Might be hard coded or something...hard to judge on a beta. I updated to it as VR updated the bootloader and that is the AC ver it came with.
And the 200 loiters ok so its not gps denied. my octaquad with the ublox 8 has reasonable EKF vel and pos noise numbers, I would guess they would be higher if the GPS was bad?
To all
apparently Randy gave his response 3 days ago related to EKF and AC 3.3
https://github.com/diydrones/ardupilot/issues/1972
thats interesting...the post at the bottom by Randy referes to it changing from 0-1 rather than 255, and my 200mm quad runnung a 3.3 beta is at 1...so maxed out again :)
In the case of an EKF, a value of 1 indicates that the state estimator believes that the GPS is giving "good" data. If your GPS data was very erratic, that value should fall to near zero. Occasionally missing a sample may not effect this "rating" in any meaningful way if the remaining readings are consistent with the rest of the data from other sensors.
This is an completely different than the old INAVerr.
Ah ok cool cheers, I am sticking with 3.2 for a bit until 3.3 is released proper for my VR ubrain on by octa quad running the ublox 8, but hopefully everyone will be getting 1 and hopefully the 255 issue is a red herring/false negative issue. or some sort of proper guidance to resolve if it is an issue comes out for people to fix.
Interesting that you don't see any more these INAVERR with this beta version 3.3 for VRBrain
Buf difficult to know if there are in this version changes for INAVERR reporting
Is they still report this error or not....
PS: last branch for Ardupilot code is 3.2.1 https://github.com/diydrones/ardupilot/tree/ArduCopter-3.2.1
An then af course the one in Master branch
Thanks for attching your log
Could you please attach this 3.2 Arducopter log using 3DR Ublox 6 GPS and INAVERR ramping up to 255 (which is the max value )?
Thanks
I just went through logs for my 200mm quad that also has a ubrain, but is running a verion of 3.3 (must be a beta :)) and the newer 5.2 bootloader, and I have just done a random check of 6 or so files and none show the issue with the old ublox 6. Not conclusive, but I will keep checking. Maybe its been sorted in 3.3.
attached is the log with the ublox 6 and yes it ended up at 255
www.rabbitstu.co.uk/SBQ/52.BIN
@Stuart Brookes
Thanks for posting infos,
Another guy Mlebret posted the same results on two of his multirotors,with 2 different VRBrain boards, and 2 GPS (VR and RTFQuad)
But as I mentionned to Randy , this INAVERR error reported in logs is also occuring with 3DR LEA 6H GPS
So even with 3DR GPS, logs are showing up to sevral hundred of times missed GPS updates !
I think this problem should be investigated and understood
But no news or updates from Randy or other devs...
No Worries,
based on what you just said I just cheked an older log from when I was using the 3DR ublox 6...and yes it had the issue too. Ramps up to 255 early in the log, Both on Firmware 3.2