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.

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:)