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!

Hello everyone!

I'm glad to see so many of you are interested in my work! I'll do my best to answer all of your questions but I'm currently in the middle of finishing my thesis defense and finalizing my report (along with searching for a job) so it might take me a few days to get back to you all if you have follow up questions.

Michael Johnston: Yes there is potential to do vertical take off and landing. Like I said in my post, the code currently only does attitude stabilization but theoretically it wouldn't be that hard to add outer loop waypoint navigation when in hover in a similar way that the inner and outer PID loops work when in level flight.

W. Joe Taylor: You are completely correct. Having an airplane with even two counter rotating motors would drastically improve the roll problems that I had. The intent of my thesis was to show that I could do it with a very generic and conventional airframe and just the base APM system so the precision of the hover was definitely hurt by that. The code is theoretically set up to handle more complex airframes though because I didn't modify any of the mixing code that is used for aircraft with non-conventional control surfaces. Potentially, the only thing that would need to be added is code for differential thrust if you wanted to use an airplane with two or more wing mounted motors and use variable throttle to control yaw when in hover.

Andrew Tridgell: I would definitely be willing to cooperate on your project. I'm not totally sure how much free time I will have the next few weeks/months but I would love to help out as much as I can. Like I said in my original post, my coding skills are poor at best so it would probably take me quite a while to sift through the current git master (I know there have been quite a few changes since the version I used) and figure out how to implement my hover flight modes. I'm sure I could figure it out eventually but I would definitely be willing to share all of the theory I used if you wanted to get something up and running more quickly.

Hugues: Not a dumb question at all. After over a year of working on it my family still has no idea what I'm talking about. Watch these videos of MIT doing a similar project. They did all their tests indoors with a smaller airplane so its much easier to see what is going on.

Phillippe Petit: Two of the flight modes use the standard arduplane PID controllers. One tries to control the plane based on a simple step input (desired pitch increases to 90 degrees instantaneously), where as the other tries to track a user defined second order reference model (basically just smooths out the transition). The last mode tries to track the same reference models but does so using a Model Reference Adaptive Controller (also sometimes called Adaptive Output Feedback Control). It's an adaptive algorithm that works similar to a proportional controller but adds gain if the system isnt tracking the reference model properly. The throttle is always controlled by the same PID controller for all three hover modes though.

Georacer: You probably need to change what branch of the repo you are looking at. For some reason the link I posted seems to be defaulting the to "Quaternion" branch (which is one of the oldest ones) and not the most recent one named "HOVER ADAPTIVE" which is where the report is located.

YOU CAN ALSO ACCESS THE PDF OF MY REPORT HERE. Dropbox should be much less troublesome than github.

Eli Cohen: Yes, definitely switched to quaternions. I originally thought I was going to have to write my own library to handle all of the conversions between Euler angles and quaternions but it turned out ArduPlane already had one built in. All I had to add was a simple function that calculated the quaterion rotation error for a current and commanded quaternion.

Chris Anderson: Yes theoretically GPS position hold could be added (see my response to Michael Johnston above). The reason I didn't try it (besides the fact that I didn't want to be in school for another 2 years) is because I was afraid that the single GPS receiver on the APM would lose signal when in hover orientation since it wouldnt be pointed up anymore. After looking at all of the results it doesn't look like that was ever the case but when I was defining the scope of my thesis I wanted to avoid making any hardware additions including (but limited to) having to add a second GPS receiver mounted in a different direction that would take over when the airplane was hovering. But yes, theoretically we could set up an outer hover navigation loop that fed the inner attitude stabilization controllers and commanded small changes to the hover orientation to do controlled strafing for GPS waypoint navigation. The biggest problem would be getting the controllers to be precise enough so that the airplane never lost stability though.

entropia666: If you really wan it you can have it. It's definitely not good by any means though and it is a pain to use. It's also EXTREMELY slow because of the iterative lifting line method I used to do the aerodynamic calculations. It would typically take 5-6 minutes do complete a 30 second transition simulation. You would definitely need some knowledge of both matlab and simulink to have any idea how to use it also.

R_Lefebvre: Yes the baro altitude noise is part of the problem but not the whole story. I used the mix altitude measurement for the throttle control so there is definitely some noise in there, and I actually compounded that noise by taking a derivative of the mix altitude so that the PID controller is actually trying to hold a commanded climb/descent rate instead of trying to hold a specific altitude. That probably seems like a weird decision, but its actually really useful for the pilot because I turned the throttle stick into a fly-by-wire climb/descent rate controller while the airplane is in hover. It was a lot easier to do it that way and just leave the stick at 50% (try to hold constant altitude) than to command altitude directly and have to worry about resetting the desired altitude at different times during the hover. The other reason for the surging is that I added what I called a "divergence throttle setting" which bumps the throttle up to 75% any time the nose gets pointed more than 5 degrees off target in any direction. This helped with wind disturbances and was meant to simulate an actual pilot increasing throttle momentarily in order to get extra air over the control surfaces to help increase control effectiveness. So sometimes the throttle surge is because of the altitude measurement noise and sometimes its because the airplane is just trying to make sure it doesn't lose it's hover stability .

Thanks to all of you for the questions. It's actually giving me a great idea of what to expect during my defense.

-Brian

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

Join diydrones

Comments

Dave Schilling November 12, 2013 at 6:22pm

Very nice!!!
Brian Marchini November 12, 2013 at 4:09pm

Awesome, that should definitely do the trick. Thanks Chris!
3D Robotics

Chris Anderson November 12, 2013 at 3:50pm

Great update, Brian! As for the GPS, you can you one with a helical antenna, which is omnidirectional. We sell an adapter for it so it works well with APM.
Brian Marchini November 12, 2013 at 1:37pm

Hello everyone!

I'm glad to see so many of you are interested in my work! I'll do my best to answer all of your questions but I'm currently in the middle of finishing my thesis defense and finalizing my report (along with searching for a job) so it might take me a few days to get back to you all if you have follow up questions.

Michael Johnston: Yes there is potential to do vertical take off and landing. Like I said in my post, the code currently only does attitude stabilization but theoretically it wouldn't be that hard to add outer loop waypoint navigation when in hover in a similar way that the inner and outer PID loops work when in level flight.

W. Joe Taylor: You are completely correct. Having an airplane with even two counter rotating motors would drastically improve the roll problems that I had. The intent of my thesis was to show that I could do it with a very generic and conventional airframe and just the base APM system so the precision of the hover was definitely hurt by that. The code is theoretically set up to handle more complex airframes though because I didn't modify any of the mixing code that is used for aircraft with non-conventional control surfaces. Potentially, the only thing that would need to be added is code for differential thrust if you wanted to use an airplane with two or more wing mounted motors and use variable throttle to control yaw when in hover.

Andrew Tridgell: I would definitely be willing to cooperate on your project. I'm not totally sure how much free time I will have the next few weeks/months but I would love to help out as much as I can. Like I said in my original post, my coding skills are poor at best so it would probably take me quite a while to sift through the current git master (I know there have been quite a few changes since the version I used) and figure out how to implement my hover flight modes. I'm sure I could figure it out eventually but I would definitely be willing to share all of the theory I used if you wanted to get something up and running more quickly.

Hugues: Not a dumb question at all. After over a year of working on it my family still has no idea what I'm talking about. Watch these videos of MIT doing a similar project. They did all their tests indoors with a smaller airplane so its much easier to see what is going on.

Phillippe Petit: Two of the flight modes use the standard arduplane PID controllers. One tries to control the plane based on a simple step input (desired pitch increases to 90 degrees instantaneously), where as the other tries to track a user defined second order reference model (basically just smooths out the transition). The last mode tries to track the same reference models but does so using a Model Reference Adaptive Controller (also sometimes called Adaptive Output Feedback Control). It's an adaptive algorithm that works similar to a proportional controller but adds gain if the system isnt tracking the reference model properly. The throttle is always controlled by the same PID controller for all three hover modes though.

Georacer: You probably need to change what branch of the repo you are looking at. For some reason the link I posted seems to be defaulting the to "Quaternion" branch (which is one of the oldest ones) and not the most recent one named "HOVER ADAPTIVE" which is where the report is located.

YOU CAN ALSO ACCESS THE PDF OF MY REPORT HERE. Dropbox should be much less troublesome than github.

Eli Cohen: Yes, definitely switched to quaternions. I originally thought I was going to have to write my own library to handle all of the conversions between Euler angles and quaternions but it turned out ArduPlane already had one built in. All I had to add was a simple function that calculated the quaterion rotation error for a current and commanded quaternion.

Chris Anderson: Yes theoretically GPS position hold could be added (see my response to Michael Johnston above). The reason I didn't try it (besides the fact that I didn't want to be in school for another 2 years) is because I was afraid that the single GPS receiver on the APM would lose signal when in hover orientation since it wouldnt be pointed up anymore. After looking at all of the results it doesn't look like that was ever the case but when I was defining the scope of my thesis I wanted to avoid making any hardware additions including (but limited to) having to add a second GPS receiver mounted in a different direction that would take over when the airplane was hovering. But yes, theoretically we could set up an outer hover navigation loop that fed the inner attitude stabilization controllers and commanded small changes to the hover orientation to do controlled strafing for GPS waypoint navigation. The biggest problem would be getting the controllers to be precise enough so that the airplane never lost stability though.

entropia666: If you really wan it you can have it. It's definitely not good by any means though and it is a pain to use. It's also EXTREMELY slow because of the iterative lifting line method I used to do the aerodynamic calculations. It would typically take 5-6 minutes do complete a 30 second transition simulation. You would definitely need some knowledge of both matlab and simulink to have any idea how to use it also.

R_Lefebvre: Yes the baro altitude noise is part of the problem but not the whole story. I used the mix altitude measurement for the throttle control so there is definitely some noise in there, and I actually compounded that noise by taking a derivative of the mix altitude so that the PID controller is actually trying to hold a commanded climb/descent rate instead of trying to hold a specific altitude. That probably seems like a weird decision, but its actually really useful for the pilot because I turned the throttle stick into a fly-by-wire climb/descent rate controller while the airplane is in hover. It was a lot easier to do it that way and just leave the stick at 50% (try to hold constant altitude) than to command altitude directly and have to worry about resetting the desired altitude at different times during the hover. The other reason for the surging is that I added what I called a "divergence throttle setting" which bumps the throttle up to 75% any time the nose gets pointed more than 5 degrees off target in any direction. This helped with wind disturbances and was meant to simulate an actual pilot increasing throttle momentarily in order to get extra air over the control surfaces to help increase control effectiveness. So sometimes the throttle surge is because of the altitude measurement noise and sometimes its because the airplane is just trying to make sure it doesn't lose it's hover stability .

Thanks to all of you for the questions. It's actually giving me a great idea of what to expect during my defense.

-Brian
MR60

Hugues November 12, 2013 at 12:33pm

Ok, thx for the video explaining what that is,

I guess the folks who are doing that are frustrated not to fly a multicopter ;)
Rob_Lefebvre November 10, 2013 at 6:28am

Cool stuff.

Is the throttle surging we hear because of the baro altitude estimate being noisy? Arducopter's inertial navigation would help that if so.
entropia666 November 10, 2013 at 2:28am

Hi again Brian,

do u plan releasing your A/C model?

BTW, I'm almost through your thesis, I'll have some questions soon :-D

Michele
Anish November 9, 2013 at 3:20pm

Great work, look forward to reading ur thesis
3D Robotics

Chris Anderson November 9, 2013 at 12:29pm

This is awesome. Do you think with the addition of GPS position hold this could be used to do a VTOL takeoff and landing? (assuming the aircraft had a design that wouldn't be harmed by landing on its tail)
Eli Cohen November 9, 2013 at 12:09pm

Cool! I worked on a project very similar to this a few years ago.

Did you switch to quaternions to get rid of the attitude singularity problems or did you do a hard swap between reference frames?

of 4

This reply was deleted.