Missing Images

At least the drone made up for it when it circled the wagon!

Just pulled down the data and overall it is ok. Thank God I don’t have to drive down there again! The deviation on the two worst spots jumped around +/- 3.5 inches, but luckily they were non-critical. Post processing also helped because GLONASS was junk that day and I would have never known it from the drone’s GPS. I processed with GPS, Galileo and SBAS and went from a 15% float to 4.5%.

1 Like

It’s a new day! Interesting how the center leg has multiple images missing… Besides that looked ok, but if you notice on the south line it is missing images and double-ing images near the turns. I have seen this more often recently where there is a noticeable lage from coming out of the turn to taking the first image on that leg.

I’ve been reading this and related threads on several community forums, because I have also occasionally seen missing images as displayed by Pix4Dcapture on an iPad. Since I recently completed a sequence of long, straight flights of two “rows” each, side by side, I noticed some things that suggest temporary failure of the radio comm link is a potential cause of missing images. A little background: Pix4Dcapture on iPad 9.7 Pro (GO 4 was completely terminated while Pix4Dcapture was open); DJI Inspire 2 with stock remote controller; onboard KlauPPK GNSS receiver for PPK; images MicroSD card marked ‘SanDisk Ultra PLUS 64GB XC1 V10’; Distance from remote to drone at far end of flight paths before turnaround to Home: 4,000 - 4,800 US feet over drained tide flats; Rural area with no tall buildings; Drone approached a steeply sloping hillside just prior to turnaround to Home on all flights; UAV Forcast app suggesting less-than-optimal GNSS satellite constellation and worsening Kp Index; Wind minimal at 5-6 knots; 75/75 overlap.

That day, did I constantly maintain the angle and orientation of the two antennas as instructed in the “Optimal Transmission Range” section of the DJI Manual? Probably not consistently. These were 12-14 minute flights and I could have wavered in how I held the remote up/down or off-axis to the drone as it flew toward the far turnaround waypoints. On one flight there were no problems near the turnaround. On three others there were several missing images and odd positions near the turnaround. As the drone approached the far-off hillside, it was probably losing sat locks because of proximity to the hill.

Atypically, on one flight there were 5-7 images missing on the outbound path toward the turnaround (I did not see that many images missing in a row on any of the other 18 flights). I was not aware of the missing images until returning to my office that day.

For the next day’s flights, I tried to avoid any situation where I was as far away from the drone like on the previous day, and I paid more attention to “aiming” the remote’s antennas to manually track to the position of the drone. Afterward, I did not see problems at the turnaround points in those flights. I did occasionally see a missing image, but that was rare and not a big issue for this project. Perhaps those few missing images were caused by a brief comm link dropout because I was near a few houses, some of which had metal roofs. I used the same MicroSD card for image recording on both days.

All that said, the missing or shifted images on both days might be attributed to another reason(s) as suggested on this and other threads.

Thanks for that write-up, very helpful! In my experience I fly sites of all shapes and sizes and while this isn’t an every flight occurrence, it is more often than not. I always setup at the centroid of the job to limit the distance to the drone and I run a parabolic antenna so I almost never have any transmission problems. Thing is though, that even if you lose complete connection the bird should be pre-programmed and continue the mission as originally instructed so it is very doubtful that signal has anything to do with this. My personal opinion is that it has more to do with how DroneDeploy is pre-calculating the positions of the images. They are basically leaving it up to the GPS position and we all know that GPS can be flaky at times. I counter this with the fact that I can fly my P4P with Litchi and my H520 with DataPilot, both of which trigger images on a timed basis usually between 1.5 and 2 seconds and they never miss an image or have any issues with uneven image spacing as you will see on another thread on this forum. DroneDeploy claims they had noticeable issues when they tried the time-based trigger so here we are. As of the last month I am now seeing a trend of the system missing images coming out of corners. Not every corner, but now at least 2 or 3 every flight and it is consistently after the first waypoint and coming out of a corner somewhere down the line.

1 Like

I should have mentioned that I have not yet used Drone Deploy. As for using Pix4Dcapture, there is this on this linked page: You should have a stable connection as well as the ability to take off and fly manually, to get the video feed of the camera, and to take pictures. That quoted, I have found some ambiguity in the documentation…

And on this linked page: Case 2 - Connection loss in Fast mode

"Gaps in the image acquisition can happen because of connection loss with the Fast mode. The interactions between the drone and the app during a mission are as follows.

  1. The app receives the GPS location of the drone (drone to device).
  2. The app decides to take a picture according to the new location, and asks the drone to do it (device to drone).
  3. The drone may or may not take a picture, even though usually it does.
  4. The drone sends back a message to say that the picture was taken (drone to device).
  5. The app shows the camera icon at the position of the drone when the message is received.

Therefore the camera icons on the flight track of the grid do not always correspond to the exact location of the photos where they were taken. Indeed some delays may happen in steps 1, 2 and 4 described above. It can happen that the camera fails to shoot (step 3.) but still sends a callback to say the image was captured, which results in fewer images on the SD card. It can also happen that the message is not sent by DJI or missed by Pix4Dcapture (step 4.) so the app thinks no image was captured whereas it is there, which results in more images on the SD card."

I typically plan missions in Pix4Dcapture with Fast Mode (not Safe Mode). I typically set the speed at slightly faster than the mid position on the range as displayed.

So it sounds like Pix4D is capturing similar to DroneDeploy, but I don’t put any stock in the relationship between the connection and the image triggering unless they are not pre-loading the mission. I have had a couple of occasions over the last couple of years where I have lost connection with different drones running different apps (not Pix4D) and every single one continued their missions and continued to take images as originally instructed. I’ve only heard a hundred variations of experiences from these scenarios so just one man’s penny in the jar.

Isn’t that the truth!
Map Pilot has 2 modes, connected and connection-less.
In connected mode, a very good signal is required for photo capture. The smart device is calculating when to “ask” for a photo based upon speed over ground. When the app “asks” for a photo, it seems that sometimes the drone fw doesn’t actually “take” a photo right away and that accounts for gaps and catch-up multiples. (their explanation)
In connection-less mode, the photos are taken in intervalometer mode and no control signal is necessary AND the capture is more reliable because the craft fw is not making any decisions. But, the image spacing may not be as good as connection mode when the fw is sending the capture commands in a timely manor.

I suspect that the underlying problem is that the craft fw doesn’t always take a photo when the sdk flight app says it wants one. BUT, it seems there should be some way for the sdk devs to overcome this because when in other apps than GO, when I hit the shutter release, it always captures the image without the delays found in the automation scenario.

And, the devs usually don’t want to talk about these details which would lead you to think they don’t quite get it either.

Okay, that’s my penny in the jar !

1 Like

One thing I have to point out regarding my testing with a M2P yesterday !!
(see images of 2 missions; 270’ and 200’ 80/80) :ok_hand:

Happy for your M2P… :wink:

The M2 is a great little drone. But for SFM work, it still has that rolling shutter. The P4P is the best except for this nagging issue. (and only 4 rotors! :wink:)

Yep, we’re still here. Nothing like watching the drone fly over a GCP and miss a shot and in the next frame a car drives over it, lol. Guess where it was? This one could be applicable to the uneven Spacing thread, but it’s not consistent.

2 Likes

Back again. While I am still seeing this behaviour on standard maps it has definitely gotten better and only misses shots a couple of times per flight and I think it is mostly coming out of turns. This case is a linear map and it is pretty bad possibly because a linear flight includes many more waypoints and that is where the system is having trouble.

Our 3rd Phantom 4 Pro, same issues 2 years in. @andrew

1 Like

If you check GPS connectivity along the flight in Airdata, does GPS look healthy throughout? GPS +/- can vary. Also curious if your processing report shows any overlap issues?

Thanks

I think it’s at least partially unique to the P4P. A mission from last week that exhibited a few skips and this is using Map Pilot. For a test, I’ve flown back to back with the P4P then the M2P using DD and had skips in the P4P capture and the M2P missed none.

Yes, I have used AirData and it looked fine. I usually have about 15 satellites every flight as well.

You may be onto something. I’ve only flown with Pix4D a handful of times and it didn’t do it and the only other thing I use is Litchi which uses a timer instead of location and it is always perfect.

Also wanted to chime in here because I’ve been having this problem for as long as the rest of you - including the spacing suddenly being tight and consistent after the first battery change (which means it cannot possibly be SD card, hardware, DJI SDK inherent fault, firmware, tablet, etc. it MUST be with the DroneDeploy app).

I noticed something interesting the other day when I had this issue. Knowing this is a constant issue, I loaded the entire flight worth of images into Agisoft on my laptop on-site to check GPS spacing. Sure enough, it was terrible. I reflew the entire mission and had the SAME gaps in the SAME places.

Has anything been found to mitigate this issue other than outrageously high overlap to mask the issue? DD doesn’t want to troubleshoot with you unless you’re a paying customer, but issues like this unaddressed for literally years, affecting the most basic functionality of the software, are exactly why I’ll never be a paying customer.

Why does DD not care about this major problem?

3 Likes

In a nutshell, this issue appears to be unique to the P4P (in my experience.)

Typically when I post process, if the purpose is just to make an ortho (no topo or 3D) I just take a quick glance (without zooming) at the camera positions to see if there are any large obvious gaps or missed rows. However lately I have some jobs that the customer does their own processing and they asked me why the camera spacing isn’t even and has gaps. So I took a closer look at am also experiencing with the P4P what you are all describing and this is with the current version of DD available to this point in the month of July 2020 and updated firmware of course.

After running different missions I can confirm the issue as far as I can tell is not significantly affected by different locations, different altitudes, different frontlaps (between 70 and 85 percent) and different speed SD cards. It also happens when manually lowering the drone speed to the minimum 4 MPH! It also happens along any point of the flight path, not just near turns. There are always numerous gaps, but, luckily with high enough sidelap and frontlap it does not cause stitching issues but to me it’s unacceptable. Why? Because the Mavic 2 Pro doesn’t have the issue!

I believe it has something to do with GPS positioning accuracy in the P4P and/or the interaction between DD and the DJI SDK for P4P. I am planning to test with Pix4D Capture to confirm 100% if it’s DD related or DJI related because if it does it with Pix4D Capture then this is not an issue specific to DD most likely.

I’ve noted in general it seems the Mavic 2 Pro has a better GPS receiver in it than the P4P for whatever reason as I get GPS lock on a dozen or more satellites WAY quicker on the Mavic than on the Phantom and the flight characteristics seem to “feel” better to me as far as the GPS positioning.

What is odd is that in the 2+ years using the P4P I don’t recall it always being this way, but frankly maybe it was and I just never noticed it as long as I didn’t have stitching issues.

I greatly prefer the global shutter of the P4P over the rolling shutter of the M2P but to be frank, I think the hype about it being far superior for mapping is just that, a lot of hype as the image quality has no significant different as far as I can tell. Maybe some very high frontlap and low-light conditions there would be a difference.

So bottom line, if the hardware/software makers don’t correct this, I’ll have to sunset the P4P and move to the M2P exclusively as it’s frankly embarassing to provide the customer with images that have location gaps.