Servers by jDrones

Can´t find the exact crash reasons for 25kg Cube Orange copter

I´m not able to identify the crash reason for a 25kg crop spraying drone. It is a new copter with only 5 or 6 flights, with Cube Orange, Arducopter 4.0.5 and 4 HobbyWing X8. The tuning is equal to other copters we use for over a year.

The copter was flying with about 20kg of total weight. After some minutes flying with no problem (4:34m), the copter started to Wobble very strongly and crashed. I do suspect of a faulty ESC or motor, but I´m unable to find witch one or if it could also be a Cube output problem (all motors work fine now). On the log file it is clear by the outputs 1 to 4 that there is a Bias problem since the CW outputs are higher than the CCW, but I don´t belive this to be the cause of the crash. I could not find any health errors. Battery was OK. All propellers were on the aircraft after the crash.

Any idea what I could look after? I do appreciate help!

The bin file:
https://1drv.ms/u/s!Am9EOGWyWxXqhYQElB8lRtQaxdG46Q?e=znMH64

The Quad is very unbalanced, with M3 and M4 (CW) maxed out for the entire flight.
Are your props level?
Calibrated ESC’s?

It looks like the yaw that you gave it was just too much for it to handle as you see M1 and M2 shutting to try and compensate for M1 and M2 not having enough thrust left to perform the yaw.
Thats when your stability broke down.

I don’t agree.
There were now YAW change when the instability occured. (neither RC input or auto). Also there were no increased ThO, so it seems there were no thrust issues.
Also the instability occured only a motor 1-2, which is also strange.
Finally I see increasing vibration clipping just BEFORE the instability occurred and continued till the impact.
But the biggest issue is that this is a custom firmware, made by SkyDrones, since there are no info what kind of modifications were made by the manufacturer, it is not possible to rule out software problem as well. I think the owner should contact the manufacturer for further support.

Strangely, attitude control looked very good before the oscillations started

Is you MOT_THST_EXPO correct? I thought you would need something around 0.75
You can set these also:
ATC_THR_MIX_MAN,0.5
PSC_ACCZ_I,0.636
PSC_ACCZ_P,0.318

Motors 3 and 4 (clock-wise) are so close to maximum that there’s not much left over for stability (and yaw). Check for motor mount or frame twist., it’s causing a physical yaw bias.

I suspect the liquid payload started sloshing and the quad soon lost control, since it didn’t have enough headroom to control everything at once. Can you fit a sponge or special two-part foam in the tank to control sloshing.

You’ll need to use less payload, or increase thrust. Changing to a quad-X8 configuartion might be feasible. Just putting on bigger props might not be ideal.

I also disagree. Look at the first part of the instability


Motor 3-4 does not maxed out, they kept running normally. But 1-2 started to oscillating. sloshing must be perfectly parallel to the axis of motor 1-2 to cause this.
Look at the vibe clipping, It started just before the instability started. So I thing something got loose onboard.

I would like to thank all for your time and crash analysis.

My company (SkyDrones.com.br) produces this copters for some years and we only have added liquid volume monitoring (pulse counting) in the code in order to control the spraying pump dosing rate.

This specific flight was in a very new situation on hill sides, where more power is required to climb. From what I noticed in your comments, lack of more power might have contributed to the crash. The copter was with the liquid tank almost full (9kg). Normally flights are done in a more horizontal flight path.

I received the video of the crash, that might help to find the cause. The copter does not seem to have touched any plant before crashing. All units have height radars in order to keep them at controlled height over the plants (usually 2.5 to 4.5m).

https://1drv.ms/v/s!Am9EOGWyWxXqhYQF5W-wRfqAzjMqkQ?e=uOgfoB

Could this be a controller board problem (specific to this unique Cube Orange unit in this Copter) since this are the first flights?

@Eosbandi I received the unit today for maintenance and nothing seems to be loose. The client told us that this unit had already 3 crashes for the same strange behavior. Is there a way to analise or search for a Cube problem or a controller algorithm “overflow” kind of behavior? I have access now of all flight logs. I really do not belive that both motors 1 and 2 have a problem.

Thanks

I cannot discover any functional or mechanical problem in the log. The the aircraft follows the controller outputs (even during the oscillation; with the usual phase delay of course) so the motors seems to be fine. And the controlller reaction seems to be fine as well.
The clipping during the strong oscillation could be physically correct, excited by the the bang-bang motor dynamics. I can imagine such values even without any mechanically loose components.

By looking to the gyro signals and the rate controller it could be a ‘simple’ closed loop oscillation because of too high rate controller gains.

Maybe is this drone family is ‘overtuned’ , and has too low stability margin on the rate control loop?
Then most of them are flying perfect, but in the case of some tolerances and other circumstances oscillations will occur. Were the rate gains tuned for an empty or fully loaded vehicle? How much were they reduced after that?

For a 25kg vehicle, the rate control loop performance looks for me too good before the oscillation. If it is on the performance limit, then only some circumstances are needed and oscillations can develop: assymetrical motor loads combined with the current load case, sloshing fluid, and… and…

The oscillations are leading to saturations (motor 1, 2 are alternating on minimum), and even more phase delay.

The lower motor load on 1 and 2 could be one of the main factors in this case. As it was already written, check the motor angles. One or more are possibly tilted and causing yaw moment. Then try to tilt back until the sum of CW motors has the same load than the sum of CCW-s.

But, as this is mostly the case, this is just a hypothesis. Just one possible cause for the crash. I am not convinced, but in your case i would reduce the rate gains just to be sure.

1 Like

@perwollf thank you for your time and insights.

I have revised all logs of this unit and there are only 10 flights with 4 problematic ones. But all were flown manually on a hill side with a full tank demanding all available power. Since this unit had “hard landings”, motor misalignments got stronger towards the last flights. Even having some flight moments with max out motors, the crazy behavior always happened after a while flying when, in theory, the copter was already lighter. But I agree that I have tuning problems that did not appear on other identical units since they are flying on flat areas.

4 problematic flights:
https://1drv.ms/u/s!Am9EOGWyWxXqhYVzP6oo0d4ij1eNmQ?e=vz2nTl






I will “retune” this unit. On literature (https://ardupilot.org/copter/docs/tuning-process-instructions.html) is stated to do the process with an empty payload. Any suggestion on this statement?

Something else to look at is escs. Some escs do weird stuff when they overheat, some reduce the output power and some change the response and breaking profiles. It could be the case that one or several escs were overheating and changed their characteristics resulting in an unstable control loop.

I have seen similar plots and I had almost the same problem with my Hobbywing Xrotor 80A HV (the old version) imagen

After the autotune was completed, the drone flew well but after some minutes it became unstable, similar to your plot, but in my case almost always it was recovered. I found that with defaults PID that problem didn’t appears, so the problem was more aggressive PIDs. Maybe with changes in the timing or adjusting other parameters of the ESC, the problem would have been solved, but I ended up changing the four ESC for the Xrotor PRO 50A and the problem was solved.

Hi David, did you mean you changed to using the Xrotor PRO 50A ? Or did you change out the Xrotor PRO 50A to something else?

Almost always too much D term causes motor (and ESC) heating. It would be nice if you could find a log from those poor flights for me to check out - even just for our own education.

I changed the old Xrotor 80A for the new Xrotor PRO 50A and the problem was solved.

Yes I found one log, here it is:Log fallo charlie 3.BIN (652.3 KB)

Thanks again for all insights!

Last week I did a new tuning using correct initial presets for 30" propeller with the same problematic unit. It was done on a complete windless day. After I reduced ATC ANG Ps according to tuning instructions.

I made very aggressive manual and Auto test flights with about 7Kg of bouncing water. Results were excellent so far. I did not exchange any hardware. It seems that aggressive PIDs were causing the problem.

Log:
https://1drv.ms/u/s!Am9EOGWyWxXqhYohg1CvW-vOScvEqg?e=EJUeXP

Thanks for all the help!

Hi, which software do you open the bin file with?

That is UAV Log Viewer https://plot.ardupilot.org/#/
There’s also Dronee Plotter https://plot.dron.ee
And MissionPlanner, and APMPlanner2

Hi ulfbogdawa,
It’s better now. I think it can be a bit better yet, let me know if you want to go further.
It’s relatively easy to set up the harmonic notch filtering, a couple of test flights and run another Autotune.

I suspect INS_GYRO_FILTER should be 20 , your FLT params can go up to 10 and your D terms are a little low.
ATC_INPUT_TC could be 0.2 for a bit softer RC control, but it’s not important to attitude control.

Hi Shawn,

Thanks again.

I downloaded your last excel file and I noticed some minor changes in values. For 30" propellers the FLT was 8.5 and now it is 10 (minimum).

Yes I would like to go further refining my PIDs and setting the harmonic notch filter. The thing that is bothering most at this moment is a little “backslash” I get when releasing the stick after a horizontal movement. Seems like a “late” or “afterwards” breaking effect - a one time overshoot movement.

How do I know how far I reduce the P (ATC_ANG_PIT_P, ATC_ANG_RLL_P, ATC_ANG_YAW_P
and ATC_RAT_YAW_P)? You wrote that the D terms are a little low, how low? How can I test/check to see if they are at the correct value?

Should I do the autotune again with the new initial settings and then make the notch filter?

Sorry for all the questions, but this is getting quite interesting :slight_smile:

.

I think ATC_RAT_PIT_D can come up to 0.0078 and ATC_RAT_RLL_D can come up to 0.009
Along with INS_GYRO_FILTER ,20 and FLT params to 10 , set these ones for 1st phase of the Harmonic Notch filter set up:
INS_LOG_BAT_MASK,1
INS_LOG_BAT_OPT,0
Do a hover test flight just a couple of meters high and for a minute or 2 - then let’s see that .bin log.
Obviously look for oscillations or anything not quite right and land immediately if you have to.

Once the attitude is fully under control it’s easier to address other issues. If the overshoot you are talking about is in Loiter mode it could be you’ll benefit from setting these, especially the brake delay:
LOIT_ACC_MAX,600
LOIT_BRK_ACCEL,300
LOIT_BRK_DELAY,0.3
LOIT_BRK_JERK,300

Shawn,

I made the test flights today with no wind. First I changed the values you suggested. Copter flies absolutely fine! No more “backslash” effect.

The .bin with the enabled log is here:
https://1drv.ms/u/s!Am9EOGWyWxXqhY0vEhp0kcw6O8p3Lw?e=Gpu9T1

Mission flight:
https://1drv.ms/u/s!Am9EOGWyWxXqhY0w9_-9SIS1ie5D-g?e=IpSfVp

I did not make a new auto tune yet and I did not applied any changes from notch filter. Is it possible to make it fly better? :slight_smile:

Servers by jDrones