We would appreciate some help on understanding the cause of a crash that happened recently after many hours of normal flight operations without significant issues.
We had two consecutive crashes on two consecutive days, with two different helicopter platforms of the same model and configuration. Both crashes showed almost identical patterns on similar conditions and coordinates while repeating the same mission plan. Currently we are still investigating whether the problem comes from a HW or SW issue.
We managed to retrieve a DataLog from the 2nd crash (000019.BIN), but from the 1st crash we only have the Telemetry Logs from our GCS. Both are linked here:
Both platforms are traditional single rotor helicopters running ArduCopter v 4.0.1 and are powered by a gas engine using Ardupilot’s internal RSC governor.
Here’s a snapshot of the crash logs with relevant info. From RCOU, C3 is the Collective channel and C8 is the Throttle channel.
As you’ll be able to see, right before the sudden drop of altitude there’s a drop of RPMs to almost idle while the C8 throttle is not correcting for it or even causing it, we think here’s the key to the issue, but we still don’t understand why this is happening.
Hi Miquel,
Sorry to hear about your crashes. Unfortunately I think your problem was due to a bug in the software at that time. I haven’t looked at your data but if you were in auto mode when it happened then I’m pretty sure this was the issue. Here is my post on this when I first learned of it.
It is best to continue to upgrade to the latest version of at least to the latest point release within a major version (I.e. 4.0). In this case I would recommend upgrading to 4.1. We have released a stable version of 4.2 but we are still making point releases in this major version.
There is one other concern that could be an issue and that is that your H_COL_MID is set too high. I will have to look at your log to be certain of the cause
If this is the case, it seems it was a well documented bug! We will probably update to the latest 4.1 release (V4.1.5) as soon as possible on most of our platforms and review the H_COL_MID parameter as well.
Miquel,
I just looked at 0000019.BIN file that you posted a link to. It shows that the version of software was 4.1.5. I looked at your value of H_COL_MID and it appears reasonable. Looking at the log, the helirsc servo that is linked to the throttle servo or ESC (not sure of your powerplant) is reversed. so in your plot where you show the RCOU.C8 and it goes to 1000pwm, that is actually full throttle. The collective goes full up. So at first glance this doesn’t appear to be related to what I posted previously. This really looks like the engine stopped since both the collective and throttle go to max. That would be strange that it happened in the same exact place in the mission for two separate aircraft.
What is the powerplant in this aircraft?
Reviewing the tlog file, I see that just before the power loss, there is a command that is a set servo command. What is that doing? What servo is it affecting?
Thank you for looking at our logs. It does seem that we misinterpreted the C8 parameter and it does try to correct the loss of rpm/power from the engine. An engine failure could be plausible, but the same issue happening with two different platforms seems really odd.
We are using a Gaui 100cc air cooled engine for one of the helis and a water cooled version for the other.
The servo event you are talking about is related to our payload, a start-stop recording pwm signal. It shouldn’t affect the heli operation.
We have been reviewing our logs after a third crash with a similar pattern. We had reviewed and updated all our Arducopter versions to v4.1.3 (we had already succesfully used this version before), but it seems it didn’t solve the issue.
With the third crash, we had performed a successful previous flight with an identical mission and PL, so we could compare both logs and see where they were differing.
Our H_RSC_MODE = 4 (AutoThrottle) is set up with a target 6500rpm and +/- 400rpm margin. The Throttle curve is normally adapted to the flight conditions before every operation.
We noticed that in the in the first successful flight, the aircraft was approaching the 6100rpm margin limit at a certain location, but it wasn’t reached. On the 2nd flight and the same location, the 6100rpm is reached, it triggers the deactivation of the Governor to the open loop method and the Throttle input seems to be reduced drastically, causing a higher decreese of RPMs and altitude.
If we go back to checking our previous crashes (0000019.BIN) with the DataLog, we can see that indeed when the Governor is deactivated, the Throttle curve goes from 100% to 70% drastically, which doesn’t help on the RPM recovery:
We are aware that our helicopter is flying on its operational limits and that’s why the initial loss of RPM might be happening (we are working on it), but the Throttle decrease issue when changing from AutoThrottle to ThrottleCurve might be worsening the problem? Is this a normal behaviour?
@mmulet i am sorry to hear of another crash. Thank you for your analysis, it has helped me determine what the problem might be. So this governor has fault logic. The H_RSC_GOV_RANGE is used to determine when the RPM sensor may have broken. It was good that you increased the range for the governor to 400 however this may not be enough. Have you tried testing the governor in a full collective pull from a hover. This would test to see how much the rotor would droop and how well the governor is tuned. I would ensure that the range parameter is larger than the droop in RPM from that test. I would also test the over speed in a collective drop. That would also cause the governor to go into a fault logic. Lastly make sure that the throttle curve is tuned so that it keeps near the desired rotor speed in steady conditions at different collective settings.
