<p>The way the PID controller works is whenever the actual rate of rotation of the quadcopter does not equal the <em>setpoint</em>, or desired rate of rotation (which you set by moving the sticks), it sends a signal to the motors to compensate and bring the rate closer to the setpoint.</p>

<p>This signal is a sum of four <em>terms</em>: The P, I, D and FF. Since it's a sum, you can think of them as each pushing the quad in a certain direction independently, some terms adding up and others counteracting each other.</p>

<p>The P term is the difference between the setpoint and actual rate, multiplied by the P <em>gain</em>. So the amount of force applied by the P term is directly proportional to that difference. You can think of it as a spring that tries to move the quad back whenever it's bumped out of position. The further it's moved (bigger difference between setpoint and actual rate) and the stiffer the spring (bigger P gain), the stronger it will pull.</p>

<p>The reason why the FF term is needed is because the signal that the PID controller outputs influences the <strong>acceleration</strong>, not the speed directly. This means that the quad will not get up to speed immediately, but take some time depending on how hard it pushes itself. So when you want to sharply begin a maneuver you want the quad to apply <em>a lot</em> of force in that direction to get going and then sustain the rotation with a smaller force. </p>

<p>The PID controller, however, is meant for stabilizing. It does not distinguish between you bumping the stick and the quad being bumped out of position by an obstacle or gust of wind. So when you move the stick it "stabilizes" itself at the new speed as if you didn't move the stick at all and it was bumped by something instead. You can think of moving the stick as moving the other end of the spring that the quad is attached to. The spring doesn't care which end was moved, just that its length changed.
This means that the PID controller won't apply as much force to start the rotation as it potentially could, which means it is somewhat slow to speed up when you move the stick, and, more importantly, slower to slow down when you move the stick back to center (and can even overshoot).</p>

<p>You can make the reaction faster by increasing the P gain, but to a point, as higher P gains lead to oscillations, when the quad's movements lead to big P terms which in turn cause bigger movements and so on.</p>

<p>So instead the FF term was added. The FF term does not consider the current rotation rate at all, so it does not contribute to the PID loop's stabilizing action and is thus unable to cause oscillations. The only thing that it looks at is the sticks. The force applied by the FF term is proportional to <em>the rate at which you move your stick</em> (multiplied by the FF gain). 
So when you, for example, initiate a roll and bump the stick to the right, the FF term will detect the fast stick movement and give a burst of force to get the quad going. Then, when you finish the roll and return your stick back to center, the FF term will detect the opposite fast stick movement and apply a corresponding force, helping the PID controller stop the quad's rotation faster and avoid overshooting.</p>

CC BY-SA 4.0
2020-04-18T13:07:07.643Z
2020-04-18T13:15:57.480Z
2020-04-18T13:15:57.480Z
FlashCactus
<h1>30,000 foot view of feedforward as a general concept</h1>

<ul>
<li><p><strong>Feedforward</strong>: I hand you a closed box and you anticipate that it will be heavy, bracing yourself in preparation.  Your control of the box is rapid  and precise.</p></li>
<li><p><strong>Feedforward failure</strong>: I hand you a box and it's <em>much</em> heavier than you anticipated. Your control of the box is sloppy until you recalibrate and figure out how much it weighs.</p></li>
<li><p><strong>No feedforward</strong>: when your eyes are closed and all you know is that I'm going to hand you something. Could be a helium balloon, could be a dishwasher. You don't know if your arms will be pulled up or down, and so you're slow to react.</p></li>
</ul>

<h1>Feedforward in drones</h1>

<p>In the case of a drone which is rolling, a feedforward term lets you anticipate that you will need <em>some</em> roll control, even if you don't know precisely yet <em>how much</em>. So popular flight controllers let you add in some amount of feedforward to have faster response to inputs.</p>

<p>Feedforward works very well in appropriate quantities. In a system like a drone, where it's constantly moving around and there is no real long-term, steady-state stability, feedforward can really accelerate response time and enhance accuracy. The devil's in the details, though, as each combination of airframe, motors, propellers, and atmospheric conditions will have a different optimal feedforward. </p>

<p>As a consequence, there are a myriad of ways to implement feedforward, and so there's no generic advice for how to tune it right. Another poster linked to <a href="https://github.com/betaflight/betaflight/wiki/Feed-Forward-2.0" rel="nofollow noreferrer">https://github.com/betaflight/betaflight/wiki/Feed-Forward-2.0</a>, and I would consider that a good resource on pathologies which can be experienced with Beta Flight. Other FCs will have their own pathologies, you will have to experiment.</p>

<hr>

<h2>Background</h2>

<p>This is at the root a controls question. In the world of <em>classical controls</em>[*], the PID was king. It turns out that simple things refuse to die, and much to the chagrin of controls researchers worldwide the PID is still king. Chalk it up to it being easy to understand and easy to tune for many systems, even if it isn't very good.</p>

<h3>Without feedforward</h3>

<p>Here is a diagram of a <strong>Roll PID without Feedforward</strong>. </p>

<p><a href="https://i.sstatic.net/WVMfp.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/WVMfp.png" alt="Feedback example"></a></p>

<ol start="0">
  <li>You have some roll setpoint (i.e. desired roll)</li>
  <li>You compare the setpoint to the measured roll, getting the error</li>
  <li>You multiply that error by tuning values (K_p, K_i, and K_d) to generate a control response</li>
  <li>You apply that control response to the system and see how the system reacts</li>
  <li>GOTO (1)</li>
</ol>

<h3>With feedforward</h3>

<p>Feedforward has all those parts, except that it adds a new element, which is the predicted control based on the anticipated roll. Here is a diagram of a <strong>Roll PID with Feedforward</strong>. </p>

<p><a href="https://i.sstatic.net/3zNfz.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/3zNfz.png" alt="Feedforward example"></a></p>

<p>Notice that there is a new pathway to the control, which is completely independent of the error. That's why it's called <em>feedforward</em>. This pathway simply takes into account the desired outcome and blindly applies a control input based on that.</p>

<hr>

<p>[*] The era of <em>modern controls</em> began in 1958 with the publishing of Pontryagin's revolutionary theory on optimizaton followed by R. Kalman's now-ubiquitous estimation filter. For a full history, read <a href="http://www.uta.edu/utari/acs/history.htm" rel="nofollow noreferrer">http://www.uta.edu/utari/acs/history.htm</a>.</p>

CC BY-SA 4.0
2020-04-29T06:44:52.497Z
The Derivative term in Betaflight is calculated not from the error signal in the above diagram, but from the gyro, or feedback signal.

The above diagram is incorrect in that respect.

The error signal shown above already includes the setpoint change; in the above diagram, and if Feed Forward was actually implemented as above, the setpoint change would be applied twice.  So we don't do it like that.

In early versions of Betaflight, derivative was calculated from error, but now it is calculated purely from the gyro, or feedback, signal.
ctzsnooze
CC BY-SA 4.0
2020-04-29T11:30:06.937Z
The diagram is not related to Betaflight. It is simply a high-level view of what a generic FF does. There is a large body of work which addresses the issues arising from using a D term, and from what you say it sounds like early versions of Betaflight ran into those classic problems. Kudos to the devs for finding a more optimized solution.
Kenn Sebesta
CC BY-SA 4.0
2020-04-18T14:58:17.427Z
2020-04-20T14:14:56.160Z
2020-04-20T14:14:56.160Z
Kenn Sebesta
<p>I'm far from an expert on this subject... but there's a good article <a href="https://github.com/betaflight/betaflight/wiki/Feed-Forward-2.0" rel="nofollow noreferrer">here on Github</a> which I find explains it well.</p>
<p>Basically feedforward is a factor which increases how responsive the stick is - somewhat like P, except that FF does not make the drone wobble at high levels. I quote:</p>
<blockquote>
<p>FeedForward (FF) is a drive factor that increases stick responsiveness. It is proportional to the instantaneous derivative, or 'rate of change' of stick movement. The faster the sticks are moving, the more FeedForward we get. FeedForward helps P drive the quad into turns. Unlike P, FeedForward cannot cause oscillation, no matter how much FF is added.</p>
<p>With FeedForward, we get better stick responsiveness without pushing P so high as to cause wobbles. It also reduces the delay time between input and response. Less delay means less error and less I windup/overshoot. It is great for racing, LOS and radical freestyle flying. It isn't great for cinematic HD.</p>
</blockquote>
<hr />
<p>Hope it helps!</p>

CC BY-SA 4.0
2020-04-18T12:22:29.360Z
2020-04-18T12:22:29.360Z
2020-06-18T08:37:30.297Z
anonymous2
<p>PID tuning involves P, I and D gains to help the quad follow RC commands. </p>

<p>Whenever there is an error, P would "push" the quad to reduce the error. So how does Feed Forward come to play?</p>

<betaflight><multirotor><pid>
What does Feed Forward do and how does it work?
Klystrom
# What does Feed Forward do and how does it work?

(Asked by: username_0 on 2020-04-18)

PID tuning involves P, I and D gains to help the quad follow RC commands.

Whenever there is an error, P would "push" the quad to reduce the error. So how does Feed Forward come to play?

**Tags:** betaflight, multirotor, pid

---

## 3 answers

### Answer by username_1 on 2020-04-18. Score: 12

The way the PID controller works is whenever the actual rate of rotation of the quadcopter does not equal the *setpoint*, or desired rate of rotation (which you set by moving the sticks), it sends a signal to the motors to compensate and bring the rate closer to the setpoint.

This signal is a sum of four *terms*: The P, I, D and FF. Since it's a sum, you can think of them as each pushing the quad in a certain direction independently, some terms adding up and others counteracting each other.

The P term is the difference between the setpoint and actual rate, multiplied by the P *gain*. So the amount of force applied by the P term is directly proportional to that difference. You can think of it as a spring that tries to move the quad back whenever it's bumped out of position. The further it's moved (bigger difference between setpoint and actual rate) and the stiffer the spring (bigger P gain), the stronger it will pull.

The reason why the FF term is needed is because the signal that the PID controller outputs influences the **acceleration**, not the speed directly. This means that the quad will not get up to speed immediately, but take some time depending on how hard it pushes itself. So when you want to sharply begin a maneuver you want the quad to apply *a lot* of force in that direction to get going and then sustain the rotation with a smaller force.

The PID controller, however, is meant for stabilizing. It does not distinguish between you bumping the stick and the quad being bumped out of position by an obstacle or gust of wind. So when you move the stick it "stabilizes" itself at the new speed as if you didn't move the stick at all and it was bumped by something instead. You can think of moving the stick as moving the other end of the spring that the quad is attached to. The spring doesn't care which end was moved, just that its length changed.
This means that the PID controller won't apply as much force to start the rotation as it potentially could, which means it is somewhat slow to speed up when you move the stick, and, more importantly, slower to slow down when you move the stick back to center (and can even overshoot).

You can make the reaction faster by increasing the P gain, but to a point, as higher P gains lead to oscillations, when the quad's movements lead to big P terms which in turn cause bigger movements and so on.

So instead the FF term was added. The FF term does not consider the current rotation rate at all, so it does not contribute to the PID loop's stabilizing action and is thus unable to cause oscillations. The only thing that it looks at is the sticks. The force applied by the FF term is proportional to *the rate at which you move your stick* (multiplied by the FF gain).
So when you, for example, initiate a roll and bump the stick to the right, the FF term will detect the fast stick movement and give a burst of force to get the quad going. Then, when you finish the roll and return your stick back to center, the FF term will detect the opposite fast stick movement and apply a corresponding force, helping the PID controller stop the quad's rotation faster and avoid overshooting.


---

### Answer by username_2 on 2020-04-18. Score: 11

# 30,000 foot view of feedforward as a general concept

* **Feedforward**: I hand you a closed box and you anticipate that it will be heavy, bracing yourself in preparation. Your control of the box is rapid and precise.
* **Feedforward failure**: I hand you a box and it's *much* heavier than you anticipated. Your control of the box is sloppy until you recalibrate and figure out how much it weighs.
* **No feedforward**: when your eyes are closed and all you know is that I'm going to hand you something. Could be a helium balloon, could be a dishwasher. You don't know if your arms will be pulled up or down, and so you're slow to react.

# Feedforward in drones

In the case of a drone which is rolling, a feedforward term lets you anticipate that you will need *some* roll control, even if you don't know precisely yet *how much*. So popular flight controllers let you add in some amount of feedforward to have faster response to inputs.

Feedforward works very well in appropriate quantities. In a system like a drone, where it's constantly moving around and there is no real long-term, steady-state stability, feedforward can really accelerate response time and enhance accuracy. The devil's in the details, though, as each combination of airframe, motors, propellers, and atmospheric conditions will have a different optimal feedforward.

As a consequence, there are a myriad of ways to implement feedforward, and so there's no generic advice for how to tune it right. Another poster linked to <https://github.com/betaflight/betaflight/wiki/Feed-Forward-2.0>, and I would consider that a good resource on pathologies which can be experienced with Beta Flight. Other FCs will have their own pathologies, you will have to experiment.

---

## Background

This is at the root a controls question. In the world of *classical controls*[\*], the PID was king. It turns out that simple things refuse to die, and much to the chagrin of controls researchers worldwide the PID is still king. Chalk it up to it being easy to understand and easy to tune for many systems, even if it isn't very good.

### Without feedforward

Here is a diagram of a **Roll PID without Feedforward**.

[![Feedback example](https://i.sstatic.net/WVMfp.png)](https://i.sstatic.net/WVMfp.png)

0. You have some roll setpoint (i.e. desired roll)
1. You compare the setpoint to the measured roll, getting the error
2. You multiply that error by tuning values (K\_p, K\_i, and K\_d) to generate a control response
3. You apply that control response to the system and see how the system reacts
4. GOTO (1)

### With feedforward

Feedforward has all those parts, except that it adds a new element, which is the predicted control based on the anticipated roll. Here is a diagram of a **Roll PID with Feedforward**.

[![Feedforward example](https://i.sstatic.net/3zNfz.png)](https://i.sstatic.net/3zNfz.png)

Notice that there is a new pathway to the control, which is completely independent of the error. That's why it's called *feedforward*. This pathway simply takes into account the desired outcome and blindly applies a control input based on that.

---

[\*] The era of *modern controls* began in 1958 with the publishing of Pontryagin's revolutionary theory on optimizaton followed by R. Kalman's now-ubiquitous estimation filter. For a full history, read <http://www.uta.edu/utari/acs/history.htm>.

> **Comments:**
> **username_3**: The Derivative term in Betaflight is calculated not from the error signal in the above diagram, but from the gyro, or feedback signal.  The above diagram is incorrect in that respect.  The error signal shown above already includes the setpoint change; in the above diagram, and if Feed Forward was actually implemented as above, the setpoint change would be applied twice.  So we don't do it like that.  In early versions of Betaflight, derivative was calculated from error, but now it is calculated purely from the gyro, or feedback, signal.  
> **username_2**: The diagram is not related to Betaflight. It is simply a high-level view of what a generic FF does. There is a large body of work which addresses the issues arising from using a D term, and from what you say it sounds like early versions of Betaflight ran into those classic problems. Kudos to the devs for finding a more optimized solution.  

---

### Answer by username_4 on 2020-04-18. Score: 2

I'm far from an expert on this subject... but there's a good article [here on Github](https://github.com/betaflight/betaflight/wiki/Feed-Forward-2.0) which I find explains it well.

Basically feedforward is a factor which increases how responsive the stick is - somewhat like P, except that FF does not make the drone wobble at high levels. I quote:

> FeedForward (FF) is a drive factor that increases stick responsiveness. It is proportional to the instantaneous derivative, or 'rate of change' of stick movement. The faster the sticks are moving, the more FeedForward we get. FeedForward helps P drive the quad into turns. Unlike P, FeedForward cannot cause oscillation, no matter how much FF is added.
>
> With FeedForward, we get better stick responsiveness without pushing P so high as to cause wobbles. It also reduces the delay time between input and response. Less delay means less error and less I windup/overshoot. It is great for racing, LOS and radical freestyle flying. It isn't great for cinematic HD.

---

Hope it helps!


---

