H520 Crash

NemesisChiken · May 20, 2019

I had my first crash this weekend

I'd done some poking around with the ST16S logs in Drone Logbook but nothing serious but now it was forensic data. Friday, I was attempting to test DataPilot waypoint programming when something went very wrong in a trial flight! I had done a trial just before the crash that went pretty good ...

but it got TOO LOW

I redid the waypoints in DataPilot to look like this ...

and this is what happened ...

BTW - I was not very impressed with UAV Toolbox's version of the flight plan

Whyyyy would it be so different ???

I was very lucky in it seems that there was only some minor damage to the gimbel that i was able to have repaired at a local camera repair shop and it scratched up 1 blade moderately and another slightly. I spent the rest of the weekend learning everything I could about Yuneec drone logs and put together this simple mindmap to sort it all out. It's not finished but it's a start

I found references to a /FlightLog set of directories but I never ran across anything like that and am guessing that is for other Yuneec models. I did review a lot of software tools available including:

Q500log2klm - a lot of features but not integrated well for H520 yet: no Overview, no Profiles, no Data Analysis
Dashware - nice interface but couldn't get it to work with H520 logs yet
UAV Toolbox - lots of features but not well integrated for H520 yet - Crash Analysis Sample
DroneDeploy - more an enterprise level operations tool
DroneLogbook - all the basics, I can see why its part of the standard lineup ... just not enough detail
Skyward - real nice suite of features that scales up for larger drone operations with LAANC
Qgroundcontrol - Part of the open-source Dronecode Project for PX4 and MavLink
Dronebase - More a global management option
PX4 - An open source solution that seems very robust - Crash Analysis Sample

Questions from weekends review:

It seems the H520 is truly based on the Dronecode Pix4D, Mavlink, etc. platform?
What are the non-DroneLogbook .ULM telemetry files used by?
Does running 3rd party software like UAV Toolkit on the ST16S cause problems or void warranties?
What does Velocity do for Gimble Tilt Mode (S1) other than 20-degree up-angle on the camera tilt ?
What is the difference between the RTL Flight Mode (S4) and the RTL soft button on the Fly Menu in Datapilot?
What does the 'Log Download' do in the PC Data Pilot Planner (Y) menu?
Where should I be looking to triage the crash event?

AH-1G · May 20, 2019

I'm going to be blunt!
Why would you test this for the first time so close to buildings and trees??
Aren't there any open fields you could have gone to?

arruntus · May 20, 2019

Bad luck, mate ?

What the cravings for training the new toy are. At 10 feet is normal, the drone has done what you sent him. With a few more miles, seeing that it was heading towards the wall, having put it in manual mode, quickly changing the stick, and you would have regained control.

1. Yes
2. In the logs goes all the information, in the telemetry files just that.
3. The warranty only covers the malfunction of the drone. It is not a manufacturer approved application. Only in case of malfunction will it cover you. The warranty is not broken.
4. That
5. No difference
6. You download it and then you can use it like you did. There's no mystery to it.
7. ???????

The drone did what you sent him. There is no more turning of the nut.

All of us, sooner or later, have made a mistake and crashed or hit him. That's how you learn

Next time, until you have at least 20 hours of flight, go to more open areas, schedule missions quietly at home and check them again. You have to learn to walk before you start running. This includes the use of the programs, if you have flown drones before

By the way, very good research work about the logs ?

NemesisChiken · May 20, 2019

AH-1G said:
Why would you test this for the first time so close to buildings and trees??
Aren't there any open fields you could have gone to?

In hindsight, starting with something other than a 2 story concrete building would have been better, but an open field would not have given me much reference for waypoint plotting and testing. My first two flights performed reasonably well, I just need to find out what caused the waypoint plan to fail; did i somehow turn it off and it just drift into the wall; did it lose GPS signal; was it a calibration issue; did i forget to turn on OA; etc.

Is a good rule of thumb for tolerances on waypoint driven flight plans? Are they just not very accurate?

NemesisChiken · May 21, 2019

THANKS for all the response! Let me reply to them individually...

arruntus said:
2. In the logs goes all the information, in the telemetry files just that.

I was asking more what other tool do these "2019-05-17 10-27-25.ULM" files feed into

arruntus said:
3. The warranty only covers the malfunction of the drone. It is not a manufacturer approved application. Only in case of malfunction will it cover you. The warranty is not broken.

So only DataPilot is approved by the manufacturer, if you use something like Qgroundcontrol you are on your own regarding the consequences.

arruntus said:
6. You download it and then you can use it like you did. There's no mystery to it.

It says "Not Connected" ... I tried plugging in the ST16S with the USB connection but that didn't seem to help. What needed to be "connected" to get this function to work?

arruntus said:
7. ???????

Do i need to just dig thru the log manually reviewing the MavLink messages to try and discover what the point of failure was with this flight?

arruntus said:
The drone did what you sent him. There is no more turning of the nut.

I don't understand what you mean. The drone didn't do what the waypoint flight plan indicated. Can you clarify what you are saying by "the drone did what you sent him" ?

arruntus said:
By the way, very good research work about the logs ?

Thanks

Deleted member 6299 · May 21, 2019

Consider that the satellites are at about 36000 km away from the earth there might be a differents up to 8 meters of the exactness. So flying in such narrow areas is pure stupidity in My opinion. But learn the lesson and go out and have a happy flying.

Phaedrus · May 21, 2019

You seem to have been expecting a positional accuracy that exceeds what is actually available to the stock 520. Testing it in a situation where you had no margin for error compounded the problems.

arruntus · May 21, 2019

NemesisChiken said:
So only DataPilot is approved by the manufacturer, if you use something like Qgroundcontrol you are on your own regarding the consequences.

And Pix4DCapture, which is officially supported, or so we believe. Anyway, what they are going to look at are the commands that the drone receives, if it receives a strange command, because the program is not optimal, is when they can say something anyway. They are suppositions with logic, but they don't stop being suppositions. What they are going to look at is the log, and there are only logical orders and tracks.

NemesisChiken said:
It says "Not Connected" ... I tried plugging in the ST16S with the USB connection but that didn't seem to help. What needed to be "connected" to get this function to work?

I don't know if a colleague has tried it lately, it's a function that works and stops working with the different updates. The truth is that I don't know how it is at the moment. In its day, I made a small tutorial of how to use it, you have it in the thread of basic procedures. Look at it and if you keep having problems, I'll take a look.

NemesisChiken said:
Do i need to just dig thru the log manually reviewing the MavLink messages to try and discover what the point of failure was with this flight?

In principle, yes. But I think there was no mistake, I think not to confuse me by saying that you put the waypoints at 10 feet high and I think that at that height has been hit with the wall. That height is relative to the home, in the capture that you have put can be read, in that particular waypoint. Another thing is that I should not have turned before having reached the wall, the fault in horizontal.

Here we should talk about precision GPS positioning systems. Very fast, normal satellite receivers, like the one carried by the H520, base have between 1.5 and 2 meters of error, so that minimum distance must be added margin. It would be interesting to search in the log the intensity of the satellite signal. Yes, when you started the mission I had enough satellites, which was the HDOP (in this case).

With this system you can't rush so much, with an RTK system, things change but making automated flights so close to objects breaks propellers, it will never be a good idea.

NemesisChiken said:
I don't understand what you mean. The drone didn't do what the waypoint flight plan indicated. Can you clarify what you are saying by "the drone did what you sent him" ?

In principle yes companion, the problem is that you have not taken into account the margins of error and to these margins must be added what I call, "it never happens, but when it happens, you prepare it", I mean, as a colleague has told you well, we depend on a system that with errors due to many factors, a magnetic storm at that time may have been the cause, to say samething.

I would look for the HDOP to see at the time of the accident what its value was. The number of satellites you had locked and from there to draw conclusions

biltno · May 21, 2019

Sorry to hear of your mishap. Watching the video, it actually could have been much worse. I’m not familiar with that particular waypoint programming , but is there anyway you can take control once it is running? Can you run obstacle avoidance with that? Just be thankful no one was standing in that area because you would have had a whole different problem for sure.
Hopefully you get it figured out and get back in the air soon

RPR · May 21, 2019

Things happens. Speaking on my behalf, when I have a new drone, I don’t try to rush and learn all things at once, despite the hours that I have under my belt.
Glad that no one was hurt, and you’re able to salvage the H520. Get back in the air ASAP, but this time around, take baby steps.

h-elsner · May 21, 2019

Low altitude and close to the wall of the building, this brings GPS multipath in my mind.

Multipath Signals: How do they make my GPS have errors?

This may indicated by the the GPS coordinates shown in UAV toolbox.

br HE

Good time Charlie · May 21, 2019

I love drones, quads, hexes, flying toys.

If I stepped out the door of my townhouse complex and a H520 (a big ol' hex) was buzzing around at ten feet over my car and the parking lot I'd have a fit. Then we'd have a long conversation about appropriate testing locations for autoflight functions.

You crashed because you didn't account for GPS margin in close quarters flying. Simple as that. No need for extensive log review. Very close proximity to buildings, cars and possibly people is NOT the place to be testing autoflight functions.

Good luck, hope you take advice and don't make the same mistake twice.

Tuna · May 22, 2019

NemesisChiken said:
I had my first crash this weekend

Sorry to hear that.

On the plus side I am really impressed with the forensic analysis of the system after the event. That sort of insight is invaluable - not only to you as a pilot, but to the community as a whole. Thanks for sharing it.

As the author of UAV Toolbox, I'll explain that the flight log that it displays covers the entire duration that the H520 has a positional fix - it doesn't only limit it to the 'in flight' portion like DroneLogBook does. It's an outstanding issue that I need to add a 'slice' option to only show the relevant section (or whatever section you wish) when you review flights.

So the differences are two-fold - firstly you're seeing the 'top' and 'tail' of the session in addition to the core flight. That'll show you where the GPS took you too close to the building. Secondly (just by eyeball), it looks like I'm using a slightly higher resolution map source for reviews, which might give a small shift in apparent location. Remember that GPS (and online maps) are not centimetre accurate. You should never rely on pixel perfect positioning when planning or reviewing flights.

NemesisChiken · May 22, 2019

Tuna said:
On the plus side I am really impressed with the forensic analysis of the system after the event. That sort of insight is invaluable - not only to you as a pilot, but to the community as a whole. Thanks for sharing it.

Thanks! At first I just wanted to bury it and never talk about it, but decided that maybe by sharing this experience and lessons learned might help others avoid it in the future

Tuna said:
As the author of UAV Toolbox, I'll explain that the flight log that it displays covers the entire duration that the H520 has a positional fix - it doesn't only limit it to the 'in flight' portion like DroneLogBook does.

That makes a LOT of sense now, that was me walking away with it at the end - thanks for clarifying that

Tuna said:
Remember that GPS (and online maps) are not centimetre accurate. You should never rely on pixel perfect positioning when planning or reviewing flights.

They aren't even meter accurate from what others have said. A 10m buffer would be a much safer methodology from what I've gathered

Tuna · May 23, 2019

NemesisChiken said:
They aren't even meter accurate from what others have said. A 10m buffer would be a much safer methodology from what I've gathered

In the UAV Toolbox app for the Typhoon H, it displays a warning before exporting waypoint files that a safety margin must be maintained when you're actually flying for exactly that reason.

Sureshot · May 27, 2019

I observed last year that the same GPS mission points can result in different actual ground locations by 1-4 meters.
This was with using an Neo M8 module.
I normally set waypoints at least 6M clear of any obstacles.

Phaedrus · May 27, 2019

Sureshot said:
I observed last year that the same GPS mission points can result in different actual ground locations by 1-4 meters.
This was with using an Neo M8 module.
I normally set waypoints at least 6M clear of any obstacles.

Wise move. The fact is that the GPS is simple consumer grade that is not all that accurate. The US Government claims consumer GPS is accurate to about 8 meters with a 95% confidence level. Expecting millimeter accuracy is simply beyond what the hardware can deliver.