RTH climb problem when using Matek F722-miniSE with dps310 barometer

[jackwca]

Hello,

This is my first UAV build of any kind since playing with RC zagi's 15-20 years ago. So I'm sure that I am doing something wrong.

I built around a month ago a mini quad with a Matek F722-miniSE and BN-880.
Running INAV 2.6.1.
First flight everything ran perfectly. Poshold was blob on and RTH was faultless.
I immediately tried RTH again without changing anything, I can't remember if there was a battery swap between these. But on flicking the RTH switch this time the little quad shot straight up faster than I could blink.
After a more abrupt landing... A new frame was required. I rebuilt but unfortunately every time since trying RTH just causes this speedy climb. Now with less of a shock though and turning RTH off and back into Poshold controls it very nicely.

If I change nav_rth_alt_mode from AT_LEAST to CURRENT, RTH performs as expected. Just have to be more observant of surrounding obstacles.

Upon more troubleshooting I notice that the barometer on the sensors page of the configurator climbs a lot after applying power.

The baro reading will generally climb to around 10 meters over ~5 mins before stabilising. Once stabilised if power is instantly reset to the board the reading is fairly stable around 0. Suggesting there is some thermal stabilisation issues.
This seems quite well discussed with barometers that are attached to the flight controller PCB on different forums.

However I don't see why this would cause the quad to shoot up in the air when RTH is activated. Quite the opposite if it thinks it is higher than it actually is.

Other trouble shooting:

• Foam covering barometer.
• Not in direct sunlight.
• Full chip erase. Multiple times.
• New BN-880 module.
• I got a new Matek F722-miniSE flight controller. Tested on bench on its own and the baro sensor gave the same readings.
• Upgrading to INAV 3.0.0 since it's release.

Am I right in thinking that Poshold uses GPS for altitude control as well as for 2D position. Full 3D fix?
Does RTH use GPS or Baro for the initial climb? If climb is required.

This board uses the DPS310 barometer, which doesn't appear to be as popular on other FCs, although it's spec suggests it should be more accurate than others such as the more used BMP280.
However as Matek F722-miniSE is listed under INAV recommended hardware I am assuming others aren't having this issue.

Anyone have any suggestions why nav_rth_alt_mode set to AT_LEAST is not working for me?

Diff All below.
Thanks
Jack

diff all

version

INAV/MATEKF722MINI 3.0.0 Jun 12 2021 / 12:44:48 (3c7b1b7)

GCC-9.3.1 20200408 (release)

start the command batch

batch start

reset configuration to default settings

defaults noreboot

resources

mixer

mmix reset

mmix 0 1.000 -1.000 1.000 -1.000
mmix 1 1.000 -1.000 -1.000 1.000
mmix 2 1.000 1.000 1.000 1.000
mmix 3 1.000 1.000 -1.000 -1.000

servo mix

servo

safehome

logic

gvar

pid

feature

feature GPS
feature PWM_OUTPUT_ENABLE

beeper

map

serial

serial 0 32 115200 115200 0 115200
serial 2 2 115200 115200 0 115200

led

color

mode_color

aux

aux 0 0 2 1900 2100
aux 1 1 0 900 1100
aux 2 10 0 1900 2100
aux 3 11 0 1400 1600
aux 4 3 0 1400 1600
aux 5 5 0 1400 1600
aux 6 30 1 1900 2100

adjrange

rxrange

temp_sensor

wp

#wp 0 invalid

osd_layout

master

set looptime = 500
set gyro_main_lpf_hz = 110
set gyro_main_lpf_type = PT1
set dynamic_gyro_notch_enabled = ON
set dynamic_gyro_notch_q = 250
set dynamic_gyro_notch_min_hz = 120
set acc_hardware = MPU6000
set acczero_x = 78
set acczero_y = 6
set acczero_z = -363
set accgain_x = 4090
set accgain_y = 4077
set accgain_z = 3997
set align_mag = CW270FLIP
set mag_hardware = HMC5883
set magzero_x = -32
set magzero_y = 59
set magzero_z = -54
set maggain_x = 553
set maggain_y = 570
set maggain_z = 453
set baro_hardware = DPS310
set blackbox_rate_denom = 2
set motor_pwm_rate = 16000
set motor_pwm_protocol = DSHOT600
set motor_poles = 12
set failsafe_procedure = RTH
set model_preview_type = 3
set applied_defaults = 2
set gps_ublox_use_galileo = ON
set airmode_type = THROTTLE_THRESHOLD
set nav_rth_altitude = 5000
set nav_mc_hover_thr = 1225

profile

profile 1

set mc_p_pitch = 44
set mc_i_pitch = 75
set mc_d_pitch = 25
set mc_i_roll = 60
set mc_p_yaw = 35
set mc_i_yaw = 80
set dterm_lpf_hz = 110
set dterm_lpf_type = PT1
set dterm_lpf2_hz = 170
set dterm_lpf2_type = PT1
set d_boost_factor = 1.500
set antigravity_gain = 2.000
set antigravity_accelerator = 5.000
set setpoint_kalman_enabled = ON
set setpoint_kalman_q = 200
set tpa_rate = 20
set tpa_breakpoint = 1200
set rc_yaw_expo = 70
set roll_rate = 70
set pitch_rate = 70
set yaw_rate = 60

profile

profile 2

profile

profile 3

battery_profile

battery_profile 1

battery_profile

battery_profile 2

battery_profile

battery_profile 3

restore original profile selection

profile 1
battery_profile 1

save configuration

save

[JulioCesarMatias]

Am I right in thinking that Poshold uses GPS for altitude control as well as for 2D position. Full 3D fix?

In multirotor mode the GPS altitude is not used.

[jackwca]

Many thanks for your reply.
Having looked at https://github.com/iNavFlight/inav/blob/master/docs/Navigation.md. It appears that POSHOLD is full 3D GPS fix.
ALTHOLD and RTH both use the barometer for altitude control.
I am assuming that there is a reason why altitude is implemented differently between these.

[JulioCesarMatias]

Anyone have any suggestions why nav_rth_alt_mode set to AT_LEAST is not working for me?

I recommend you update to the new version 3.0.1 >> https://github.com/iNavFlight/inav/releases/tag/3.0.1

[jackwca]

Many thanks for the suggestion. I just tried today with this latest version.
Very interesting, this gave the exact same results as when I first built and ran the quad with 3.0.0.
Which is, the first attempt at RTH seemed to work as expected. Although with a couple of meters horizontal over shoot at the home position which it managed to auto correct.
However after this first attempt I could not stop it from just doing a run away climb. Even after a full chip erase multiple times. Which doesn't make sense to me as I assume a full chip erase is "Full".

POSHOLD was a little more drifty than I remember the other version to be. Though I will try recalibrating tomorrow.

[A2BELE]

Hi jackwca,
I fly similar quad same problem as have many others. I have a program change suggestion modify RTH climb program so that it can only climb at a fixed rated. Also instead of climbing to an altitude climb for X seconds with motors at X speed. Say 5 secs at 2000 or something.

The issue with current Failsafe is that it doesn’t Failsafe, it needs everything working perfect to perform a set task.

Otherwise
1)It’s not the baro, ive done back to back testing without foam. No problem. ( i still run foam for safety)
2) Props, my 2 blade props cause vibrations the 3 blades don’t. (Back to back testing)
3) Known issue of the baro not being zero. This can be fixed by runnning SD card in FC and i believe 3.0.1 addressed this anyway.
4) ESC protocol / vibration back to to FC.

I’ve slowed down the althold climb rate. Which works but i think this also affects the decent rate once the quad is back home as it seems to now just sit over head. (More testing required)

Still lost, may have to work out how to program these things!

[jackwca]

Many thanks for your response and interesting suggestions.

I have been looking at the telemetry sent back during inflight. The "GALT" seems to show a reasonably accurate GPS reading above sea level. The "ALT", which I assume equals the blue Alt line on the barometer graph of the sensors page in the configurator, doesn't appear to always be accurate. Sometimes it appears to get pulled to zero even when in flight. This may suggest why it performs a runaway climb on RTH if it is getting pulled to zero.
It would be interesting if I could get the actual baro readings sent in telemetry. I believe I can get this post flight with the black box data, although I have only dipped my toes into this.

v3.0.1 didn't appear to solve the baro sensor climbing due to board thermal stabilisation.
It created the same results as when I first built the quad as described in one of my above replies.
I am using the Matek F722-miniSE which doesn't have an SD card but does have onboard flash memory.
This board is using a dps310 barometer, does this barometer have as much success as other more used barometers?

I shall try again tomorrow and see if I can get some black box data.

[jackwca]

Black box attached showing run away climb after RTH initialised with "AT_LEAST" RTH altitude mode selected.

blackbox_log_2021-07-17_135014.txt

Quad is stable during "poshold" and with RTH with "Current" RTH altitude mode selected.

[jackwca]

Anyone else having this same situation? I am still having the same issue.

I just lost another frame after it shot into oblivion. Glum Face.
Strangely I had it set to RTH at current altitude, which has normally worked.
I couldn't get it to stop shooting up even when switched to poshold with idle stick. In the end I disarmed as it was too far to see.

I was trialling the Mateksys Optical Flow & Lidar Sensor, to see if that would improve stabilisation with the surface mode.

[A2BELE]

Set you climb rate slower and try different props. That is what finally worked for me