Add functionality to store an error log / flags.

This is similar to the blackbox events, but is only storing rarely happening (error) events.

This error log should be then available in the Configurator, without the need to load the log files in the BB Explorer.

Some events / flags that we would like to have:

• Voltage low / critical
• Low / Lost RX signal
• Failsafe events
• RPM signal errors
• Vibration level errors (excessive vibes etc.)
• HW faults

Add a function for auto-tuning the collective / cyclic / tail feedforward in the main rotor governor.

Describe the bug
Blackbox is not found with this FC.

To Reproduce
Flash 4.2.12 20220401; Apply Defaults; BB not found
Flash Betaflight 4.3RC5 - BB chip found

Expected behavior

Screenshots

The current CRSF / ELRS is very limited for helicopter use.

An alternative should be considered how to pass telemetry sensors to the Tx.
One option is to use the "Ardupilot FrSky telemetry passthrough", which is sending FrSky telemetry information with custom CRSF frames. This can be decoded by a LUA widget in the Tx.

It appears that the RX configuration in Rotorflight is getting corrupted with ELRS.
This seems to happen when modelmatch settings are changed.

This is resulting the Rx protocol changing to DSM2/X + inverted.
And other Rx parameters changing to zero or random values.

Triage found evidence of ELRS Tx sending MSP_SET_RX_CONFIG, which is likely sent to the FC accidentally.

Discussion with ELRS ongoing.

Describe the bug
I think PT1 filter gain formula is wrong

float pt1FilterGain(float cutoff, float sampleRate)
{
    float omega = tan_approx(M_PIf * cutoff / sampleRate);
    float alpha = 2.0f / (1.0f / omega + 1.0f);
    return alpha;
}

I was courious how it works, so I've calculated some results and compared to previous version

float pt1FilterGain(float f_cut, float dT)
{
    float RC = 1 / (2 * M_PIf * f_cut);
    return dT / (RC + dT);
}

I noted that characteristics is slightly diferrent, especialy if the cutoff is above 0.1 of sample rate. And at the 0.25 of sampling rate is equal 1 and raises.

Expected behavior
PT1 gain shouldn't exceed 1.0, on a picture below you can see, that it equals 1 at 0.25 of sampling frequency. On the second picture you can see that filter starts oscillating if k > 1.

Screenshots

Additional context
I don't know why PT1 filter gain formula is diferrent than in Betaflight. But if I modify it slightly to

float alpha = 1.0f / (1.0f / omega + 1.0f);

then gain is lower than 1 for cutoffs below nyquist.

Here is the link with my calculations https://docs.google.com/spreadsheets/d/1Nv-octpMxmQeqS8wSkmaLvypIiryuTpIMJ8j50X9rwg/edit?usp=sharing

I hope this helps.

At the moment we have BLHeli (KISS) telemetry and Hobbywing V4 telemetry.

We should add more protocols. Possible candidates are:

• Hobbywing V5
• Kontronik
• Scorpion
• Castle
• YGE
• ExBus
• MultiPlex

Hi there,
I am also try to develop helicopter mode base on BF.
First thing I did is Software-in-the-loop, I think it may help you.
Video here, with a helicopter in RealFlight and my branch of betaflight.
https://youtu.be/1nEuF6Eeu2Q

Code for bridge:
https://github.com/xuhao1/RealFlightBridge

My branch for BF:
https://github.com/xuhao1/betaflight/tree/heli

SITL for BF:
betaflight/betaflight#11304

Servo tail should benefit from TTA as well.

The variable pitch tail / servo is always slower than a motorised tail / main rotor torque, which means we can help it with TTA with fast moves.

It would need to work differently from the motorised tail TTA.

This would mean using TTA for high-pass filtered yaw, and the variable pitch for low-pass filtered, or something like this.

This would need to be investigated, as this is just an idea.

When the disarmed throttle and 0% throttle output in the esc page is set to around 500us, if I perform a dump, the value would be reset because RF thinks it’s corrupted.

Add support for measuring more voltages, other than just the battery.

The MCU is likely to have free pins on the ADC, so they could be as well connected as voltage measurement inputs,
for measuring whatever voltages we have on the FC.

For example:

• Servo bus voltage and current
• +5V regulator voltage / current (if present)
• Any other voltages

A low voltage 12s pack can still be recognized as 11s even if cell count is set to 12

The collective to tail feedforward is not working well enough in some setups.
Investigation needed + a better FF algorithm.

Fix GPS_RESCUE to work with separate collective / throttle.

At the moment the code assumes that throttle is the up/down control.

Allow using PWM for the main motor and Dshot for the tail motor. Or any other combination.

One improvement to the rescue mode would be rate of change limiting (negative direction) on return from rescue mode...... The issue is if you rescue from inverted and it rolls to upright --- if you don't raise the collective stick before you exit rescue mode it will immediately pitch down negative to match your collective stick position (can be really rapid). It would be good to rate limit the reduction in collective until the collective command >= rate limit. I'm thinking this would be more of an issue if/when auto rescue based on baro was implemented.

Due to fluctuations in the PID loop speed, the RPM filtering is sometimes 1-2% off the correct frequencies.

The information whether the heli is actually in the air and flying, is needed in many places in the FC.

A reliable method for detection this is required.

Add functionality to measure and report vibration levels.

Calculate and report the following:

• Main rotor harmonic levels in the gyro signal (1,2,3,4)
• Tail rotor harmonic levels in the gyro signal (1,2)
• Motor vibration level
• Remaining total vibration level in the filtered gyro signal
• Exact frequency of the main motor and tail motor

This can be used also for fine-tuning the RPM input / filters.

It may be possible to detect one-way bearing detach from this too (in autorotation).

The BF4.3 system is hard limited to 18 channels. But then some Rx systems, like SXRL2 has 32 channels.
This is causing a array overflow and memory corruption.

If the throttle is connected to a servo (nitro / gassers), the direction need to be reversible.

Add temperature logging to BlackBox. Including MCU temp and ESC temp(s).

Add a function for auto-tuning the collective / cyclic to tail feedforward.

Hi,

I'm just setting up my first rotorflight helicopter and I wonder, why dynamic notch is disabled USE_GYRO_DATA_ANALYSE . Is it problematic in helicopter configuration or rather you plan to enable it later? i think it will do a good job in setups without rpm measurement.

09f4271#diff-d33783862cc8c9583b6f155ba705b5272895c781f296766d05122b94f77a3e2fR303

Thanks, I really appreciate your work, looks promising, good job ;)

TTA with GOV Passthrough does not work unless the Full Headspeed is set, and there the TTA headroom is also set.
Obviously passthrough should not need the HS, so the headroom calculation should use some other logic.

There should be an easy way to adjust the levelling trim inflight.

Right now it's only available in the Configurator, which is a hit-and-miss approach.

Develop / fix the rescue altitude hold function.

Add a governor feature for the tail motor, to be used with a variable pitch tail running on a separate motor.

Some ESCs are providing more data than the FC can use at the moment.
The ESC telemetry support should be extented to handle this.

Refactor the LED indications, for better match with RF and helicopters.

Serial pin swap should be possible to do in the Configurator without CLI commands.

The governor has been designed to work with throttle on switch, expecting the throttle level to jump from a very low value to a high value. Slewing the value (throttle on stick) is not working totally smoothily.

The governor should be refactored with this in mind.

Replace the tail motor idle throttle with a proper speed governor, not unlike in Betaflight.

This will help slowing down the tail motor, as the throttle can temporarily drop to zero, as long as the motor is still rotating.

The only parameter needed is the minimum tail motor speed.

Internally, a PID controller is needed.

The mixer page has a value for setting the scaling of the collective and cyclick.

Currently this scaling affects both positive and negative.

It would be very advantages to allow the scaling to be separated for positive and negative. This would essentially allow absolutely identical collective to be configured.

As soon as there are more than 100 log files stored on the internal flash memory of the Matek G474-HELI, activating Mass Storage Device Mode won't work anymore. Other FCs don't seem to have this problem.

Work-around: click on Save to file on the Configurator to download all log files as one big file.

A method is needed for giving visual indications, other than LEDs. Most people seem to hate the buzzer, so the same indications should be available visually. Maybe with swashplate jerk or similar.

Helicopters have much more vibrations than drones.

The current filtering for ACC is in adequate for helicopters.
It should be improved, possible with notch filters just like the gyro.

Hi,
I'm looking at the code and have a tiny doubt.
In the filter.c https://github.com/rotorflight/rotorflight-firmware/blob/master/src/main/common/filter.c#L109 there is a fragment

void biquadFilterInitBessel(biquadFilter_t *filter, float filterFreq, uint32_t refreshRate)
{
    biquadFilterInit(filter, filterFreq, refreshRate, 0, FILTER_BESSEL);
}

then later in https://github.com/rotorflight/rotorflight-firmware/blob/master/src/main/common/filter.c#L118
there is

void biquadFilterInit(biquadFilter_t *filter, float filterFreq, uint32_t refreshRate, float Q, biquadFilterType_e filterType)
{
    ...
    const float alpha = sn / (2.0f * Q);

The 4th parameter Q is set to 0, I wonder how is that possible that MCU do not crash here with division by 0 exception? ;)
According to this article https://hackaday.com/2018/11/21/creating-black-holes-division-by-zero-in-practice/ division by 0 is allowed in floating point operations, but result in NaN. Technically alpha is not used in bessel variant, but you never know when it might kick us :)
Personally I'd use 1.0 here, just for sure. If you want, I can prepare PR.

Add a new flight mode ALTITUDE_HOLD.

As the name suggests, the altitude is stabilised and kept constant, while the collective stick is centered.
Off-center collective would cause climb/decent, with a speed indicated by the collective stick deflection.

This flight mode can be used together with ACRO, ANGLE, HORIZON and TRAINER modes.

When more than 100 files are stored on flash memory, only the first 100 can be accessed when you activate Mass Storage Device Mode. I think it has to do with EMFAT_MAX_LOG_ENTRY, which is also 100.

Work-around: you can access all files by clicking Save to file in the Configurator. This takes a while and results in one big file, where each individual log file is a part.

1. The main distinction of nitro engine is that it requires an "idle" mode where the motor spins slowly and the clutch is not engaged. For simplicity, I believe that the "Arm" switch should be safe enough to enable the "idle" mode where a significant effort is required to start the engine (glow plug and starter) so that safety should not be a concern here.
2. The idle mode needs some special attention. Let's say that we want idle mode enabled when the FC is armed but the throttle is still on hold. There should be an easy way to trim the idle output position (either by a trim knob or some people like to use the collective stick to output throttle position directly.) It is necessary because due to the different weather, fuel, temperature, the ideal idle throttle position might be slightly different.
3. There is a problem with starting the motor as well. I found that the "start up" and "spool up" logic fails here since the rpm will have valid readout as soon as the motor is in idle. In addition, I found that at low rpm output, especially when the clutch is not engaged yet, the governor could be over-gained which results in rpm oscillation during spool up. Some ways to fix it is to engage PID loop after the output throttle or RPM has reached a minimum level to ensure the clutch is engaged.
4. There is a notion that for nitro to work well, the output throttle should not be lower than a certain value. Therefore, we should have a "min output throttle" similar to "max output throttle" we currently have.
5. (optional) Since nitro usually requires a lot of gov feedforward to work properly, it would be nice to have a way to visualize the gov FF effect on the throttle servo. One way to do it is to enable throttle FF when throttle is active and the spool up is completed even though the motor is not spinning.

Provide ESC setup / programming functionality using the Tx via bidirectional telemetry on par with other modern R/C systems.

As heli pilots we are accustomed to being able to setup (set BEC voltage, change rotation, set cutoff behavior etc.) and tweak at the field (ESC internal gov gains etc). A growing number of ESCs support this functionality.
Support in RF.

Let's compose a list here.

Add an option to log all ESC telemetry data to BB.

Currently the RPM sensor is limited to one sensor input per timer.

With T2 or T5, it should be possible to have 4 RPM inputs per timer.

TTA function is likely to be beneficial to a bidirectional tail motor.

Changing the direction is slow, it can take up to 250ms for the motor to stop and then start in the other direction.
Meanwhile, TTA could take care of the tail torque control.

This requires development, evaluation and testing.

I was wondering did we removed the OSD features/target on the devel rotorflight 2.0

I was following the wiki page to set up OSD, but it OSD_CS, and max7456 came out to invalid in CLI, so I'm assuming it got removed at some point.

resource OSD_CS 1 A15
feature OSD
set max7456_spi_bus = 3

https://github.com/rotorflight/rotorflight/wiki/Adding-OSD-support-for-FPV-Setups

The yaw inversion is done before the rcCommand is calculated, which means the rcCommand[YAW] is reversed.
The stick commands and OSD/CMS stick control are expecting it to be the normal way.

The inversion should be moved somewhere after the rcCommand calculation.

Refactor the RPM filter, for full autoconfiguration.

Detect the RPM peaks and their widths, and configure each notch filter automatically.
Do this separately for each axis.

Improve ELRS / CRSF telemetry to pass RPM and Temperature to the Tx.

This is a difficult problem, because the CRSF protocol does not have these telemetry values.