Wrong crash check

Hi,

i’m not shure, but maybe there is a bug.

My hexcopter (pixhawk 2.4.8, arducopter 4.0.0) disarmed during flight and felt 10m to the ground.
Hardware seems to be all okay. It seems that ardupilot thought there was a crash, but there was nothing unusual. i think this should not happen.
it was during autotune.

the logfile is here:

could someone have a look at this case?

thanks,

Easy

Looks like you triggered the crash detect when you input full pitch deflection from the Tx.

Did you go through the tuning Wiki here and set the recommended parameters before auto tuning?

I’d recommend updating to AC 4.0.3

Not directly related to the crash, but your Vcc 5volts is very low, maybe see if you can get a better “power brick” or at least check all its connections are good. You need around 5.1v to 5.3v

Do the Compass/Motor calibration too, it’s not required but helps a lot with compasses.
https://ardupilot.org/copter/docs/common-compass-setup-advanced.html#common-compass-setup-advanced-compassmot-compensation-for-interference-from-the-power-wires-escs-and-motors

The MOT_THST_HOVER value is very low so I’m going to assume you’ve got 12inch props with 3cell LiPo. I recommend changing these settings and doing Autotune again - first do some basic Stabilize and AltHold tests to make sure everything is work OK before Autotune.

ACRO_YAW_P,2.80
ATC_RAT_PIT_FILTD,18.00
ATC_RAT_PIT_FILTE,0.00
ATC_RAT_PIT_FILTT,18.00
ATC_RAT_RLL_FILTD,18.00
ATC_RAT_RLL_FILTE,0.00
ATC_RAT_RLL_FILTT,18.00
ATC_RAT_YAW_FILTD,0.00
ATC_RAT_YAW_FILTE,2.00
ATC_RAT_YAW_FILTT,18.00
ATC_THR_MIX_MAN,0.50
AUTOTUNE_AGGR,0.075
BATT_ARM_VOLT,11.00
BATT_CRT_VOLT,10.50
BATT_LOW_VOLT,10.80
INS_ACCEL_FILTER,20.00
INS_GYRO_FILTER,36.00
MOT_BAT_CURR_MAX,50.00
MOT_BAT_VOLT_MAX,12.60
MOT_BAT_VOLT_MIN,9.90
MOT_THST_EXPO,0.67
PSC_ACCZ_I,0.36
PSC_ACCZ_P,0.18

You can copy/paste this straight into notepad and save as a .param file to load via MissionPlanner.
Some of your MOT_BAT and BAT_ values were close but not quite right.
Let us know your correct prop size, it might affect some of those values.

Hi mike,

Yes, this could be. Thanks for the link. This was new to me. Normally my copters fly very well just with the default parameters.
I will study those parameters, adapt them for my copter and try it again. But first of all i have to repair the frame.

Thanks shaun for the additional hints.

Very helpful to improove stability.

I have 10" props and 3s.
Compas/motor calibration was not made yet .

I will test your parameter proposal and write again the results here.

For 10inch props use these:
ACRO_YAW_P,3.00
ATC_ACCEL_P_MAX,108700
ATC_ACCEL_R_MAX,108700
ATC_ACCEL_Y_MAX,27000
ATC_RAT_PIT_FILTD,21.00
ATC_RAT_PIT_FILTE,0.00
ATC_RAT_PIT_FILTT,21.00
ATC_RAT_RLL_FILTD,21.00
ATC_RAT_RLL_FILTE,0.00
ATC_RAT_RLL_FILTT,21.00
ATC_RAT_YAW_FILTD,0.00
ATC_RAT_YAW_FILTE,2.00
ATC_RAT_YAW_FILTT,21.00
INS_GYRO_FILTER,42.00
MOT_THST_EXPO,0.65
Plus the other parameters I suggested, and then autotune of course.

Okay, now i have repaired everything and changed the parameters as you proposed.
But it seems that there is another problem, because during autotune the copter very often looses altitude or is wobbling.
After Autotune finished the pitch and roll axis seemed to be okay, but yaw is very instable. Especially the left turns are instable. right turs are okay. the wobbling increases, when battery is low.
I also tried 9.5" Propellers. They are more stable, but they have the same problem with left yaw turns.

Could it be that one of the left turning motors is defective?
I have done the motor test, but all motors start at the same throttle speed (7%).

Here are two of the last logs: 0011 is with 10" and 0012 is with 9.5" props.

thanks for your help!

Your ATC_RAT PID’s seem very low.
There is definitely something happening related to yaw as can be seen between Desired v Actual here.


When you yaw a large deviation sets up in pitch as roll.

Looking at you RCout there is definitely a balance issue as the front motors are working much harder than the back.

Although your overall VIBES look good the actual IMU data shows some large spikes in the Z axis.


How rigid is this frame?
Can the motors twist under load?

It’s looking happier than the first try but still not as stable as it should be.

The frame is a dji flamewheel f550 clone.
Take off weight is 1800g.
The motors can twist under load without problems.

I think i have found something that causes part of the left yaw problem.
I have powered my camera and the video transmitter from the motor supply connection on the center plate for motor 4. This is a left turning motor. I think it took too much current, so that motor 4 received less current than the others.
Now i power this directly from the battery.

The yaw problem now nearly disappeared.
But i still can not fly really stable. After extreme stick movements the copter gives potential thrust loss errors. And autotuning pitch never finished, due to extreme thrust loss.
Tomorrow i will replace my power module as proposed by shawn. This is the only remaining posibility i could imagine. I hope it works.

Thanks for your help!

mike, what software do you use for analyzing the log files? It looks a bit more comfortable than Mission Planner.

Mike uses APM Planner2, you can also try Dronee Plotter https://plot.dron.ee/

This is wrong:
MOT_BAT_VOLT_MIN,102
Use:
MOT_BAT_VOLT_MIN,9.90

These MOT_BAT_VOLT settings are more important than most realise, they dynamically adjust the PIDs depending on battery voltage. Incorrect settings can cause the PIDs to be crazy.

Check that your MOT_SPIN_MIN, maybe use the MissionPlanner motor test to test and set it to the highest you can without producing much thrust, although it looks OK to me. It’s already getting close to your hover throttle.

Some of those clone DJI flamewheel kits flex a lot and it is a real problem, you might need to try and reduce weight as much as possible.

i found that wrong parameter already some days ago. It had an effect, but it was not the main problem.
it seems that my version of mission planner needs a komma as decimalpoint and my android qgroundcontrol needs dot as decimalpoint.
i wanted to write 10.2V.

it is really weird, because i have a hand full other flamewheel clones (the same hardware) that fly perfect from the first start.

This is what i tried meanwhile:

  • I changed the power module, but that had no effect on the flight stability.
  • I analysed the propeller thrust and changed the not so perfect propellers.
  • i changed the right motor (no 1) , that was getting warmer than the others.
  • I resetted the tuning parameters to default values (ATC_ANG_PIT_P, ATC_ANG_RLL_P, ATC_ANG_YAW_P)

but nothing prevent the copter from raising potential thrust lost events. Every now and then the copter touches the ground, because it has not enough thrust.
the potential thrust lost events occur more often when battery gets empty.

the lateset logfile is here:

i have seen in the log, that there are lots of maximum values on rcout before the position thrust lost events.
Could it be, that your proposed value for MOT_BAT_CURR_MAX = 50 A is causing this position thrust lost events?
I will check that tomorrow.

I don’t believe this will be an issue, you’re only peaking at about 26 amps in that log.
Provided that MAX value is well above hover and normal flight requirements, it will only serve to limit the absolute maximum current draw for things like a big climb.
The way to set it correctly is work out what current you motors would use maximum combined, what your power distribution system (including current monitor) can handle, and what you battery can safely supply - set it to the least of all these, such as 60A for a typical power brick. You can build in a bit of safety by reducing it 10% or so…

In logs you’d see it take effect during a really big climb or “speed run” by the current really flattening off at the specified value, as Arducopter limits PWM values to stay within the specified current draw.

I probably shouldn’t have included it in my parameter suggestions, but in your case it certainly wont make things worse.

Your X and Y vibrations are really low, that’s great. The Z vibrations are another story, not really bad but getting into a grey area. There’s clipping towards the end of the flight and this will cause altitude problems.

Your motors are really struggling, overall the average PWM is a bit high, but motors 1,3 and 6 are going to absolute maximum at times. Motors 2,4 and 5 are sometimes reaching minimum PWM. With a hexacopter this indicates the flight controller is fighting a physical yaw issue, like arm or motor mount twist or serious differences between CW and CCW props (less common). I think this is what’s causing the problems - not having enough overhead left for proper attitude and altitude control.

I cant imagine a camera supply would be robbing an ESC of available current, but truth can be stranger than fiction… Power everything through the power brick/current monitor.
I’m clutching at straws a bit here, but:

  • Are all your ESCs relatively new and have capacitors on them? What are they?
  • Heavy duty power wires to ESCs? Length matters
  • ESC calibration done OK?
    Maybe a couple of photos

New thought: ESC settings - voltage cut off and so on. Make sure all optional features are disabled, let arducopter and it’s attitude control/battery monitoring handle everything.

Thank you shawn,

Finally I have found the solution.

vibrations!

I have rubber dampers between my pixhawk (in the white case in the photo) and the frame. Normally they are positioned diagonal, but this copter has vertical dampers.


With two additional rubbers i have pulled the pixhawk case, so that the dampers are diagonal.

After that, i had no problems anymore.
Even extreme movements are no problem.
Here are two diagrams before and after the rubber treatment.

The difference is not so big, but it’s enough to fly crazy or not.

The camera powering from the motor connection seemed to just have an effect, because the system was a little bit too vibration sensitive.

Again thanks for your help mike and shawn. I have learned a lot.

Good that it’s working.
You might want to check those PWM values from a flight log, in conjunction with the motor order diagrams, to keep an eye on the uncommanded yaw.