Drone logs from our third crash

Hi all
My name is Dan and I’m a drone pilot doing surveys in Africa and we recently lost a drone for an unknown reason. The reason I am asking for help here is that our manufacture has gone radio silent after uploading logs to them and this our 3rd crash using their drones. Auralia X6 max and X8 max. We use UGCS to create our flight missions and upload them to the drones herelink controller I’m fairly certain we are using the latest version of ardupilot.
So a brief description of what happened.
It was our 4th flight of the day and approx 10min after take off I noticed the drone starting to fly off mission at first i thought it was a gust but the drone never corrected itself. From there I kicked the drone into loiter mode to see if I could fly it manually with little success. On the wat home the drone starting yawing uncontrollably and spun extremely fast with no response to input from my remote. All I could do was a blind landing. Its an 8 prop octocopter and the only config we change in MP is to set the drone to continue mission on comm loss.
I am linking my google drive to the crash log. I’m not cleaver enough to read the logs apart from finding the yaw error so any help would be greatly helpful.

1 Like

Check your file in ardupilot hardware report… compass 1 and barometer 1 health is down, seems the same module …

Yes had a look with that tool now very interesting. I even checked the logs before the crash and there was some errors also there. I’m just curious as to why Qground control never gave any errors before take off as well as the fact that the drone was calibrated 7 hours before the first flight of the morning.

Hi again had a check on the flights with no incidents and i see those have no compass issues. It could be that they developed from the crash or during the flight I’m not sure?

First, you are using old firmware (4.4.3 - over a year old at this point). Highly recommend updating to latest stable (4.5.7 at the time of this post).

The tune appears incomplete, missing many of the basic steps from the basic documentation or methodical configuration. You have no battery failsafes enabled, no ESC telemetry, no proper filtering, and a lot of default parameters that should’ve been configured more precisely.

What ESCs are you using? You’re using legacy PWM output, which might be appropriate if your ESCs are very basic, but for a craft of this size and complexity, I’d expect they support DSHOT or another more capable protocol.

Your internal compass calibration is poor at best, which isn’t helping, but isn’t necessarily causal. The Cube’s internal compass is often affected by interference due to the proximity of the autopilot to high current sources (like ESCs) in the compact space afforded for component installation in many copters. As a result, it is often disabled in favor of external compasses.

On to what appears to be the root cause:
At timestamp ~02:31:40, it looks like you had some motor issues on one or both of Motors 2 and 8. Their thrust output spikes quite high, while Motors 3 and 5 reduce output to compensate.

Wow another user with troubles with Aurelia support. ( don’t worrie its not just you)

@Yuri_Rage I wonder if this was how it was delivered from Aurelia? I also think the esc’s provided dont support telemetry.

Is it possible a sensor was disconnected or became loose during flight? ( I have had that happen with a GPS receiver that was on a round tube ( but the EKF caught it and switched to another GPS)).

The motor outputs sure seem all over the place after 2:31

Thanks a million for taking a look at least its a step in the right direction.

I’d look at a mechanical issue first. Check that all motors are still aligned with the props horizontal. Beyond that, check wiring and ESC/motor function.

When you see motor output saturate at one extreme (in this case, Motors 3 and 5 at the low extreme), there is little to no margin left for control and stability. An Octa frame naturally increases that margin, but more than one motor saturating will almost certainly lead to some degree of control loss, if not catastrophic loss.

Once you determine the root cause, please update the firmware and have a look at configuring your Copter IAW the documentation I linked. Continuing to operate in the present configuration will almost certainly lead to further issues (at best) and could actually be dangerous on a craft of that size. Did the manufacturer provide that set of parameters as ready to fly? Or did you attempt to reconfigure from defaults at some point?

We were supplied with a ready to fly parameters. The only things we change are the RTL heights depending on were are flying. What I am going to do is get a log from a brand new drone that went down a couple weeks ago and if you would maybe have a look it would be a great help. And again thank for your help thus far.

Ok, thank you for providing that detail. I have reached out to the dev team regarding the subject, as well.

At the price point and advertised RTF configuration, I’m surprised that those parameters are what is provided. This is only a single data point, so I don’t want to make this an indictment of the manufacturer. It’s entirely possible that this particular craft was mistakenly delivered with an incomplete tune or that someone on your team mistakenly loaded a set of parameters not intended for flight.

I will be providing parameters to other drones and logs so we can get more data points. Second question is there a place to do courses to become proficient in setting up our drones going forward.

There are several developers who offer professional services for operations like yours. @amilcarlucas first comes to mind, though there are several others who might be able to consult with you if he is unavailable.

I’m afraid I’m probably not the best candidate for large copter setup, though I’m happy to review logs here and provide at least a cursory look at the big picture.

Hi everyone, my name is Seb and i work for the same company as Dan, also as a qualified commercial drone pilot.
I think what would help us tremendously is to get some online trainings on Ardupilot systems. We operate quite a few aircrafts from Aurelia but due to some disappointments we might move across to Drogonfly drones in the near future.
Can anyone suggest any good online training provider please? We are based in South Africa.
Many Thanks.

See my response just above your request. I think you’d best be served by consulting directly with a dev team member rather than relying on online sources.

Bummer. For the future I would like to suggest that most flyaways are related to the GPS. The correct mode is to quickly switch to stabilize. Once in Stabilize you will have control of your craft. I tested this multiple times with older firmware using bad GPS data.

1 Like

We can help you out if you want.

Yuri, the internal compass is not notoriously poor. It is very accurate.
You are misidentifying the failure mode. The issue is that the the autopilot is mounted <2cm from very high current ESC power wires. At that distance, the magnetic field from the wires is orders of magnitude stronger than earth’s magnetic field. The magnetometer is accurately reporting the magnetic field but that magnetic field is dominated by the wiring, not the earth’s magnetic field. The end result is that the compass should not be used in this installation, not that the compass is poor or defective.

Thanks for the correction, Craig. I worded my response poorly and have edited the verbiage for those who may read it in the future.

Thanks. I appreciate you doing that.
https://ardupilot.org/copter/docs/common-magnetic-interference.html#maxwell-s-equations-the-magnetic-field-on-the-axis-of-a-current-loop

Thank you. How would we go about that?