Terrible day. Drifting and crash

[flodi]

Please start a new thread and we'll be happy to comment on your log too.

Ok, sorry. My bad. I will start a new thread.

 

[flodi]

HANG ON A SECOND.

There's a huge difference in your first posted log and the second (Russia in the first and Brazil in the second). What's that all about?

So where were you?

Sorry, Alan. apparently I had the same problem here in Brazil and used the same thread. As msinger oriented, I created a new thread.

Thanks

 

[welsewool]

I'm guessing there was some kind of interference -- perhaps due to a bad compass calibration or flying near magnetic metal objects. If you upload your DAT file to dropbox.com and post a link back here, perhaps we can get @BudWalker to check it out.

@welsewool can you provide the .DAT so we can take a look? Look here to see how to retrieve the .DAT. It'll be large so you'll have to Dropbox it and provide the link

guys thanks for help!
here my logs files Dropbox - drone-logs
hope we will find the reason of this drone vs human fighting.

 

[GMG]

This is another example of why DJI should at least allow the option for people to manually select and practice flying in ATTI mode. If it's not an option and you're suddenly confronted with a lack of satellites to stabilise the flight the likelihood of a bad outcome is high!

 

[welsewool]

This is another example of why DJI should at least allow the option for people to manually select and practice flying in ATTI mode. If it's not an option and you're suddenly confronted with a lack of satellites to stabilise the flight the likelihood of a bad outcome is high!

Yeah. I think even if there are 0 sattelites - vision positioning system had to set drone to hover and not allow to drift back

 

[AlanTheBeast]

guys thanks for help!
here my logs files Dropbox - drone-logs
hope we will find the reason of this drone vs human fighting.

That's the one in Russia - not Brazil.

 

[BudWalker]

guys thanks for help!
here my logs files Dropbox - drone-logs
hope we will find the reason of this drone vs human fighting.

FLY018.DAT is the .DAT for this flight. The problem seems to be that the Mavic was in GPS_ATTI when it shouldn't have been. The way it got into this state is similar to some other incidents. The common thread is that gpsHealth rises to 4, and the switch to GPS_ATTI is made. But then gpsHealth drops for some reason; maybe the Mavic is being moved. After that the Mavic doesn't switch back to ATTI and/or it can switch to GPS_ATTI when it shouldn't. This all takes place before launch, and is not recorded in the .txt file.

The Mavic was powered up at time -83.0 secs and went through it's normal start up. Although the numSats never got above 11 the gpsHealth finally reached 4 at -52 secs. This probably caused the Go App to show the green Ready To GO(GPS) indicator. But, then gpsHealth dropped to 0 twice at times -31 and -10. After motorStart and launch gpsHealth was sitting at 0 but the Mavic was in GPS_ATTI.



I've done some experimenting with this scenario to determine if the Go App is showing the green Ready To GO(GPS) indicator when the Mavic gets into this state. I.e., ii is saying everything is good, go ahead but it shouldn't be. My results have been that the indicator either shows the green Ready To GO(GPS) or the yellow/orange Ready To GO(Vision). As a result I try to remember to look at the GPS bar graph display on the RC which shows the gpsHealth value. I'll admit that I forget to do this more often than I remember

The other incidents that are similar to yours happened because the Mavic was moved from a gps friendly spot to a gps not so friendly spot. I can't quite tell with this incident. The Home Point (H) was different from the launch point (A) but the accelerometer data didn't seem to show the Mavic being transported. Was it powered up and then moved to the launch site?

 

[jayeddy]

Mine drifted also about two months ago over the roof of my house. Backed up to see it and fell in the pool. Two phones, controller took a bath. Controller and my ego did not survive the event. Drone hovered and control ler lasted long enough to land it. After a couple of bonehead attempts to determine the state of my controller involving flight time, I put Drone away. Rice saved my note edge, but not the Controller. I am back up and running now!

 

[welsewool]

. Was it powered up and then moved to the launch site?

No. It was launched from the same point as it was positioned right with powering on. It was sidewalk near 3-floors building.

It's a mystic. How home point and launch point can be different even without fly there? There is building there.

So it's seems to be like Mavic error or my fault with flying bad conditions?

 

[welsewool]

The Home Point (H) was different from the launch point (A) but the accelerometer data didn't seem to show the Mavic being transported.

Wow! Also I've just kept my eye on provided logs map and realized one very interesting thing! I don't know but I've missed that before: REAL path and path from LOGS are totally different! They are mirrored. I was standing on other side of the road and Mavic tried to fly opposite directions. See the image to understand the real situation:

It was 20-30 meters away and mirrored. Fantastic =(

 

[BudWalker]

Wow! Also I've just kept my eye on provided logs map and realized one very interesting thing! I don't know but I've missed that before: REAL path and path from LOGS are totally different! They are mirrored. I was standing on other side of the road and Mavic tried to fly opposite directions. See the image to understand the real situation:

It was 20-30 meters away and mirrored. Fantastic =(

The inconsistency probably is due to two things. Google Maps imagery is sometimes not quite accurate. And, the gps data for this incident can't be trusted. Why do you think the paths are a mirror image? The gps data (flawed as it is) shows the Mavic travelling South after launch. Did it actually travel North?

You had asked about who is at fault; either you or the Mavic. I like to think my forte is incident analysis and software that helps with that. I'm not very good at assigning blame, legal minutiae, blah, blah. It's too complicated and there are many here who like to do that sort of thing. </rant> Anyway, this incident was due to the Mavic being in GPS+ATTI mode when it should have been in ATTI mode. If it were in ATTI mode it would've only been drifting in the wind and much easier to control. It's possible you could have looked at the RC display and see that the gps bar graph was sitting at 2 instead of 4 or 5.

 

[welsewool]

Why do you think the paths are a mirror image? The gps data (flawed as it is) shows the Mavic travelling South after launch.

Because I remember every movement and believe my eyes. Today I made short video from that place.

 

[BudWalker]

Because I remember every movement and believe my eyes. Today I made short video from that place.

I think I see now. The video shows that the path shown by the .DAT and .txt is not what actually happened. But, we already knew that. I was asking if they were a mirror image. From what I was able to understand from the video the actual path was not a mirror image of what actually happened. It was just different.

The video also made clear to me that the launch site had a lot to do with the incident. In fact, I'm surprised that the Mavic managed to get enough gps signal to ever switch to GPS+ATTI, if only briefly. The surrounding buildings block a significant number of gps satellites. I had checked to see the concrete rebar was a problem. It didn't seem to be, but, IMHO, you got lucky.

My advice is don't try to do a flight from a location like this. If you absolutely have to then consider trying to keep the Mavic from ever switching to GPS+ATTI. And, be prepared for problems. I've seen some posts where pilots are attaching some type of EMF shield with adhesive backing over the GPS receiver.

 

[welsewool]

I think I see now. The video shows that the path shown by the .DAT and .txt is not what actually happened. But, we already knew that. I was asking if they were a mirror image. From what I was able to understand from the video the actual path was not a mirror image of what actually happened. It was just different.

The video also made clear to me that the launch site had a lot to do with the incident. In fact, I'm surprised that the Mavic managed to get enough gps signal to ever switch to GPS+ATTI, if only briefly. The surrounding buildings block a significant number of gps satellites. I had checked to see the concrete rebar was a problem. It didn't seem to be, but, IMHO, you got lucky.

My advice is don't try to do a flight from a location like this. If you absolutely have to then consider trying to keep the Mavic from ever switching to GPS+ATTI. And, be prepared for problems. I've seen some posts where pilots are attaching some type of EMF shield with adhesive backing over the GPS receiver.

Maybe you are right, but when I'am looking at videos from other cities around the world like Chicago, Honkong, etc. it's a little bit confusing )))

 

[Robbyg]

Mine drifted also about two months ago over the roof of my house. Backed up to see it and fell in the pool. Two phones, controller took a bath. Controller and my ego did not survive the event. Drone hovered and control ler lasted long enough to land it. After a couple of bonehead attempts to determine the state of my controller involving flight time, I put Drone away. Rice saved my note edge, but not the Controller. I am back up and running now!

Not to side track the thread. I am sorry that happened but at the same time it would have made one hell of a Mavic bloopers video.

Rob

 

[AlanTheBeast]

I think I see now. The video shows that the path shown by the .DAT and .txt is not what actually happened. But, we already knew that. I was asking if they were a mirror image. From what I was able to understand from the video the actual path was not a mirror image of what actually happened. It was just different.

The video also made clear to me that the launch site had a lot to do with the incident. In fact, I'm surprised that the Mavic managed to get enough gps signal to ever switch to GPS+ATTI, if only briefly. The surrounding buildings block a significant number of gps satellites. I had checked to see the concrete rebar was a problem. It didn't seem to be, but, IMHO, you got lucky.

My advice is don't try to do a flight from a location like this. If you absolutely have to then consider trying to keep the Mavic from ever switching to GPS+ATTI. And, be prepared for problems. I've seen some posts where pilots are attaching some type of EMF shield with adhesive backing over the GPS receiver.

Just adding to your comments:

GPS masking (buildings) = poor horizontal accuracy.
GPS multipath (reflections off of the buildings) = poor accuracy.
GPS being too sensitive (tracks very weak signals that contribute to error) = poor accuracy and quickly shifting position.​

 

[crazybill]

City sidewalks = lots of rebar. Not suggesting this as a cause but it can't help either. It may not show up immediately, but reflections and ground plane change with distance.
-Bill-

 

[AlanTheBeast]

City sidewalks = lots of rebar. Not suggesting this as a cause but it can't help either. It may not show up immediately, but reflections and ground plane change with distance.
-Bill-

Rebar would affect the compass, but not GPS so much.

Bricks, concrete, asphalt, trees, earth, water ... all reflect 1.6 GHz quite well w/o need for rebar. The smoother the surface, the cleaner that multipath looks and the correlators lock on like stink. Given a wavelength around 17 cm city surfaces are pretty smooth places. So a building masks the direct path (what you want) to a satellite and instead you get a bounce off the other building. That PR is now many metres longer than the direct path ... repeat for various satellites and then add drone movement to the mix! And of course, the sats you want for horizontal positioning (lower elevation) are the ones that will mask/multipath the most.

His issue may involve the compass as well as the GPS. (Or something completely different...)