Neither P4P will maintain altitude

[spirytus]

I also had a look. At the beginning of the run the AC gains altitude as it starts to increase speed. There is a descent, but it's not gradual; it's all at the end of the run where the AC slows down. After the run there is a gradual increase to get back to the proper altitude. Here is the first run out past the baseball diamond and the second run back to the home point.
View attachment 75398
The first run started at 244 where the speed started rising above 0. The AC had gained 1.5 meters in altitude by the end of the run and braking started. This is where the drop of 2.5 meters occurred. Finally, at 258 secs the AC had stopped, was hovering and the gradual ascent to home point altitude started. That gradual ascent was cut short by the beginning of the second run back to the home point.

My P3A, P3P, and Mavic do this. I've looked at a couple of P4P flights that I have data for and they do it as well. Doesn't matter if it's the .DAT file from the AC or the .txt from the App. In fact ,one of my flights used AutoPilot.

It's apparent from the videos that there is a gradual altitude increase after the run and the AC has stopped. But, to my eyes at least, an altitude change in the first part of the run isn't apparent. This means that, in my case at least, that I'm not able to see the drop while the AC is in motion. Without actually knowing the profile of that drop I would probably assume that it had to be gradual. I would also expect that if the AC were flying straight at me it would be very difficult to determine if the descent were gradual or occurred during the braking.

@jpk1080 can you try a different experiment? As before fly it out past the baseball diamond. Then wait until it has reached the home point altitude. Then, on the return run don't remove the elevator input until it's past you and observe it's altitude as it flies past. The AC should fly past you a little above the home point altitude. It will have gained a little altitude during the first of the run as the speed is increasing. If you post the results it doesn't matter if it's the .DAT of the .txt.

Aside: BudWalker, can you post the same graph for gpsAltitude only? I can't get CsvView running on my 32 bit system here...

 

[F3honda4me]

Good point but I'm not so sure the phantom is actually ignoring GPS elevation. Had a quick look at the data:

Right after he pitches full forward and the phantom begins its forward traverse, GPS altitude (erroneously) spikes up in altitude while his throttle remains neutral. Going by the assumption that the flight controller is not ignoring GPS data (P mode?), I'm thinking it's trying to compensate for the unwanted GPS elevation increase by attempting to descend.

Right after he stops, (and finally receives accurate GPS elevation data) you'll notice a sudden drop in elevation (lower than when he begun forward traverse, since he did infact loose altitude). So the FC corrects this discrepancy by commanding the motors to ascent until it reaches the user requested altitude.

The gradual descent during forward flight and the altitude correction after he stops is clear in the video.

When I have more time, I'll plot a graph for you guys.

P.S. If I wasn't working and the weather was better I'd test this out on my P4P but I'll probably experience the same flight dynamics as you -- I think honda is right in stating this is nominal behavior for DJI quads that relay heavily on sensor data - my experience with "assisted" flight here is limited since this is my first DJI product, all my other quads are fully manual. If you feel brave try it in ATTI mode (which should ignore GPS altitude data) and see if the gradual descent goes away - just be very careful. Flying low to the ground in ATTI mode is not for the inexperienced.

The drone does not use GPS for height in any way. This was confirmed by DJI engineers on RCG forum. The small changes in height are totally normal.

 

[F3honda4me]

Aside: BudWalker, can you post the same graph for gpsAltitude only? I can't get CsvView running on my 32 bit system here...

I can but as mentioned the GPS alt is only logged for troubleshooting reasons. gPS alt has a margin of error over 5 meters. This is why the drone completely ignores it.

 

[BudWalker]

Aside: BudWalker, can you post the same graph for gpsAltitude only? I can't get CsvView running on my 32 bit system here...

Also, the attached .zip contains the .csv that CsvView created. You could use this if you are familiar with the Excel plot package.

Sorry about the 64 bit requirement. The Mavic, P4P, P4, Inspire 2 data have a different record structure than the P3 and Inspire 1. It would have been a significant development effort to change the 32 bit version CsvView/DatCon to accept these new crafts. It was much easier to switch to a 64 bit version.

 

[jpk1080]

Sure I will try to post more info today. Appreciate the help. The drone descends much more than a few feet. I can start it at 50 feet and eventually it will be down to two if I never increase the altitude manually. I will try atti mode but I'm almost positive I have already with the same result. I will also try filming it with the iphone did the visual reference along with showing the constant descent on the app. During flight in any direction the vervain speed will show a constant decrease.

 

[BudWalker]

Sure I will try to post more info today. Appreciate the help. The drone descends much more than a few feet. I can start it at 50 feet and eventually it will be down to two if I never increase the altitude manually. I will try atti mode but I'm almost positive I have already with the same result. I will also try filming it with the iphone did the visual reference along with showing the constant descent on the app. During flight in any direction the vervain speed will show a constant decrease.

Please just start with that one simple experiment so that we can verify that the AC behaves as I've described. Fly it out past the baseball diamond and wait until the altitude has stabilized at the altitude when the AC was still over the home point. Then fly it back and remove the elevator input only after it has passed you.

I believe you when you say that you can make it descend 50 feet using a sequence of runs. That was happening in the part of the flight that I analyzed. The reason for that is that the AC was not allowed to ascend to the home point altitude prior to the second run. Doing this repeatedly will result in a lower altitude at the end of every run. This is normal behavior in the sense that the P3A, P3P, Mavic Pro, and P4P all do this.

 

[jpk1080]

I just meant that I can take off ascend to 50 feet and in one continuous run without stopping get it to descends all the way down to a few feet

 

[BudWalker]

I just meant that I can take off ascend to 50 feet and in one continuous run without stopping get it to descends all the way down to a few feet

I'll be interested in seeing the .DAT for that. But, let's just start with the experiment that I've described.

 

[Roamer105]

You should calibrate the remote (sticks). Looks like there is a throttle bias to be corrected.


Sent from my iPad using PhantomPilots

 

[F3honda4me]

You should calibrate the remote (sticks). Looks like there is a throttle bias to be corrected.


Sent from my iPad using PhantomPilots

Not the case. Per the DAT there is no throttle input being received by the drone.

 

[jpk1080]

Alright I hope this is a bit more clear. The last video I hope illustrates just how low it actually gets. I went up to 25 feet according to the vps. Go towards the trees. On the return flight, I actually move out of the way b/c the drone is less than 6 feet according to the vps. I'm also 6'3 for reference. It then climbs back up, but only to 15 feet according to the vps, and stablizes at that altitude. Forward flight was a bit into the wind, but it still descends indicating ~1mph vertical speed descent. Thanks for looking.

Dropbox - DataLogs

 

[F3honda4me]

Alright I hope this is a bit more clear. The last video I hope illustrates just how low it actually gets. I went up to 25 feet according to the vps. Go towards the trees. On the return flight, I actually move out of the way b/c the drone is less than 6 feet according to the vps. I'm also 6'3 for reference. It then climbs back up, but only to 15 feet according to the vps, and stablizes at that altitude. Forward flight was a bit into the wind, but it still descends indicating ~1mph vertical speed descent. Thanks for looking.

Dropbox - DataLogs

Now THIS is showing something. Budwalker is spot on with his suggestion for you to test. That last run, the drone drops a tremendous amount of height even though the barometer thinks it is going up. I assume that the ground here is not slanted downwards as you go away from the home point towards the baseball field, correct? I do see it looks like the ground drops a bit when you switch from soccer to baseball field, but nothing more than a few feet.

Budwalker is a lot better at datcon/csvview than me (he did after all write the program) so there might be more insight he can provide. But looking at everything else, nothing jumps out at me. But this final run specifically where you go until the drone goes past you actually DOES show an issue. I think the other runs were simply not long enough and all looked pretty normal. Even the run to the fence looks normal. Again I assume the ground here is level right? I had my I2 out today and while mine changes height during low to the ground runs like this, at no point does it do so as drastically as this last run you had.

For reference here is the screenshot.

Have you sent this drone back to DJI yet at all?

 

[jpk1080]

No that's the thing. This drone and my other p4p do the same thing. My inspire 1 also does this now as well. I can't understand what exactly could be causing this.

 

[F3honda4me]

No that's the thing. This drone and my other p4p do the same thing. My inspire 1 also does this now as well. I can't understand what exactly could be causing this.

I sent this to a DJI rep on another forum. Hopefully he can pass it onto the engineers. Might be a bug or maybe need to do some more testing or troubleshooting.

 

[blade strike]

Does this happen when VPS is off? Have you calibrated VPS?

Have you refreshed firmware and done a factory reset via the assistant?

 

[spirytus]

I'm telling you guys, the FC thinks it's ascending during horizontal traverse so it's applying a negative vertical vector to counter.

If it's not GPS, than one of the other altitude sensors, or some product of all.

Sent from my Pixel XL using PhantomPilots mobile app

 

[F3honda4me]

I'm telling you guys, the FC thinks it's ascending during horizontal traverse so it's applying a negative vertical vector to counter.

If it's not GPS, than one of the other altitude sensors, or some product of all.

Sent from my Pixel XL using PhantomPilots mobile app

The barometer thinks the drone is going up so that could be a possible cause.

 

[AlecW]

I saw it doing down this time. This is the weirdest issue with 3 drones all doing the same even with different devices.

 

[jpk1080]

Yes all three drones. I appreciate you guys looking at the data. Is there some way these could have had the barometers damaged flying below sea level for a sustained period of time? I've had the Inspire 1 for over a year, and never recall having this issue but it's making think I never noticed somehow (thought unlikely). The P4P's I honestly didn't fly enough before my trip to be able to detect this kind of issue. They went out on a semi that I company I work with sent out. Seems unlikely they would have all been damaged the same way. Yes I have tried with atti off, vps off, calibrated everything both on the drone, through the app, and through dji assistant. It seems like one direction is worse than the other sometimes, but it various. For example, forward generally seems to be the worst, but today it was going in reverse where it had a severe dip on the way back. Sometimes it's left, other times it's right, but it's always present. I'm stumped.

 

[BudWalker]

FLY129 had 4 pairs of runs with an out and back in each pair. It appears to me that the behavior was exactly as I described for the previous flight and predicted for this test. I'll get to the video and vps/barometer later.

At the end of the 1st and 4th pair the altitude had returned to the altitude at the beginning of the pair. In the 2nd and 3rd pair there was not enough time for the AC to return to the home point altitude resulting in a gradually decreasing altitude.

The 3rd video was taken during the 4th pair. On the return run the props can be seen towards the end of the run indicating the elevator input had been removed and the AC was braking. This occurred before the pilot came into view. Therefore, the pilot can't be used as a reference when determining if the AC descended during the run.

The last run pair seems to show a discrepancy between the vpsHeight and the relativeHeight at the end of the run that wasn't there at the beginning. In fact it looks like the AC is actually 2 meters lower than the it was at the beginning of the run pair. However, the begin and end locations are different making comparisons problematical. Also, the AC was stopped with a stable attitude at 360 but the vpsHeight continued to change for another 12 secs.

To summarize the AC flew 1580 meters from 3 different locations and returned to 3 different locations. There may have been an uncommanded or unexplained deviation of 1 or 2 meters. IMHO this is well within specs. If the barometer caused the 1 or 2 meters deviations this has been discussed many times in this and other forums. My advice? There isn't anything here to be concerned about.

@spirytus The attached .zip has the .csv in case you want to take a look at this one.