Hi,
I am using master v1.6.0, and went for couple of flights with my F550 hexacopter frame. I did around 6 flights. Five of them went fine in alt hold and poshold modes. However, in the last one, I faced the issue of not being able to bring the copter down in altitude hold mode. I was pulling the throttle all the way down, but the copter would respond to that as it should. It was mainly staying hold and drifting up slowly. I was not using any range sensors. Only baro and gps for altitude estimation.
This issue has been around for some time in similar scenarios. I also faced this, some time ago, while using liar light ware sensor. Actually it was worse, as the copter would shoot up in the sky!
A log of today’s flight is here,
http://logs.uaventure.com/view/HNFY7UpSuabPusXNsj2vzM#_PLOT
Kindly, help to identify the problem. And I believe a special attention is hugely needed to solve this issue!
My hypothesis is that IMU vibration or irregular EKF updates is causing an unstable bias estimate and the estimated vertical position and velocity error to grow to a value that prevented the copter from descending. Changes to the estimator to reduce the likelihood of this occurring have been made since v1.6.0 was released.
The position controller is vulnerable to vertical velocity estimation errors because it does not track a position set-point when the user demands a climb or descent and the users demanded descent velocity demand is limited when below an altitude threshold above takeoff point.
Changes to the estimator to reduce the sensitivity have been made since v1.6.0 was released, but the position control loops still have the vulnerability. Your short term options are to improve vibration isolation and turn off IMU accel bias estimation by setting EKF2_AID_MASK = 5, however make sure you have a recent accel calibration if you do change this parameter.
Here are the vertical velocity and position innovations (difference between inertial and measured baro position and GPS vertical velocity):
Here is the Z accel delta velocity bias estimates:
Here is the Z accel data:
Thanks, Paul, for the explanation. I was actually questioning the IMU vibration, but I don’t know which levels of vibration are acceptable.Currently, I am using damping pads (4 pieces under 4 corners of Pixhawk). Are there better vibration dampening methods?
With the same exact setup, I flew last night couple of flights, and I did not get the issues I faced. So I am trying to understand when this happens! If it’s vibration, then it should be about the same level in almost all fights as I did not change the setup, no? Also the wind conditions in all flights were about the same.
Regarding the EKF2_AID_MASK = 5, it will stop estimating the velocity bias, and, hence, it won’t be used in the velocity updates. Theoretically, if there is actual bias, then it won’t give the correct velocity estimation,no?
So, my question now is: what is the side effect of disabling the bias estimation?
I am trying ti understand what is exactly happening in order not get surprised in the future, and reduce failures, specially with expensive setups.
Thanks.
The effet of disabling bias estimation will be minimal if the IMU accels are calibrated with the board at the same temperature it will be during flight.
I use soft latex foam for the pixhawk isolation https://hobbyking.com/en_us/anti-vibration-foam-orange-latex-190mm-x-140mm-x-6mm.html to reduce the natural frequency of the pixhawk on the mounts. Alternatively you can reduce the amount of foam pad area or add mass to reduce frequencies which can be achieved by placing the pixhawk on a plate that is then isolated.
Also check that that all wiring to the pixhawk has enough loop or bend so that it is not transmitting vibration.
If you are able to build your own binary from source, you could also try this PR which brings PX4 EK2 up to date https://github.com/PX4/Firmware/pull/7087
Thanks. I will try https://github.com/PX4/Firmware/pull/7087 today, keeping the same parameters and setup. Also those are nice EKF tools for analysis! Do they work only on ulog format ? If yes, do I need to specifically set some topics to be logged in ulog? or the default logged topic are enough to generate the log analysis like the one you attached in your PR https://github.com/PX4/Firmware/pull/7087 ?
I will post my results in the comments of that PR to help finalizing the merger or debug. But I need to know if I should set the logged topic manually some how.
Thanks for the effort.
@Paul_Riseborough I can not connect to QGC 3.1.3 when I flash this PR. Any hints?
