Autonomous Fixed Wing Hovering With APM 2.5

 Hello everyone,

 I'm not sure if anyone is interested but for my master's thesis in Aerospace Engineering I developed 3 new flight modes for ArduPlane that command a fixed wing aircraft to transition from level flight to hover flight and then attempt to hold stable hover (a.k.a prop hanging).  Each of the three modes all have the same end goal but each uses a slightly different control strategy.  Looking at the strengths and weaknesses of each of those methods was the focus of my thesis, but I was able to get decent results with all three using an E-flite Carbon-Z Yak 54 model.  I made an attempt to keep all of the code easy to use in the spirit of the APM project so there are only a few extra parameters than need to be set and tuned for the hover modes to work in addition to the standard set of PID gains.  I used an APM 2.5 and no additional hardware is needed for the modes to work (not even an airspeed sensor) but the modes only perform attitude stabilization at this point so there is no waypoint control or even fly-by-wire capabilities while the airplane is hovering.  Theoretically, the same code should be able to command any fixed wing airplane to hover as long as the airplane has enough power and large enough control surfaces.

 I posted a video of some of my results above and I have a github repository set up already if anyone is interested in the code. A copy of my paper is also in the repository which has more information on how I developed the control schemes.  Be warned, this was my first experience with coding in Arduino and C++ so I don't make any claims to using good coding practices or even common sense compared to an experienced programmer.  If you find yourself thinking "why in the world did do that?" it's probably because I didn't know there was a better way to do it.  I was new to github too so I'm not totally sure if there is a good way to release a final version of the code but the "HOVER_ADAPTIVE" branch is the one with the final version.  The other branches were just checkpoints along the way in case I severely messed something up and needed to revert back to a stable point in the code.  

 Unfortunately, since I started this project over a year ago, the code is based on ArduPlane version 2.68 so it is severely outdated but the concepts I used to implement the hover flight modes are fairly simple and could probably be transferred over to a newer version of APM: Plane fairly easily if someone wanted to.

 Update (11/12/2013):  It sounds like some of you have had trouble viewing my report via the github repository so to make it a little easier you can also access it HERE through Dropbox.  Hope that helps!

E-mail me when people leave their comments –

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

Join diydrones


  • Hi Brian,

    thanks for the answers :)

    Did you already defend your thesis? I hope it all went well :)

    To you and all the others:

    We should all definitely work on a common project, I see there are a lot of small indipendent projects working on similar things, we should build up a kickstarter project and make something bigger!

    My choice would be, for example, a hybrid flying machine capable of hovering and forward flight, to achieve range capabilities of a fixed wing without losing the ability to take off/land vertically and hover over a place. Amazon drone delivery (if ever possible), for example, could benefit from this.

  • @Brian Marchini


    Yeah the telemetry link was a HUUUUUUGE help for the gain tuning. It was still a ton of trial and error though, and I didn't really figure out a better way of doing it unless you have gains from a similar airframe to start with. The only other way to do it would be to try to get a linearized plant model put together and do the gain tuning the old school way with bode plots and a root locus but that's no fun. At least when you do it by trial and error you get a fly the airplane instead of just doing a bunch of frequency domain math. "

    You get to fly and you have a good excuse to do it! Yes, that is cool. However, I swore that I wouldn't go over that process of guestimating the PID controller gains. Toward that goal, I am trying to learn about aerodynamic coefficient estimation through least squares and a bit about thrust module modeling. It's good fun on its own!

  • Hello everyone, sorry it has been a little while since I have answered questions.  I am not officially done with my academic endeavors though so I should have some more time on my hands now. 


    1) Perhaps.  I wanted to have some way of incorporating the downwash effects that happen for 3D wings instead of just converting the sectional aerodynamics directly into forces though.  The lifting line method I used isn't actually non-linear on it's own.  It was only non-linear because I used the non-linear NACA 0012 data for the sectional aerodynamics.  You can use whatever kind of drag polar you want to provide the data for the lifting line calculations though.  The method itself was actually fairly easy to implement, it was just slow because of it's iterative nature and the fact that I was doing it for 3 different aerodynamic surfaces simultaneously. 

    2) No the prop wash isn't always strong enough to ensure the control surfaces aren't stalled, that just seemed to be the case most of the time.  I never actually checked to see if there was ever a time where the entire control surface was stalled but it potentially could have happened during the fastest transitions where the plane was at high angle of attack and still had a lot of residual forward momentum.  Probably 99% of the time though the prop wash was enough to keep the portions of the control surfaces that were in the stream tube from stalling.

    3) I only tried to tweak the model a little bit.  I attempted to fix the rudder problems that I discussed in my report but I didn't have much luck.  The goal of the thesis was never to build a good simulator, and by the time I realized I had problems with it I had already gotten the controllers working well in flight, so I decided not to spend any more time on it and just move on with the flight tests.  

    4) Thank you! I can't take full credit for it because I got the idea from some RC forums where people had suggesting similar methods but I was really happy with how easy my final method ended up being.  

    And yes, my great grandfather was born in Italy and came to the states when he was a kid.  Good catch.


    Yeah the telemetry link was a HUUUUUUGE help for the gain tuning.  It was still a ton of trial and error though, and I didn't really figure out a better way of doing it unless you have gains from a similar airframe to start with.  The only other way to do it would be to try to get a linearized plant model put together and do the gain tuning the old school way with bode plots and a root locus but that's no fun.  At least when you do it by trial and error you get a fly the airplane instead of just doing a bunch of frequency domain math.  


    Awesome! Let me know when you guys get an initial design put together.  I would love to see the some pictures or even the engineering drawings when you get to that point.   

  • This is the self same thing we are working on from a hardware point of view. With the right airframe is very easy to trasition manualy. And give awsome range endurance over a convetional quadcopter to put the lift onto a convetional wing. We intend to have more quad (penta in fact) style of thrust lay out but I am no programmer and the code when turning the flight controller through 90 degrees is well beond me!

  • Thank you for answering my questions, Brian. When I was developing my autopilot system for my master's thesis as well, the most annoying part was the gain tuning. Since I didn't have any telemetry to speak of, I had to either land the plane and re-load the firmware or (since I have a 6-ch DX6-i TX) come up with an elaborate pattern where the control sticks instead of controlling the plane would perform as gain sliders. Not the most relaxed way to tune gains.

    Initial gain values where an issue as well.

    I just wanted to see if you came up with a smarter way to do this, for systems under development but it seems it's not as trivial.

  • Hi Brian,

    thank you so much for answering the questions, I see you appreciate the questions, so I go on:

    1) On page 59, you show the NACA 0012 polar, isn't it non-linear enough?

    2) On page 61 Control Surface deflection modeling is shown, they are effective up to stall, after which the efficiency is equal to 0: is the prop wash always strong enough so that the profile is never stalled?

    3) Did you try to "adjust the model" by analyzing flight test results? I mean, adjusting the flight control surface effectiveness for example? Motor response?

    4) I love how you estimated the motor assembly inertia :) 

    Thanks a lot, I really look forward having a talk with you when you'll be more relaxed after the thesis discussion! BTW, have you got Italian origins :) ?

  • Georacer and entropia666,

    Thanks for the questions! Answering them is good practice for my defense.


    1.  Getting an initial set of PID gains that could keep the airplane stable in hover was extremely hard.  It was mainly due to my inexperience with tuning gains in flight and I'm sure I would have a much easier time doing it now.  The other thing that was tough was trying to make sure each test started at the desired airspeed.  I wanted to avoid using an airspeed sensor in the control schemes since it isn't a standard part of he APM system, but it would have been nice to have just to make sure the airspeed was correct when flying in windy conditions.  

    2.  I did use Mission Planner to tweak the PID gains but only the ones used for level flights.  The "Hover Speed Scaler" and Adaptive parameter gains I talk about in my paper were hard coded into the firmware because I don't have nearly enough programming experience to feel comfortable even attempting the Mission Planner software.  

    3.  I only tweaked the level flight PID gains in flight. All of the adaptive parameters I modified in between flights since modifying them required reloading the firmware.  For the PID gain tuning I used that same process I talk about in my report.  Basically just a lot of trial and error.

    4. It would have been really nice to have an airplane where the battery lasted a lot longer just so that I didn't have to change batteries so often when testing, but off the top of my head I actually can't think of another plane that would have worked better for what I did.  If I did it all over again I would have tried out some different props though. The stock propeller (12 x 5.25) wasn't that great for hover performance and I know using slow-flyer style props can sometimes help that.


    I needed to use a method for calculating the aerodynamic forces that could capture the non-linear aerodynamics that occur at high angle of attack.  The iterative lifting line method was the only one I could find that actually incorporated the non-linearity and still be relatively simple to implement.  I also looked at using a panel method that could also handle the non-linear calculations but those are MUCH harder to implement and could have been a thesis in itself. But to answer your overkill question, I needed to have the non-linear aerodynamics incorporated in the model to see how the controllers reacted to the non-linearities.  If I had used a linearized model the simulations would have been much faster but I wouldn't have been as confident in my controller designs' ability to actually work in flight.

    I definitely made the simulated controllers discrete based on the APM sampling frequency and I definitely used S-functions.  The way the simulator worked was to take the current state of the aircraft, sample the attitude error, calculate the desired control surface deflections using the chosen controller (all that was done using basic simulink functions) then all of that info was passed into Matlab functions (which I wrote) that would use the iterative lifting line method to calculate the aerodynamic forces for the current time step, which would then be combined and applied to body axes before being handed back to the simulink model and integrated using the 6DoF block.  So the simulation is constantly handing information back and forth between matlab and simulink (probably another reason why it was so slow).  

  • Thank you for your answer Brian!

    I'm still reading your thesis :) I don't necessarily need the model, just wanted to compare it to mine which is a lot less refined :)

    I have a question, why did you choose an iterative lifting line model when your main interest was evaluating the Flight Control System? Don't you think it is overkill?

    Another question, did you make the simulation with a continuous time flight controller or did you simulate the APM sampling frequency? Did you use S-Functions?

    Sorry for all these questions, thanks and good luck for your thesis!


  • Hello Brian,

    I just finished reading your thesis and I have some questions:

    1. What aspects of flight testing where the most challenging and what would you do differently if you started all over again?

    2. Did you use the Mission Planner to tweak gains? Did you alter its code as well?

    3. Did you tweak gains in-flight? If yes, how did you go about it?

    4. Looking back, would you choose another aircraft to perform the same tests, if money was not an issue?

    Thanks in advance.

  • Best of luck with your Thesis defense. Thanks for the very complete and concise reply, to all our questions. Also the thesis link was helpful.
This reply was deleted.