Inav: 9" F7 multirotor fails to even lift off on 2.5 RC1

[leeph]

Current Behavior

Was previously running the latest 2.4 branch on my 3D printed multirotor, Matek F722-STD FC and 9" props. BLHeli_S ESCs running DShot typically. R9Slim+ receiver (ACCST, SBUS+Smartport).

All was fine under 2.4 config, I used the modes conversion tool to convert the 2.4 config to 2.5 and I also omitted the PIDs and filter config from 2.4 and went with the 10" 2.5 preset. The quadcopter arms OK and I switch to Angle mode but the motors seem to be stuck around 40% throttle and the multirotor will not even lift off at full throttle anymore.

I have checked motor and prop directions but since I've imported the mixer from 2.4 I don't see why anything would have changed in that regard. I tried copying the PIDs from my 2.4 config but the same issue persists.

Expected behavior

I expect the quadcopter to at least lift off the ground in Angle mode.

Suggested solution(s)

I have included my (working) 2,4 and (broken) 2.5 configs here for reference.

iNav 2.4 diff all - https://pastebin.com/99J1crqr
iNav 2.5 diff all - https://pastebin.com/DgLkejXi

• FC Board name and vendor: Matek F722-STD with FCHUB-6S PDB
• INAV version string: INAV/MATEKF722 2.5.0 May 9 2020 / 15:08:50 (272de567d)

[digitalentity]

Are you not able to control throttle at all or throttle is capped at 40% and you can't increase beyond that? Can you record a blackbox log of non-working setup?

[leeph]

I know what it is... motor_direction_inverted has been set to 1 by default!

This rotor uses standard props-in configuration and as part of the upgrade process, iNav has defaulted to props-out. I see that the motor_direction_inverted parameter has replaced yaw_motor_direction, but should the default for this parameter not be props-in (0), really - since that is what the multirotor motor mixer diagram displays?

[DzikuVx]

@leeph INAV defaults motor_direction_inverted to OFF. The question is how it was set to ON. The most probable cause is that you flashed without Full chip erase. Please try flashing again with Full chip erase and check the value right after flashing.

[digitalentity]

@DzikuVx configurator settings probably still use the field to set yaw_motor_direction. https://github.com/iNavFlight/inav/commit/90e9f77a52db7d77aabee2762cb8d646f36086f8 didn't change MSP frame.

Presets would happily set yaw_motor_direction to 1 (legacy-compatible) which will result in motor_direction_inverted set to ON

[digitalentity]

So this is in fact a configurator bug that didn't fix the presets

[DzikuVx]

@digitalentity that is a good explenation!I will patch Configurator ASAP

[leeph]

Confirmed - after flashing with full chip erase, the parameter is defaulted to 0, but after applying the 10" preset, the value changes to 1.

[digitalentity]

@DzikuVx don't forget about backwards compatibility with 2.4.0 (Configurator should still correctly set the setting on 2.4 since we support the previous version as well)

[DzikuVx]

so we move forward! Cool. Probably we will need both Firmware and Configurator fix for it to make it robust

[DzikuVx]

For now I updated release notes with info not to use presets

[NasirHayat]

motor_direction_inverted

I can conform yaw spin issue in omnibusf4v3 inav 2.5 resolved with the change in cli
set motor_direction_inverted = Off

Thanks @DzikuVx

[leeph]

Well... for me this issue has been a bit of a red herring.

I've reverted the motor_direction_inverted parameter to off, but the quad still won't take off, in Angle or Acro. It's as if the throttle is limited somehow and it won't go beyond about 40%, even with the stick full high.

I will try re-flashing and setting up from scratch. I'm totally stumped.

[leeph]

I have re-flashed (full erase), not applied any preset, and only ported over the config snippets relating to accelerometer calibration, board alignment, serial ports, OSD & battery profiles & some telemetry parameters, plus the converted modes / aux statements. Everything else was left at iNav defaults, particularly relating to PIDs and filters, but the same issue persists.

In short, it's completely un-flyable with 2.5 RC1.

I've just reverted back to 2.4 latest and restored my original config and it flies perfectly again.

I have pasted the diffs from the old config and the new as part of the original bug report so, can the developers see anything in there that might be causing this, other than the motor_direction_inverted parameter?

[DzikuVx]

@leeph please record a blackbox log so we can see what is going on

[GregMichalski]

I am experiencing the same situation on a Kakute F7 v1.5 on a 5" quad. Full erased the board, and configured from scratch (no migrated diff). Props are run in the outward configuration so the motor_direction_inverted is supposed to be on. Did a line by line compare of the pre-update 2.4 CLI dump and the new 2.5rc1 dump and nothing stood out as in error to me.

Motors idle on arm, raise throttle and they spin up maybe a few hundred more rpm but additional throttle movement results in no change. RPY input will induce tilt/spin to the craft in the grass.

LOG00001.TXT
INAV_cli_KOPIS2_20200510_192459-2.5rc1-diff all.txt

[leeph]

Please find below blackbox log at 1/1 rate. This is just a single attempt at a lift-off in angle mode using 2.5 RC1.

LOG00001.TXT

I've just had a quick look using the Blackbox Explorer, and I don't know much about blackbox analysis but it seems strange that one motor is not registering / stays at 0%, but I can guarantee that motor is working and spinning the correct direction etc.

[DzikuVx]

@leeph @GregMichalski please test without THR_VBAT_COMP enabled. I have a feeling this is a case

[DzikuVx]

BTW, I'm marking it as a bug since seems like THR_VBAT_COMP breaks mixer throttle input

[leeph]

Yes - that's done it - it lifts and flies OK without THR_VBAT_COMP enabled.

I test flew with the 10" preset PIDs and they are far too aggressive, at least for my multirotor, visible oscillations. I have reverted to my 2.4 PIDs and it seems to fly great with those.

[GregMichalski]

@DzikuVx THANK YOU! That solved it for me as well. And I must say - I installed iNav 2.4 around April 21st and I could not fly on the default 5" GPS enabled PIDs and had to tune from scratch, and had gotten POSHOLD to an 'ok' state the week before 2.5rc1 was released. Your video on Sunday about the filtering improvements convinced me to give it a shot and now that I'm in the air I can say the new 5" Preset flew cleaner than my old 2.4 tuning. A little perturbation in POSHOLD after a full stick yaw rotation but I am sure I can clean that up easily!

[JurikRistjouw]

I know what it is... motor_direction_inverted has been set to 1 by default!

This rotor uses standard props-in configuration and as part of the upgrade process, iNav has defaulted to props-out. I see that the motor_direction_inverted parameter has replaced yaw_motor_direction, but should the default for this parameter not be props-in (0), really - since that is what the multirotor motor mixer diagram displays?

You Sir, saved the day! I thought it was a new default. I had the problem that right after takoff, the quad would yaw 'o death clockwise...

set motor_direction_inverted = off
fixed the problem

Please correct this in the final... would safe some innocent props that way

[JurikRistjouw]

@leeph INAV defaults motor_direction_inverted to OFF. The question is how it was set to ON. The most probable cause is that you flashed without Full chip erase. Please try flashing again with Full chip erase and check the value right after flashing.

I did full chip erase, still had this issue.

[DzikuVx]

fix in place, will be available in the next release