Altitude not performing well with barometric pressure

[DanielePettenuzzo]

When moving around in altitude mode I get some large altitude drops (several meters). This happens only when I use barometric pressure. With GPS height or a range finder it performs much better. Still not sure if it is a baro issue. I opened this issue because it is not the first time I see this issue in the past weeks.

I will improve the baro shielding and send some more logs soon.

Frame: S500 Autopilot: Pixhawk 4 Mini (fmu-v5) PX4 version: Master (100f955)

Log (barometric pressure height): https://review.px4.io/plot_app?log=d6fdcb0d-e7e3-44fd-905e-286eaac3726a Log (GPS height): https://review.px4.io/plot_app?log=6babba16-d57f-4b3c-be8d-c8aae86b2fb4

[DanielePettenuzzo]

FYI @priseborough @RomanBapst @thomasgubler

[priseborough]

This is unlikely to be the cause, but when I went to check the correlation between XY specific forces and baro error and noticed that the accel data is extremely noisy which will may cause problems in the future if we wish to enable the drag fusion/wind estimation feature (see EKF2_BCOEF_X,Y parameters) which is required to use the baro pressure compensation feature (see EKF2PCOEF* parameters).

Do you know what could be causing this? How has the pixhawk been isolated?

This was able to be cleaned up with a LPF and the specific forces in the X and Y axes (which are proportional to dynamic pressure) correlated to the transients in baro innovations.

It would also be worth me experimenting with dynamically adjusting the baro process noise as a function of the XY magnitude of specific force after lowpass filtering.

I'll wait till you have done some experiments with Baro shielding. Can you please set the SDLOG_MODE so that logging starts at boot. That way we can test any code and parameter changes using the replay.

[DanielePettenuzzo]

@priseborough I took a few more logs in which we changed the shielding on the baro. I went from no shielding at all to shielding with thick foam and taping most holes on the pixhawk with tape.

no foam: https://review.px4.io/plot_app?log=0b0a4f78-abf8-455c-b3ae-3b8ed4719741 original foam: https://review.px4.io/plot_app?log=aa6c5c8d-5c49-4f3e-a145-f875e2adf51a thicker/more dense foam: https://review.px4.io/plot_app?log=8d69f861-6668-4cfa-ba08-0e5f7886ecee ticker/more dense foam + tape on pixhawk case: https://review.px4.io/plot_app?log=3fb06717-6e71-4ea3-83b2-f920ecbb3e89

The noise in the accel seems to be caused by the frame we are using (quite common hobby frame). The pixhawk has only the internal damping on the imu board. The board is then hard mounted on the frame.

Logging from boot to disarm and ekf replay were enabled in these logs.

[thomasgubler]

@DanielePettenuzzo @RicardoM17 can you add pictures of the setup for Paul?

[thomasgubler]

@DanielePettenuzzo @RicardoM17 this is with the PH4 mini. But the behavior with the PH4 was the same. Correct? Do we have logs from PH4?

Do we have logs with range finder and starting from boot for replay?

[DanielePettenuzzo]

These 4 logs are with a normal PH4 (not mini). For some reason the range finder did not start. We can take more with the range finder.

By the way these logs were taken with SDLOG_MODE set to 1, which is log from boot.

[RicardoM17]

Here are the pictures of the setup used. Frame is the S500 and we used foams with different thickness (we had to open the Pixhawk everytime). No pictures of the "duct tape cover" but it wrapped the pixhawk all around.

[priseborough]

I think you are getting static pressure measurement errors due to to the location of the autopilot on top of a larger flat deck that is generating large pressure variations with airspeed and tilt angle. This is indicated in how the vertical position and velocity innovations vary during manoeuvres.

The following figure illustrates how during acceleration into forward flight initially the forward tilt of the top plate counteracts the drop in pressure due acceleration of airflow passing around the body. Then as the tilt reduces, there is a 'suction' effect above the plate which causes a positive baro height innovation, than then takes 5 seconds to recover after the vehicle stops.

Note: The data in this figure has had noise filtering applied before plotting

Changing foam will not alleviate this effect and wrapping with tape appeared to make it worse, probably because it effectively moved the static pressure reference to less favourable locations.

We do have some ability to compensate for this type of effect by firstly enabling and tuning fusion of Drag Specific Forces (see https://dev.px4.io/en/tutorials/tuning_the_ecl_ekf.html) to enable wind estimation and secondly tuning the EKF2BCOEF* parameters to compensate the baro for the interference.

Also the practice of hard mounting this board is not good and vibration levels are excessive, however with the size of baro errors present, it is hard to tell if this has contributed. I have not opened one up, but there is insufficient depth to implement an effective vibration isolation design for the IMU that will have the isolation mount natural frequencies below the motor rotation and blade passage frequencies. We should run a test with the board board mounted on soft foam squares. I have found this material to be be effective for isolation of low mass autopilots due to its low modulus and moderate damping. https://hobbyking.com/en_us/anti-vibration-foam-orange-latex-190mm-x-140mm-x-6mm.html

[RicardoM17]

@priseborough we went flying again this morning. We enabled the fusion of Drag Specific Forces like you suggested. Unfortunately the behavior persisted and changing the parameters didn't have a noticeable effect in improving the performance of the quad.

You can see the following logs:

• First flight with EKF2_AID_MASK enabled and default values on the coeff and noise params: https://logs.px4.io/plot_app?log=b64b6be5-45ad-4c13-b908-4fee3e2464b2

• BCOEF_* to 40 - DRAG_NOISE 5 : https://logs.px4.io/plot_app?log=96f0afd2-30ed-42f4-8c18-5f348fa34e60

• BCOEF_* 10 - DRAG_NOISE DEFAULT: https://logs.px4.io/plot_app?log=4222a204-77e9-4cb6-913c-187dda9bfafd

• BCOEF_* 55 - DRAG_NOISE 5 : https://logs.px4.io/plot_app?log=45b11504-196a-432a-9cc6-89691b5bd621

• BCOEF_* 75 DRAG_NOISE 10: https://logs.px4.io/plot_app?log=3242d70f-4d8d-4c2a-b756-e9492c4cb091

One particularly interesting observation is that when we tilted hard (for example Roll Right) the quad would maintain altitude when moving and it would lose altitude only when/after performing the counter-tilt maneuver (Roll left to maintain position). However when the sideways motion was achieved by a less aggressive motion (i.e. a smaller tilting angle) the quad would lose altitude while in motion and quite fast actually. Maybe some conclusions can be drawn from this observation.

We are still looking for a vibration dampening foam similar to the one you posted that it's actually available for us to purchase. Once we find one we will test that as well.

[priseborough]

@RicardoM17 There are 2 steps to follow:

1) Tune the wind estimator via changes to the ballistic coefficient parameters EKF2_BCOEF_X and EKF2_BCOEF_Y so that the RMS of the X and Y specific force innovations is minimised

Looking at your first log, the default EKF2BCOEF* values are working, but cannot be improved using ekf2 replay because logging from boot was not enabled. Here are the specific force (drag accel innovations).

Here is the wind estimate:

2) Tune the static pressure corrections via use of the EKF2BCOEF* parameters which are zero by default. They should be set to values that minimise the baro height innovation change after the copter has braked at the end of each manouvre. Until this step is done there will be no be change in behaviour.

A log starting from boot is require to complete tuning.

[DanielePettenuzzo]

@priseborough these are two more logs similar to the ones Ricardo sent you. I enabled log from boot. Let me know if these are more useful otherwise we can get more, also with different drag coefficients. Log1: https://review.px4.io/plot_app?log=ac2c3202-98bb-40ac-a2d9-69e1db93c6de Log2: https://review.px4.io/plot_app?log=fbeefadb-a01b-4735-9aa7-860d602c1d92

For future logs we will also mount the autopilot with foam to reduce vibrations.

[flochir]

Don't know if it's the same issue, but we also see height drops after quick deceleration to stop - on our open frame test setup as well as with the flight control in a surrounding housing: https://logs.px4.io/plot_app?log=f67e07f2-954b-44f4-a512-ee8942f885bd

The best example is from approx 0:40 to 0:52 in the video. The flight was in position mode, and during this time span the throttle stick was not altered.

The FC is a Pixhawk 2.1 Cube, we saw this on both PX4 version 1.8 as well as various development snapshots.

[RicardoM17]

@flochir Looking at the video the behavior is very identical. We also get the drops in altitude after a roll/pitch to stop the horizontal motion and maintain position. Can you share some pictures of your setup? Especially on the mounting of the FC. Is it hard mounted?

Also do you also get a slow but continuous drop in altitude when you roll/pitch for a longer period (say 2-3 sec) even at a lower tilting angle? We experience this and it usually doesn't happen when we roll/pitch more aggressively which is not very intuitive. (in this case we only get the drop in the correction after we finish the motion)

[flochir]

For the continuous drop I can't tell. Possibly, but it didn't catch my eye. But next flight I will test that. The FC is hard mounted using 3M double sided pads.

Here are some pictures of our quick test setup:

I don't have pictures of the enclosed flight control ready, but it's a full housing, however with a ventilation grating.

[flochir]

One more detail - observed a dropping in altitude during a strong breeze from the side while holding position - dropped 1 m, then I had to correct up. After the breeze stopped, the system climbed about 2m on itself.

[priseborough]

@flochir with the 'cube' autopilot exposed to the airflow like that it will help to tape over the SD card/USB hole.

[priseborough]

@DanielePettenuzzo Isolating the board will help with tuning the EKF2_BCOEF parameters. The vibration makes the specific force observations very noisy and masks the effect of tuning changes in the innovation sequence. After filtering the plotted innovation values, I was able to determine that a EKF2_BCOEF value of 23 gave a reasonable innovation sequence:

I then tried tuning the EKF2_BCOEF parameters but there are two impediments:

1) The test log contains mostly lateral movement, so the EKF2_PCOEF_XN and EKF2_PCOEF_XP parameters could not be tuned

2) There is a significant prop wash effect on the baro alt under some flight conditions - see figure below illustrating the correlation between motor current and baro disturbance:

I was able to get a reduction in the magnitude of post manoeuvre baro innovations with a EKF2_PCOEF_Y value of -0.4 so that would be worth testing along with sewtting EKF2_BCOEF_X and Y to 23.0.

These figures illustrate the effect of the position error correction coefficient on the Baro alt innovations sequence, eg:

EKF2_PCOEF_Y = 0.0

EKF2_PCOEF_Y = -0.4

[priseborough]

I forgot to mention in the previous post that when tuning the EKF2_PCOEF_Y value, the baro observation noise EKF2_BARO_NOISE was also increased from the default value of 2.0 to 3.0. Ideally this would be made dynamic so that when the copter was hovering with minimal manoeuvre acceleration it would use the default value, but increase when the length of the gravity compensated acceleration vector indicated a manoeuvre.

[RicardoM17]

@priseborough here is the log of the new test flight we did today:

https://logs.px4.io/plot_app?log=cdc0ab30-8105-48b3-981a-fab2b73724e4

The behavior is about the same. I included more forward/backward motions so that you can tune the X parameters as well. One particularly interesting detail was that in this flight log when we rolled right it lost altitude when it was braking while when we rolled left it actually appeared to gain altitude when it started braking even though it that was still usually followed by a lost of altitude afterwards. It could have been a coincidence, as we are not sure that it's something that's consistently happening.

We also tried a soft foam we had in the office, to reduce the vibrations on the FC but unfortunately it was too soft and it lead to worse results. Next week we should receive several types of foams/gels so we can try them out and hopefully get better results in order to reach a conclusion.

[flochir]

@priseborough did you observe the direction of wind while it showed that asymmetric behaviour? Breaking against the wind our system dropped, while with the winded it maintained its height. It didn't really rise though.

[RicardoM17]

@flochir I believe you meant to tag me?

And I did not note the direction of the wind but iirc there wasn't too much wind and given the speeds that we were moving it was probably more due to an assymetry in the Pixhawk board than to the wind direction. But I will remember next time to do the same motions but while facing a different direction.

[EliaTarasov]

@DanielePettenuzzo @priseborough @flochir @RicardoM17 Are there any news on this issue?

[neom89]

I faced similar problems with pixhawk 4. I had the controller dampened with thick pads. Here is the issue I created for the same #10850

When I swapped pixhawk 4 with pixhawk 1, this behavior went away.

[EliaTarasov]

@neom89 Thanks! I disable internal baro and replaced it by external one. Now it works ok.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

Closing as stale.

[bys1123]

I think I have the same issue on Pixhawk4+S500 https://logs.px4.io/plot_app?log=47609dfb-3d5c-4c68-9e0b-2d549712b997 I think this cause by S500 prop is not directly face to ground, If you roll or pitch, drone can't get enough power.

[bys1123]

@DanielePettenuzzo Do you have any new updates?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

Closing as stale.