Testing Follow me-mode, fly away and crash :( - happy ending! :)

If the P3 got an incorrect tablet location to the west, why would it shoot off to the east. I am wondering if the false location was to the east way off the map. If you zoom out of the map are there any green dots to the east?
If it got an incorrect reading far to the west, when I initiated Follow Me, and then suddenly it got the correct reading, to the east compared to the starting point, the P3 assumes the RC has moved to the east and goes away to the east to accomplish the Follow Me mission.
 
Viewing the tablet location in Google Earth doesn't convey the abrupt, unrealistic change in location of the RC. Plotting the tablet longitude and latitude each against time looks like
View attachment 47117

Clearly, this abrupt change is an error.

For fun, I plotted the tabletLongitude and velocity
View attachment 47118
This shows the P3 racing off as a result of the RC location error.
I've been studying your great graphs some more. The time scale, is it in seconds? It looks like that, it took about 10 seconds from initiating Follow Me until it crashed into the tree.

I think it is odd that the latitude and longitud is changing so slowly after the glitch at the start of Follow Me, it takes about 10 seconds before they are close to the correct values. But ok, it might be the tablet's GPS values that takes some time to establish. Do you have any thoughts about that?

Is it possible to retrieve the GPS position of the RC from the flight log in the iPad, with a good resolution?
 
I've been studying your great graphs some more. The time scale, is it in seconds? It looks like that, it took about 10 seconds from initiating Follow Me until it crashed into the tree.

I think it is odd that the latitude and longitud is changing so slowly after the glitch at the start of Follow Me, it takes about 10 seconds before they are close to the correct values. But ok, it might be the tablet's GPS values that takes some time to establish. Do you have any thoughts about that?

Is it possible to retrieve the GPS position of the RC from the flight log in the iPad, with a good resolution?
The time scale is in seconds. The RC location is a 15 HZ signal. This plot shows the RC longitude and the total acceleration. So, yes it's about 10 seconds from the glitch to the crash
upload_2016-3-15_5-10-50.png


It's hard to say why it takes so long for the RC gps signal to return to correct values. One possibility is that it is being "smoothed".

I would guess that it's not possible to retrieve the RC gps signal from the .txt produced by the Go App. @msinger and @ferraript are both working on .txt converters. You might ask them.

I've attached the eventLog file. You might some of the info interesting. The first number on each row is the time.I've also attached the .csv for this flight. The file name has a .txt appended; i.e. change the file name by removing the .txt so that you can view it in Excel.

I had another look at the previous flight with a similar incident to yours. He was using an Android as well. The incident occurred when he initiated Follow Me the second time. It took about 6 seconds for the RC gps to return to the correct value.
 

Attachments

  • FLY075.log.txt
    7.1 KB · Views: 403
  • FLY075.csv.txt
    7.5 MB · Views: 359
  • Like
Reactions: AndersGB
If anybody is interested there is a beta version of DatCon that contains the columns tabletLongitude and tabletLaitude. It can be obtained by going here.
 
  • Like
Reactions: happydays
The time scale is in seconds. The RC location is a 15 HZ signal. This plot shows the RC longitude and the total acceleration. So, yes it's about 10 seconds from the glitch to the crash
View attachment 47150

It's hard to say why it takes so long for the RC gps signal to return to correct values. One possibility is that it is being "smoothed".

I would guess that it's not possible to retrieve the RC gps signal from the .txt produced by the Go App. @msinger and @ferraript are both working on .txt converters. You might ask them.

I've attached the eventLog file. You might some of the info interesting. The first number on each row is the time.I've also attached the .csv for this flight. The file name has a .txt appended; i.e. change the file name by removing the .txt so that you can view it in Excel.

I had another look at the previous flight with a similar incident to yours. He was using an Android as well. The incident occurred when he initiated Follow Me the second time. It took about 6 seconds for the RC gps to return to the correct value.
Hi and thank you very much for your help with this! Maybe I will look at the file to get some more info.

You know, I'm a very careful person and during my first flights with the P3 I was very anxious. Not that I shouldn't be able to fly with it, I've trained a lot on a small drone and P3 is easier, more that I've read a lot about fly aways, with P1 and P2 especially. And I've been very anxious that something that that could happen and that the P3 would hurt a person, animal or property seriously. But more and more the unrest disappeared, I felt trust in the P3, it behaved fantastic. And suddenly this happened and I was wondering if I should buy a new one and continue flying or put it to a rest. But now, when I understand what happened, I think I will give it a go again. And don't use Follow Me mode.

I have one more question, if your don't have time to answer it just don't, you have helped me so much with this. In a previous post you wrote "Yes, the RC location is recorded in the P3's .DAT file. But, only during a Follow Me mission...." but you seem to have the RC location, recorded by the P3, for the whole flight? I tested Follow Me three times, so there should be a lot of time without Follow Me. Perhaps I have misunderstood your post.
 
Last edited:
TXT log structure mentions also RC_GPS record, but I haven't seen the log, that actually contains non-null values in it and this applies to TXT log from this incident too
but there is APP_GPS record and I can see values there
Interesting, is it possible to match them against the P3's recorded GPS values for the RC?
 
All,

This is my first post. After reading this forum since mid-December when I got my P3P, I was highly motivated to register now to say that the "Follow Me" mode fly-aways may be more common than you think. I also had an uncommanded fly-away during a recent "Follow Me" mode event that is almost identical this this OP's fly-away event. Fortunately, I was able to switch back to the "P" flight mode and regain control of my P3P before it got out of range or crashed. I flew the P3P back to my location and landed.

I wanted to know if there was something wrong with my system before flying it again, so I sent my flight log, dat file and Healthy Drones log to customer support in China ([email protected]) to find out what happened. Long story short, after 3 weeks of email correspondences for further info, they determined my iPhone 5s device recorded a bad GPS location and when I entered the "Follow Me" mode, the P3P took off at full speed in the direction it thought my R/C transmitter was located. It was (erroneously) trying to fly to the location it thought my transmitter coordinates were reporting. By switching back to the "P" mode, I disabled the automatic flight mode and I was able to regain control of the quad copter. And yes, I did perform a Compass Calibration at the beginning of my flights (I flew 3 flights without any issues before my fly-away on flight #4.). The Customer Support tech assured me that the aircraft and transmitter were working correctly and that nothing is wrong with my system. That may be so, but there appears to be a serious flaw in how the "Follow Me' mode works. OR is there a serious interface error with our devices?

I ran across this link that seems to explain what is going on. I am not saying this IS what's happening in all suspicious fly-away cases, but after my experience, I can see how this could be the problem. Watch the video in the first post: DJI Flyaways. - Page 1

FlatSpin
 
  • Like
Reactions: AndersGB
Yes - I've posted that video on this site at least a half dozen times.

Re the video and its explanation of flyaways, basically the same problem here, it's just different. :) Instead of the aircraft recording a bad home point, the phone/tablet is sending a bad GPS fix. Same thing really. But it's certainly not DJI's fault and it's not the pilot's fault either.

This situation is a little unusual. Yeah, it happens, but I wouldn't say it's a chronic problem. It was bad luck for the OP.

It's the phone/tablet's fault. What can we do about it? How can we keep this from happening?

One thing we could do is try to use a device that has a solid GPS module. And that's kind of tough to research, since phones/tablets don't tell us how many satellites they get (the idea being the more satellites, the least likelyhood of a bad fix). But maybe that cheap tablet from South Korea wasn't the best idea. How about a phone/tablet that uses GLONASS as well as GPS? That would be nice. During Follow Me, we could hold the controller out a bit, rather than close to our belly (a big belly will block a satellite or two or three). Otherwise, it seems to me we must be sure to use follow me in wide open spaces. We should try to move around rather than stand so that the tablet is inclined to reassess our location. We might check uavforecast.com prior to flight and see how many GPS satellites (not GLONASS) are visible. And we should check the elevation mask depending on where we are walking (valley/desert) because it's not like our phone/tablet is going to gain satellites with elevation. And most importantly, we should be ready and know exactly how to take our aircraft out of Follow Me in an instant.
 
You may be right, the bad GPS location reporting from the phone/tablet device issue may not be widespread, but it's certainly something we need to be aware of and understand. Good info and advice on how to mitigate the false GPS reporting conditions! Keeping a fast finger on the "P-A-F" switch is key to recovering from this condition.
 
....

I have one more question, if your don't have time to answer it just don't, you have helped me so much with this. In a previous post you wrote "Yes, the RC location is recorded in the P3's .DAT file. But, only during a Follow Me mission...." but you seem to have the RC location, recorded by the P3, for the whole flight? I tested Follow Me three times, so there should be a lot of time without Follow Me. Perhaps I have misunderstood your post.

I took another look and the RC location starts getting recorded the first time the Follow Me is intiated. In your flight this was at 177.693. You can see that here Testing Follow me-mode, fly away and crash :(

I quite interested in your attempt to sync the .csv from the ,DAT and the .csv from the .txt. The flightTime column (C) should match the row number in the .csv from the .txt file using the formula (flightTime /100) -1. Anyway, that's how it was engineered; you'll be the first to try it.

It would seem you want to sync the two in order to make the case that the tablet's GPS produced the right values? And, that implies there is a subsequent software bug that is the cause of the incident? IMHO the case is very strong that there exists a software bug. I mentioned a few posts back that there was another flight very similar to yours. In both flights the incident occurred when Follow Me was initiated after the first time. Moreover, it was exactly when Follow Me was initiated. There is a lot of structure in that behavior; i.e. it's not random. That's what we in the software biz call a bug.
 
  • Like
Reactions: AndersGB
All,

This is my first post. After reading this forum since mid-December when I got my P3P, I was highly motivated to register now to say that the "Follow Me" mode fly-aways may be more common than you think. I also had an uncommanded fly-away during a recent "Follow Me" mode event that is almost identical this this OP's fly-away event. Fortunately, I was able to switch back to the "P" flight mode and regain control of my P3P before it got out of range or crashed. I flew the P3P back to my location and landed.

I wanted to know if there was something wrong with my system before flying it again, so I sent my flight log, dat file and Healthy Drones log to customer support in China ([email protected]) to find out what happened. Long story short, after 3 weeks of email correspondences for further info, they determined my iPhone 5s device recorded a bad GPS location and when I entered the "Follow Me" mode, the P3P took off at full speed in the direction it thought my R/C transmitter was located. It was (erroneously) trying to fly to the location it thought my transmitter coordinates were reporting. By switching back to the "P" mode, I disabled the automatic flight mode and I was able to regain control of the quad copter. And yes, I did perform a Compass Calibration at the beginning of my flights (I flew 3 flights without any issues before my fly-away on flight #4.). The Customer Support tech assured me that the aircraft and transmitter were working correctly and that nothing is wrong with my system. That may be so, but there appears to be a serious flaw in how the "Follow Me' mode works. OR is there a serious interface error with our devices?

I ran across this link that seems to explain what is going on. I am not saying this IS what's happening in all suspicious fly-away cases, but after my experience, I can see how this could be the problem. Watch the video in the first post: DJI Flyaways. - Page 1

FlatSpin
Thank you very much for posting your experience with Follow Me mode.

Yes, they seem to be more common than I thought also, I hadn't read about any such event before, but now several have posted about similar experiences.

During this flight, I tested Follow Me mode two times first, without any problems. But at the third time, it just flew away. Did yours fly away when initiated also?

It's a little bit strange that P3 got an incorrect GPS location for the RC at the instant when I activated Follow Me, but as Marknmd and others have said, it is important to move around a little to ensure a god GPS reading for the tablet. It might be difficult, but an essential security measure. And also be ready to switch to P mode all the time during a Follow Me mission.
 
It would seem you want to sync the two in order to make the case that the tablet's GPS produced the right values? And, that implies there is a subsequent software bug that is the cause of the incident? IMHO the case is very strong that there exists a software bug. I mentioned a few posts back that there was another flight very similar to yours. In both flights the incident occurred when Follow Me was initiated after the first time. Moreover, it was exactly when Follow Me was initiated. There is a lot of structure in that behavior; i.e. it's not random. That's what we in the software biz call a bug.
Yes, that's exactly what I would like to do! I will try that. Especially when the position of the RC is correct all the time in the replay of the event in the iPad. BTW, did you watch my little video? :)

Yes, I'm in the software biz also (or have been :)) so I'm very eager to find out if this is a bug or not. But I won't be surprised if it is a bad GPS reading from the tablet at that instant, it's not random, I agree, but I stod still for a while when initiating Follow Me, and I assume that the other OP did that also, and that may have caused an incorrect GPS reading at that moment. But on the other hand, why a spike in the reading exactly when initiating Follow Me?

Thank you for the formula and all the help. I will come back with my results if I succeed.
 
Yes, that's exactly what I would like to do! I will try that. Especially when the position of the RC is correct all the time in the replay of the event in the iPad. BTW, did you watch my little video? :)

Yes, I'm in the software biz also (or have been :)) so I'm very eager to find out if this is a bug or not. But I won't be surprised if it is a bad GPS reading from the tablet at that instant, it's not random, I agree, but I stod still for a while when initiating Follow Me, and I assume that the other OP did that also, and that may have caused an incorrect GPS reading at that moment. But on the other hand, why a spike in the reading exactly when initiating Follow Me?

Thank you for the formula and all the help. I will come back with my results if I succeed.
I was in a hurry yesterday and didn't watch the video. Now, I can't find it. But, wasn't the point of the video that the tablet had the correct values for tablet location? I already knew that; that's why I didn't watch it. Could you post another link to it please.

The flightTime column I mentioned was engineered to exactly match the "time(milliseconds)" column(G) in the .csv you can generate in HealthyDrones. Since that value comes from the part of the .DAT that gets transmitted to the RC I had assumed that it would exist in any .txt generated from a .txt converter. But, I didn't see it in @ferraript 's converter. That's the reason for the funky formula.

I would think that standing still would increase the accuracy of the GPS. The fact that it's exactly when initiating Follow Me screams software bug; to me anyway.
 
...
I would think that standing still would increase the accuracy of the GPS. The fact that it's exactly when initiating Follow Me screams software bug; to me anyway.

Okay I'll just post the vid directly.


Watch between 15 secs and 1 min.

Standing still is the worst thing you can do.
 
  • Like
Reactions: pomonabill220
Okay I'll just post the vid directly.


Watch between 15 secs and 1 min.

Standing still is the worst thing you can do.
The author of the video didn't present a compelling case that moving around will increase the accuracy of the GPS. He just supposed that it did. Maybe moving around takes more time and the GPS info will get better in the extra time.

The P3 often sets a home point and then sets it again. In the flights that I've looked the distance between the first home point set and subsequent home point sets is a few meters.
 
I took another look at the output of @ferraript 's converter. The flyTime that would match the flightTime column in DatCon's .csv is there. It's called "OSD.flyTime" (column AV in the latest). It's units are seconds whereas the DatCon's flightTime units are milliseconds. But the sample points are the same, so it should be easy to sync the two outputs.
@AndersGB
 
The author of the video didn't present a compelling case that moving around will increase the accuracy of the GPS. He just supposed that it did. Maybe moving around takes more time and the GPS info will get better in the extra time.

...

I think when a person sees a bad GPS location in his phone, most people's instinct is to walk around a bit so that it can correct. Why? Because it makes sense. Also because it works. Maybe your instinct is to stand still. I don't think most people are inclined to freeze when they have a bad GPS location on their phone. But maybe you're right. Maybe standing perfectly still is the best way to improve a bad GPS location on the phone.
 

Recent Posts

Members online

Forum statistics

Threads
143,092
Messages
1,467,577
Members
104,975
Latest member
cgarner1