When flying in loiter mode my 7 inch quadcopter falls around 2m once it initiates the brake maneuver after releasing the sticks.
In the logs I can see that the barometer seems to register an increase in altitude once the braking maneuver initiates which might be the problem. However, I already tried shielding the barometer (its an external ms5611 placed inside a sealed 3d printed box with foam) and it did not improve. I also tried messing with the PSC_ parameters but without success.
I also have a 2.5 inch quadcopter which shows the same behaviour but only falls around 1m.
During this flight I was not using the external MS5611 because I had not installed it yet. I was using the bmp280 that is in the kakute h7 shielded with foam but with or without external barometer the behaviour is the same.
Also, in this log it is possible to identify another problem which I think might have something to do with this “sinking” effect caused by the barometer. During the brake maneuver sometimes it is possible to see a fast oscillation in pitch which it think might be happening due to the fact that the drone is trying to brake and descend at the same time leading to low motor rpm and being unable to maintain pitch attitude. However this is just my theory. If you guys know another reason for this pitch oscillation let me know
I already tried baro wind compensation but did not like the behaviour because the drone becomes unpredictable. Some times it sinks during the braking maneuver and other times it rises. I think it might be because the wind effect over the baro is not exactly the same everytime
Sorry to doubt about this but I can´t seem to understand how flying near the ground for few mins can help. Does the craft “learn” baro behaviour during this maneuver?
Tuning looks really good apart from that baro issue.
It looks like the baro altitude is changing in line with pitch, so the likely problem is prop wash.
Are able to shield the entire flight controller area? Even temporarily as a test, like wrap some cling film around.
The HNOTCH is working very well as ESC RPM based. I would disable the FFT since you already have all the data you need. Also I couldnt help wondering if the FFT was imposing any unwanted CPU load or lag, unsure about this…
FFT_ENABLE,0
INS_LOG_BAT_MASK,0
INS_LOG_BAT_OPT,0
You have good GPS performance for a small quad, I would consider putting back
ARMING_CHECK,1
and set
GPS_GNSS_MODE,5
probably do this anyway
even if you have to wait a minute to launch. It’s good to know the Home position is set correctly.
You could try a small lidar pointing down. I’m getting good results using a TF luna lidar at low altitude (4 meters). On a small 4" copter I have some EMI problems which I limited by shielding the lidar, perhaps on a large 7" the problem could be less. Alternatively you could use the product suggested in this thread:
I am already using a tfmini lidar. In fact, it stops the sinking effect when altitude is in range of the lidar. However I eventually turned off SURFTRAK mode because I don´t like the fact that the drone climbs automatically when it detects an obstacle below the drone, so the tfmini is not contributing to altitude maintenance anymore but only to the optical flow navigation. This means the sinking effect continues
I also believe that the loss of altitude can also be influenced by the power-to-weight ratio of the quad. Here the altitude loss is small on my very small 3" (sub 250gr) and I’m only using the barometer.
However, on my 4" I have the possibility to activate and deactivate the lidar in flight when necessary (RC option). Just today I did a fast roll test at low altitude and the lidar is much more precise than the barometer (blue barometer red trace lidar green sonar as avoidance) Then at higher altitudes the loss of altitude (with the barometer alone) is much less perceptible
I can´t shield all the FC area but I connected an external barometer completely shield inside a 3d printed box with foam and the behaviour is almost the same, only a bit better.
Is there anyway to check cpu load in the logs?
I will try those parameters that you suggested and see what happens.
In terms of arming checks, I disable the ones related to GPS because I want to be able to fly loiter or poshold indoors with the optical flow
I already tried several flights with those parameters and it did not work. Here is the log of a flight with an external barometer MS5611 sealed inside a box with foam. It is noticeable that there is still a major low pressure during the braking maneuver which I can not solve
Both barometers are affected exactly the same by the same prop wash. I think this is life with such a small quad where everything is so close. We still get the same effect on larger quads and it’s hard to avoid.
When you are about ready for takeoff, can you wrap the whole body of the quad (except arms and props of course) in cling film or something and try a flight? This would at least prove if the issue us prop wash or not.
You could enable GPS and set
EK3_SRC1_POSZ,3 (GPS)
but that is a bit non-standard, more for people doing long missions in open areas.
It might not be accurate enough for flying close to the ground.
The 2nd EKF instance will still use baro if needed - EK3_SRC2_POSZ,1 (baro)
I think you can safely set
EK3_GND_EFF_DZ,1
but this may not help the issue you are having.
Experimentally, you could change this parameter down in steps of 0.25 and see if has any effect. Alternatively increase it in steps of 1. I’m not sure which way is best, because I’ve not altered this before.
EK3_ALT_M_NSE,1
@Jai.GAY I don´t want to set the rangefinder as main altitude source because I don´t want the jumpiness over obstacles that results from that so those rangefinder parameters are not useful to me. In terms of EKx_ALT_M_NSE I tried increasing it until 7 and the problem still persists. I also tried reducing as @xfacta sugested and the drone seems to sink even more although becomes more stable during hover.
EK3_GND_EFF_DZ,1 also did not solve the issue as expected
