Thanks for taking the time to read this post. First of all I would like to reassure you that this is in no way a criticism of the code or the Dev team, they have done a fantastic job.

I am working towards making my own contribution to the Arducopter code base to improve the "Fly by Wire" aspects, but it will take time for me to get the environment set up. (two kids under 2 and 2 jobs) So in the mean time I would like to discuss my ideas. If they are supported and still not implemented when I get my finger out then I will start attempting to implement and test them.

I would appreciate any feedback you can give me.

So this is my first idea to address two problems I and others have experienced in using the Arducopter.

The dreaded drop in altitude when transitioning from Alt Hold or any other Auto mode to Stabilize. Ok, it isn't a big deal once you get used to it but it isn't pretty and I think we could do better.

So I see a number of problems to be addressed:

1. Drop or increase in height when changing modes.

2. Throttle hover position in Stabilize is not in a fixed location so it needs to be "found"

3. Alt Hold is implemented such that it changes height rather aggressively.

I was able to address point 2 and even point 1 to a lesser degree setting up my throttle curve in my transmitter to set hover at mid stick.

Point 3 makes using Alt Hold to control altitude while learning or filming quite clumsy or impractical.

Ok so here is the idea. It has three parts to bare with me.

3689475373?profile=originalManual Throttle curve making hover at mid stick

Now I could see in the code where the throttle offset was changed to place throttle_cruise at mid stick but it did this by simply offsetting and limiting the curve. What I suggest above is to add two slopes for > throttle_cruise and < throttle_cruise. This means that no matter what throttle_cruise is set to the pilot will have access to full throttle range in Stabilize. throttle_cruise takes approximately 5 seconds to move 90% to hover. This means that the throttle position during hover for a bad throttle_cruise setting would move quiet slowly even in the worst case.

Alt Hold has progressive rate vs stick input and smaller dead band

The diagrams on the right show the throttle input vs requested climb rate when using Alt Hold. I am suggesting that we should make this progressive with only a small dead band in the middle. This makes it possible to make smooth and slow altitude changes without having to use the Manual Throttle. (great for learning and filming)

Transitioning from Auto mode via Alt Hold mode

When switching from Auto to Stabilize we could pause in Alt Hold mode. How I was thinking we could do this is to spend a maximum of 2 seconds in Alt Hold mode or until we move the throttle to the dead zone in Alt Hold. What ever happens first. The effect of this is to limit the sudden drop or increase in hight to -120cm/s to 180cm/s and give the pilot time to react by moving the throttle to the central position. Once in the dead band the throttle setting should be within 10% of that required for Hover.


Mid stick is always what you need to hover.

Change from Alt Hold to Stabilize should not result in scary moments because the throttle stick position should be within 10% of Hover.

Change from Auto modes, when the throttle has been set to max or min, will give the pilot 2 seconds warning before going to full or no throttle.

Alt Hold is much more "Fly by Wire".


Alt Hold would drift if the throttle is just outside the much small dead band.

There may be times when the 2 second delay moving to Stabilize could prevent the pilot adding full throttle in time to prevent a crash.

I would really appreciate any feedback and insight people have into this idea or these problems in general.



Code for this approach:

As always the code is marching on and there are already changes made in the areas I have been discussing. So I thought I would list the main requirements in the code to make this work the way I describe.

The main requirement is that g.throttle_cruise is only updated when the copter is in a stable stationary hover. The simple testes for this could be

(g.rc_3.control_in > g.throttle_min && abs(climb_rate) < 60&& abs(g.rc_1.control_in) < 1000 && abs(g.rc_2.control_in) < 1000 )

This can happen in all flight modes. Altitude is kept in different flight conditions other than hover using the Rate I term. The Rate I term limit needs to be large enough to compensate for all flight conditions.

The code for the throttle position to manual throttle output is very straight forward.

if(g.rc_3.control_in < (500 - th_deadband/2)){
    g.rc_3.servo_out = g.throttle_cruise * (g.rc_3.control_in / (500 - th_deadband/2));
}else if(g.rc_3.control_in > (500 + th_deadband/2){
    g.rc_3.servo_out = g.throttle_cruise + (1000-g.throttle_cruise) * ((g.rc_3.control_in-500-th_deadband/2) / (500-th_deadband/2));
    g.rc_3.servo_out = g.throttle_cruise;

The code for the throttle position to altitude rate output is something like this:

if(g.rc_3.control_in < (500 - th_deadband/2)){
    th_Rate = -120 * (g.rc_3.control_in / (500 - th_deadband/2));
}else if(g.rc_3.control_in > (500 + th_deadband/2){
    th_Rate = 180 * ((g.rc_3.control_in-500-th_deadband/2) / (500-th_deadband/2));
    th_Rate = 0;

Sorry but I am not familiar enough with C to add the types quickly.

In the latest version of the code the throttle_cruise factor is updated in two places. Here where it was before and what I think works well with this approach.

throttle_avg = throttle_avg * .99 + (float)g.rc_3.control_in * .01;
g.throttle_cruise = throttle_avg;

The new addition here is a problem for this approach. The code is Here:

and here:

The second update prevents this approach from working because it is constantly resetting the Altitude I term and adding it to g.throttle_cruise.

E-mail me when people leave their comments –

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

Join diydrones


  • Developer

    Re the 2second thing...I had been thinking that we should phase in the manual control.  So instead of a drop or a jet coaster ride into the sky, we blend in the manual control over a period of time.  maybe just one second.


    Leonard, thanks for the PM.  I'll reply here 'cuz it's possibly of interest to others too..

    Leonard wrote: the new code looks like it is treating g.throttle_cruise as the integration term for the Altitude PID feedback, in contrast to the throttle offset for a stationary level hover

    I haven't looked super closely at Jason's latest changes to the throttle control and maybe I'm missing your point but in any case, we have this angle_boost function that is suppose to correct the throttle to account for how much the copter is leaning over.  It's currently only applied to the throttle_cruise but I think it should be applied to the full throttle output from the navigation controller.  Otherwise the navigation PID controller is essentially trying to correct for both natural changes in altitude and the changes in lean that will happen when, for example, it reaches a way point.  I would expect this would cause it to pop-up as it reaches a way point.


    Anyway, don't be shy at making suggestions or contributions to the code.  Even the core devs have just been making it up as we go along..perhaps gained a lot of experience on the way but still greatly appreciate input and ideas.  If you make a patch that works better (test it first please!) we'd love to have it.

  • Developer

    Thanks everybody for there replies. First to respond to the points raised.

    Low battery: This should be fine as the throttle cruise setting changes anytime that the copter is in hover so it should be continually tracking unless you do heap of fast flying then stop as the battery is going dead. In this case it should only take about 5 to 10 seconds to correct.

    2 second delay and crash: Yeh, full throttle during Alt Hold will still increase the throttle to achieve a 180 cm/s increase in altitude. The only case I can think of is if you are flying in Alt Hold at high speed and want to apply full throttle to miss a tree, I have a video :).

  • How would the 2 second delay affect a pilot trying to "catch" a vehicle and prevent a crash? That part worries me a little. I suppose though that adding a significant amount of throttle, given your new alt-hold curve, will still result in a rapid climb (assuming all is well with the altimeter?) so maybe it will be ok.
  • Developer

    Good suggestions.

    There's some possibility that your throttle cruise value will be too low once you slip out of auto mode because your voltage has dropped and you now need a higher throttle cruise to maintain a hover..but that's a bit of a detail and maybe we should address that by reading in battery voltage and factoring it into the throttle (or throttle cruise) anyway.


  • Currently in Stabilise mode one has to constantly play with throttle stick and in Alt Hold mode is as you wrote. Nothing, nothing, bziuuuuum, oops..

    Having a mode where middle position of the throttle will hover, no matter if it uses 10% of power or 80% and climb rate being linear/exponential to the stick movement outside 10%..20% dead band sounds like the most intuitive way of alt changing.

    If in that mode roll/pitch will hold the alt too no matter of amount of roll/pitch then we will have a holy graal.
  • Yes I agree, and nobody is calling anybody a moron, or saying "I'm right and you're wrong because I have a higher post count than you..." or any of the typical forum BS.  It's more like a college classroom than a high school locker room around here.

  • As a newbie, this thread - and this thread - are two examples of why I like the DIY Drones community. Accomplishments, ideas and concerns are posted, clarifications are requested for better understanding of assumptions, alternative solutions are proposed, constructive dialogue happens (most of the time), and we move ahead. Nifty.  :-)

  • I like it!

    FYI, the variable climb rate in Alt_Hold is already implemented in the upcoming 2.7.2.  Marco tested it and liked it. However, the deadband is still quite large.  Personally, I would also support shrinking the deadband now that we have this variability.

    Moving the throttle curve in Stab mode automatically, I also support the idea, but I also wonder if it's not already being done?  I thought maybe it was, but I don't know the throttle code that well.

    I'll make sure Jason Short sees this post. 

This reply was deleted.