Hi all, we do a lot of large scale mapping with fixed-wing UAVs, and are heavy Pix4D users. We recently tried using a multi-rotor for a 20km road survey, as it needed higher resolution imagery than we could reliably get with the fixed wing. It worked, but not without some issues: here’s the feedback.
This is all using the latest Pix4DCapture under Android on Lenovo 7" tablet.
Critical missing feature: Polygon Areas
This project was a road survey, and although large sections of it were straight, and therefore suited to a simple rectangular capture area, much of it was winding curves and this was incredibly inefficient to capture with only rectangles. For example for some 500m sections I needed to fly 4 separate flights to tile it with rectangles.
The ability to add/remove vertices from the capture polygon, and also then define the flight line direction (two finger drag to rotate the flight lines would be great, plus a numerical input) would allow for much better capture in this and many other cases
Bug: camera sometimes not nadir
I experienced a number of flights where after landing I checked the photos and they were forward facing rather than down. I *think* this correlates to times where I manually took off and then switched to automated flight, but can’t be certain. Nevertheless, it would be good if the app was more actively ensuring that the camera was pointing down when mapping
Bug: “Unfortunately CTRL+DJI has stopped”
I seemed to get this about 50% of the time when uploading a mission after powering up the drone. It was reliable when moving from one mission to another while powered up the whole time, so seems related to the initiation process. I always power up the transmitter first, then the drone, then unplug+replug the USB cable. It then asks which app to use, I pick CTRL+DJI, it seems happy for a bit (i.e. I see the battery reading and other telemetry), but when I go to start/launch it dies. No major problem, just switch to CTRL+DJI app, where you then notice the connection status go from connected->disconnected->connected, and you’re good to go
Bug? Auto whitebalance is all over the place
I’m not sure how this can be a Pix4DCapture bug, but I notice that the whitebalance temperature/tint it all over the place, giving wildly purple and other coloured images when they are all taken one after the other in consistent lighting conditions. I fully appreciate this in general, but if I was to take these photos manually with the Inspire looking down, I would not get this result.
No major problem, I’ve just graded them all in Lightroom to fix, but it would be good if this could be more consistent in future, perhaps using auto whitebalance for the first photo then locking that into place for the remainder of the mapping?
Bug: app slows to a crawl with many flights in a Project
I was using the project workflow, so I can have the area KML loaded in and plan each flight in turn over the top as I went. Unfortunately after about 10 flights the app slows to a crawl, to the point of being unusable. It is fine when a flight is open, but it slows/hangs when moving between a flight and the project overview (where you see all the flights).
I’m pretty sure this will be caused by storing previous flight image positions in an inefficient way. We’ve seen similar performance problems with other high-end commercial systems when they have tens of thousands of image dots marked, and they tend to have a ‘clear’ button to erase these and make it fast again. Alternatively, store them in a more efficient memory structure rather than what I expect is a flat list of photo positions?
Bug: flight speed setting not consistent
I noticed the flight speed would set itself back to one end or other of the slow/fast scale, despite me wanting them always flown in the middle setting. Is this stored at the project level? If so then I think you need a way of setting it at that level, rather than storing it from the first flight created in a project.
Bug: abort flight can get stuck
I had this happen a few times where I would abort the flight and the app would get stuck in a state where it is trying to tell the drone to come home, and you can’t use the app any more. I had manually taken over and landed the drone, yet the app was still in the abort process, the only available button being ‘Resume’. Quitting and re-loading the app didn’t fix it, I needed to restart the tablet to clear this
Issue: Not recognising when photos have failed
At one point I had what appeared to be a bad microSD card, in that it would start the flight and take a number of photos before then stopping. The Pix4Dcapture app showed photo dots for the entire flight, but on landing there were only for example 20 out of 120 photos taken.
Perhaps there is another SDK hook available for verifying successful image capture, rather than assuming that each time you request a photo, one is successfully taken. Perhaps just checking that the image counter has increased by one each time, or even more naively, that the available storage space has decreased.
Feature Request: show drone heading
At the most distant points the drone is often 700m+ away, and very difficult to tell orientation visually. It would be very reassuring if the app showed the heading of the drone as a means of checking this, as you should always be vigilant and ready to take back manual control at any point. A small heading arrow pointing out the front of the drone icon would be great.
Feature Request: global setting to enable/disable image transfer
Although I’m sure it is a great feature for some people, in our workflow we would never have the drone imagery transfer to the flight control tablet, so need to cancel this dialog every time.
Feature Request: KML import for iOS app
We flew this using an Android tablet to be able to use a KML, but it would be good to have the option to use the iOS version. Every single mapping job we do starts with a KML file, I’m not sure how the app went so far along in its development missing this feature! 