Octocopter Violent Crash

ArduCopter Copter 4.5
1

Octocopter ran great for many flights, all of a sudden today we had a violent crash. Orange Cube. Any insights are greatly appreciate. Trying to figure out which hardware parts might still be salvageable, don’t know what to trust. I did the best I could to try to “review the log” but I honestly don’t know where to begin or what to look for that might help determine the possible cause of the crash. If you figure out what might have happened could you tell what messages I should have known to look at, Thanks : )

The bin file for the flight should available at the link below but I’m not sure this is the proper way to share the file…

2

First thing that I see right off is your vibrations are a touch high.

Did you use the configurator?

https://ardupilot.org/copter/docs/common-measuring-vibration.html

image
image1602×917 26.4 KB

3

I don’t see battery voltage in the log. Is it possible you ran out of power?

4

Thanks you guys!

We had plenty of power, I think we shut battery monitoring off because we couldn’t get the Orange Cube monitor settings to allow us to arm the octo. We use a battery alarm instead.

Vibration, Ughhhh, had no clue, appreciate the advice. We used double sided foam tape to mount the FC and based on your recommended readings that will get fixed on our second octo.

We have two Tarot Octos for High School Technology projects and figured we needed to know what to expect when Autotune was enabled. Roll and Pitch tuning went well in successful previous flights, the crash occurred when we were bring the octo home after what we thought was successful Yaw tuning. We couldn’t have been much more than 100 ft from home when the octo spasmed crazy hard and smashed and ruined just about every appendage. We can’t afford to ruin the second octo, it’s grounded until… I’m not sure, our confidence is totally rattled. We’ve flown at least 6 other models with Arducopter and various FC’s, mostly Pixhawks, but all of our previous issues were obvious pilot issues, never a reason to look into logs, Arducopter has been great!

5

Shutting the battery monitor of will kill PID voltage scaling, and that is a bad thing.
Never turn of the failsafes, nor turn off voltage monitoring. Period!

2 Likes
6

Lua script enabled, autotune happened at the same time. overloading the FCU processor could be the cause. There are about 95 ‘hello world’ within 1 sec.
also, your initial parameters are mixed with 10" and 14" propeller values. The quick tune is not done yet.
You may also want to go deeper into why when you roll + pitch, your drone propulsion seems unstable. potentially due to high vibrations.

ATC_ACCEL_P_MAX,110000
ATC_ACCEL_R_MAX,110000
ATC_ACCEL_Y_MAX,27000
ATC_RAT_PIT_FLTD,20
ATC_RAT_PIT_FLTE,0
ATC_RAT_PIT_FLTT,20
MOT_BAT_VOLT_MAX,0
MOT_BAT_VOLT_MIN,0
MOT_THST_EXPO,0.65
SCR_ENABLE,1
1524 42:19.4 MSG 146213160 ArduCopter V4.5.4 (fd1bcc61)
1525 42:19.4 MSG 146213168 ChibiOS: 6a85082c
1527 42:19.4 MSG 146213222 CubeOrange 001F0031 34305106 37373930
1528 42:19.4 MSG 146213264 Param space used: 756/5376
1529 42:19.4 MSG 146213272 RC Protocol: SBUS
1530 42:19.4 MSG 146213283 RCOut: PWM:1-14
1531 42:19.4 MSG 146213289 New mission
1539 42:19.5 MSG 146215229 New rally
1540 42:19.5 MSG 146215235 New fence
1541 42:19.5 MSG 146215245 Frame: OCTA/X
1545 42:19.5 MSG 146215265 GPS 1: specified as DroneCAN1-125
1546 42:19.5 MSG 146218768 hello world
11162 42:33.0 MSG 159728866 hello world
11163 42:33.0 MSG 159738802 hello world
11164 42:33.0 MSG 159744847 EKF3 IMU1 MAG0 ground mag anomaly yaw re-aligned
11169 42:33.0 MSG 159748652 hello world
11170 42:33.0 MSG 159749866 EKF3 IMU2 MAG0 ground mag anomaly yaw re-aligned
11171 42:33.0 MSG 159752322 EKF3 IMU0 MAG0 ground mag anomaly yaw re-aligned
11172 42:33.0 MSG 159758878 hello world
11175 42:33.0 MSG 159768441 hello world
11830 42:34.0 MSG 160727920 hello world
11831 42:34.0 MSG 160737751 hello world
11832 42:34.0 MSG 160744879 EKF3 IMU1 MAG0 ground mag anomaly yaw re-aligned
11837 42:34.0 MSG 160748597 hello world
11838 42:34.0 MSG 160749857 EKF3 IMU2 MAG0 ground mag anomaly yaw re-aligned
11839 42:34.0 MSG 160752292 EKF3 IMU0 MAG0 ground mag anomaly yaw re-aligned
11840 42:34.0 MSG 160759977 hello world
11845 42:34.0 MSG 160770777 hello world
13226 42:36.1 MSG 162825149 hello world
13231 42:36.1 MSG 162836031 hello world
13233 42:36.1 MSG 162844827 EKF3 IMU1 MAG0 in-flight yaw alignment complete
13235 42:36.1 MSG 162847472 hello world
13296 42:36.2 MSG 162938699 hello world
13302 42:36.2 MSG 162949854 EKF3 IMU2 MAG0 in-flight yaw alignment complete
13303 42:36.2 MSG 162951033 hello world
13304 42:36.2 MSG 162952331 EKF3 IMU0 MAG0 in-flight yaw alignment complete
13305 42:36.2 MSG 162960948 hello world
13310 42:36.2 MSG 162970703 hello world
19958 42:46.2 MSG 172945660 hello world
19962 42:46.2 MSG 172956109 hello world
19963 42:46.2 MSG 172957228 EKF3 IMU1 switching to compass 1
19966 42:46.2 MSG 172967587 hello world
20032 42:46.3 MSG 173048666 hello world
20033 42:46.3 MSG 173060093 hello world
20034 42:46.3 MSG 173062171 EKF3 IMU2 switching to compass 1
20035 42:46.3 MSG 173064663 EKF3 IMU0 switching to compass 1
20041 42:46.3 MSG 173071341 hello world
20042 42:46.3 MSG 173082942 hello world
20044 42:46.3 MSG 173092648 hello world
20049 42:46.3 MSG 173103974 hello world
32879 43:05.3 MSG 192093521 hello world
— — — — — —
32881 43:05.3 MSG 192102545 AutoTune: Started
32887 43:05.3 MSG 192103991 hello world
32888 43:05.3 MSG 192104681 AutoTune: pilot overrides active
32936 43:05.4 MSG 192115252 hello world
32937 43:05.4 MSG 192126153 hello world
52451 43:34.8 MSG 221525190 hello world
— — — — — —
52452 43:34.8 MSG 221532529 AutoTune: Yaw(E) Rate D Up 0%
52453 43:34.8 MSG 221535958 hello world
52455 43:34.8 MSG 221546624 hello world

image
image1279×877 13.9 KB

image
image1279×877 16 KB

image
image1279×877 36.4 KB

7

With respect to the Lua Script overloading the FCU processer, . . .

  1. How are you monitoring processor use during a flight with telemetry?
  2. How do you determine how much of the system resources can be allocated to Lua scripts?

Is the consensus that the scripts were using too much of the system resources for the FCU to perform, the vibrations were so great that the cube could not determine its position, or are there other options to explore to determine what actually caused the flight and how to make adjustments?

8

I don’t see any evidence of System Resources overloaded. Look at the PM messages in the log. Disable the script anyway, it’s a major pain in the ass to review the log with the flood.

I see loss of thrust on Motor 8 and an untuned craft on default parameters. And you need voltage monitoring at a minimum.

RCout
RCout3306×1040 231 KB

Vibe levels are not great but not a cause of the crash. If you can lower them you will get a better tune.

9

Do you guys in-the-know think there is a problem running two compasses at the same time?

10

We know that running two compasses at the same time does not cause any problem.

We know that an un-configured vehicle causes lots of problems.
We know that a badly built vehicle causes a ton of problems.

1 Like
11

No doubt about the sources of lots of problems. Here’s the thing, we have built a variety of at least 8 arducopter quads, all great, so much so that we felt confident investing in two octo builds. This octo was not a new build it flew many successful flights so many that we were confident to experiment, like add a Lua script and additional PID tuning. It a experienced a violent spasm and crashed to pieces.

What I haven’t mentioned is that an old quad that hasn’t been flown in a year but flew well prior to that was also recently brought out and it too had a what we think was a similar violent spasm but corrected itself and landed without damage. Strange, old logs were still on the SD card but no recent logs, no log of the spasm. We should have grounded our whole fleet until we identified the source of that spasm and it hasn’t been flown since but we didn’t and disaster struck now we are questioning everything about the quality of our builds and understanding of the instructions.

Vibration has been mentioned several times in the replies, got it, now we’re think vibration wasn’t a problem but over time if vibration is cumulative, our bad, we got that and the fix is in the works. But is that all?

10" and 14" mixed initial prop value instructions are a mystery to us, how did we manage that (?). we did it before and after to all of the rest of the setup steps to be on the safe side :

You have to set some parameters based on battery and prop size for a new copter setup.
Please make sure that before entering data here and updating parameters:

– ALL INITIAL SETUPS ARE DONE (Calibrations, frame settings, motor tests)
– BATTERY VOLTAGE MONITORING IS SET AND WORKING

Note: INS_GYRO_FILTER with a value other than 20 is optional and probably only for small frames/props. At first, you can keep it at 20

The crashed octo has an Orange Cube which is new to us, previous models were all Pixhawks, our power experience was similar to the following and we gave up, our bad again, it wouldn’t arm so we shut off the monitor and flew with an alarm:

We’ll shut off Lua, that was a bust anyway. We still don’t know if we should trust any of our builds now and our whole fleet is grounded because our confidence is shot. We should have dug deeper into the quad that spasmed and that’s kind of where we are at but what to do? Why don’t logs work, is Pixhawk Tlog only, why no bin file? When should we do the initial parameters? What does un-configured vehicle mean, isn’t that setup or is configure something else? Ughhhh, how were we successful before but now spasms on two models…

12

Sorry for my rant, I’ll try to be more specific, does anyone have any insight that might explain the cause of the giant spike in roll that resulted in the crash:

image
image556×680 9.53 KB

13

Could the compass fail listed in the LogAnalyzer have something to do with the giant roll spike?

Large change in mag_field…seems very suspicious, what could be up with that?

image

14

Mission Planner’s Log analyzer is outdated and not usefull. The ArduPilot Hardware Report is a better but still not perfect.

15

That is clearly explained in both QUICKSTART and on the TUNNING_GUIDE

It means you did not configured the vehicle according to the ArduPilot documentation nor according to the ArduPilot Methodic configurator sequence.

  • The ArduPilot documentation presents you with lots of options, and lots of possible sequences, and lots of choices. Currently contains around 800 documents.
  • The ArduPilot Methodic configurator presents you with less options, and a single linear easy-to-follow sequence. A single document automated by the Ardupilot Methodic configurator software

Both are correct, and both get the job done.

1 Like
16

Are you still talking about the same flight? Did you look at the RCout graph posted above? And you are wondering why it rolled? Motor 8 was commanded to max, 5.6 & 7 dropped to attempt to Stabilize, now there is a general lack of thrust and it’s not Stable. Down it goes.

The Log Analyzer is nonsense. It hasn’t been up to date or useful for many years. Do you wonder why it says “MAG_ENABLE not found”? Because that parameter hasn’t existed in Arducopter for years.

17

Yes talking about the same flight, octo crash…

Dave, In your RCout post you commented that you saw a loss of thrust on Motor 8. I looked at the plot and saw Motor 8 maxed out… Ughhh, disconnect in my head, maxed out to me meant max thrust so I regrettably dismissed your comment. Regardless, I had no idea that the plot also showed that 5, 6 and 7 attempted to compensate.

What might be the most likely cause of the command for Motor 8 to max?

Whoa, LogAnalyzer is nonsense? It’s in the ArduCopter documentation:
https://ardupilot.org/copter/docs/common-downloading-and-analyzing-data-logs-in-mission-planner.html#common-downloading-and-analyzing-data-logs-in-mission-planner

I really appreciate you guys hanging in there with me : )

18

By right if purely one motor failure it shouldn’t have crash it.

The image on the right from a test I did with AttracLab last week to test hexacopter motor failures.

19

Hi @dwiener sorry for your troubles and being led astray by the wiki. I’ve created a wiki issue to remove that section of the wiki.

20

You guys are great, this is a remarkable endeavor, I can’t resist all that I’m learning about the complexities of copters that I never could have imagined. The crash heightened my awareness of my ignorance about all aspects of my builds and configurations.

I’m also thinking that you guys don’t seem to mind trying to straighten out those us in the dark if we just ask. I have another perplexing state of uncertainty…

I didn’t and don’t get the RCout plot that Dave shared in the forum. Motor 8 maxed out but lost thrust, say what(?). PWM signals range from about 1000 usec and 2000 usec, for motor 8 on the plot why would maxed out be no thrust??? Doesn’t matter but Motor 8 is on the opposite side of the octo as motors 5, 6 and 7 and if motor 8 lost thrust wouldn’t increase in thrust on the opposite side make it worse? Or if motor 8 maxed out on thrust, like my intuition led me to believe, and motors 5, 6, and 7 lost thrust that would have made it equally worse? What am I missing here?