New Throttle PID Idea


Hi All,

I have been thinking about the way we have implemented our throttle and the performance issues that we have observed. First of all I would like to say that I get great altitude hold. I can cruise around at 1 or 2 meters above the ground with no problems. It is only when I start to get aggressive with my pitch, roll and speed that I start to see areas that we could improve. So I started thinking about how we are doing things and why this might cause us problems.

So the problems I see are:

  1. The pwm input to the esc is not linear with respect to the lifting force generated by the motors. Randy improved this by adding a throttle curve, however this can only be truly accurate for a particular combination of esc, motor, and propeller AT HOVER. When we start to climb, descend or move forward, the curve changes and we are back to a non linear response.
  2. Boost throttle compensates for the angle that the copter is compared to the ground. But how much do we compensate? We don’t know because of point 1. We know what force we need but not how this translates to pwm. Hang on...... Force.... Acceleration.....

So I got thinking about how we could ensure we could get the correct acceleration from the props for any given situation. Then I thought we have a sensor to measure that!!! Why don’t we put the Z accelerometer in a pid loop to directly measure and calibrate the lifting force supplied by the motors and propellers. The Pid loop design I started thinking about is shown above and compared to our current design at the top of the figure.

This has a number of advantages over the current system:

  1. The last pid loop, running at 100 Hz, takes an acceleration request then uses the z-axis accelerometer to vary the motor pwm until the required acceleration is achieved.
  2. The last pid loop linearises the rest of the system making analysis and tuning simpler.
  3. The frame translation takes care of the angle boost function automatically.
  4. When at hover or in fast forward flight changes in pitch will cause much smaller variations in altitude because the last pid loop will be working to ensure the vertical acceleration (in the earth frame) will stay as close to 9.9g as possible. We no longer are waiting to detect a change in altitude, we are reacting when we feel that we are accelerating at the very beginning of the unwanted movement.
  5. This should also improve the rise on yaw problem. As the yaw command is entered we experience a positive acceleration body frame z axis. The final control loop should sense this very quickly and reduce the throttle to bring it back to 9.8G.

There are a number of problems we may also need to solve:

  1. The z accelerometer will have noise that may need to be filtered. A moving average filter is the best choice for this because it give the greatest noise reduction with the fastest step response. This filter will be one of the biggest contributors to the delay in the throttle control.
  2. When at rest on the ground the copter will experience an acceleration in the vertical direction of 9.8G provided the motors are going slower than that required to lift off. How do we ensure that the copter provides the user with the appropriate feedback to let them know that they are near hover or not? How does the user know when the copter is about to lift off? This could be a problem because the integrator could wind the motors down to minimum throttle. This may not increase until the requested G increases above 9.8 and then it could increase very quickly to make the copter take off as requested. I believe that these effects could be minimized by sensible selection of Imax in the final loop but only experience will say.

Ok, so that pretty much sums up my idea. I would really appreciate any feedback that people can give. Has this been tried before? Does anybody know if this is being done in other systems?

Thanks for taking the time to read this far,


E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • Developer

    Thanks Phil!

    I have just finished testing the idea and it is working pretty well. I have made a few changes on the diagram above though.

    I have set up a number of test examples where the throttle control vertical acceleration, vertical speed, or altitude. I have noticed that the slow barometer response makes it hard to get really decisive response from the controller. I think it is better than the current Alt Hold but I wanted better. The good news is that Randy is working on some other stuff that will give a much faster altitude measurement that should let us really lock it in!

    Doing this work is a little hard on the equipment so I my progress will slow a little until I get replacement parts for my quad.

    Thanks again for the encouragement!

  • @leonard et al,

    Just a weekend shout of encouragement and appreciation from a 'throttle jockey'. Keep up the good work. It's really been a help to those of us who want to have graceful, precise control. 

  • Developer

    Hi Hans,

    I have no experience with the sonar but I understand that it can be quiet sensitive to both electrical and physical noise. Both of these will increase when you up the throttle so it may be that. I think there are a few threads around that can probably tell you more than I can.

    Let me know how you go!

  • Hi Leonard,

    Thanks for your comment!

    I am still awaiting the BEC from the DIYDrone store. In the meantime I realized, that I have only sharp spikes when I change the throttle input. A greater change in throttle results in greater spikes in the altitude (actual height down to the minimum height (approx. 20 cm). Without altering the throttle input the altitude is correctly measured (practically very low noise or spikes with full running motors).

    How do you interpret this behaviour? Influence of the receiver which is located near the sonar sensor and corresponding cables? Is there only a PWM output of the receiver to the ESC's in case of a change? 

    I am not yet aware about the detailed working of the ESC's. Are they emitting spikes depending on the throttle change via some way?

    Thanks and best regards



  • Developer

    Hi Hans,

    I just did it manually through the mission planner and it worked fine so I didn't go any further.

    I am working on an improved version at the moment and I have some matlab code that I have tried to use to work out optimal pid parameters but it is hard to get the model right with the time that I have spent on it. The throttle controller is the most complicated controller in the system in my opinion and it is still giving me trouble. It is also hard because we need to come up with something that is relatively easy to tune.

    I am glad you liked the simpson desert video :) It was a bit rough around the edges but I hope I can improve the quality with my next frame.

    Let me know how you go with the noise problem and the filtered BEC. I will be very interested to hear the results!


  • Hi Leonard,

    Thanks for your explanations! Do you tune with ch 7 or manually via the mission planner? Which range of oscillations are to be expected? 

    Concerning your investigations about the alt_hold PID's. Do you use some simulation program (Matlab or else.) before in flight testing?

    By the way, I realized that the alt measurements are very corrupted. At roughly 30 cm I observed during tests correct altitude measurements, but above many spikes between 1.4 m (Quad hangs at this height) and 0.2 m. Just ordered a seperate ESC with a filtered BEC at a DYIDrone shop. Hope this helps. Will report the results.

    I have seen your first FPV flight in the Simpson desert. Impressive!


  • Developer

    Hi Hans,

    The way I tune Alt hold is to start with the default parameters and go fly it. Make sure everything is working well in Stabilise mode before trying to tune Alt hold.

    With the default parameters for the throttle switch to Alt hold a good altitude (20m or above) and see what it does. If it starts a slow oscillation up and down, reduce the Rate P on the throttle.

    The problem with Alt hold is that there is a large delay in the altitude reading so it can be tricky to tune if you are starting from scratch.

    Good luck and let me know how you go!

  • Hi, I see you studied the alt_hold function in detail. Perhaps you can help me to solve my alt_hold problem with an APM 2 on a Storm Drone ( ). I tuned the attitude PID's with a simple testbench (see photo) with attaching the drone via cam holder. The motors were running approx. in a hover condition. The alt values from the MB 1200 sensor seem correct without much noise. So I am astonished that I did not succed to tune the alt PID parameters up to now. The best I can achieve up to now that the drone holds at low altitude (over short lawn) for some seconds (say 10 ... 20 s). Afterwards it climbs continously (somtetimes after going down nearly to ground) to 10 ... 20 m or more (I stop here switching to stabilize mode).

    Thanks for your suggestions

    Hans Jakob Bosshard

    3692542721?profile=original - The Largest RC Helicopter Online Store - The Largest RC Helicopter Online Store online at the Lowest Price. HeliPal is the largest rc helicopter online store. HeliPal is famous…
  • @leonardthall

    "... HOWEVER in fast forward flight the drag force counters
    the lifting force resulting in a reduced accel measurement..."

    Thats the problem i encountered today. The main forumla in my code (wich is taken from Mwii forum/Mahowik, and wich i don't understand :) ) will produce a wrong velocity sum with tilted copter. Althold in one place ie good, but moving around will result in serious drop due to misreading. A throttle angle compensation can not compensate for that error. Because of my very limited understanding of mathematics, i did a workaround, wich minimizes the problem without eliminating it. I took the tiltangle (0.99 = Horizontal 0 = 180 degree) multiwii: "float  TiltAngle = EstG.V.Z/acc_1G;"  and multiplied the wrong accz projection result 4 times with it (don't know the correct english expression for "hoch 4"). So when tilting the copter the wrong readings are diminished in the sum. Besides this i used a small deadband for the resulting accz of "5". This solution is not perfect but def. ok to fly. I think a bigger deadband could stop wrong readings completely - didn't try today.

    Here is the code i added after the accz "formula"

      float  TiltAngle = EstG.V.Z/acc_1G;
      accZ = accZ*(TiltAngle*TiltAngle*TiltAngle*TiltAngle);
      if (abs(accZ) < 5) accZ = 0;

    velz = velz+accZ*accVelScale*ACCDeltaTime;

    Sorry, that i am not able to present you a mathematically correct solution, but perhaps you can make some use of my findings.

    So long

    Kraut Rob

  • I did used Z-ACC to monitor Throttle when rotating in my HefnyCopter2 ... I noticed the YAW change altitude disappeared or minimized based on the value.. I used a simple P value to be multiplied by ACC delta from 9.8 then to be added to Thr with negative sign...

    I will study your model more closely.. Thanks for sharing.

This reply was deleted.