Crash when I switched to Loiter mode

ArduCopter Copter 3.2
1

Hi !

I was out flying my HK X650F quad yesterday.
First flight about 16 minutes without any problem, in Stablize, Alt-Hold and Loiter mode
Second flight, I run the Autotune, and after that normal fly in the three above modes, also without problem.
Third flight, everything worked perfect to the very end (14min). I was near my home point at an altitude of 3-4 meters, and I switched to Loiter from Alt-Hold. The quad than flipped over and down into the high grass field, so I only broke 2 props, no further damage.

Pixhawk with version 3.2-dev from 2014-04-26
I know, I should not run this, but because to get SBUS working from Futaba 7008SB I used it.

Short summary of hardware:
HK X650F quad
T-motor 2814/10 770kv with 12 inch Gemfan CF-prop
Maytech 40A SimonK ESC
1x 4S 8300mAh LIPO
3DR Pixhawk with 3DR uBlox GPS/Compass module
Futaba 7008SB RX with T14SG TX

Before the above flights, I have made all kind of calibration according to arducopter.com, and even the compass-mot calibration, and I did get about 25% of compass interference.
In an earlier flight I measured the vibrations, witch to me looks fine with AccX: +/-1 AccY: +/- 2 and AccZ around -10 . After that I turned off IMU-logging.

I think I will wait for en official 3.2 release before I fly this again, I saw that 3.2-rc1 is out now.
What could the cause be for this flip over, should I change something in my setup.
What should I log during future flights ?
I will attach the following log files:

[attachment=3]9.BIN[/attachment]
[attachment=2]10.BIN[/attachment]
[attachment=1]11.BIN[/attachment]
[attachment=0]12.BIN[/attachment]

When i look at the 12.BIN log at the point of flip over. I can see that ATT.Roll/Pitch go high and ATT.DesRoll/Pitch go high in the other direction. CTUN.ThrOut went high to 1000.

I hope someone could find something out of this logs.

Regards
//Stefan in Sweden

2

Roll and pitch suddenly and simultaneously diverge from command, suggesting a hardware failure. Probably the best thing for the devs is what you are planning to do anyway - rigorously test with 3.1.4. Let us know in this thread if the problem recurs on 3.1.4.

It is suspicious that the problem occurs with the mode change.

Edit: Oh, and please just fly the Pixhawk default log bitmask. Pixhawk can log everything just fine, and it could be important for support purposes.

Thanks for your test and sorry about the crash.

3

Hi !

Ok, thank you for looking into this.
I´ve analyzed the cut area of my two props, and they look a bit different.
The back left prop, have a more clean cut if you compare them.
And if I look at the log, the heavy pitch/roll is back left, so I´m think more of a mid air prop failure, and the other prop was broken when it touched ground.

About the version 3.1.4, I can not use that as the Futaba S.BUS from the 7008SB Receiver not work in that release. I think the new S.BUS was implemented in 3.2-dev during march, and therefore i used 3.2-dev.
I now have installed 3.2-rc1.

Again, thanks for a good work !
//Stefan

4

Stefan, does the futaba 7008sb work with 3.2-rc1 without the need for the ppm encoder? or are you using the encoder? thank you.

5

Yes, it works without ppm encoder, so thats nice !

6

I’d been hopelessly trying to get my 14Sg & R7008SB to work on the PixHawk until I found this thread.
The ACM V3.2-RC1 firmware does indeed work with the R7008SB RX set in mode ‘B’ or mode ‘D’.
…[ I know this a BETA version ]… , But now after testing the throttle fail-safe, using the Radio Calibration Screen in MP, I have found that the PixHawk, [using ACM V3.2-RC1], does not respond to the TX being turn off. It also does not respond to the removal of the SBUS connection between the PixHawk and the RX. There was no change in the reported servo positions

The failsafe in the R7008SB RX is working. When set to mode ‘B’ , where CH 1-8 Are sent to the SBUS & PWM outputs concurrently, a servo connected to the throttle channel showed that there is a proper fail-safe response from the RX. This was also tested for some of the other RC channels and the results were the same as with the throttle channel.
Checking the SBUS output on an oscilloscope also shows that there is a response to the Fail-Safe event.
I did not decode the SBUB data stream, however, so I cannot state for certain what the nature of the change in the SBUS data was exactly.

Further testing … With both MP and the PixHawk freshly rebooted and no connection to the RC-input on the PixHawk the RC inputs read as all zeros, [which I expected], I then put the RX, into a fail-safe condition by turning off the TX and then connected it to the PixHawk and observed that there was no change to the reported servo positions in MP. They were all unchanged, still showing zero.
Next, I tried the RX battery fail-safe feature of the Futaba system and it did work… BUT it only works if the TX is operating.

I then attempted to see if there might be a work-around to this “lost-TX-signal” throttle fail-safe issue by setting the fail-safe voltage to a high value, (allways active), and then assigning an unused {switch, channel, or Logic Switch} to over-ride it , hoping that in the absence of an active over-ride that the RX would then create the lost-TX-signal throttle fail-safe condition. IT DID NOT!
It would seem that the RX battery Fail-safe is completely managed by the transmitter by way of the telemetry system.

In conclusion I would say that there is still some more firmware work to be done in the decoding of Futaba SBUS data before the R7008SB RX can safely used with a direct SBUS connetcion.

I hope this information is helpful.

Cheers
Chris Card

7

Now my quad flying again, or at least did fly.

I´ve installed the version 3.2-rc1, and did some flights yesterday, pretty windy though.
The first flight went well, in both Alt-Hold and Loiter.
Second flight mostly i Stabilize mode, and I did little more play around with acceleration to high altitude.
Everything fine so long. At the end I bring the quad down to low altitude, and switched to Loiter, and a steady position hold as it should. Then I want to show my friend, that even if you do YAW, it will hold the position. Even that working at the beginning, but at faster YAW speed, it suddenly flip and down into the ground. Not so much damage this time either.

As I measured vibrations with the new props, I´ve have IMU logging enabled.
I´ve looked at the log, and one thing that wonder about is when i YAW at the end, the GyrZ is starting to fall, what does this really mean.

I hope this logs can bring something good. But now my quad is grounded for a while.

//Stefan

8

Old thread, but I am looking for Maytech-information on this site. Regarding the Maytech ESC-manual, SimonK-ESCs do have problems with stuttering Tiger Motors. Do not use. I have been trying to get BL Heli Firmware from Maytech (their solution to the problem, but they dont answer anymore).