This video explains the FeedForward improvements in Betaflight 4.2. FeedForward pushes the motor in advance according to the change of the joystick setpoint. It does not have to wait for the error between the actual gyro and the target before the P term responds, so it can improve the chirality; however, the jitter of the receiver data packet will turn the input that should be smooth into a sudden jump, causing a FeedForward spike. 4.2 Mitigated by setpoint interpolation, averaging, smoothing and spike limiting.
Why FeedForward can respond before P
With PID alone, a stick movement first changes the target angular velocity while the actual gyro reading is still zero. P must see an error between target and actual motion before producing output. FeedForward directly estimates the required control action from the rate of setpoint change. It can intervene before actual motion falls behind, making fast commands track the sticks more closely.
Its main role is response to pilot input. It does not replace closed-loop P/I/D corrections for disturbances and attitude errors. Too little FeedForward feels sluggish; too much, or an unsmooth input, can cause sharp motor actions. Evaluate setpoint, gyro, FF, P, and motor traces together.
How packet jitter creates FF spikes
The video uses R9 and Crossfire as examples. Ideally, a linear stick movement makes RC/setpoint progress from 1500 through intermediate values to 2000. If packets are delayed or lost, the receiver temporarily holds the previous value, then jumps to a newer value in one step.
FeedForward responds to the rate of change. Compressing the same total change into one time slice increases the calculated instantaneous rate, producing FF spikes, sudden motor actions, and roughness near stick center. The problem is not necessarily a low average packet rate, but uneven arrival times and setpoint steps.
Interpolation and averaging modes in 4.2
In the recorded version, feedforward_interpolate_sp provides OFF, ON, AVERAGED_2, AVERAGED_3, AVERAGED_4, and other modes. The video interprets ON as essentially no additional averaging. AVERAGED_2 smooths using two FF/setpoint data points, while 3 and 4 use longer windows. A longer window makes a single step less likely to create a spike, but also makes the response gentler.
The author found that AVERAGED_4 significantly improved flyability on his R9/Crossfire aircraft at the time. That is an experience from Betaflight 4.2 in 2020 with particular links and aircraft, not a current universal preset. Modern Betaflight FeedForward, RC smoothing, and parameter names have evolved. Start with current documentation and defaults.
Balancing response and smoothness
First record Blackbox logs with default settings. Use regular small stick movements and fast rolls to compare setpoint steps, FF spikes, gyro tracking, and motor output. If uneven input arrivals cause spikes, gradually increase interpolation/averaging or adjust Smooth Factor or Spike Limit, changing only one variable at a time.
Racing may favor less smoothing and shorter windows to preserve response, provided the aircraft does not twitch, motors do not overheat, and gyro tracking remains clean. Do not disable all smoothing simply to be “faster,” or use a very long averaging window to hide a receiver-link fault. Update and correctly configure the receiver first, then verify in a safe environment.
Operation steps
- Understand the roles of P and FeedForward
P responds to target error; FeedForward responds to setpoint changes. First establish whether the problem is sluggishness or input spikes.
- Check whether RC/setpoint updates arrive evenly
Use Blackbox to see whether a smooth stick movement produces an old value held steady followed by a sudden jump.
- Identify FF spikes caused by steps
Align setpoint, FeedForward, gyro, and motor traces to check whether a twitch coincides with one large step.
- Start with the current default mode
Historical 4.2 options include OFF, ON, and AVERAGED_2/3/4. Consult current documentation for today’s names and algorithms.
- Add only the minimum smoothing needed, gradually
Adjust one of the averaging window, Smooth Factor, or Spike Limit at a time, then repeat the same input for comparison.
- Recheck fast maneuvers and small movements near center
Check both roll response and smoothness near stick center, and monitor motor temperature.
FAQ
What is the fundamental difference between FeedForward and P?
P needs an error between target and actual motion. FeedForward produces output in advance from setpoint changes, making it faster but also more sensitive to abrupt input steps.
Why can packet loss cause a sudden twitch?
The receiver may hold the old value, then jump to a new one. When the change is compressed into a very short time, FeedForward calculates a larger spike.
Should I simply use AVERAGED_4?
Do not copy it blindly. That was the author’s experience with Betaflight 4.2 and particular R9/Crossfire links. Current algorithms, receivers, and aircraft may differ.
Is a longer averaging window always better?
No. A longer window suppresses spikes but also softens response and may add delay. Use only the minimum needed to solve the problem.
Can FeedForward smoothing hide a faulty receiver link?
No. Check firmware, protocol, packet rate, and link stability first, then use smoothing for the normal jitter that remains.
Full timeline transcript
Transcripts are arranged according to video time, making it easy to quickly locate the explanation content. Transcript language: Simplified Chinese.
The second new feature I want to discuss is FeedForward. First, a disclaimer: I am not trained in industrial control, so professionals, please forgive any imprecise explanations. This is my understanding. To understand the new feature, we first need to understand how FeedForward works, right?
Originally there was no FeedForward parameter, only PID. What problem does PID have? With no radio input, it works fine. For example, if a gust turns the aircraft away from its intended attitude, PID can stabilize it and maintain that angle. But when there is radio input—
—we encounter a problem. Suppose I move the stick to command clockwise rotation at 50 degrees per second. After the movement, the flight controller’s PID loop first sees the requested 50-degree rotation rate. What is the actual angular velocity? It is 0, so there is a difference of 50 degrees—
—and P must now start working to produce that 50-degree rotation, which gradually begins. There is some delay. Where does it come from? First I move the stick, then an error appears, then the PID terms respond. There is a delay in between: must I wait for the error to appear before PID can work?
But when we detect the stick movement, we already know P should kick in. Is there a way to make the control action start earlier? That is FeedForward, or FF: FeedForward acts ahead of PID. This can greatly improve the aircraft’s response speed. But it has a problem. What problem?
It is particularly noticeable with R9 or Crossfire. I use R9 myself. Before 4.2, I noticed that when I moved the sticks left and right around center, the aircraft’s response was extremely rough, almost as though there were sand in the motors.
With tiny stick movements around center, the aircraft would twitch badly. Why? The chipsets used by R9 and Crossfire have an issue: at a somewhat greater distance—and even close up, though less noticeably—the packets—
—arrive at very uneven intervals. Suppose I move the stick from center all the way to one side. RC goes from about 1500 to 2000, right? Assume it takes five time slices. In the first time slice, it is 1500—
—then 1600 in the ideal case, then 1800, 1900, and 2000. Ideally, the flight controller should receive a signal from the receiver that gradually progresses from 1500 to 2000, assuming we move the stick at a linear rate. That is ideal; what happens in practice?
In practice, the first time slice starts at 1500. It begins at 1500, but the next time slice still reports 1500 because an intervening packet was lost. The receiver does not stop outputting a signal, because that would look like a lost link. Instead, it outputs the last signal it received, assuming it has not changed: still 1500, still 1500—
—then suddenly one thousand nine hundred, two thousand. What happens? A change from one thousand five hundred to one thousand nine hundred that should have taken four time slices now happens in one. In a single time slice it rises from one thousand five hundred to one thousand nine hundred. FeedForward measures how fast the signal changes, so this greatly magnifies its calculated value—
—and a large FeedForward value makes motor response too strong, causing twitching and roughness. Now that we understand the problem, how does the new 4.2 feature help? One especially useful parameter is FeedForward Interpolate SP.
This parameter introduces new FeedForward operating modes. OFF disables the new mode. My understanding is that ON is like 4.1: enabled but without smoothing. A time slice or frame arrives—not an RC frame, but another internal signal frame called a setpoint—
—which we can think of simply as an RC frame. A frame arrives, its value changes, and I use the FeedForward value directly. If the signal is uneven, that still causes a problem, right? That is why other modes exist, such as AVERAGED_2. AVERAGED_2 averages two FeedForward values, then feeds that averaged value into the FeedForward system.
Similarly, AVERAGED_3 and AVERAGED_4 average three or four FeedForward data points, respectively. That average enters the FeedForward system and drives the motors. For R9 or Crossfire, AVERAGED_4 works relatively well. Before 4.1—before 4.1, my R9 aircraft was unflyable. In 4.2, using AVERAGED_4 made it flyable and fairly smooth.
There are other parameters too, such as Smooth Factor and Spike Limit, which you can adjust. For racing, generally less filtering and a shorter averaging window are preferable, provided they do not harm how the aircraft flies: it must not twitch. That is the introduction to this new feature.
