As we still hadn’t figured out what caused the problem of drifting when trying to hold height, we ran some further test flights. We looked at the DAlt value, as it seemed from looking at logs that this value was behaving oddly. We searched online for issues with DAlt values, and found this forum post. This person’s problem is that DAlt stays at zero, which is a bit different to our problem. However, other users comment on their Z vibrations (AccZ) looking quite high. We decided that it would be a good idea to look at how much our UAV was vibrating, and so attempted to find this data in past logs. However, it seems that this data is not recorded as default, but we found this guide explaining how to measure it. So, after setting the UAV to record this value, we ran another test flight. For these flights I attempted to record the flights to create a visual record of how well the UAV flew. Flight 1:
The UAV flew as it had done the previous day. Looking at the DAlt/Alt/BarAlt values of this flight is quite interesting:
The AltHold command still causes the odd spike in the desired altitude (DAlt), but Alt and BarAlt actually touched this value (which should in theory be their target) before then bouncing away from it. It may be co-incidence that these values actually touched, or it could be evidence of massive over-shooting in trying to oscillate around the value. In some of the later test flights we did try varying PID values to see if this helped. The vibration values for the first flight can be seen here:
According to the forum post, the value should be within the range of -5 to -15, as ours are (excluding the landing). Therefore we do not think that vibration is causing us any major issues, yet may try and place a bit of foam under the ArduPilot to lessen the vibrations as an aside.
For the second flight, we tried changing Altitude Hold P value from 1 to 2. This resulted in the following flight:
On this setting we actually conducted 3 flights, although they all share a single logg. On the middle flight, the UAV was flown (and not by me this time) in to a power strip hanging from the ceiling, resulting in the UAV crashing in to the iCub’s cage, followed by the floor. This can be seen in the DAlt/Alt/BarAlt of the flight:
The first AltHold represents the flight seen in the video above. The middle one shows the crash, which was caused by the UAV drifting in to the plastic. The third is at the end of a short manual flight to check that the UAV was still functioning correctly. The UAV experienced a small amount of damage, i.e. some damage to the blades that impacted the power strip:
This did not appear to cause any issue with the flight however, and the frame appeared to sustain no damage. The graph of ThrIn vs. ThrOut (the throttle control input vs. output) although amusing due to the crash, is also of interest (and has been in several other flights):
It shows that on AltHold mode, the throttle output value seems to be very noisy. It would be interesting to see how the ThrOut value compares to the Alt values, but Mission Planner does not support such a graph due to scaling issues (in theory it allows you to have 2 different scales on the same graph, but in reality this piece of functionality does not work).
For our third flight, we changed the Throttle Accel P value to 0.5, and the I value to 1. This brings them back in line with the minimum recommended values by the software. This led to the following flight:
This flight was the longest that it has flown continuously indoors so far, as it seems to hold the height more accurately than previously. Increasing the Throttle Accel P and I values seems to make the adjustments more jerky, and so perhaps it was the previously implemented changes to the Altitude Hold P value that had the greater effect. The jerkyness of the throttle control can be seen in the log graph of ThrIn/ThrOut:
The DAlt/Alt/BarAlt values were as follows:
For the fourth flight we decided that we would lower the Throttle Accel value back down to 0.3, as although 0.5+ is recommended, we think that due to the power/weight balance we need lower. The recommended ration of P:I is 1:2, but we decided to leave the I value as 1, as it seems possible that this ratio may not work for us when our UAV seems to require stepping outside of recommended ranges already. We took the the Throttle Rate P value from 2.8 back up to the minimum recommended value of 5. This resulted in the following flight:
We are quite pleased with this flight, as it yet again ran for longer than previous attempts. Some of the jerkyness in the thrust has been reduced again due to setting the Throttle Accel P value back down to 0.3. The DAlt/Alt/BarAlt values can be seen below:
In this graph, the Alt/BarAlt values seem to be hanging around the DAlt values a lot better than they had previously, which could explain why the UAV seemed to be flying much better.
For the fifth (and final) flight of the day, we increased Throttle Rate from 5 to 7. This resulted in the following relatively short flight:
This test ended up being 3 flights, with the first 2 being short and the third being long (which I did not record). This difference seemed very odd, and so we looked at the DAlt/Alt/BarAlt values:
What is interesting is that for the first flight, the DAlt value seems to have set itself to below zero. We are so far unsure as to what exactly dictates the desired altitude. However, it being set to a value below zero would explain the attempting to fly through the floor. For the second flight it seemed to set reasonably, but the UAV still drove in to the floor. However, on this flight it seems to have been set to a lower value than it was on the final flight. It is possible that the DAlt being low caused the UAV to overshoot in to the floor. Indeed, in the prior more successful flights the DAlt value has been over 1.
Although these trials were interesting, we still made only a small amount of progress. It is unclear what could have caused the issues seen, but we hope to figure it all out via a mixture of online research and trial & error.
Be First to Comment