Zombie copter?

Post Reply
Noctaro
Posts: 280
Joined: Thu Sep 08, 2011 11:15 am
Contact:

Zombie copter?

Post by Noctaro »

Hi all!
I had a very creepy adventure 2 days ago.

As normal i did my testflights at a location, where i should take some captures. Anyhow, my copter behaved strange. As the windsituation wasnt the best, first i thought it was a gust that made it jumping up and down in a slightly uncontrolled manner.
I landed the copter and wanted to copy the testfootage from my cam. The copter was still powered on.
To my left was the transmitter Turnigy TGY-i6 with AFHDS. To my right the copter.
Suddenly the copter armed, without any input on the RC transmitter which was showing 0% RSSI error.
Of course i instant grabed the copter.(ouch my finger)
It was pitching one time forwards, one time backwards and then it went to full throttle and acted like in levelmode :shock:
Flightmode was set to acro the whole time.
The only way i could stop it was to turn it around and unplug the battery. :?
You know where it would have gone, if i could not grab it.......i am glad it was a small 300 size copter and not a big octo.....

Its a HK MWII Pro (the red one) with MTK GPS using official 2.4 release.
I have a bluetooth module running also. May someone have armed and controlled it via bluetooth? As AFHDS seems quite hard to hack......
Did not see such a behaviour since my old 2.4ghz transmitter without channel hopping, which i used five years ago....
Of course i did further testflights indoors, but was not able to reproduce the problem....even when the copter was sitting on the ground for around 4 hours with power connected....
With EZ-GUI i tried to arm my copter via bluetooth, but this also did not work. Is there an MSP-command for arming, that could have taken control?

How may this happen, i mean our rc signals are digital and secured, not any creepy analog signal that may just be overpowered or jammed....
Did anyone else have such a problem?
Any tips?
What may i try to reproduce?

I am totally scared :/

Pls help

Cereal_Killer
Posts: 221
Joined: Fri Mar 06, 2015 5:44 am

Re: Zombie copter?

Post by Cereal_Killer »

Do you have fail safe setup?!

Noctaro
Posts: 280
Joined: Thu Sep 08, 2011 11:15 am
Contact:

Re: Zombie copter?

Post by Noctaro »

Yes failsave is set and tested. Works as it should.

Cereal_Killer
Posts: 221
Joined: Fri Mar 06, 2015 5:44 am

Re: Zombie copter?

Post by Cereal_Killer »

Can you show us pictures of how you have everything connected? I think the LEASE LIKELY is that there was radio interference...

I had a VERY SCARY experience and a very close call a few months ago when I had a strange condition that caused failsafe to activate, deactivate and then miss an error condition that caused a flyaway (thank god a tree was in the way).

You can read about it in detail at my RCG blog (the only post I've made), it's a little long but it goes into technical detail.

Cliffs: In short a faulty throttle signal wire caused the failsafe routine to get stuck in a loop and not kick back in when I needed it most.

Noctaro
Posts: 280
Joined: Thu Sep 08, 2011 11:15 am
Contact:

Re: Zombie copter?

Post by Noctaro »

Hi, thank you for thinking about my problem.
I did read your post on rcg. A strange situation. Sorry for your loss. Sometimes trees jump in your way, just at the right moment :mrgreen:

But the main difference i guess is, my copter was not armed! Not even moved. Failsave cant arm my copter as far as i know.
I use the yaw stick command for arming and disarming. Further, it not just went into levelmode and up.
Before it pushed up, there was a very controlled pitch forward and then backward. It did not feel like a random twitching in levelmode.
And why would failsave send it to full throttle?
Btw. i already did 5 other flights in safe conditions with this copter, without any strange bahaviour....

I will add some pictures of my fc. But i did the cable stresstest over and over without any errors... :?

gboediman
Posts: 1
Joined: Sun Mar 22, 2015 1:59 am

Post by gboediman »

hi. just 2 days ago, my multiwii SE 2.5 armed by itself and run all 800kv motor for just a couple of seconds. It happen after approx. 5 zecond i plug the 4s lippo. Luckly my hand a centimeter a way from 11" props.
after that, the esc, one by one make a beep (not in sync like).. It happen all the time after i plug the lipo.
i check using Ez.Gui, and got a note "i2c" error. Then i un.plug my Gps+ i2c board.
luckly it solved the problems.
i can fly the quad again for 10 min. But suddenly the quad fly high, and my thumb drop the throt. stick to zero (just by reflex), and luckly, again, the quad decend and landed hard way.
it was damn scary.
if anyone can give a technical comment, i will be appreciate. For now, i will not fly the quad w/ that Mwc se. Thk you.

edsimmons3
Posts: 100
Joined: Thu Sep 10, 2015 11:29 am

Re: Zombie copter?

Post by edsimmons3 »

Hi all,
First I'd like to say thanks for all the hard work everyone is putting in with MultiWii.

I have had a similar experience a couple of times to this, not with the copter arming, but with sudden and unexplained loss of control.

My setup is as follows:
Turnigy 9XR pro with FRSKY DJT module
Crius multiwii 2.5 with atmega 328p
I2C gps board
Bluetooth module
Crius Ublox GPS
Working and tested failsafe setup!!

Flying the quad today close to myself in horizon mode with bluetooth connected to my phone, EZio gui running for monitoring and setting params... suddenly the phone announced that GPS hold or home had been activated, the throttle increased by maybe 25% and it flew away in a big arc and found a bush.

GPS hold works reasonably well but I'm not happy with my current PID tuning, this is however another story. I'm sure that it would have held position in the breeze and not crashed had I commanded the position hold.

Totally scary.

I recently changed my crappy 2.4GHz radio out for the 9XR pro as I initially thought a similar scary incident was just a loss of radio and a really unfortunate last frame of stick positions was remembered by the old RX.

This has now happened to me several times and I'm willing to help debug this...

I'd like to answer a few questions for myself somehow, these are:
Is it possible to have GPS hold and RTH on the 328p based board with I2C gps and failsafe options set up? (as in does it work properly, not can I compile it!)
Is there a problem with memory in the code that would cause this sort of issue to appear in flight?

I'd be very interested to see the config.h file of other people's setups who are using similar equipment...

I'm going to fly again this afternoon without the I2C GPS board and see if anything scary happens again.

Any ideas?
TIA!
Happy flying
Ed

edsimmons3
Posts: 100
Joined: Thu Sep 10, 2015 11:29 am

Re: Zombie copter?

Post by edsimmons3 »

So with a bit more digging I think I might have found something that could trigger my kind of incident...
In GPS.cpp there is the following:

Code: Select all

//Check fence setting and execute RTH if neccessary
//TODO: autolanding
if ((GPS_conf.fence > 0) && (GPS_conf.fence < GPS_distanceToHome) && (f.GPS_mode != GPS_MODE_RTH) ) {
  init_RTH();
}


Given that I was flying and suddenly the mode changed, this would appear to be *one* possible explanation. Perhaps a duff set of GPS data was presented by the I2C GPS board...???

I don't know if this was the cause 100% and probably never will, but to be clear of one thing I've now set the fence distance to 2000m.
I still think that there is something memory related happening too, the behaviour of the quad was too weird, it had maybe half a second of weird yawing, during which instead of landing I corrected for it (stupid move, should have landed).
This certainly doesn't explain any situation where arming was occurring though...

I plan to keep looking through the code and will try this out with a 2560 based controller too for comparison.

edsimmons3
Posts: 100
Joined: Thu Sep 10, 2015 11:29 am

Re: Zombie copter?

Post by edsimmons3 »

The best explanation I have at present *for my* incident is that the 328p ran out of ram and something was corrupted in flight.

By changing my config file to reduce the ram used by a few things (powermeter and battery voltage) I was able to get my controller to run well in bench tests using the GPS. RTH and posHold modes "worked" fine in bench tests but I didn't move. No ill effects that had been seen previously showed up with my new configuration...

The config file is available for anyone who is interested: http://pastebin.com/D6XUR5xw

I have flown the quad successfully using the firmware generated by this config but not yet fully tested RTH and position hold in flight - that said, I do not expect any issues...

Ed

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Zombie copter?

Post by Hamburger »

you could enable the 'display free memory' feature maybe and check how much free memory your MWii reports once it is running.
With all my incidents during testing where I enforced or somehow encountered 'low memory' condition it always caused complete lockup of the main loop. Not your symptoms, so my bet is you got another problem.

Bluetooth is a likely candidate to induce spurious garbage - but to match an MSP with correct checksum?
If you could live without bluetooth for some time then you could at least observe if the problem persisted or seemed to have gone.

edsimmons3
Posts: 100
Joined: Thu Sep 10, 2015 11:29 am

Re: Zombie copter?

Post by edsimmons3 »

Lol, I tried that option but didn't find anywhere where the ram was reported!!

I added code that EOSBandi had posted on the forum to check the ram usage, this reported into debug[0] in one of the tasks in the main loop.

I was able to trigger a condition in bench tests where the flight modes got all jumbled... I think I was just a few bytes over the overall ram limit! This looked exactly like what happened while I was flying... I think I have resolved this problem now, I've flown for 30 mins with new firmware but the wind was too strong to be setting up PIDs for poshold and alt so I'm not 100% confident in it yet. I'll keep people posted...

And yeah, I know I'm really pushing the limits of the 328p with my config, I'm sure I can make it work now I know what was going wrong...
Thanks!

I don't expect anything unusual came from bluetooth... it was entirely on the atmega.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Zombie copter?

Post by Hamburger »

Below 100bytes free is a direct route to lockup.
With 200bytes free you should be good.
Pure e perience. 0 science.

edsimmons3
Posts: 100
Joined: Thu Sep 10, 2015 11:29 am

Re: Zombie copter?

Post by edsimmons3 »

Is that as reported by the GUI as bytes free while running or is that the arduino IDE's guess at free ram?

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Zombie copter?

Post by Hamburger »

that is for the free mem value @ runtime. (either EOSBANDI code or the other implementation already present in the code from arduino forums)

edsimmons3
Posts: 100
Joined: Thu Sep 10, 2015 11:29 am

Re: Zombie copter?

Post by edsimmons3 »

thanks... I presume you're referring to the free ram whilst everything is up and running too, eg TX on, GPS fix, modes cycled through, armed etc.

I have around 30 bytes free memory when fully functioning, when it starts up it shows 70-80 bytes and drops gradually when other things kick in, eg GPS fix and other modes but it never drops below 30 bytes. I flew again earlier, headfree works, flight is smooth etc. :)

Kbev5709
Posts: 451
Joined: Mon Aug 17, 2015 5:56 pm

Re: Zombie copter?

Post by Kbev5709 »

Saving some memory.....I'm not sure how much gets saved when you do what I do because I never checked to see if it saves any or how much, but there is a slew of stuff defined by default in the config.h sketch that does not get used even in a typical quadcopter configuration. For example, under the heading "Airplane" anything that is defined there can be commented out. Anything under "Common for Heli and Airplane can also be commented out. Anything under the heading "Heli" can be commented out. Anything under the heading "LCD/OLED - display settings" can be commented out IF YOU DON"T USE AN ON BOARD LCD READOUT. Same goes for "Display settings", "Navigation" /* keys to navigate the LCD menu */ and "LCD configuration menu". If you aren't running FPV or an LCD you can do away with things that are enabled under "LCD telemetry". Unless you depend on servo's like in a tricopter to steer, or if you use a servo gimbal and camtrig, you can disable all servos and references to them. My quad flies awesomely with all of these things commented out of my sketch.
All of that stuff relating to collective pitch and servo mixing for heli are not needed for your quadcopter to fly properly. All of that stuff adds up using a lot of dynamic memory. Not sure how that translates to on board memory.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Zombie copter?

Post by Hamburger »

If we did it right it wont matter.
I am quite sure we did.

edsimmons3
Posts: 100
Joined: Thu Sep 10, 2015 11:29 am

Re: Zombie copter?

Post by edsimmons3 »

LOL - yeah looking at the code nearly everything that's not used is already enclosed in

#if defined(OPTIONAL_FEATURE)
unit8_t myThing;
#endif

so in theory it makes no difference to the compiled size... I think that since you're doing things like
#define OPTIONAL_FEATURE
#define THIS_PARAMETER 100

#if defined(OPTIONAL_FEATURE)
uint8_t myThing = THIS_PARAMETER;
#endif

nothing should get declared that isn't needed... I can confirm from a few tests that this all behaves as expected. Virtually no difference with/without the unused defines in config.h (which is as I hoped & expected)... I actually think I tested this before and have some vague memory of coming to this conclusion before. I look at too much code ;)

Post Reply