Hello All. First off, thank you to all who have worked so hard for this community!!

I am posting this here(as opposed to the main thread) on the advice of other members.

I just had an event happen with a new quad I assembled.

I know the setup was incomplete on this quad. I had intended to fly only in stabilize to test my camera gimble.

I had an RTL trigger with a resulting significant crash and would like to know why.

If someone could please help analyze my Flash log(no telemetry during this flight) for clues, I would greatly appreciate it.

My setup is as follows:

APM 2.5 with ublox and seperate external compass.

Dji 450 motors and arms and 10x4.5 props with a custom spider style frame.

30amp simon K flashed f30 speed controls from RCmanchild

Tarot Gopro gimbal with separate 1000mah 3s pack

Single 2800mah 3s main pack(incorrectly setup as a 5600mah dual pack in apm)

FRsky tfr4-b receiver with ppm single input to apm

Futaba T8FG transmitter

900mhz 3dr telemetry( Not connected during this flight)

The flight went like this. powered up quad, turned on Gopro(in wifi mode) and took off to get an aerial shot of a bus leaving an event. It was windy, but quad was quite stable. I got up to about 100 feet alt and about 100 feet away and quad did a piroette(spelling?) then stabilized momentarily, then pitch hard forward and away it went from 100' to the ground at about a 25degree angle. I know the logs show RTL triggered. Can someone tell me specifically why?

What I assume was a Radio failsafe. But it appears to me the roll in and pitch in are still registering my stick inputs.

******Attached Tlog is for reference only. It is from my only previous test flight. Exact same config as main event. There is outdoors hovering with GPS lock at about 70% in this Tlog*****

Here is a link to the onboard video from this event.

Onboard view of unexpected RTL

 

Thank you for any help on this,

Frank

Views: 1308

Attachments:

Reply to This

Replies to This Discussion

I think it comes down to the code does not have a "Failsafe" for the failsafe. It can not recognize that it has lost control, it simply continues to do what it thinks will solve the problem.

It would be a great next step in the development of the code to put a watchdog in place for just such events and switch to stabilize and land. I know that in my case, if you watch the video, you can see there was well over 5 seconds where it was outside of any reasonable possibility that it had control.

I am very happy with the performance of the code and the speed at which it is developing. Like many others, I have had problems with the learning curve.

My Failsafe and consequent RTL event came down to improper/incomplete setup.

If I can make 1 suggestion to anybody first setting up their Copter it would be turn of Failsfe RTL until you have tested RTL is working as expected.

Frank

 

I agree with all that - except for the fact that on mine RTL was working well, and always has been, and only two days previously I had flown in gusty winds with accurate performance in loiter and RTL - and changed nothing on the setup in between times. So being happy with "deliberate" RTL one day is apparently no guarantee that it's safe to turn on failsafe RTL another day. It's not just down to setup, there is clearly something that can cause this behaviour on a previously-working system.

Anyway. To get back to your question of why the failsafe triggered in your case. Presumably there's no chance that you accidentally powered on the Tx module in range testing mode? (Which reduces the output to something like 3% of normal, from memory). I use FrSky too and with a telemetry receiver you get some serious beeps from the Tx when you're going out of range, so you'd have noticed that if you have the same setup and were actually out of range.

Failing that I notice you're using PPMSUM. I've not tried this. But I'm aware there is, or was, an issue with the FrSky implementation of it that can cause it to drop out if more than 6 channels are used. Could this be relevant? See 

http://diydrones.com/profiles/blogs/why-frsky-cppm-signal-is-so-dis...

Same thing appears to be happening to a lot of people...RTL and LOITER are making the aircraft pitch violently in one direction (mostly seems to the right and away from the pilot), go to high throttle, and fly into the ground at a steep angle.

Happened to me 3 times today...last time in fatal crash.

I guess it did a reboot at crash spot...

Yes, me too, but the weird thing is that it doesnt always happen. But when it does happen it goes to the right, where right is the starboard side when looking from the back of the copter towards its front.

Frank,

    I've had a look at your logs and there are three radio failsafe events so it looks like your tx and rx lost contact (and regained it) a few times.  There's also a compass error in there but that's that as it crashes so perhaps the external compass was ripped off.

    Your logs look very similar to Harry's in that it also shows the desired velocity and actual velocity diverging massively which is most likely a compass issue.  It looks like you did set your compass orientation to ROLL_180 which is the right value if you're using the 3dr gps+compass module.  If you're using the stand-alone compass then it depends how you mount it.

   The issue was not compass interference (at least according to the tlog of the previous flight).  The interference looks quite low vs throttle.  I see your point about more failsafes when things seem to be going horribly wrong.  We have GPS glitch protection coming in AC3.1 which will hopefully reduce the fly-aways caused by GPS problems but wouldn't help in your (or Harry's) case.  Some kind of check of the desired velocity vs actual velocity is possible so I'll look into that and chat about it with the dev team.  Thanks for the suggestion and sorry for your troubles.

Thank you very much Randy for taking the time to review this.

My external compass did indeed get completly removed in the crash.

Can you please confirm one thing for me.

When RTL is triggered via failsafe, does the code ignore all user inputs until another mode is requested?

Also, thank you to Harry for calling attention to this thread!

Frank

Frank,

     Yes, RTL ignores all user input on the roll, pitch, yaw and throttle channels (it still allows input on flight mode, tuning and aux switches) until it gets to the landing stage.  As it starts descending in the landing stage the horizontal control is the loiter controller so you can push around it's horizontal position with the roll and pitch sticks.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service