While doing a PID adjustment in Yaw using the Zeigler-Nichols method of tuning I experienced a flyaway. I spent the majority of the day before the flyaway doing these adjustments in Copter-3.5.5 without incident using the same aircraft. The method had me fly in position hold up to about 15m and allow the craft to hover in the air. PID values were changed to what is below. ATC_RAT_YAW_P was changed using the channel 6 knob until the the craft was in a consistent yaw oscillation for approximately 30 seconds. PID values are changed back to a known working configuration and the craft is landed. From the logs better PID values can be calculated.
For this adjustment values were changed to as follows during midflight:
The channel 6 knob was used to change ATC_RAT_YAW_P from 0.100 to 2.000 but for the entirety of the incident was left at 0.100
The incident occurred after updating the Pixhawk to Copter-3.6.0-rc7. The craft was tested and confirmed to be working normally before the PID adjustment. The craft was flown up to 15m and the above values were submitted through mission planner. The craft began to move away from it’s position where as on the previous firmware it would stay fixed in one spot. Yaw was knowingly compromised but roll and pitch were as well on this flight which to my knowledge should not happen. Once the craft was about 500m away the transmitter connection was lost while telemetry signal remained. This put the craft into RTL and from review of the logs the craft slowly pitched toward home but aggressively rolled away from the home position. The last data point placed the tricopter at 44m AGL and a ground speed of 25m/s. The overall direction of travel was south with it slightly curving to the west.
The aircraft has not been found so the dataflash log is not available but I will attach the .tlog and the 3.5.5 parameter file and the 3.6.0 parameter file.
If reviewing the .tlog the flight with incident begins at about 81%
After some review of the .tlog in between my two flights the home position can be seen moving around and is lost before I take off for the second flight. Where would the RTL send the craft with null values in the latitude and longitude locations?
I was monitoring the Z-axis accelerometer in the tuning window on Mission Planner. I had set the update rate for sensors up to 50hz could this have bogged down the CPU enough to cause problems like this?
Sorry about the loss of your copter, that’s no fun.
I’ve had a preliminary look at the logs. I don’t yet understand the cause but here’s a few things I see:
- the vehicle flies off in PosHold mode. It is banking hard to the right and climbing.
- the home position looks OK, the vehicle does switch to RTL eventually but it’s a long long way off by then and traveling very quickly. I don’t think it’s an issue specific to RTL (i.e. nothing to do with a “lost” home position - there’s no way that I know of that the home position can be lost actually).
- the EKF seems OK, it’s not reporting a bad position or compass
- there is RC input arriving during the event. It looks like the pilot if mostly moving around the yaw before the vehicle starts moving… as it starts moving he/she gives some yaw (perhaps to correct the direction of the vehicle) then attempts to pitch back and roll left… this is the opposite of the way the vehicle moved so presumably the pilot was trying to (naturally) fight the movement of the vehicle. after that it looks like the pilot puts the sticks back in the middle but raises the throttle to maximum.
- there are a few parameter changes made about 40sec before things go bad:
- ATC_RAT_YAW_I = 0.01
- TUNE = 6
- TUNE_HIGH = 2000
- ATC_RAT_YAW_D = 0
I’ll have a look at this more tomorrow…
it looks like ATC_RAT_YAW_I was actually changed to 5.0, not 0.01.
I suspect that the relative gains for yaw versus roll and pitch were the problem. The yaw control started taking all of the control authority, and it lost control of roll and pitch, leading to it not being able to control position.
At the time it got into trouble the key parameters were:
that is very badly balanced, with far too much yaw authority, and not enough for roll and pitch control. We then see the attitude diverge from desired roll and pitch, and it flies away.
I wonder if it’s possible that this issue (fixed in this PR) was the root cause of the flyaway.
It’s hard to be completely sure but this will be released with -rc11 within a week.
@Patrick1, if this is the cause, we’re really sorry that a software bug contributed to the loss of your vehicle! If it’s any consolation, this probably contributed to finding the bug in the beta software so the official release will be a bit more solid.