HobbyKing.com New Products Flash Sale
Reply
Thread Tools
Old Nov 01, 2011, 07:26 AM
RH Guy
RHash's Avatar
Oahu, Hawaii
Joined Dec 2007
417 Posts
Discussion
FPV Crash - caused by Eagletree/guardian lockout?

I just recently got a guardian stabilization and installed it in my FPV setup. Flashed the Windows App to 10.08. I flew it a couple of times (successfully) - the guardian seems to work much better than the FMA copilot system I previously had.

However, my last flight ended in a crash, due to an apparent OSD system lockout. I had entered RTH mode to test the system out in windy conditions (using the Carlyle method). Almost as soon as I hit my RTH switch, a "stabilizer disconnected" message came up on the OSD, and everything locked out. Attaching link to the video (luckily I was recording this off my ground station receiver). At about 3:10 is where the event happened. Notice that all data freezes right after RTH mode is entered.

Any ideas on what happened here?

10-30-11 RC Crash (3 min 24 sec)
RHash is offline Find More Posts by RHash
Reply With Quote
Sign up now
to remove ads between posts
Old Nov 01, 2011, 10:25 AM
Registered User
Norway, Hordaland, Bergen
Joined Feb 2009
280 Posts
Hi,

I feel sorry for you. Did you not get control back when you returned the rth switch?

But I think you should attach config file from your osd and guardian, and the elogger data file, then it will be much easier for someone from ET to help figuring out what went wrong..
Megafluffy is offline Find More Posts by Megafluffy
Reply With Quote
Old Nov 02, 2011, 03:49 PM
billpa's Avatar
Joined Nov 2003
4,920 Posts
RHash, sorry to hear about this! We're digging in to try to figure out what could have happened here. Our best theory right now is this:

a) the four pin cable either came loose, or one of the yellow or brown wires in the cable broke, between the eLogger and the OSD/Guardian. This caused data to stop being sent to the OSD. Are you able to check to see if the 4 pin wires are intact now? I realize they could have come loose in the crash, but if everything is still connected with no broken wires, we could at least rule that out.
b) If something goes wrong with the Guardian/eLogger connections, stabilization simply switches off, and full control is maintained albeit without stabilization. This happened in your case (the "disconnected" message indicates this mode was triggered). However, we had the "dual failure" of this situation occurring when RTH was also triggered (though the RTH was manually triggered, of course, rather than having an actual link failure). Do you recall if you tried to disable RTH by moving your throttle when the problem started? That will help to prove or disprove this theory also.

Please do post your OSD config file (.TXT) here or attach it to a web ticket at http://ticket.eagletreesystems.com, which may help us further narrow down the problem. Also, any other info you can give would be very much appreciated.
billpa is offline Find More Posts by billpa
Site Sponsor
Reply With Quote
Old Nov 03, 2011, 06:32 AM
RH Guy
RHash's Avatar
Oahu, Hawaii
Joined Dec 2007
417 Posts
Hi billpa,

Thanks for your quick response. Yes the 4-pin wires are intact. I bench tested the system and all seems to be OK - I tried wiggling the connector to try & see if plane vibration may have caused a comm break but it remained solid. I find it rather hard to believe that connection would have worked loose by itself in flight.

During the flight, I turned off my RTH test switch as soon as I sensed something was wrong, but I could not control the plane (I was applying full up elevator pretty much all the way down). I can't remember if I moved the throttle, though I do know from previous flights that simply turning off the RTH switch takes the system out of RTH mode.

I was able to recreate the "Stabilizer disconnected" message while bench testing by pulling out the guardian connector from the OSD while powered up. However, I can still move the control surfaces with the tx in this condition. If I pull the guardian connector off, AND turn off my tx (simulating a control lockout), then everything freezes. However, if I do this while in flight simulator mode, the system does move the servos as if trying to return to home (albeit without the benefit of stabilization).

The only thing I can think of (other than a system glitch) is the guardian stabilizer connector came loose just when I entered RTH mode (again, hard to believe), AND I had a control lockout at that moment. BUT . . .if the system is still trying to RTH, would it at least try to get the plane flying again?

The order of connection in the comm link chain was v4 logger - OSD - guardian - alrspeed indicator - altimeter. Does changing the link connection order make a diff?

Attaching my config file and my v4 elogger file (I changed the extension from .fdr to .doc so I can post it here ). Hope this can be sorted out.

Thanks!
Ryan
RHash is offline Find More Posts by RHash
Reply With Quote
Old Nov 03, 2011, 12:20 PM
billpa's Avatar
Joined Nov 2003
4,920 Posts
Hi Ryan,

Thanks for the update and the files. I'm glad everything is working on the bench, but had hoped you'd find a broken or loose wire. Do you remember if all the wires intact when you recovered the plane? One other possibility - is there any chance the male pin connector on the altimeter (which was at the end of the chain) could have shorted with something else?

Re the RTH behavior you're seeing on the bench test, the servos should go to their failsafe positons if you are in RTH mode and no valid GPS signal is reaching the OSD. The assumption is that GPS signal will be restored, in this "double whammy" situation. However, in your case, all data stopped coming to the OSD, so that would not have happened. In the case of the simulator, GPS data is simulated so it is not interrupted.

No, the connection order does not matter.

I'll be going through the data you attached, and will post soon with additional findings.
billpa is offline Find More Posts by billpa
Site Sponsor
Reply With Quote
Old Nov 04, 2011, 03:09 PM
billpa's Avatar
Joined Nov 2003
4,920 Posts
Hi Ryan,

I have examined the logged data and the configuration settings, and it confirms my original theory. The eLogger stopped collecting data from all the sensors shortly after RTH was triggered, and the OSD detected this and put up the "Disconnected" message. Since RTH happened to be engaged when this happened, control didn't return to the sticks.

So, the big question is why the eLogger stopped talking to the sensors. Here are the possibilities I can think of:

1) a loose or intermittent wire between the sensors. For this to happen, one of the yellow or brown wires would have had to break the connection (not both) or a short circuit would have had to happen. If one of the connectors was only partially connected, and was pulled to the side, this would explain it. Or, if there is corrosion on one of the connections this could also happen.
2) the 4 pin connector at the end of the sensor chain shorted against metal.
3) The main pack became disconnected. This would only be a possibility, of course, if you are using a separate video battery.
4) your eLogger or one of the sensors had a hardware failure. Do all the sensors still work?
5) there's an as of yet unknown issue occurring with that combination of sensors. However, that's a very standard combination, and there have been no other reports like this, so I don't think that's the issue. But, we're going to set up a system that will be stress tested over the weekend with your exact combination of sensors and settings.

If you you don't think it's one of the first 3 issues, I'd like us to get your hardware in for inspection/replacement. If you'd like to do this, please open a ticket with us at http://ticket.eagletreesystems.com.
billpa is offline Find More Posts by billpa
Site Sponsor
Reply With Quote
Old Nov 04, 2011, 07:57 PM
RH Guy
RHash's Avatar
Oahu, Hawaii
Joined Dec 2007
417 Posts
Yes all of the sensor wires are intact. Some of them were disconnected and the pins bent, but that was definitely due to the crash impact.

It's unlikely that the altimeter pins would short to anything - the fuse was foam and I had the altimeter sitting in a niche I created on the outside of the fuse.

All the sensors seem to work OK (I think having a foam fuse helped a lot in cushioning the components from the impact). I can't test the GPS yet - it was just vecroed to the tail boom, with the wires tie wrapped - the impact sheared the unit off at the solder joints. I hope it's just a matter of soldering the wires back. The GPS looks physically OK.

For the possibilities you mention:

1) All the connections seem to be OK in the sensor comm loop. However, I notice one of the GPS signal wires at the logger connector is frayed. It might have been like this pre-crash. Can a comm break in the GPS connection also cause such a lockout?

2) Unlikely

3) I am using a separate video system batt. I'm also using a BEC off the main pack to power the control receiver and servos. There is a possibility the BEC lost power, but it seems fine during my testing. Does the elogger & OSD get power from the batt connection, or the 3-pin receiver connection(s)?

4) Yes all sensors still seem to work. I still need to resolder & test the GPS though.

5) OK - noted.

I think 1) and 3) are the most likely culprits. During the flight it felt like entering RTH mode was the trigger for the event, but this may have been just bad coincidence.

Thanks for all your help - I will post updates if I find anything else.
RHash is offline Find More Posts by RHash
Reply With Quote
Old Nov 08, 2011, 02:50 PM
Registered User
Joined Aug 2010
864 Posts
I was able to recreate the OP's failure. My summary has been moved to the Eagletree OSD thread.

http://www.rcgroups.com/forums/showt...0#post19822090
thekubiaks is offline Find More Posts by thekubiaks
Last edited by thekubiaks; Nov 08, 2011 at 03:09 PM.
Reply With Quote
Old Nov 08, 2011, 04:38 PM
billpa's Avatar
Joined Nov 2003
4,920 Posts
RHash, thanks for the update.
Quote:
I notice one of the GPS signal wires at the logger connector is frayed. It might have been like this pre-crash. Can a comm break in the GPS connection also cause such a lockout?
If it is the yellow or brown wire, no, that should not be able to cause this issue. It could certainly cause GPS failure though.

Quote:
I am using a separate video system batt. I'm also using a BEC off the main pack to power the control receiver and servos. There is a possibility the BEC lost power, but it seems fine during my testing. Does the elogger & OSD get power from the batt connection, or the 3-pin receiver connection(s)?
I don't think this is the issue. The eLogger gets its power from the main pack, and optionally through the eLogger's throttle input, if connected to your receiver. The OSD gets its power from either the eLogger and/or the receiver. For the symptoms to be caused by a main pack failure, the following would have to be true:
a) the eLogger lost power - this would mean that the main pack connections failed, and that the throttle connector could not be in place
b) the OSD continued to be powered. This would mean that the OSD was receiving power from the servo connections.

If the receiver is powered from your main battery's BEC, then the above scenario couldn't have happened.

I'm following up with thekubiaks also to see if his issue is somehow related.
billpa is offline Find More Posts by billpa
Site Sponsor
Reply With Quote
Old Nov 09, 2011, 05:20 AM
RH Guy
RHash's Avatar
Oahu, Hawaii
Joined Dec 2007
417 Posts
Hello thekubiaks - thanks for your post. What you experienced sounds a lot like what I did. I had also changed my menu input method to 3pos, so I could free up the aux2 for guardian gain control. And I also have the beta 10.08 firmware installed (I usually don't like to use beta firmware but I could not get the release firmware [10.04?] to install at the time.

The OSD reboot issue brings up an important point - there is a chance that I had entered the menu system (to adjust some values) via the 3pos tx sticks prior to taking off. Maybe even went through the servo analysis wizard. I can't remember if I did or not. But if I did go through the servo analysis wizard, there is the possibility that I did not unplug the main batt (i.e. reboot the OSD/guardian) prior to taking off. I was not aware you had to do this - I don't remember any mention of this in the manual.

If this is indeed the cause, then I will make a (strong) suggestion to put this notice in the manual. Better yet, make it a message on the OSD wizard after the last step (e.g. "Unplug main batt to reboot OSD" or something like that). Best option: fix firmware to do an auto reboot on exiting the wizard.
RHash is offline Find More Posts by RHash
Reply With Quote
Old Nov 09, 2011, 07:48 AM
Registered User
Joined Aug 2010
864 Posts
Quote:
Originally Posted by RHash View Post
Hello thekubiaks - thanks for your post. What you experienced sounds a lot like what I did. I had also changed my menu input method to 3pos, so I could free up the aux2 for guardian gain control. And I also have the beta 10.08 firmware installed (I usually don't like to use beta firmware but I could not get the release firmware [10.04?] to install at the time.

The OSD reboot issue brings up an important point - there is a chance that I had entered the menu system (to adjust some values) via the 3pos tx sticks prior to taking off. Maybe even went through the servo analysis wizard. I can't remember if I did or not. But if I did go through the servo analysis wizard, there is the possibility that I did not unplug the main batt (i.e. reboot the OSD/guardian) prior to taking off. I was not aware you had to do this - I don't remember any mention of this in the manual.

If this is indeed the cause, then I will make a (strong) suggestion to put this notice in the manual. Better yet, make it a message on the OSD wizard after the last step (e.g. "Unplug main batt to reboot OSD" or something like that). Best option: fix firmware to do an auto reboot on exiting the wizard.
I agree, the fact that both of us were doing the same thing and had the same lockout is a strong case for a reboot. The only problem would be for those that want to change gain values in flight for fine tuning. You wouldn't want the firmware to cause a reboot inflight.

I don't know enough about the inner workings of the firmware to know how to correct this but it needs some kind of fix.
thekubiaks is offline Find More Posts by thekubiaks
Reply With Quote
Old Nov 09, 2011, 12:12 PM
billpa's Avatar
Joined Nov 2003
4,920 Posts
Sorry, but I've created some confusion. After reconfiguring the OSD from non-guardian to guardian stabilization mode, several fundamental things change internally, including how RTH operates, and a reboot is indicated. This will normally happen anyway since the Guardian needs to be physically connected. I theorize that this is what caused theKubiak's issue, but that has yet to be verified.

Changes other than enabling stabilization mode, such as running the wizard, etc., do not require a reboot.

I am going to attempt to reproduce this issue when going from non-guardian to guardian mode and then enabling RTH without a reboot. Then, we'll get this documented (or fixed) if that's found to be the cause.

TheKubiaks, do you have the .FDR data from the logger that was captured when the issue occurred? That will let me completely rule in or out whether these two cases are related.

RHash, there is one thing that confuses me about your case: you mention that you were running 10.08, but the OSD config file and the data log you posted indicated 10.04. I had used that info to rule out a possible issue with 10.08. Is it possible that you installed 10.04 after the crash, and then collected the .FDR data and config file after that?
billpa is offline Find More Posts by billpa
Site Sponsor
Reply With Quote
Old Nov 10, 2011, 04:42 AM
Registered User
Melbourne, Australia
Joined Jan 2008
1,036 Posts
Hi Bill, I'd like to join this discussion if I may from the point of view of the desire to be able to control the Guardian stabilisation gain in flight.

Apart from what ever difficulties Rhash and thekubiaks experienced due to possible coding problems, it seems to me they were altering their systems from "Option A" menu control to "Option B" menu control so they could control Guardian stabilisation in flight.

I feel this demonstrates there are people that still would like to use 2 switches (or dial/lever) to navigate the menus, AND would also like to be able to adjust Stabilisation gain in flight.

Of course it is right that users are able to control Stabilisation gain using menu control "Option B" if they desire but I humbly ask that a Stabilisation control method be implemented using menu control "Option A".

Or at the very least that Stabilisation Gain go from the menu setting to fully on in the event of RTH being activated.

Perhaps another possible implementation (apart from my emailings to you and John), could be 2 menu Stabilisation settings. One level of gain for normal flight, and another level of gain when RTH is activated.

Of the 2 methods above and what I have previously suggested, I feel that gain level set by AUX2 switch position (or Dial/lever) would be the best because that would allow some relaxed hands off flying if one desired. It would also allow transmitter mixing to automatically set the AUX2 channel position when RTH testing is initiated by Carlyle method.

Further, I feel it desirous to be able to turn off or reduce stabilization gain in flight because I find normal flight with stabilisation to be quite un-natural in that normally when banking for a turn and relaxing the aileron stick so as not over roll, an aircraft will keep its set bank will pulling the elevator to turn, Then only requiring small adjustments of aileron stick to maintain bank angle.

With Stabilisation on, one is required to hold the stick over to maintain bank angle which feels un-natural to me.

With Centre Stick stabilisation activated, when the stick is moved outside the box (I tried as low as 2 so far) my glider wants to over roll. When I release the aileron stick my glider levels off out of the turn, so I have to keep modulating by large amounts the aileron stick to maintain the turn.

Sorry to take this thread slightly off topic to RHash's problem but I feel there is some relevance.

Best Regards
Geoff
garris2 is offline Find More Posts by garris2
Reply With Quote
Old Nov 11, 2011, 06:51 AM
RH Guy
RHash's Avatar
Oahu, Hawaii
Joined Dec 2007
417 Posts
Quote:
Originally Posted by thekubiaks View Post
I agree, the fact that both of us were doing the same thing and had the same lockout is a strong case for a reboot. The only problem would be for those that want to change gain values in flight for fine tuning. You wouldn't want the firmware to cause a reboot inflight.

I don't know enough about the inner workings of the firmware to know how to correct this but it needs some kind of fix.
Yes I totally agree! Although my policy is NOT to enter the menu while flying - I have crashed before while doing this, so I'd rather adjust values while the plane is grounded.
RHash is offline Find More Posts by RHash
Reply With Quote
Old Nov 11, 2011, 07:01 AM
RH Guy
RHash's Avatar
Oahu, Hawaii
Joined Dec 2007
417 Posts
Quote:
Originally Posted by billpa View Post
RHash, there is one thing that confuses me about your case: you mention that you were running 10.08, but the OSD config file and the data log you posted indicated 10.04. I had used that info to rule out a possible issue with 10.08. Is it possible that you installed 10.04 after the crash, and then collected the .FDR data and config file after that?
No, I did not update any firmware post-crash.

When I originally updated the firmware (pre-crash), I thought I had installed the beta version at the time (this was a few weeks ago). The "v10.08" I mentioned was due to my reading thekubiaks post - I just assumed this was the beta version number. I do remember I had a problem trying to download/install the release version - so I just clicked on what I thought was the beta version link. Maybe that was actually the release v10.04 I installed? The windows version in the about screen in my software does say that it is 10.04, so I guess I never did have the beta installed.

I notice the website is different now in that there is no beta version.
RHash is offline Find More Posts by RHash
Reply With Quote
Reply


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Discussion Eagletree Guardian gain problem Oscar J FPV Talk 2 Nov 01, 2011 10:37 AM
Help! T-28 RX cut out caused crash pow-wow Micro Ready-to-Fly 19 Oct 19, 2011 10:32 AM
Sold Complete EagleTree OSD Pro and guardian. bakchos FPV Equipment (FS/W) 9 Oct 04, 2011 11:40 PM
Sold EagleTree Guardian Dan777 FPV Equipment (FS/W) 2 Sep 19, 2011 09:05 AM
Discussion Fy-20a vs eagletree guardian? g3f0rc3 FPV Talk 6 Sep 05, 2011 08:09 PM