When stopping the drone after having horizontal velocity, there is a noticeable decrease in height (2-4m), which is regained a couple of seconds after stopping. The vertical speed is only ~6m/s in these flights. This indicates that the barometer is affected significantly when stopping.
According to the PX4 documentation Correction for Static Pressure Position Error this can be compensated by running a python script on a specific log file and adjusting the parameters:
EKF2_PCOEF_XP = [-0.5, 0.5]
EKF2_PCOEF_XN = [-0.5, 0.5]
EKF2_PCOEF_YP = [-0.5, 0.5]
EKF2_PCOEF_YN = [-0.5, 0.5]
EKF2_PCOEF_Z = [-0.5, 0.5]
However, the estimated parameters for my drone are outside the allowed range even though the estimated corrections looks OK in my eyes. The height is still wrongly estimated when demanding vertical velocities, when compared to GP,S and is not corrected by the tuning script
Log (no wind): https://review.px4.io/plot_app?log=cb1a6965-07ad-4a1f-a2a1-59195b77638a
Tuning script output
Optimization terminated successfully.
Current function value: 1810.789198
Iterations: 441
Function evaluations: 701
param set EKF2_PCOEF_XN -2.735
param set EKF2_PCOEF_XP -0.361
param set EKF2_PCOEF_YN -2.943
param set EKF2_PCOEF_YP -2.420
param set EKF2_PCOEF_Z -10.185
Are these limits perhaps suited for smaller drones like x500 or should my larger drone also be in the [-0.5, 0.5] range, indicating something is wrong with my setup or flight?
Are drag specific forces tuning required before tuning the Correction of Static Pressure Error. The documentation states For multi-rotors, fusion of Drag Specific Forces can be enabled and tuned to provide the required wind velocity state estimates. ?
My goal is to have the drone not lose 2-4m altitude when braking to a stop.
If it helps I also run the wind estimator tuning script.
Output when running mc_wind_estimator_tuning.py results in parameters in allowed range except EKF2_DRAG_NOISE which is below the minimum of 0.5.
Optimization terminated successfully.
Current function value: 250.423765
Iterations: 79
Function evaluations: 141
param set EKF2_BCOEF_X 47.2
param set EKF2_BCOEF_Y 51.9
param set EKF2_MCOEF 0.07
/!\EXPERIMENTAL param set EKF2_DRAG_NOISE 0.05
I added this to the dev call agenda (tomorrow 8AM PT). I havenāt used this feature since 2019, but back then it never really worked. I canāt say much more than that. Hopefully someone who knows more than me like @MaEtUgR or @bresch can comment.
Thanks for bringing it up. Am I allowed to join in on the meeting to listen in? If not, and the subject is brought up, would you mind posting the results?
Of course you can join the call on Discord to listen and ask your question, see
On the topic:
Are you sure itās losing altitude because of barometer error? Just asking to rule out any other influence. We can double-check the log
Whereās your barometer mounted? The more bernoulli effect is generated e.g. with a high airspeed over a small hole the worse the performance and hence necessary corrections. I donāt have a feeling for the coefficient numbers but I can imagine that depending on the barometer placing and the housing of your avionics the effects can be quite strong. Itās always advisable to fix the hardware first but if the high influence remains it could be theoretically possible that a lot of correction is needed.
Did you compare with another log if the results are somewhat reproducible? The pattern I usually fly is Altitude mode accelerating with full tilt in each direction and then letting it coast for as far as possible e.g. until it stops or I run out of space or visibility. Similar like for the drag, wind fusion which I usually do first.
That said Iām only user of these features and donāt know the internals so @bresch could probably correct me here.
From a quick glance at the log there seems to be a lot of barometer influence, the data looks somewhat noisy and the vehicle measures going up based on barometer with higher wind speed.
Check if you can improve the hardware e.g. barometer placement.
Apply the high correction coefficients, especially if you verified them to be somewhat reproducible from two logs.
Compare to setting the GPS as primary altitude source see EKF2_HGT_REF . Note that Iād make the baro work because using GPS altitude has its own problems especially if you ever have any GPS inaccuracy because of obstruction, multi-path or any other jamming source.
You could also play with the barometer measurement noise EKF2_BARO_NOISE if itās not as accurate.
We can see that there is an offset of about 0.3m/s^2 (on the Right axis) between the predicted and measured accelerometer data. This would create a wind offset that can affect the baro compensation.
Do you also have a log with this tuning applied? We should verify that in calm conditions, the wind estimate should stay close to 0 regardless of the speed and direction of the drone.
One potential issue is the level horizon; if the autopilot is leveled correctly, you can set SENS_BOARD_[XYZ]_OFF back to 0
Regarding the pressure coefficients, EKF2_PCOEF_Z is probably unobservable as you can see that the fit is really bad at the end of the flight, when you only perform altitude changes. ā you can thus ignore that result and leave it to 0
I am certain it has to do with barometer error. I performed multiple flights today where I initially used barometer as primary height source EKF2_HGT_REF = 0 (baro) and observed the problem. I then switched to EKF2_HGT_REF = 1 (gps) and disabled baro aiding via EKF2_BARO_CTRL = 0 (disabled) , and did not experience the altitude drop to the same extent. Using baro drop is about 1-4m, using gps itās below 0.5m, which isnāt really noticeable.
Barometer is the internal Cube Orange+ which is mounted inside the airframe body (not an airtight frame but fraily water resistant (IP54). The body uses pressure/vent/moisture plugs to allow pressure changes and moisture to escape. Itās similar to this part form digikey. I am not sure how I can improve barometer placement, itās not in the open air. Do you have any suggestions @MaEtUgR ?
Do you know if the wind estimation using drag specific forces are required for baro compensation to work? (usingEKF2_DRAG_CTRLand associated parameters)
Hence, I believe this drag-specific forces (wind estimation) might need to be enabled for this compensation to work, as outlined in my initial questions. I will try that compensation script and enable Multicopter Wind Estimation using Drag Specific Forces via EKF2_DRAG_CTRL and see if that is the required action.
Let me see if I understand the wind estimation correctly.
With a correct wind estimation tune using EKF2_DRAG_CTRL, EKF2_BCOEF_X, EKF2_BCOEF_YEKF2_MCOEF and EKF2_DRAG_NOISE the estimated wind estimate should be close to 0 even if the drone is flying with some horizontal / vertical speed. The estimate is just the wind speed then, make sense.
The autopilot is mounted on vibration dampeners and was perhaps leveled on a flat, but not perfectly flat, surface. Offsets are quite small at SENS_BOARD_X_OFF = 1.08, SENS_BOARD_Y_OFF = 0.038 and SENS_BOARD_Z_OFF = 0.0
Using the ācoastingā flight (higher velocities, no sudden stops, just coast until stop) the parameters are a lot closer to the suggested range by PX4 documentation, but the estimate looks worse in my eyes. Especially since the fitted model only estimated the error well during the dynamic part and not the coasting, see my red mark. Could there be a problem with my airframe? Perhaps my slightly āsealedā box doesnāt change pressure fast enough and the built up pressure takes time to be released?
The drag noise is however, a magnitude lower than the minimum suggested in PX4 Is it still a reasonable number? @bresch EKF2_DRAG_NOISE = [0.5, 10] (2.5 default) (m/s^2)^2
I donāt really have an intuition about this parameters other than looking at the estimated model outputs.
If that is the case I will apply the following parameters and see if I observe any improvement tomorrow:
