Open dominickmscialabba opened 4 years ago
dagar
commented
4 years ago Would you be able to give current master a try? In particular, the defaults for EKF2_BARO_NOISE and EKF2_GPS_V_NOISE were adjusted not to long ago in response to baro related height estimation issues.
dominickmscialabba
commented
4 years ago Hello @dagar, thank you for your response! I have built and uploaded the master to my quadcopter. For this test, I removed/disabled all external barometers and non-stock sensors (LIDAR, external GPS, etc.). I have also removed all shielding from the Pixhawk 4 barometer except for the stock case.
In addition to stock hardware, I have also reverted to all stock parameters except for the Rate PIDs, Attitude PIDs, the MPC_MAN_TILT_MAX, and the MPC_TILTMAX_AIR. The PIDs were saved from the previous version of the craft and the maximum tilts were set to 20deg to accommodate the craft’s size and applications.
I then performed a test following Method 2 of the original post on a day with a 3-7mph breezes. In this test, I noticed better Z-velocity and Z-position control from the controller without RC input with default PIDs (good news, even if case-sensitive) and even had some periods of sustained accurate hover. There was one test (log not included) where it gained 3-4m of altitude in a cross breeze while hovering but no other trial replicated this magnitude of error.
Wind Altitude Gain/Loss 2
This first set of tests revealed that the X- and Y- position controller PIDs needed to be adjusted (controller is over-tuned and hyperactive) and the jerk limits needed to be reduced but the Z-control was slightly better in the breezes.
The true test is Method 1. After de-tuning the XY controller (to ~1/2 of the default P value) and lowering the jerks it performed safely enough to replicate Method 1. The previous results were confirmed even on the new master. Although there were dips/jumps while traveling left, right, and backwards they can be considered small when compared to the altitude loss in forward flight. Maneuver Altitude Loss 2
The same problem as before is replicated on the master. I will try EKF Replay in the coming days and am willing to try just about any test you can conceive that may be helpful in solving this problem. Thanks again for the help!
dagar
commented
4 years ago It looks like you didn't get the new default values for the EKF2 parameters.
Could you try these?
EKF2_GPS_V_NOISE 0.3
EKF2_BARO_NOISE 3.5
After that you could also try EKF2_GPS_V_NOISE 0.2 and EKF2_BARO_NOISE 4.0 as another comparison. Be sure to reboot after setting these parameters so that the EKF has them from the beginning.
dominickmscialabba
commented
3 years ago Hello @dagar, I am very sorry they looked to be default in QGroundControl and it tricked me! :P Here are some more flights with the changed parameters. All flights were performed using Method 1 and the same craft, unchanged from the last tests (no external sensors, mainly default params, no enclosure other than stock, etc.).
3.5, .3 Method #1 3.5, .3 Long Flight (90deg yaw) This flight has a large gain of altitude when rolling left. There was a bit of wind (3-7mph, 12mph gust) this day blowing from the west. This is believed to have exaggerated some of the errors it makes in its altitude along the roll axis in the first flight. To gauge the effect of the wind against other directions of travel a second flight is included. This flight features a 90deg yaw mid-flight, transferring the wind from coming from the craft’s X-neg to coming from the craft’s Y-pos (90deg CCW rotation about Z). This did change flight performance but did not remove the altitude losses/gains.
4, .2 Method #1 This flight was performed on another day with less wind (2-4mph). The controller now exhibits rises on some axes but also loses altitude in some directions….
4, .4 Method #1 4, .4 Square This parameter combination was an accident but is included as another data point. The craft exhibits qualitatively larger rises with this configuration. This flight was performed on the same day as the first flight (.3, 3.5).
Looking at all 3 flights, commonalities are present in the Altitude Estimate plots which are pasted here for the reader’s convenience. Prior to any increase or decrease in the craft’s altitude, the thrust would increase or decrease, respectively. This is a slight paradigm shift. Instead of barometric altitude fluctuation causing thrust fluctuations resulting in loss/gain of altitude, the thrust fluctuations now cause an altitude loss/gain resulting in barometric fluctuations (from baro causing thrust to thrust causing baro). This may be a subtle difference in the timing of things but is worth noting. This can easily be seen in each of the Altitude Estimate plots as shown by the outlined blue regions.
EKF2_GPS_V_NOISE = .3 and EKF2_BARO_NOISE = 3.5
EKF2_GPS_V_NOISE = .2 and EKF2_BARO_NOISE = 4
EKF2_GPS_V_NOISE = .4 and EKF2_BARO_NOISE = 4
stale[bot]
commented
3 years ago This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.
Description: PX4 struggles to hold altitude using the barometer in both the AltHold and PosHold flight modes. Cross-breezes result in altitude gains/losses. Maneuvers result in altitude loss. Typically, the more rapid the maneuver the larger the altitude loss.
To Reproduce:
Method 1
Method 2
Expected Behavior: In AltHold and in PosHold, if the z-setpoint is not changed, the craft will not change altitude.
Screenshots: Method 1
Caption: Note the bulge in the barometer altitude coupled with the decrease in thrust both of which result in a dip during and after maneuvers.
Method 2
Caption: Note the three bulges in velocity and the area between the actual and desired curves. NO RC commands or values were given between 2:40 and the 3:25 time-stamps. After 3:25, the drone started to gain many meters of altitude at which point a downward RC command is given. Even though almost full-stick down is commanded, the copter continued to rise until the breeze (2-5mph) settled.
Craft Specifications: The craft itself runs 18x5.5in props on a 900mm frame and uses a Holybro Pixhawk 4 running PX4. The craft is rather heavy but well within the motors and batteries specifications for thrust and power available/required respectively. Firmware version v1.10.1 was used for all initial testing. Firmware version v1.11.0-beta2was used to connect external barometers through the I2C port (ex. for BMP388) because this is not provisioned for in v1.10.1. These same performance issues are also present and reproducible on a much lighter craft (15x5.5 props, 750mm frame, Pixhawk 4, v1.10.1).
Attempted Solutions: 1) The first tests were performed using the stock on-board MS5611 barometer with no shielding. The flight performance was fine but produced noticeable dips upon maneuvering in any direction. 2) The issue https://github.com/PX4/Firmware/issues/10058 suggested shielding the barometer, and adjusting the EKF2_BARO_NSE, EKF2PCOEF%%%, EKF2BCOEF%%%, and EKF2_DRAG NOISE parameters. Shielding the barometer in an indirectly ported enclosure did not produce noticeable differences. (in either data or performance). Adding open-cell foam around the PX4 inside the enclosure also did not produce noticeable differences. Moving the barometer very far away from the propellers did not produce noticeable differences. 3) After shielding and isolation were tested and had no effect on the problem, the suggested parameters began to be changed but shielding with enclosure and foam was kept for the remaining test. Setting the XN, XP, YN, and YP EKF2_PCOEFs to their minimum value of -.5 very slightly reduced the dip (10-30cm out of 1-3m). 4) After PCOEFs were ineffectual, the BCOEFs were next to be altered. A theoretical ballistic coefficient was calculated for this aircraft using the drag coefficient of a flat-plate, the mass of the aircraft, and the area of the central plate. The calculated value was 23.96kg/m^2 (1kg/m^2 lower than default). The ballistic coefficient parameter was altered from minimum to maximum values. The EFK2_drag.innovations[0:1] were examined after each flight but did not change in RMS value. EKF2 Replay was attempted using JMavSim on a Windows 10 machine but errors were thrown upon completion of the documentation steps and replay never worked. Changing BCOEFs had little to no effect on the EKF2 innovations for both drag and wind estimation. 5) The last of the suggested parameters was EKF2_BARO_NSE. Raising EKF2_BARO_NSE to a value of 5m improved flight performance and reduced dips while maneuvering. This is NOT a solution to the problem as all it does is transition estimation authority from to the barometer to the GPS. The entire intent of this testing is to have consistent altitude performance even without GPS assistance (to fly in buildings and structures) therefore this is not the most desirable solution. 6) After the above parameters failed to solve the problem, the EKF2_HGT_MODE was changed from barometer to GPS. This stopped the dip from occurring but once again is not a solution. After GPS was used, a downward-facing LIDAR was used with range-aid enabled without it being the primary height sensor and with range-aid and as the primary height sensor. Both of these removed the dip while maneuvering and followed terrain well. These too are undesired solutions due to limited LIDAR range and the possibility of ground-based objects messing up the LIDAR altitude estimation. 7) The next series of testing began with an external barometer/GPS from Zubax enabled via UAVCAN. This also featured the MS5611 chip and yielded the same results as the on-board MS5611 for all of the above tests. This GPS was also enclosed in the Zubax designed enclosure with open cell foam in the barometer enclosure (inside the overall enclosure). With UAVCAN enabled, both the external barometer and the external GPS were used as the primary GPS and barometer but did not produce noticeable differences in flight performance. 8) No other types of barometers were supported in v1.10.1 so v1.11.0-beta2 was used for the rest of the testing. The v1.11.0-beta2 code was altered to enable the driver for the BMP388 acquired from Adafruit. The MS5611 driver was also disabled to ensure that the BMP388 would be used for pressure-height data and not the on-board sensor. The PIDs for the rate, attitude, and XY- position controllers were able to be tuned to achieve the desired performance. The Z-position/velocity controller gains were left at default. Hover flight could be achieved as expected however, when a breeze blew the craft would gain altitude and not settle back to the set-point. The second log of the 3-4min flight is the best example of this. No control input would be given and the craft would gain altitude at the maximum allowed vertical speed (2m/s, default = 3m/s). The P and I values of the controller were reduced to close-to or just above the minimum allowed values (to create a sluggish and under-tuned controller) and still the craft would ascend at maximum vertical speed in a slight cross-breeze (2-5mph). For the end of the flight, the rise in altitude was partially counteracted by a downward RC command but almost full-stick down was commanded before the aircraft consistently began to descend.
Notes:
I hypothesize that both flight abnormalities are caused by the pressure changes across the barometer. That being said, all tested barometers were a fully enclosed as they could have been without rendering them inoperable. My second hypothesis is that the altitude fusion in the EKF2 does not handle these barometer fluctuations well. The same craft flown with a DJI A3 controller does not have these problems when flown under the same conditions (wind, maneuvers, poor GPS environment, etc.). These logs and descriptions hopefully show problems with dynamic pressure handling (either craft moving in static air or air moving over static craft) that Pixhawk 4 has. This problem effects AltHold, PosHold, and Loiter flight modes and mission performance in many different scenarios and its significant diminishment or removal would make PX4 based systems more useful and versatile.