New features to consider - rotorflight/rotorflight GitHub Wiki

❗ This page is outdated

Rotorflight Wiki is replaced by www.rotorflight.org.


Features ranging from easy to hard

Based on 1018 version

1. LPF on collective-to-yaw compensation (WORKS!!):

I noticed that the helicopter tail does not always lock well enough during fast collective changes. The compensation seems to be always too fast (a bit counterintuitive ngl.) The theory is that the compensation should apply to main motor torque. Because there is a significant delay in the motor governor loop, the tail won't need compensation until a bit later. Adding a LPF on collective-to-yaw, specifically the output of the pre-comp (not the input collective position used to calculate the pre-comp) shouldn't take too long and would be easy to test. Ideally, the low pass filter should simulate the delay from the governor loop. If we want it to be more adventurous, we could try both the normal compensation (for motor&gear inertia) and the LPF compensation (for motor torque)

1.5. LPF on cyclic-to-yaw compensation (WORKS!!):

similar logic to collective-to-yaw, adding a LPF with the same cutoff should suffice.

2. Tail geometric compensation:

It's a common fact that with higher collective pitch the more sensitive the tail is. We could use a simple $-\alpha (output)^2 +1$ formula for the overall output of the tail to see if there's any improvement.

3. Cyclic geometric compensation:

It's very noticeable that the cyclic is more sensitive when the collective pitch is large. We could use a similar $-\alpha (collective)^2 +1$ geometric compensation for the cyclic to see if there's any improvement.

4. LPF on collective-to-pitch compensation:

Similar to #1, I believe that the collective-to-pitch compensation might be too fast because it essentially compensates the windspeed on tail. Adding a weak LPF could smooth it out and should be easy to test.

5. ABSOLUTE FLAT DISK piro compensation:

Some helicopter when pirouetting, the disk will stay flat in one yaw direction but not flat in the other yaw direction. There is also a difference in magnitude with positive vs. negative collective pitch. I believe that this is due to the tail blowing into the rear right side of the main rotor (for normal helis at least,) which creates more lift there. Therefore, for example, when the collective pitch is positive, CW yaw piro would result in the heli tends to roll right and pitch down. When the collective pitch is negative, the heli would tend to roll left and pitch up. The opposite applies to CCW motion to a different degree. There should also be a difference with positive and negative collective because if the wind from tail is blown away by the main rotor (at positive collective most likely) the effect is reduced compared to negative collective. Therefore, I propose a formula to add to roll & pitch feed forward:

$$ FF_{roll} = \alpha(coll) \times coll \times yaw \ output$$

$$ FF_{pitch} = \beta(coll) \times coll \times yaw \ output $$

$$\text{where } \alpha(coll) = \alpha \quad if \quad coll \geq 0, \quad = \alpha \times \gamma \quad if \quad coll < 0 $$

$$\text{and } \beta(coll) = \beta \quad if \quad coll \geq 0, \quad = \beta \times \gamma \quad if \quad coll < 0$$

There is one concern however, at very high positive collective, the effect from tail blades to main blades might be too small. Therefore, a "ceiling" on the POSITIVE collective input might be needed. i.e.

$$ usable \ coll = \text{min} [ coll, \ coll_{maximum}]$$

6. TTA feedforward

It is noticeable that the CW stop with motorizes tail is soft. This is potentially due to that the TTA only increases the governor target rpm, which takes time for the governor to react. It would be more ideal if TTA can give a feed forward or even boost on the main rotor rpm so that the stop is fast and sharp.

7. Motor torque approximation for yaw compensation

It should be possible to estimate the motor torque for yaw compensation using only throttle out and rpm data. The motor torque should be roughly proportional to $RPM_{ideal} - RPM_{real}$ where $RPM_{ideal} \propto throttle$

A fancier version could use the voltage telemetry if its fast enough. $RPM_{ideal} \propto throttle \times voltage$. However, at that stage we might as well use the current telemetry data.

8. Motor torque approximation using high speed current telemetry

If high speed current telemetry is available, we could use this formula $power \propto torque \times RPM \propto I\times V$, therefore, $torque \propto \frac{I\times V}{RPM}$. If we do not have high speed voltage sensor, we could assume that voltage is constant, thus $torque \propto \frac{I}{RPM}$

9. Separated Rate Smoothness (SOLVED)

The cyclic, collective, and tail rate smoothness should be adjusted separately.

10. Tail HSI

It's noticeable that the vbar has way better rotation consistency with the tail. We could implement a second I-term for the tail that reverse its direction when the heli rotates 180 degrees. This term is a vector and it detects windspeed when it is rotating fast. If the tail is not rotating, we should use some technique to let it "forget" its memory. One way to do it is to bleed out the x-direction (perpendicular to the heli side frame) term into the normal I-term using a constant exponential decay, and simple decay out the y-direction (along the forward & backward) term with the same decay rate. This way if the heli is spinning, there is enough charge to balance the decay rate and have an effect.

In addition, similar to main rotor HSI, the tail 'airspeed' vector should also bleed out into the normal I-term in the cyclic input direction so that it won't keep the charge when the heli is flipped 180deg.

11 TTA optimization

Since the tail output is to provide torque in the yaw direction, I do not think a constant "P" gain in the main motor would satisfy the requirement. The torque on yaw axis should be proportional to the main motor acceleration in most cases. Therefore, we should add an "I-gain" to the TTA calculation. To implement, we would have a "integration pool" which sense the full range of tail output. If the tail motor is at the exactly 0%, nothing would get charged into the pool. If the tail motor required is less than 0, the pool charges it positively. If the tail motor requires is more than zero, the pool is negatively charged. (Which is very similar to the integral calculation. Just replace the error to the tail output centered at 0% tail motor). The only big difference is that the pool can only increase the main motor speed. Which is similar to the "error limit" but with only one direction that is equal to zero. This logic plus the normal "P" term should be able to provide a crisp and reliable tail and reduce the chance of loss of control in most cases.

Advanced idea: since we know that we could estimate the main motor torque using rpm measured and governor output, maybe we could use this logic to implement TTA to control the main motor torque directly?

12 Governor Gain Scheduling

The current governor works well in most scenarios. However, it tends to oscillate when the collective pitch on the helicopter is very low. This is essentially a system with a lot less damping. I propose that we should have a D-gain scheduling on the governor. At zero collective, since the natural damping is low, we should add more digital damping to stabilize the rpm.

13 High Speed Gain Compensation

The lift of the blade is a function of velocity squared. For example, at very high speed forward flight, the pitch input would have much higher (mechanical gain). This creates a much more responsive reaction to the heli which could make it difficult to control. One solution would be to use gain scheduling on the output cyclic gains depending on both the magnitude of HSI in the stick direction and the magnitude of current Integral (since during very fast flight the integral is probably charges a lot as well). Another solution might be to increase the amount of geo-correction on the main rotor at very high collective. However, we need a lot more testing and analyzing to find a good solution here.

⚠️ **GitHub.com Fallback** ⚠️