Ok, I just did some testing with several different mapping solutions. All of this was over the same general area and as close I could with settings to be the same. This is all on the same hardware (tablet: ipad Pro, inspire 2 latest firmware x7 camera with 16mm lens). Sandisk Extreme Pro 64gb.
DJI GS Pro – Was able to shoot every 2 seconds, jpg, no missing frames. Dead accurate GPS information and positioning.
Map Pilot - Was able to shoot a DNG raw file every 5 seconds without fail. Accurate GPS.
Drone deploy - Was able to shoot ON AVERAGE every 2 seconds, lots of timing variation and really odd GPS position information. Strangely, if you look at the actual source image spacing, it has just about the right amount of overlap, but whatever DD is doing for capture methods is causing failures.
I have not tried Pix4d capture yet.
Here’s a dropbox link if anyone wants to check out the sample images from these runs.
Here you can see timing, gps position, etc. There is something really wrong with drone deploy.
This is all very interesting. I’m looking for a mapping solution and considering a business license to drone deploy. However, it would seem that if they can’t be willing to fix the most basic of things in their software it seems wise for me to spend money elsewhere. How they respond to this thread will be very telling. @Andrew_Fraser I saw your list of 5 steps, but as I can use this exact same hardware without issue shooting at the same or faster rates, I firmly believe this is a bug is dronedeploy.
Do you have the flight flogs for this flight? Do you have the DD Flight Mission for this as well? Meaning was this a DD designed flight and you flew it using the DD app? I took this photo from the other thread and I cropped out the Pix4D app, I just want to verify this was a DD Mission and not a Pix4D Mission.
Even though this flight looks bad it actually shows a pattern which is different than the rest of this thread where they have random image spacing.
Now we need to figure out why yours does 2 photos then skip then 2 photos then skip in a repeatable fashion.
Random skips are going to be a tougher to track down.
This is closer to the pattern that I am getting when it “works”. The paired images condition has existed longer than the missed images condition. If anything it creates more overlap, but I would need to inspect image quality of the second shot. I have a feeling that is why there is a gap between pairs. A timing is that would cause that effect regardless of what card you use.
You can see from my original post that both conditions existed in July of 2018. Unfortunately I will have to back to my archives to get any imagery earlier than this year, but I will try to do that asap.
To all on this thread, thank you for the discussion and the points you’ve brought up. I love the evidence, the proactive investigations, and testing here. It’s awesome.
In my time here, I’ve only seen dropped photo issues that were because of either hardware issues or DJI 3rd party integration issues that all 3rd party flight platforms will be subject to.
If you’d like our flight team to investigate these specific cases, especially if you believe there is a problem specifically with DroneDeploy, and would like for these reports to be tracked in our internal systems (which, even if we can’t fix the issue, can help us bring these issues to the attention of DJI), I encourage you to email us at support@dronedeploy.com or chat us via the app. This is how these problems can be directly addressed.
It was a DD designed flight and flown in the DD app. I don’t seem to be able to access the flight logs right now, they won’t sync. From looking closely at the data, I have a theory: Whatever drone deploy is doing it’s causing a lag on the EXIF data – if you inspect the images frame to frame they have the same amount of overlap. Just the GPS data AND timestamp is wrong. it’s a consistent number of pixels offset! Here’s a theory: DD is doing something to overload the bird. Maybe it’s writing camera settings 10 times a second or who knows what on the DJI sdk which is causing the bird to freak out or get overloaded.
Thanks @Adam_Carp, I think that is the direction we are heading. Practical field troubleshooting so that we have an intelligent case to pass on. We’ll find it!
I run PPK and when I bring the images into Geosetter and read by exifTool they are located as the DroneDeploy interface shows. When I retag they move from varying locations due to the inaccuracy of the onboard GPS to the cm level positions. The backup to this is that the events that are recorded by the cm GPS are unevenly spaced as well.
When I watch the live preview window it shows a video feed, followed by a pause to show the image it just shot. The timing interval of the pauses is spot on when contrasting with a stopwatch – it’s like a metronome. The timestamps in the files are NOT (same with gps data).
I did step through some of the photos and they looked evenly spaced as you stated, once DD get’s done processing the photos I will compare the photos and the Dot Map to see if I can see anything.
I was looking through some of @MichaelL’s DD flight logs last night to get familiar with what DD and DJI has to offer in the logs. I did notice like 6 entries per photo (I won’t know until I get more data from Michael) and the times it took for each of those steps which could add up to seconds.
Now the other test we can do is turn off Live Map (please don’t hit me) and see if that makes any difference. It shouldn’t but it is data going over a shared network connection from the Drone to the Controller which may cause a slowdown on the drones processing.
In programming you have threads and interrupts. Threads are used to multitask and interrupts are callbacks that says have I have something for you. If there are not enough threads created then the interrupts can’t take place quick enough. You have to manage threads properly or you can cause issues. In the Drone there should be multiple threads, one to run the main firmware, one for lightbridge/occusync/wifi, one for photo/video, one for logging, etc etc and each of those threads should have multiple interrupts that allows SDK API calls to send/receive data from the app to the drone and visa versa.
I will look at the data when DD is complete and let ya’ll know what I find.
