Quadcopter rises to the sky in AltHold mode when at high speed - iNav 2.6

[elielmarcos]

Current Behavior

I have a 4" quadcopter, with FC F4 Noxe V1 and Matek M8Q-5883 (GPS and compass) and iNav 2.6 installed.
If I'm flying in Angle/Acro mode, everything looks fine. When I am in AltHold mode (regardless of whether GPS/PosHold is on or not) the quadcopter maintains altitude if I fly less than 40km/h, everything works normally, but when I am at a higher speed, it rises very fast to the sky alone (without stopping, even reducing the throttle), I have to quickly return to Angle/Acro mode and regain control.

PS: The same behavior occurs with or without foam-protection on the barometer.

LOG Taranis QX7:
Altitude (meters):

Vertical Speed (meters/s):

*Note that the moment the quad climbs crazy into the sky, the vertical speed recorded -18m/s, but it never really happened

Steps to Reproduce

1. Take off in AltHold mode or take off in Acro mode and change to AltHold mode.
2. Reach an altitude and stay at it (I usually test with 40 meters).
3. Provides a lot of forward pitch control with the goal of increasing forward speed.
4. Reach over 40km/h without touching the throttle stick.

Expected behavior

The quadcopter must reach high speed forward and not change its altitude (it must not go up or down more than a few meters because of some turbulence)

Suggested solution(s)

Regardless of the quadcopter X/Y speeds, it shouldn't change the height Z, because it's in AltHold mode and the accelerator is in dead band (it's not going up or down)

Additional context

My dump:

https://pastebin.com/VEVSQ8G4

---

• FC Board name and vendor: F4 Noxe V1 - JHEMCU
• INAV version string: INAV/FLYWOOF411 2.6.0

[avsaase]

I have the same problem so I made this plot based on a blackbox log to see what is going on.

As you can see, baro and GPS altitude track each other fairly closely, so I assume they are both reasonably accurate. At some moments, though, the estimated altitude goes in the complete opposite direction, because the estimated vertical speed goes negative (as your second plot also shows). This happens at the exact same times when the accelerometer measures a downward, not upward, acceleration (the green line on the lower panel). Since the accelerometer is used for the initial estimation of the altitude and vertical speed, I assume this is where the problem starts. So what I think is happening is, the accelerometer thinks it is falling, so the vertical speed must be negative. But the fc is trying to climb so it adds more throttle and the quad climbs. This continues in a feedback loop until you take over control.

The question then is why the accelerometer thinks it is falling, or even accelerating towards the ground at more than 1g. I think it is either horizon drift causing the accelerometer to be confused about the direction of the acceleration (but it would have to be VERY confused to see the upward acceleration as a downward acceleration) or the accelerometer is getting swamped with vibrations. I don't think I actually have a vibration problem so maybe it is something else, idk.

As for a solution, assuming your baro gives accurate readings, you can try increasing inav_w_z_baro_p to add more weight to the baro at the cost of the accelerometer in the altitude estimation, and/or increasing inav_w_z_gps_v to increase the weight of the GPS vertical speed in the vertical speed estimation. However, there is a bug that basically disabled this last parameter, especially for large errors like in this case. This bug should be fixed in 2.6.1, to be released soon. I'm already using this fix, and still have this problem so it is not a solution to this issue.

@digitalentity, what do you think? Could we maybe scale down 'accWeight' using the gaussian distribution to make the estimation more robust?

[elielmarcos]

@avsaase Hello, I did not put the acceleration graph, but I have the same problem as you, before starting to rise the acceleration on the Z axis is negative, close to -1g, so the quad thinks it is falling and climb very fast...

After some research I am convinced that the problem is some vibration / resonance in the FC that affect the sensors.

I also believe that the problem could be minimized by some configuration in firmware.

What values ​​do you recommend for inav_w_z_baro_p and inav_w_z_gps_v ?

Thanks

[avsaase]

With inav_w_z_baro_p = 1 the barometer fully determines the altitude estimation and with inav_w_z_gps_v = 1 the GPS fully determines the vertical speed estimation, so that would be the upper bounds.

[elielmarcos]

With inav_w_z_baro_p = 1 the barometer fully determines the altitude estimation and with inav_w_z_gps_v = 1 the GPS fully determines the vertical speed estimation, so that would be the upper bounds.

@avsaase Thanks for your reply, I understand perfectly. But I still believe that just changing these weights is not going to solve the problem entirely, perhaps it will mitigate.

As we both have a similar assumption (vibration, interference ...) I will first try to make the FC support (mechanical) more flexible and install some filter capacitors (electric)

If I don't get better results, I will have to change these weights in the iNav settings

[elielmarcos]

Hello, I solved 90% of the problem just by reducing the vibration in the FC. I put softer supports and the problems have reduced a lot!

Now there is a small increase in altitude (10 meters and then stabilizes) when 80km/h is exceeded.