Hello,
I need a bit of help. Today, after 2 years and 100's of flights, I lost my plane due to low RSSI Failsafe. The problem is, I failed but not safe.
The low RSSI happened without warning. It was not a graceful degradation that usually occurs but a 2 second okay >>> fail.
The issue is the plane went into circle but applied no power to motor and the elevator was at -14 degrees!! The plane lost altitude and crashed into a fence. It was stolen before I could retrieve it. :-((
Why doesn't failsafe result in full power and climb??? Did I set it wrong? This is the first time I've actually had an all out failsafe. Well, it didn't work!!! Very disappointed!!
Regards,
Steven
Replies
Tridge and Iskess,
On the last post of page 1, I supplied a recent tlog. I would be very appreciative if either of you have a moment to review it. I still can't figure out what went wrong.
If I made a mistake or there is an error in the code, either way, it would be helpful to the community in preventing a needless crash.
Thank you,
Steven
Since the log you posted isn't from the ill fated flight, there isn't much to take from it other than extracting the parameters. I'm not seeing any issues with your settings. You had it configured to CIRCLE upon FS_SHORT which is what it did. I don't know why it didn't hold altitude. I fear we may never know without a log. I'm a real believer in having MP connected for the .tlogs to act like a Flight Data Recorder. Even if your plane hadn't been stolen, sometimes the .logs are damaged in the crash.
Sorry for your loss.
FS_BATT_MAH 0
FS_BATT_VOLTAGE 0
FS_GCS_ENABL 0
FS_LONG_ACTN 0
FS_LONG_TIMEOUT 9.073
FS_SHORT_ACTN 0
FS_SHORT_TIMEOUT 1.99
ALT_HOLD_RTL 7500
TERRAIN_ENABLE 1
TERRAIN_FOLLOW 1
TERRAIN_LOOKAHD 2000
TERRAIN_SPACING 100
Iskess, thank you for your reply. Normally, I use telem and use MP as "black box" flight recorder. This time I was going for a short flight and used only the OSD. I also recorded the video feed.
The settings on the flight that crashed, were unchanged from those in this tlog. The revisions of MP and PH FW were also identical. I was hoping that you or Tridge would be able to spot something in an obscure parameter that I may have set wrong.
Anyway, on my next plane, I will test FS with under real conditions. This event, however, does chip away at the confidence I had in the PH, SW and FW. For example, have you tested the Terrain Following FS in an actual FS mode? That would be a really scary one. You will lose RC and Video due to line of sight and just have to cross your fingers the plane makes it over a mountain or hill.
Also, it anyone sees a Skysurfer with Mobius, Telem, TSLRS and PH for sale from S. California, please let me know. :-)
Andre K. > your disappointment shoud be in your own inability to RTFM, and test features before depending on them, aka, flying responsibly.
You may want to read (or re-read) the link mentionned above from that US Air Force pilot. Or maybe you think that him too flies irresponsibly, doesn't RTFM and deserves his crashes, and why, if he could just do RTFM and fly responsibly, problem gone?
Knee jerk, condescending reactions of the "I know better" type, blaming messengers, do not solve problems, they actually add to them. Understanding exactly what happened, working on documentation, and fixing possible bugs does. And this will lead to an environment that is even better. Glad Tridge is thinking that way too.
Here is that link again just in case: https://groups.google.com/forum/#!searchin/drones-discuss/failsafe/...
It's happened to me twice where my failsafe kicked in and APM tried to return to default altitude, problem was I was over a hill, so it cratered. Since then the APM code was changed and it would use the glide slope to come back.
Yep, that's why I was excited about the Terrain Follow feature on Pixhawk. But something did not follow the script.
your disappointment shoud be in your own inability to RTFM, and test features before depending on them, aka, flying responsibly.
rest assured that RTL does work, and luckilly, not the way you suggest (which brings us back to RTFM).
The community and your (unmentioned) flight controller is disappointed by irresponsible flying, should you ever find the .log and have RCIN logging enabled, we will tell you exactly why you failed. :)
> your disappointment shoud be in your own inability to RTFM, and test features before depending on them, aka, flying responsibly.
This is Mark Jacobsen, the US Air Force flying safety officer who wrote the aforementioned post about the many errors in the failsafe documentation. Andre, your comments reflect a harmful attitude that ultimately undermines the safe operation of these aircraft. I'm coming down hard because I'm passionate about this. We need to do better.
Aircraft mishaps usually do trace back to human error, but the key insight of aviation safety is that mishaps are never because of ONE error. There is a causal chain of events that can include everything from engineering deficiencies or inadequate flight manuals to leadership or training. If we want to reduce the rate of mishaps, we need to systematically identify deficiencies and make continual improvements at every link in the chain. If we put the burden solely on the pilot--who is, in many ways, the last defense against a mishap--we will never address those other links. The 3DR/APM communities should be focused on engineering out the risk of human error to the maximum extent possible. Documentation, training, and a supportive community also play critical roles. This is still an emerging technology with a steep learning curve, so we know there is room to continually improve its reliability, safety, and accessibility. Fortunately, this technology has an amazing community standing behind it who can help that process along. And that, fortunately, is the attitude and role that most community members take.
When something like this happens, the community should be looking for -all- the causal factors involved. Pilot error will likely be a key contributor, and should be addressed, but we should also ask ourselves, "Why did this pilot error occur?" That's where the discussion starts to get interesting. That's where we start noticing the errors in the failsafe documentation; where (going back to your point) we ask HOW users are supposed to test failsafes on the ground; where we ask about how accessible SITL/HIL are for new users; where we ask what training resources are available to teach new pilots how to test failsafes; and so on. I will leave these questions for discussion.
This is how we improve safety, reliability, and the user experience... not by berating pilots who experience a mishap. Especially when, in this particular case, the manual is completely wrong (I have had numerous crashes and a costly, dangerous flyaway, in which my confusion over failsafe modes was a contributing factor).
Just as an aside, 3DR and the dev team have been completely supportive of helping remedy any deficiencies. I've been talking to Tridge and others about helping rewrite the ArduPlane failsafe documentation. I am hoping to begin that project this week. I welcome any inputs!
Thanks for the support. Just as background, I have a pilots license. I flew small, fixed wing, planes. I would classify myself as a very cautious FPV pilot but not infallible.
In this instance, I suppose one could claim pilot error for getting into the Throttle FS. I accept that. As I said, I have never had a FS before, so I depended on what I "thought" I had read in the documentation. With terrain following implemented just recently, I felt secure that in almost any FS situation, the plane with be "safe". Well I learned something right off the bat, in FBWA mode, circle is ALWAYS the first loss of signal FS action. I thought, wrongly, that I had set that to RTL. None the less, Tridge stated that the Circle mode should maintain altitude and if Terrain Follow was enabled, follow the ground contour.
Coming from a highly technical area of the Aerospace industry (rockets and satellites) I'm a firm believer in a complete Failure Analysis and Corrective Action. In starting this post, that's what I was my goal was. So, I would still like some help looking at the tlog I posted on page 1, bottom. If I did not set a parameter correctly or made some other error, identifying that would help others. On the other hand, if there is a code issue, that can be fixed as well.
As far as the documentation, it's come a long, long way. That said, maybe it could use some "for Dummies" polish. I prefer the example walk through myself. For instance; If you want to set Throttle FS, here's step 1, step 2, (and like the Dummies series, the little bombs for the really important stuff)
Thanks,
Steven
You need therapy if question marks and the word disappointment triggers a tirade...I hope you don’t have any small animals!
Perhaps you didn't see that I've been flying FPV for years, with almost 1,000 flights and this is the first mishap I've encountered. Perhaps you didn't read Tridge's response either where he says Circle is supposed to maintain altitude or follow terrain, if it is enabled. Perhaps you also didn't check the link I provided from a military Safety Officer critiquing the documentation. https://groups.google.com/forum/#!searchin/drones-discuss/failsafe/... Perhaps you didn’t read that I did find a log and attached on page one. You also missed that I did mention the FC, a Pixhawk. Lastly, would you be disappointed if you lost your plane and someone stole it!!
So maybe you need to take you own advice and RTFThread! Before you comment!
-
1
-
2
-
3
-
4
of 4 Next