The height holding issue

The UAV has now been repaired after it’s visit to the ground via a tree, and so I can move on with my project
On the outdoors test flight, we noticed that the UAV seemed to have some issues with holding it’s height.  From how it moved (generally heading for the floor), we assumed that it had an issue with how high up it thought it was vs. how high up it actually was.  If the UAV consistently thought that it was higher up than it was, it would in theory keep drifting downwards, as it did.  We took a look at the data from the flight, and this did not provide any clues in to where the issue was coming from.  We first looked at the BarAlt field.  According to the ArduCopter Wiki, this value is the altitude above the ground according to the barometer.  We do not believe that GPS data was being integrated in to height measurements due to how innacurate that would be, and so assume that this value will be a large component in how the UAV checks that it is holding height correctly.  The BarAlt data can be seen below:This graph looks fairly reasonable to us.  It does not appear to be very noisey, and as it touches zero at appropriate times, this does not appear to be the cause of the height issues.  On the graph, you can see the labels indicating what mode the UAV was in at the time.  Unfortunately, we could not find a way in Mission Planner to zoom in on a given section of a graph, instead only being able to zoom in on the enter (which is the area that is of no interest here).  The size of the label does not seem to correlate with the duration of the mode either, instead just being placed where the mode begins.  Although the stabalize labels are covered over by other labels a lot, you can still see roughly where they are.  The altitude values seen around here are quite varied, which does reflect accurately how the UAV behaved while in this mode.  The addition of the labels also confirms that the UAV was in the correct mode, and that the controller was not simply trying to put the UAV in to the wrong mode.

We decided to also take a look at the ThrOut and ThrIn values.  These values are the pilot’s throttle input, and the throttle being output to control the rotors of the UAV.
This graph shows that the throttle control is quite noisey.  This suggests that the control system may be “overshooting” it’s target levels of throttle, which again could cause the odd behaviour seen.  We decided that it would be best to re-run tests in one of the laboratories at the University, in which there will be no disturbances (such as wind).  We were however glared at by iCub.
For these tests we changed the mode being used on the controller.  Instead of Loiter, we used the AltHold mode.  This means that the X and Y values are not necessarily being held, just the height.

The ThrIn and ThrOut values for this are interesting.

You can see that when AltHold is set, the throttle becomes very noisy and drops.

What is interesting in this flight is the DAlt value.  According to the wiki, this is the desired alt as used in AltHold mode.  The graph of this can be seen here:

It appears as though as soon as AltHold mode is engaged, the desired altitude spikes up massively.  This seems odd, as it results in a drop in the height of the UAV.

We did a quick search in to why a UAV may gradually drift down, and ended up back on the previously linked Wiki page, dealing with AltHold.  Under common issues, we found the following point:

Copter slowly descends or climbs until the pilot retakes control in stabilize.  Normally this is caused by not having the throttle stick in the mid position.  This commonly happens when the pilot is switching into AltHold from a manual flight mode (like Stabilize) on a copter that does not hover at mid throttle.  See the wiki page related to setting the mid throttle position.

We decided to check where the manual control hovering point was of the UAV, and realised that it was indeed below the mid position of the throttle stick.  Apparently this can cause issues, as the UAV assumes that the hover is within a given range of the center, and not having this set correctly causes issues.  So, under the tuning sections of Mission Planner, we changed the Throttle Hover level from 500 (default) to 325.  This brought it in to the acceptable range for the middle, and according to my supervisor made the control feel a lot nicer.  We think that this issue was caused by the relavtively powerful rotors in relation to the weight of the UAV.  We think that this difference may also be causing some of the other issues.  The weight of the UAV will likely be increasing however.  I intend on having my GoPro on the UAV, which will add over 100g, and the lure+dropping mechanism will also add some weights.

We ran another test flight with this setting changed, which did not solve all of our problems.  We found that the UAV still drifts, only it goes both up and down instead of just down.  It is not oscillating over a set point (and so not simply overshooting slightly), and so decided to look at other parameters.  The BarAlt data of this flight demonstrates the upward+downward drifts:

This flight also had an error apparently, which did not seem to cause any issues during the flight and so we have elected to ignore it.

For our attempt at fine tuning the throttle, we looked at the Extended Tuning section of Mission Planner:

We lowered the throttle rate (default 5), and found that this made the entirety of the control much more smooth.  We also changed around the Throttle Accel P & I values (degault P: 0.5, I: 1) and found that these helped a small amount.  We ran numerous flights and found that although these settings helped (the descent became a lot more smooth rather than doing the drifting in jolted movements), ultimately they did not fix it completely.  We ran a quick test with a UAV that was known to work, and found that this hovered correctly (thus eliminating the possibility that it was something in the environment causing the issues).  What was interesting is that making these changes took us outside the recommended value ranges, and actually caused us to face some barriers in trying to make the change.  Apparently the Throttle Accel P value should not be less than 0.5, and the Throttle Rate should not be less than 5.0.  We think that this is again due to the abnormally large differences in the weight vs. power of the UAV.