Plane 4.0 had a flyaway in auto, looks like it could be a bug

We were doing some routine flights in auto mission and the aircraft passed a waypoint and then flew off in a random direction.
The aircraft appears to have been in control and did not throw any errors, but stopped following the desired roll and instead flew in a straight line. (Message at this point: Passed waypoint #1 dist 168m
which is obviously weird)
The aircraft ended up in the lake but due to some nice people with a boat we were able to retrieve it.

I just want someone else to look at the log before I file a bug report because that seems like a pretty major bug and I want to be sure Iā€™m not missing something obvious.

Hardware is a pixracer with gps and airspeed sensor from mRobotics on a mini skyhunter.

Log here

Desired vs actual roll weirdness here:

AP is still trying to correct, pitch is working so the servo voltage rail must have been OK. So most likely to be something with the aileron connection/servo/linkage.

Given the message: ā€˜ā€˜Passed waypoint #1 dist 168mā€™ā€™ right before that and the fact that when we switched modes in an attempt to bring it back it handled normally, I donā€™t think thatā€™s the case. I just checked the aircraft and everything in the control rods is solid, but I did not power the servos yet to check them.

Just powered them up with a servo tester and everything working as it should. Iā€™m also using individual servos, so thereā€™s a small amount of redundancy there.

@iampete is right that there could be a servo issue, but I think there is another explanation.
You can ARSPD_FBW_MIN set to 18, which is telling ArduPilot that this plane stalls below 18m/s, but the log shows that for most of the flight you donā€™t go above 18m/s:


as you have ARSPD_USE=0 that means that while you have an airspeed sensor, ArduPilot didnā€™t use it, it just logged it. The value it used is the synthetic airspeed estimate, which is CTUN.Aspd in the above graph.
The reason this matters is that ArduPilot disables the use of the PID integrators when you are below the stall speed. This is needed so that we donā€™t get a big integrator buildup before takeoff.
For this aircraft that matters a lot, as the plane is very poorly tuned. If we take a look at the earlier part of the flight, we see this:

you can see that the PID is not managing to bring the roll in line with the desired roll. There is an error of about 8 degrees. If the integrator had been working then it would have slowly increased the amount of aileron it applied until it reduced the error to zero. As it was ā€œbelow stall speedā€ it didnā€™t do that, and just applied the amount of aileron given by the P gain, which isnā€™t nearly enough.
The same happened when you lost control and couldnā€™t turn at the end. It applied the amount of aileron setup by your P gain, but didnā€™t apply more as the integrator was disabled.
The way to fix this is as follows:

  • set a correct value for ARSP_FBW_MIN. Looking at the log Iā€™d say a value of around 10 would be about right.
  • re-do your tuning. The values you have for the P gain is way too low for this aircraft. Iā€™d suggest at least doublilng it, and very likely 3x.
  • keep the ratio of P to I at about 5 to 1. So if you set P to 1.0 then set I to 0.2
  • as your airspeed sensor does appear to be working I suggest setting ARSPD_USE=1

I hope this helps!

1 Like

I have another question. If you look at the KMZ file of the log file, you will notice the following:


Dan_Jones has switched 4 times to auto mode. The first 3 times the plane follows correctly the waypoint-track (Blue, Yellow, Green track) . But the fourth switch to auto mode, the aircraft completely wrongly follows a course almost 90Ā° transverse to the desired track (Red) . What could be the cause?