On the third day of trying to work out why the UAV had issues with holding it’s height, we found a solution. During research in to the problem my supervisor came accross this blog post, which stresses the importance of checking AHRS_MPU6K_FILTER. The equivelant on my system appears to be INS_MPU6K_FILTER, but it appears to still serve the same purpose. The forum post recommends that this value be set to 20, i.e. 20Hz. According to the parameter’s description, the default value should be 20Hz. However, the suggested range says:
0:Default 5:5Hz 10:10Hz 20:20Hz 42:42Hz 98:98Hz
The value was set to 0 on my ArduPilot. What I think has happened here is that there used to be a bitmask in place, and so having this variable set as 0 led to the default value (20Hz) being used. However, at some point, it has been changed to take the given value as a literal value, making the 0 represent 0Hz. When firmware updates are made, they do not overwrite the parameter sets to avoid causing issues/annoyances and so this value never got updated when the firmware did. So, for our first flight of the day we decided to change the value of INS_MPU6K_FILTER from 0 to 20. This led to the following flight:
Changing this single setting seems to have lead to a dramatic increase in the flight performance. In the graphs of DAlt/Alt/BarAlt, it can be seen that Alt remains close to DAlt, while BarAlt (showing the true position of the UAV) is a bit out:
It seems that the software does not put as much weighting on the BarAlt value as it really should. We have looked in to the code of ArduPilot, in an attempt to work out how the weighting is done. We found the code to be very hard to work with, and so could not figure out exactly how the weighting is done. It does however appear that the positioning takes in to account sonar and GPS, if present (which they are not in these flights). We do not have a sonar to use to increase accuracy, and we do not foresee GPS providing any great increase in vertical accuracy.
To attempt to see if “more is better” when it comes to INS_MPU6K_FILTER, we increased the value from 20 to 30 for our next flight, resulting in the following:
This did not cause any increase in performance compared to the previous value. We then considered that 30 is not one of the recommended values, and so decided to try 42 (the next highest recommended value):
This still did not present an improvement on 20. For our next flight we decided to return to 20, to check that it wasn’t a fluke:
From this we surmised that 20Hz seems to be a magical value. There still appears to be some drifting however, perhaps due to the issue of barometric height weightings previously mentioned. We considered updating to the newest firmware, to discover that this would not be possible. The coding project’s code has become so large that it now will no longer fit on an ArduPilot (3.2.1 is the latest that will fit), and would require for me to change hardware to a PixHawk, which is not something that I want to do. The code only fit for so long because of increases in efficiency due to developments in the GCC compiler. It would likely be a pain to try and manually update the code to apply more weighting to the BarAlt values, and so we have decided not to. With the change to the INS_MPU6K_FILTER value, the UAV seems to be holding height acceptably well. It is not as perfect as a pre-configured COTS UAV, but it is no longer flying in to the ceiling/floor. It holds height well around a designated point, and even if it oscilates heavily around this value, it should not cause too many issues in the context of this project (when it is hovering at 300ft high, +-3 will not make a huge difference). It is possible that wind could make the issue worse, but we will run some trials outside and see.
We made some further attempts to fine-tune the system. We changed Altitude Hold P value (the_alt_p) from 2 to 3. This led to the following flight:
We found it hard to discern if this led to any increase in performance, as we were largely assessing performance in terms of how long it took before it crashed in to the floor. We tried changing Throttle Acceleration I (thr_accl_i) to 0.6, and the d value to 0.1, leading to the following flight:
We think that the oscillations seemed a little slower, but that the movements became quite pulsey. We changed the d value back to 0, resulting in the following flight:
This fixed the pulsing issue. We conducted some tests on how the height held when being flown around sharply, and found that it still holds well. At this point we are quite happy with the performance of the UAV, and will be trying to do an outdoors test flight when the weather permits it.
Be First to Comment