Thanks for your description. I also saw vertical position changes and increasing vertical speed sometimes in phases, where the drone was sitting on the table in my office (with no GPS reception). I do not exactly remember the messages but I think it was something like “Error pos vert variance”.
@rmackay9:
Can you give me a hint, how the EKF “vert pos” is estimated and what could propably lead to these errors? GPS seems not to be responsible here - at least on my workshop table, where I have no GPS. As external magnetometer I used a LIS3MDL first, later an IST8310 but meanwhile “GPS for Yaw”.
I forgot to mentioned during that 5 minute hover I had 15-17 Satellites, ndop:0.6-0.8. GPS was really good. That burst of about 2m up was only for fraction of a second and I was be able to land in Loiter quickly. That also was my first attempt after FW update from 4.0.7
It is probably related to the larger value of EK3_ALT_M_NSE that has been set (4 instead of the usual 2), but even with that change we shouldn’t be seeing this. @Hacky if you do any more testing then please set LOG_DISARMED=1 and LOG_REPLAY=1. That will give us a “replay” log, which would really help in fixing this issue.
Meanwhile, I’ll discuss with @priseborough
The touchdown bit appears to be coincidental. I’ve submitted a PR https://github.com/ArduPilot/ardupilot/pull/17787 that will make the code more robust to a collapse of the vertical velocity state variance that was the trigger event. The root cause of the vertical velocity variance collapse is still unconfirmed, but one hypothesis is that it is related to fusion of the GPS yaw on the same frame as the GPs position and velocity data and with a small angular accuracy value.
@rmackay9, @tridge, @priseborough
Thanks for taking care of that issue. As you may have noticed, LOG_DISARMED was set to 0 during the flight and when I saw that strange behaviour on ground, I set it to 1 and this seemed to have an immediate effect (but with a certain gap between landing/disarmed and starting further recording).
Regarding the parameter EK3_ALT_M_NSE: You are right, I have set this to 4 because the drone was way too nervous in keeping the altitude at windy situations (1-2 bft ok but already getting nervous at 3 bft with some gusts - which still is not much). When I used EKF2 with ArduCopter 4.0.7, the value 4 was a good setting for EK2_ALT_M_NSE in my case (where 3 was the default) and the behaviour seemd OK also for with EK3_ALT_M_NSE = 4. Even if it were a bit lax now, I still see no reason why it should be behave like we have seen. IF EK3_ALT_M_NSE should be left at default (2), there would be no way left for me to get a better altitude stability.
Next time I will set LOG_DISARMED = 1 already from the beginning.
Regarding: LOG_REPLAY=1:
How much CPU performance will this eat? As you know, the current implementation with RTCM message traffic between GPS1 and GPS2 going through the flightcontroller (acting as a proxy for “GPS for yaw”), this also already consumes CPU performance. If the amount of logged data increases significantly during flight, I am also a bit anxious that the SD card can not cope with that (it is the card that was included with Cube Orange at delivery) and that I cause trouble only by logging…
very little. The RTCM issue is not about CPU btw, it is about DMA contention between the uarts carrying the RTCM data and the other peripherals. I am separately working on a method to fix that.
Your CPU load in the above log is around 30%, so about 70% of the time the CPU is completely idle. Your uarts are working hard however.
We’ve just merged this fix which we think will resolve the issue that started this thread. This will be included in Copter-4.1.0-beta5 which will be released within a week or so.
It is not the “jumpyness” that you mentioned (which of course could be calmed by PID tuning). It is really a strong dependency to small barometric pressure changes. With EK2_ALT_M_NSE = 4 I got better results, with EK2_ALT_M_NSE = 6 it alrady was too much dependent to GPS altitude variance (which may be ok, if you have “rtk fixed” status permanently).
But here we talk about EKF3 and I do not know, how much it differs from the EKF2 behaviour.
OK. Just one thing to remember is that the EKx_ALT_M_NSE essentially controls the balance between IMU and whatever the EK3_SRC1_POSZ has been set to. So by default it would control the balance between IMU and barometer. It would not help to control the balance between baro and GPS because the EKF will never fuse altitudes from both of these sensors at the same time.
“This is the RMS value of noise in the altitude measurement. Increasing it reduces the weighting of the baro measurement and will make the filter respond more slowly to baro measurement errors, but will make it more sensitive to GPS and accelerometer errors.”
So it clearly mentions also GPS and not only IMU accelerometer fusion. That was the reason, why I assumed, that also the GPS altitude is fused into the “canonical” altitude. And I am pretty sure, that I saw height changes that followed significantly more the GPS altitude variations, when I was using EK2_ALT_M_NSE = 6 - but still not as strong, as I saw it, when I tested EK2_ALT_SOURCE = 2 (primary source is GPS in that case).
With EKF3, you (still) have EK3_ALT_SOURCE and now also EK3_SRC1_POSZ - which also is quite confusing…