INAV Helicopter Support

[Woga65]

Intended for use with Heli-Quads, Chinook style Twin-Rotor-Helis and regular Helicopters.

Corresponding pull request for the Configurator: iNavFlight/inav-configurator

INAV Configurator 6.1.0 for Variable Pitch Aircraft live preview: INAV Configurator 6.1.0_vari-pitch

*_VP - target files are variable pitch while regular target files should behave like regular INAV. The *_VP - target files can also handle regular aircraft, albeit they are intended for use with Collective-Pitch aircraft. The *_VP - targets offer extended RC-Channel remapping to account for the COLLECTIVE + GYRO_GAIN RC-channels.

Latest changes

• added configurable PID scaling (CLI)
• added timer usage flags for helicopter (TIM_USE_HC_MOTOR + TIM_USE_HC_SERVO)
• prevent the use of turtle mode on helicopter-like aircraft
• ensure throttle is cut on failsafe (helicopter) this might change when RTH + AUTO-LAND are sufficiently tested
• separated helicopter altitude controller from multirotor altitude controller
• improvement of RC-channel remapping from the CLI
• improved the handling of variable-pitch targets in the Configurator
• NAV-ALTHOLD now confirmed working on (at least the developer's) Collective-Pitch aircraft
• prevent I-term from winding up on the ground while spinning up the blades
• reworked on-the-ground detection to ensure stability in the air + calmness on the ground
• added separate hover settings for NORMAL + IDLE-UP 1 + IDLE-UP 2 flight modes (CLI)
• added configurable soft spool-up feature (CLI)
• show the RPM per motor in the configurator's Outputs tab
• added support for different NAV-ALTHOLD modes (CLI)

Notes

• to make use of the *_VP targets, the matching INAV Configurator is needed (pull request in progress)
• 1500us on the collective-pitch rc-channel should result in a collective-pitch of 0 degrees
• when using BLheli_s, BLheli_32 or similar ESC, deactivate damped mode / braking and configure soft spool-up in the INAV CLI
• no pirouette compensation at this point
• governor in progress / coming soon
• D-gains should be very low: 1 or 2 (one or two) maximum. To mitigate this, there is a group of CLI variables named pid_scaling_factor_... which allow for PID scaling between 0 and 1 or 2. For the D-gain it is advised to set the scaling factors (for roll/pitch/yaw) to values between 0.1 and 0.05 so you have a finer grained resolution and can use Derivative values between 1 and 15 or 1 and 30 in the PID tuning tab of the configurator
• the P and D gains should be lowered with rising head-speed, this is what the Gyro-Gain RC-channel is for
• the Gyro-Gain RC-channel works kind of reversed: 1499 - 0 elevate gains | 1500 gains untouched | 1501 - 2000 lower the gains (more head-speed => higher value of the Gyro-gain RC-channel)
• the Gyro-Gain and Collective-Pitch RC-channels replace AUX3 and AUX4.
• CH7/AUX3 channel in the Modes Tab is internally forwarded to the throttle channel, which allows for switching between nav_hc_hover_collective_normal + nav_hc_hover_collective_idleup_1 + nav_hc_hover_collective_idleup_2 with the throttle (= flight-mode) switch. The values stored in the nav_hc_hover_collective_xxx CLI variables are used as a starting point for NAV-ALTHOLD.
• the soft spool-up time can be configured in the CLI: hc_rotor_spoolup_time (10 = default, 0 = soft spool-up disabled). Active on the ground, disabled in the air to allow for bailing out of an auto rotation.
• the behaviour of the collective stick during NAV-ALTHOLD can be configured in the CLI: nav_hc_althold_collective_type (STICK | MID_STICK | HOVER).

[mmosca]

I converted it to draft. This should prevent it being merged before you think it is ready.

I will try to have a look at this over the weekend.

[mmosca]

FYI; #9268 may simplify things for your pr, as you won't really need to define TIM_USE_VP_MOTOR / TIM_US_VP_SERVO on targets.

And unless you are space constrained (F411/F722) you can probably always enable USE_VARIABLE_PITCH (if it does not break the other modes in INAV)

Edit: Add #define USE_VARIABLE_PICTH to the list at the end or src/main/target/common.h if you need to enable it only for mcus with enough more than 512k flash.

[Woga65]

@mmosca PR #9268 looks interesting. If motors are assigned first, is there a logic in place that prevents a single motor assigned to a timer blocking more timer channels / outputs than needed? On helicopters there are few motors and lots of servos. In borderline cases the machine will be happy with servos only with one or two (logical) servos being (physical) motors.

[mmosca]

No, logic is simple. First come, first served, but I will add code to let the user override a timer and force it to servo or motor.

I plan on looking into supporting different output settings / timer.

That should allow us to support 760us tail servos and set update rates for the swash servos, independent of the tail as well.

[Woga65]

@mmosca Adding #define USE_VARIABLE_PITCH by default or for targets with enough memory space would enable the 8 RC-channel remapping feature system wide. I know this is strongly opposed by Pawel and some others because of this being confusing for some users. Ofc I could enable the extended RC-channel mapping for the helicopter platform only ...

[MrD-RC]

@mmosca Adding #define USE_VARIABLE_PITCH by default or for targets with enough memory space would enable the 8 RC-channel remapping feature system wide. I know this is strongly opposed by Pawel and some others because of this being confusing for some users. Ofc I could enable the extended RC-channel mapping for the helicopter platform only ...

It’s not necessarily that it’s confusing. Though I 100% think that it would be for new pilots. Its that it’s completely unnecessary for anything other than helis. No need to remap any channels above 4 on fixed wing or multirotors. Maybe for rovers?

[Woga65]

@MrD-RC I totally get it, that it is unnecessary for most platforms and confusing for beginners. This is why I implemented it on a per-target base rather than globally. Maybe it could be useful for Rovers, Ships, Submarines and expensive planes with constant-speed / variable-pitch props.

[Woga65]

@mmosca @MrD-RC I would like to get rid of most oft the #if defined(USE_VARIABLE_PITCH) compile time queries to make the code more readable and better to maintain. Same for TARGET.isVariablePitch in the Configurator.

This could be done, as Marcelo mentioned before, by adding #define USE_VARIABLE_PITCH globally or to src/main/target/common.h. For the moment the helicopter code fits well into the F722 memory.

Initially I have introduced those queries to keep my helicopter code as separated from the existing logic as possible. I am not having much time to do real in-the-air testing but also do not want to worry about breaking pre-existing stuff.

So what are your thoughts on this matter? What would be the best approach to get/keep things going?

[mmosca]

@mmosca Adding #define USE_VARIABLE_PITCH by default or for targets with enough memory space would enable the 8 RC-channel remapping feature system wide. I know this is strongly opposed by Pawel and some others because of this being confusing for some users. Ofc I could enable the extended RC-channel mapping for the helicopter platform only ...

It’s not necessarily that it’s confusing. Though I 100% think that it would be for new pilots. Its that it’s completely unnecessary for anything other than helis. No need to remap any channels above 4 on fixed wing or multirotors. Maybe for rovers?

A helicopter has 5 main controls, instead of the traditional 4 of plane. the 5 is the pitch of the blades. On traditional systems, without a fc this is handled on the radio with a mix with different curves for pitch and throttle, driven by the throttle stick.

To not have the extra channel for helis would probably need to bring all this extra helicopter specific stuf into inav. + different curves for different flight modes

The extra channel mapping for cyclic should probably be done in a similar way as it is handled for the 4 main channels, with a default value for channel 6 for cyclic. That is the default value for cyclic in helicopter setups, and channel 5 is problematic with elrs.

[Woga65]

@mmosca

To not have the extra channel for helis would probably need to ...

As it comes to me, I am absolutely fine with helicopters requiring at least six RC-channels plus probably extra channels for arming and fancy stuff. I would rather lose an RC-channel than having to deal with a software that tries to be helpful while at the same time making life more complicated.

... and channel 5 is problematic with elrs

Out of curiosity and because I am preparing to move to ELRS. What kind of problems occur with ELRS and CH5?

[mmosca]

Out of curiosity and because I am preparing to move to ELRS. What kind of problems occur with ELRS and CH5?

Channel 5 in elrs is 1 bit. Either on, or off and should be high when "armed", so not really useable for gyro gain. If you use an elrs rx outputting sbus or pwm, you can remap the channels and send another channel value as channel 5, but you are still supposed to fly with channel 5 set high.

My concern with the gyro gain is more to follow what is already there. I am not opposed to improving the existing functionality either. Plenty of gains that may benefit from being able to adjust more easily.

[mmosca]

I am still waiting for a stack small enough to test this on my m1.

Ali vendor sent me just the esc, instead of the stack I ordered. :/