Crash after a takeoff after multiple succesfull takeoff on a mission on 4.2.3

hello,

my copter X8 frame on 4.2.3 flight successfully on many hours
but after lot of repeating the same mission and without any modification,it sundenly crash already after the takeoff.

after the crash every components where verified (motors…ect) but nothing have failed.

here is the log below (ask me if the link if dead) :

i’ve read that takeoff was improved on the last 4.3.0 stable last release,but why ?

thanks for help

Don’t know the cause for the crash… but seeing your log, it seems that you have two GPSs Here3 connected right? You must upload their firmware to the latest stable, you have lots of bad messages coming from them.

Thanks for watching the log.
It’s right.i’ve 2 gps connected.
By update gps you mean update of ublox or change firmware via can ? Do you have a link for a firmware because by update via mission planner, via can, it says that firmware is up to date.

Thanks

1 Like

In the last arm and fly near the end of the log, the craft looked like it was landing, but then changed to NOT Landed for some reason. It doesnt actually disarm. Is that just the midpoint of the mission for payload drop? I think the copter tipped over or crashed because it tried to move laterally while still touching the ground to satisfy the wandering GPS position.
For quite a while the GPSA and GPSB had varied quite a lot and correlation with the IMU position was all over the place.
After crashing it switched to RTL then AltHold, maybe attempts to regain control.

In this pic the blue, green and red lines should all be on top of each other, or at least close. This is just the final segment of the land, gripper release and crash.

Probably best to implement a motor emergency stop switch.
RCxx_OPTION,31
on the channel of your choosing. If you see it’s landed but not disarming or tipping then hit the emergency switch.

To improve reliability I would
BRD_BOOT_DELAY,5000 to allow CAN GPS units to boot before the flight controller
INS_ACCEL_FILTER,10
INS_HNTCH_ENABLE,1
INS_LOG_BAT_MASK,7
GPS_GNSS_MODE <–set these at 5 or 65, whichever gives the best HDOP for your area
GPS_GNSS_MODE2 ←
then check and configure the HNOTCH as per below and probably an Autotune.

Once you’ve done repairs you will need to do another test flight just in ALTHOLD mode with hovering and a few gentle movements, nothing too radical.
I suspect the FFT params do not suit your copter and will need adjusting. This test flight will gather data for those FFT and HNOTCH adjustments.
Let’s see that log and we can help with those adjustments.

Also with GPS_AUTO_SWITCH set to 1:UseBest (the default) means that position could shift quite a lot when GPS units are diverging and accuracy is changing. It might be best to check and change their order if one seems more reliable than the other, and set 4:Use primary if 3D fix or better, will revert to ‘UseBest’ behaviour if 3D fix is lost on primary

Can you describe the copter? Frame and props size, motors and ESCs?

Do you do this firmware update procedure?

@Fusionflight @xfacta, I’m having exactly the same issue!!!
Copter tries to move sideways upon takeoff randomly (only happened twice in 30 odd flights). Then flips. Both times has been using GPS guidance for vertical take off.
I’m also running a here3 with stock firmware and a secondary dgps for backup gps. I’ve got GPS_AUTO_SWITCH = 4, as I only want to use the dgps if the Here3 shits itself.
You can see in the logs it veers ever so slightly to the right then launches left and does a double barrel roll.
I’ll try the BRD_BOOT_DELAY and look at the GPS_GNSS_MODE (I’m in Australia Victoria, Southern Hemisphere).
I’ll also try the firmware upgrade on the Here3.
Below is a link to download the logs. I’d really appreciate it if I could have some expert eyes across it.

image


Section 1 is where it tries to go right immediately upon throttle up and Section 2 is the start of the barrel roll to the left.

This one

Are you running Mission Planner latest stable?

thanks for your reply !

i’ve updated via mission planner lastest stable. old gps i’ve buy it was 2 years and are stock in a box are updated but not the news one we bought last year that are in the actual version.i haven’t try the ublox updated but i don’t know if it could change anything.

1 Like

To improve reliability I would
BRD_BOOT_DELAY,5000 to allow CAN GPS units to boot before the flight controller
INS_ACCEL_FILTER,10
INS_HNTCH_ENABLE,1
INS_LOG_BAT_MASK,7
GPS_GNSS_MODE <–set these at 5 or 65, whichever gives the best HDOP for your area
GPS_GNSS_MODE2 ←
then check and configure the HNOTCH as per below and probably an Autotune.

Once you’ve done repairs you will need to do another test flight just in ALTHOLD mode with hovering and a few gentle movements, nothing too radical.
I suspect the FFT params do not suit your copter and will need adjusting. This test flight will gather data for those FFT and HNOTCH adjustments.
Let’s see that log and we can help with those adjustments.

unfortunately meteo is very bad since a week.i will test it asap.

do you have a right procedure to set notch filter ?

Yes, setting up the harmonic notch filter is easy once you’ve done test flights with
INS_LOG_BAT_MASK,7
INS_LOG_BAT_OPT,0
I use the FFT feature in MissionPlanner to determine the frequency and bandwidth requirements, and generally put those values in for throttle-based HNOTCH.
The you change
INS_LOG_BAT_OPT,2
and do a test flight to see if it’s working (filtering the noise)

What size props have you got?

You had FFT enabled, which is good, but I suspect FFT_MINHZ,80 is too high for your X8. Within its allowed range the FFT is reporting a hover frequency of 127Hz which is more like full throttle RPM than hover.
FFT_MINHZ should probably be 30 to allow the FFT to capture the real hover frequency and lower.
You can set that if you want, but either way the INS_LOG data will tell us the story.

thks for answer. i’ve 28p props