I have a general question on APM 2.5 Throttle Failsafe, and then will follow up with tlog, log files and OSD video later...
I have been flying a reliable 3DR Robotics Y6 on release 3.1 for several weeks and yesterday had a bad crash from 400ft up. (For equipment Ardcopter 3.1 (APM 2.5), flying a 3D Robotics Y6, Frame 10, DragonLink, 5.8 ghz FPV etc.)
My question is,
- If I had the throttle failsafe setup and tested (fires at loss from DragonLink set to 1026 low)
- and show that Channel 3 raw did go to1026 for two seconds (some reason loss TX from DragonLink... yet to be determined.. may be FPV CAM interference) ....
- and if I see that the MP Tlogs show that the System stat went to "5 - Failsafe" two seconds after the TX loss ....
- and it wasn't a BROWNOUT on the APM board...
- and that the Battery FAILSE in not enabled ....
- and was flying in Stabalize mode at 400 ft up ....
- and I see in the TLOG (and MP telemetry log replay) that the APM board DISARMED immediately after the FAILSAFE event ... INSTEAD of doing an RTL (the main reason I have Failsafe turned on!)
THEN
- what kind of circumstances could have caused the APM to DISARM at the FAILSAFE event, when the copter wasn't sitting on the ground and/or with the throttle set to zero?
I have full OSD video of the flight, along with TLOG and downloaded LOG file.I will follow up with submitting these for help.
In the meantime, I would appreciate it if someone knows of any general conditions that could cause such an un-welcomed response from the APM Failsafe function....
Background:
I had this same failure on my Hexacopter on November 2013. Randy helped me back then on 2.9, but we never found a root cause. I subsequently thought it was a "flaky" GPS, but now on 3.1, a different APM board, GPS, another new Y6 model, new DragonLink TX (instead of 2.4), etc., I thought I had long left that issue behind.
I was fortunate that the fully loaded Y6 feel to its death from 400 feet upside down. Had it hit feet first, my GoPro 3, Tarrot Gimbal, and 8000 mah bat would probably have been destroyed, if not in flames.
In any case, other than everything being sheered off the upper deck, including the APM 2.5 board, all parts seem to be functioning and just need to rebuild.
I just really need to find the root cause of this type of crash before risking again. I know that there are others that have run into this issue and hope that someone might have put their finger on this issue.
Replies
Hello,
I am having the same problem with motors shutdown while in RTL, please check my problem at
http://diydrones.com/forum/topics/rtl-and-motor-shut-down
thanks.
Hi Mike,
Randy asked me to look at your log. It is a very odd log. Looks like you browned out.
The dataflash log stops 134m in the air. The system time on the last dataflash log GPS message is 619.521, and the tlog shows a short (1.5sec) pause in GPS messages at the 620.721 mark, then continues on until 625.908, at which point the copter crashes.
In addition, AHRS.error_rp spikes immediately after the pause, showing an estimated error of 30 degrees. No associated GPS glitch, so it would follow that we just stopped updating the attitude solution for a couple seconds.
I suspect we could recover a copter like this, if we had some way to work out on boot that we just browned out and re-arm. Could be really dangerous though! I think I'd rather it just crash far away from me than randomly spin up to full power on boot.
So my questions for you are, do you have any other logs on the dataflash, and how are (were) you powering your APM? Power module?
Jonathan,
I've attached the video of the crash that was captured in the HUD view of Mission Planner. I loaded it to YouTube and the link follows.
OSD/HUD Video of Crash (Low Res)
Thanks for the observations you have submitted from viewing the logs of my FAILSAFE/DISARM crash. I reviewed the points in the log that you highlighted but not sure that I understand the APM brownout you saw.
In any case, during my flights, besides having the MP Tlogs, I also capture the raw AVI in the HUD display, which is recorded on the laptop. I also have the HD video from the GoPro 3 (which has the audio, and you can hear two points where the motors shut down). The AVI (not so great video) does show both the TLOG and OSD before and after the FAILSAFE even.
Two key things that we have been centered in on at this point from all the great help ...
1. It seems that if my DragonLink receiver did suffer a "brownout", then after the FAILSAFE, the throttle would have gone to zero, and it would have DISARMED during flight, just as seen in the videos. This is still currently a bug with the ppm encoder (as Randy stated).
2. Immediately after the FAILSAFE/DISARM, the copter flipped and fell all the way down UPSIDE DOWN to its death. I'm sure that GPS went crazy, and maybe other APM functions ....
Also, it can be seen that the current draw shoots up to over 60 amps on ascent right before the event...
By the way, the power design before the crash was using one 8000 mah 4s battery to supply the APM 2.5 PM, DragonLink receiver... and with a 12volt stepdown converter, it also supplied all the FPV and lighting equipment.
Also, Mike from DragonLink has gotten back to me and said that the receiver should really run on at least 5 volts and above. I was pulling the receiver voltage from the APM board's receiver inputs (and I think its at a max 4.5 volts during good times).
In my new rebuild, I have removed the JD-board/LED's and have a separate 3s LIPO for the tarot gimbal, FPV 1 watt TX, and Sony CAM. I also have taken Mike's (DragonLink) recommendation and added a 5 amp UBEC to convert a dedicated 6vots supply from the main 4s 8000 mah flight battery. I have tapped in to the 4s, immediately before the APM's power module. This way, APM can use its 4.5 secondary voltage only for the APM and minimosd. Since its a 3DR Y6, I no servos to worry about.
I hope the attached video will help to "visualize" what happened and can shine more light on the logs that were captured. On the HD video capture from the GoPro camera, when the FailSafe Event occurred, you could hear that the motor total shut down as it flipped and fell.
Thanks,
Mike Governale
Hi Mike,
I have experienced the same problem however I know now it was due to no power supply rail to the output side of the APM. I did not realise that the 8 esc's on my octo had no bec's and as there are no servo's to drive and indicate poor power, did not see that insufficent power to the output was being delivered (J1 removed). It must have been some stray voltage from the esc's enough to drive the o/p circuits enough (measured later to be around 3.2 volts or so) and had flow 10 or more times but then one day.......shut down in flight and flipped upside down to its death (it was DOA before it hit the ground so it felt no pain...)
So now I put a seperate BEC on both input and output. I tend to remove the 3DR power module +ve power pins as I sometimes draw power to drive pan /tilt servos from the APM via the input BEC (castle creations 10A) Havn't had a problem since. It does say in the old WIKI to put power on the o/p side but I must have missed that little important detail when I was starting....
Thanks Choppy.
I know its a twisted feeling, but it sure felt good to hear that you still have nightmares of a similar crash.
I was so glad you documented a low voltage down to 3.2 volts from the APM supply. This is most certainly what caused my brownout on my DragonLink receiver. Mike (from DragonLink) told me that it needs above 5 volts to be happy and he had no idea how mad the chips might get below 4.5 volts.
Again,
Thanks for your help and information. As you can see from this long discussion thread, there are still a lot of good generous people in the world..
Mike Governale
The throttle failsafe really is meant for inferior radio setups... the dragon link you have is very advanced.. The way I setup failsafe is to set the sticks and my switches to my intended behavior and program that as the dragon link failsafe. This really is way more advanced
Thanks Julian for your reply.
I'm somewhat confused.
You are right, my DragonLink's are hight quality.
If I just program the DragonLink receiver (at TX failure) to go to stick settings that will have the throttle raised to either still hover (and pitch/roll set to a slight circling scheme), would this not still introduce the danger element that APM developers have gone to great lengths to avoid with their advanced conditional FAILSAFE logic?
If a user lands and turns off his transmitter when approached the copter before it is disarmed, then won't the receiver spin it up to maybe mid throttle?
I must be missing something.
Please help me understand the more advanced failsafe method you suggested, that does not use the APM throttle failsafe (along with its GPS, battery and other interegrated logic in its implemented FAILSAFE functionality).
In the days of Flying LOS our Heli's, and multicopters with our simpler FRYSKY receivers (and no sophisticated flight control boards), your suggestions was the approach we used for failsafe (at the receiver level only).
I value all suggestions but am just trying to fully understand appreciate this one.
I must be missing something with my DragonLinks..
Mike Governale
the scenario of the user landing and turning off transmitter has to be aimed at a less experienced modeler... For you, my recommendation was to use the dragon link to set all channels to exactly how you would like to operate in a failsafe situation.
Would adding one of those little capacitor to your rx pins help to avoid brownouts like this ?
Thanks for the suggestion but after talking with Mike from DragonLink, I found out that the receiver is happier with 5 and above volts. Using the power off the APM boards input rail I think that at its happiest will only be 4.5 volts. From this and Mike's suggestions, in my rebuild, I have put a separate 5 amp 6volt step down converter off the 4s flight battery right before APM's PM. Also, I will supply the FPV system with a separate 3S LIPO. With the new power isolations, I'm hope to get past this issue. I could be wrong.
Also, I'm just about to reply to Jonathan and attach a couple of videos of the crash. You might be interested.
I always hate to watch, but the videos also add to the forensic evidence.
Mike Governale