Some context, I’m flying indoor with a “GPS” I’m working on providing the same interface as a classic ublox.
I’ve no problem with my 2D position, but my altitude drift after 30s of flight.
I’ve included a rangefinder in the drone to compare my GPS altitude & the rangefinder’s one, and considering their relative position offset, my GPS’ data seems ok.
screenshoot on the test from 500s to 550s the drift is visible, but the correction never happen.
I’m now convinced that my ek2 parameters are bad, and realize that I’m obviously missing a important point in my settings, but I can’t quite figure it out.
Looking at the data, your baro is rock solid but the GPS data shows your alt all over the place.
It seems that your “fake gps” is not populating the velocities… Check GPS.VZ, they’re always zero. That’s a critical feedback that is confusing it because you’re feeding it other valid GPS data.
Looking at the ekf data, your have zero velocity innovations and small/good position innovations. Check:
NKF3.IVN/IVE/IVD (innovation for Velocity North East Down)
NKF3.IPN/IPE/IPD (innovation for Position North East Down)
Well as GPS isn’t used for 3D velocity (yet) VZ being empty is “normal”.
Second point, altitude from GPS isn’t all over the place, variations you sees are in cm, they do still contains errors but if you compare datas to rangefinder they are actually similars, bar is outputing altitude over the ceiling of the room. Can you detail on that, I’m interested on where datas are crumbling.
I did find the problem, digging in the data with matlabs, I’ve ellapsed time between gps data that are greater than the supposed frequency.
Digged that lead, checked my timers, added log on my soft, and had no issue, finaly plugged output of the GPS to an arduino to read datas, and frames are missing, the FTDI usb-serial seems to have a problem.
