@Michael Kemper I found this thread which provides some nice instruction for using Pix4D on the phantom 4 pro v2.0 + remote with integrated screen but I wasn’t able to get it to work… I tried a few different USB cables I had lying around, still no go. I feel like I’m close though. Anyone else have any clues?
I am running Android (I don’t do iThings) 4.3.1 and still do not see the option for safe/fast. I wonder what other differences there are.
I just had a successful 1st flight with p4dCapture…a quick grid at 50 feet over my hay field. Flawless, except when it was done it started to rocket towards space…haha. I’m guessing my RTH height was still set at 250’ from a prior flight…no troubles taking control and bringing home. Photos looked as expected given the lighting and cam. settings. All seems promising…
Surprising that the Android version and the Apple version seem to be different. Why no ”safe mode” on Android?
Any comments from PIX4D are clearly welcome here.
Good to hear Richard that your mapping flight with the P4Pv2 seemed to have worked. Will not have a chance to test iOS version for me for a few days.
As to simply stitching images together - will not work well at all. That was my first naive attempt at mapping. If you take a set of shots on the ground with a camera from a fixed position and stitch with photoshop or lightroom, you rely on the fact that the images all have the same angle of view of all subjects. Consider for example a oil drum on the ground appearing in adjacent overlapped images taken from the air slightly to the left and slightly to the right. Both images see the top, but also the sides (different sides) of the drum. Panorama stitching in Lightroom cannot make the image of the top of the drum with the ground cut up all around it. Mapping can. Mapping can because the middle step if creating a 3D point cloud of the ground and drum, and then constructing a what if view from above of that point cloud. This process is completely different than panorama stitching in Photoshop (and what we pay the big bucks for.)
Note that there are still some artifacts around edges in the mapping orthomosaic. PIX4D’s Desktop Mapper (but not Cloud Mapper) allows you to go in and edit these to clean up your 2D map and 3D mesh. This is what I am experimenting with now.
@ Mark Muntean
I stitch nadir photos together all the time creating ortho-mosaics in GIS. In doing this, the positional error is spread across the aerial photo depending on the method chosen for the georeferencing (order polynomial). The main difference being that the photos are usually taken from a MUCH higher altitude. Generally speaking, the number of tie-points/control-points are more than sufficient due to the ground coverage within the photo frame. With UAS acquired photography, I’m limited to 400ft AGL, so even if the number of control points is sufficient in an individual frame, it’s extremely time-consuming to perform this operation on 100+ photos. Long story short…I want software that’ll do it for me…without the blobs. I want software that’ll stitch the raw raster files based on RGB (I realize there is fluctuation in RGB between frames - I still think it’s doable). Perhaps this software can use the sensor locational metadata as a “first-pass”, but not rely on it for network accuracy. Once stitched, the software will need to discard the majority of the overlap pixels, those that are farthest from nadir. Once stitched, I can georeference the orthophoto myself in a matter of minutes, perhaps even using the Pix4D supplied orthophoto as a geospatial reference. For this scenario, for the end product, I am uninterested in any pixel other than those captured as close to nadir as possible…I’m thinking +/- 5° from vertical.
Thoughts are welcome.
Through another processor (not P4D), I’ve run the same dataset multiple times with identicle settings and produced different results. This is open source software, so that likely explains some of my problems with it. For example -
Run 1 - The software applies the image of the street light from input “Photo 12” to the output ortho; Looks pretty good as photo 12 was captured very near nadir to the streetlight.
Run 2 - The software applies the image of the streetlight from input “photo 15” to the output ortho. Looks bad and blobby because photo 15 captured the streetlight on the outside of the frame (3 or more photos away from nadir).
In the image below, processed in the open source software, you can see the streetlight hanging over the gravel drive in the correct (give or take) position based on the software-calculated point-cloud; however, the photo that was applied to it was obtained from a location far from nadir (red arrow) to the streetlight (as is evident by the stack of wood and grass shown underneath it (blue oval)). The correct location for the stack of wood is the red check mark. It baffles me as to why the output ortho would contain anything other than the most nadir image for any given point - especially for an object that is elevated above the lowest surface in the dataset. I also included a screenshot of the RGB point cloud for positional reference.
I’m just trying to get the best understanding possible before I jump into the Pix4D trial. I’ve saved Pix4D for last because my research and forum conversations all indicate that it’s the best. I’ve run these datasets through processors multiple times under controlled variables with regards to camera settings, photo post-processing (photoshop type stuff), etc…
The last step is to run the identical data sets through P4D and marvel at the enhanced results (I hope). In the meantime, I still have some learning/testing to do on the camera/lighting side of things.
It does seem odd that it would not use the most central portions of each nadir image to build the orthomosaic.
Also - it seems like there is possibly some exposure difference between images. Did you have the camera in manual (fixed) setting (versus allowing auto exposure)? Or, was the lighting vary during the capture possibly due to changing clouds?
My guess is you will get better results from P4D Mapper. I look forward to hearing.
Also, if you do see similar issues with PIX4D, you can (using P4D Desktop Mapper but not P4D Cloud Mapper) go in an edit the orthomosaic. You can for example select a specific region in the orthomosaic and see all the original images that contain that region and then select manually the original image you wish to use in the merged projection. This can be helpful for example if something moves like a person or a vehicle. It might also solve the light pole issue here if it comes up in P4D.
You are wise to study study study then test. P4D is powerful but very complex. I ended up licensing it to complete my evaluation since I was still learning. They do allow you to license on a monthly basis and start / stop / restart your license so you do not need to commit to a continuous year if you just want to continue for a month.
You will want to study how to upload and download from Desktop Mapper to Cloud Mapper. It was not that clear or simple for me. While there are upload and download / sync buttons again it is not that simple in practice. Unless you have a red hot Windows machine with super GPUs you will likely want to use the Cloud Mapper for processing. The Could mapper does not have many controllable settings however, and you cannot edit the point cloud or orthomosaic with the Cloud - only with the desktop. My workflow is to perform the first computation on the Cloud or Desktop. All is brought to the Desktop where I can then control settings and add and mark GCPs. This is where you can also now merge two or more projects into one. You then upload the images and the .P4D file to the Cloud again and let it re do the orthomosaic and mesh computation. The Cloud is also where you can compute measurements of distance, area, and volume.
You are correct, there was some exposure difference even though manual camera settings were used. The shooting environment was not ideal. The sun was quickly retreating behind a ridge. The location where I was shooting was already in the shadow of the ridge when I started, but it did get significantly darker during the flight. I had done a poor job of choosing my camera settings because I wasn’t going to get a flight in at all if I didn’t hurry. With that particular data-set I actually had to post-process to try and normalize the RGB and lighten the photos. All that being said, I’ve had the same problems with photos taken mid-day with zero clouds. (Again, this is open sourced software we’re talking about, not one of the major players)
Another item on my list is to determine how the different processing providers handle data ownership. I’m a big fan of the P4D/Drone2Map products because all data can be processed on local drives. I feel like DD offers the free processing specifically for the purpose of building their library (quite genius, actually, but I’m no sucker). Often in my business, the data that I acquire are kept confidential for various reasons.
You can for example select a specific region in the orthomosaic and see all the original images that contain that region and then select manually the original image you wish to use in the merged projection.
I saw this being done in a webinar and I had completely forgotten about it - I am glad you reminded me.
P4Pv2 / PIX4D Capture iOS TEST!
I had a chance to test the new iOS P4D Capture version 3.4.0 that now officially supports the P4Pv2. Some good news, some bad news…
First, P4D Capture worked and found and recognized my P4Dv2. I was able to construct a flight plan and flew it successfully. Images looked good. This is the good (and long awaited) news.
Two issue I found however. Capture does utilize the the P4Pv2’s accurate (visual) precision take off that will allow the P4Pv2 accurately RTH at end of mission. As result RTH may be 10-30 feet off from the take off point due to GPS accuracy limitations. It tight areas this is not precise enough. I have concluded that (unlike DJI GO 4 / DGI GS Pro) all P4Dv2 Capture based missions must be landed manually. This is a small point, but important to know. It might be possible to launch the drone with DJI Go 4, and then start P4D Capture in flight, but I have not tested this.
The second issue (and this really frustrates me) is that P4D Capture now seems to OVERRIDE ALL CAMERA settings. I believe that in prior versions it would honor them. It not only turns RAW+JPG to JPG only as before, it also now changes everything else. For my 175’ nadir row test flights it set the camera to fixed ISO 100, Aperture Priority of f/5.0, and autoexposure via changing the shutter speed. Shutter speed will vary by image (my flight saw shutter speeds of 1/320 to 1/500). I tried various methods to control the camera settings by starting P4D and allowing it to set camera then going into DJI GO 4 to reset the camera, and then returning to P4D. P4D detects the temporary loss of drone communications and resets the camera again! This forced override of camera settings is new to me, renders my previously described workflow non functional, and is in conflict with the best practices as recommended by a top P4D trainer that I have spoken with. There is another thread where many are asking P4D to allow RAW+JPEG. Now we have lost even more control over the camera settings. AARGH!
On a good note - I discovered though an unplanned test that P4D flights do make use of the obstacle avoidance features of the P4Dv2. There was a very tall Redwood just off the side of my map area. Defining the map permitter on the iPad is not as precise as I would like, and I ended up with the tree just inside my flight path. The drone flew up to about 10’ from the tree tip and stopped. This is a good feature, and again useful to know. I would like to be able to define a P4D Capture perimeter by manually flying and marking polygon corner points. In this way I could assure precise perimeters in difficult areas with obstacles to avoid.
And one last note to Richard Rogers… I did a test with the “SAFE MODE” versus “FAST MODE” options. These can be found under the settings > Advanced Settings in the iOS version (it is there still). I tried both extremes - a SAFE MODE flight where the drone stops at each photo (~8 minutes) and a FAST MODE flight (~4 min) with the flight speed set to FAST (worst case for motion blur). Note that the reported GSD at 175’ is 0.57", while the motion blur at 12 ft/sec and 1/320 shutter speed is 12 / 320 = 0.0375’ or 0.45". So motion blur is about the same as GSD. Looking at the original images I could not really discern any different between the two. The P4D Capture quality reports also reported basically the same results. Conclusion - at this altitude and full daylight it is fine to fly fast. If the light was dimmer or the altitude much lower, then I would prefer to control the camera in manual model to control the motion blur, but as noted above I cannot now.
Seems like the designer’s strategy is to try to keep things simple by taking away options for the pilot/mapper. This is a strategy tradeoff. One of the advantages of P4D over alternatives is the greater customizability. I have no problem with separating basic / simple mode from advanced use options, but it is frustrating when some clearly useful options and capabilities of the bird are simply taken away.
We have not had any comments here from any moderator for sometime. I think this thread may be about done. I will continue to post comments re camera control / raw shooting on the other related thread.
Thanks all pilots for all of your shared experience.
I am still keeping up with the thread, but I agree. It may be time to retire it.
I also tested the app again today. A much larger dataset meant for processing. I used your step by step for setting up the camera in DJI Go4. I was remarking how much better my photos were from previous flights. I’ll have to check the metadata to see if P4Dcapture took over my camera settings or not. I DID notice that all I got were JPEGS rather than Raw+jpeg as was set in DJIgo4. The clouds were beautiful, so I took a few shots in DJIgo4 before the autonomous mission. They were RAW+jpeg as I had the camera set. All photos from P4Dcapture were jpeg.
I too don’t trust the return flight. Partially because I had read another post of a person complaining that it repeatedly landed at the end point. I didn’t like it trajectory as it started for home so I did an override. I might be a little overly concerned though. I flew her home again today, for the second of two flights so far. I’ll try to do controled test of this feature soon.
My data are currently processing in webODM. If it looks alright, I plan to jump into Pix4d processing for a direct comparison.
The DD app still honors the DJIgo4 cam setup…last I checked.
Cheers
For anyone trying to use 3rd party apps with the Phantom 4 pro v2.0 + (with integrated screen), don’t waste your time with this video as I’m almost positive the loophole is now dead. I tried it as many ways as I could with as many USB cables I could find. Looks like I’ll be purchasing another remote, but DJI is currently out of stock 
Luckily, I picked up on this problem before my purchase and avoided it. However, my expensive Samsung tablet is not supported by DJI, so even Go4 barely works. I have to power down the tablet, power up the aircraft, controller, let them link, plug the tablet in to the remote, THEN power up the tablet. It seems to be a problem with the tablet recognizing the USB device.
Solved that problem by using my old Samsung S6 phone. Works flawlessly, but small.
I’m going to start a new post on my experiences with the P4P V2 and P4D.
@ James Maedling
I think a new post chain is an excellent idea. We now officially have PIX4D Capture support for the P4Pv2 which was what this post was about. At this point we will all be exploring mapping with the P4Pv2 and will have a lot to share with each other. I will follow your new post thread.
Also please see the post/thread titled:
Pix4DCapture Collecting Raw Imagery
https://community.pix4d.com/t/2945-Pix4DCapture-Collecting-Raw-Imagery
It started with the request/discussion about having the option to collect raw photos, and I recently expanded it to request allowing the pilot to optionally override PIX4D Capture and control _ all _ camera settings. This can apply to any drone, not just the P4Pv2.
Another topic I am interested is using PIX4D Capture on a CrystalSky monitor. I am interested in this display, but I understand that DJI has basically locked down the Android OS so that it will only run DJI Go 4. This is a DJI issue, but it impacts PIX4D users (as well as others such as Litchi users). If I could confidently use Litchi, PIX4D on a CrystalSky (even without official support)I would buy one.
@Mark Muntean
I do heave the cristalsky monitor it’s awesome compared to tablet and phones I tried
But you have to install app via APK installer works fine you just have to figure out how it works, it 's on youtube
Today I had an issue, I have been using PIX4D capture so CTRL+DJI in consequence, I wanted to make some photo/video with DJI GO4 not possible to connect to the drone, I tried everything (close ctrl+dji, force stop the app) finally I uninstalled ctrl+DJI and I was able to connect to the drone.
I do some more teste when possible, you should be aware of that before buying one, It 's a great screen and it has Two batteries to load I love it.
I have seen some videos of the “workaround” to get other apps on the CrystalSky tablet. I also think I have seen some posts that suggest that prior approaches may no longer work. The workaround also seemed pretty complex with various cables, etc.
My concern is that all will be working fine, and then some update from PIX4D or DJI will throw a wrench in the works, and I will find this on site at a job in front of a client.
I think DJI would be better to embrace third parties, and allow selected support of other Capture apps on CrystalSky. I am not even sure whether their DJI GS Pro is supported.
I would LOVE to have the large and bright monitor, and may still get this for video and photo work. Just would like to have this reliably work for mapping and Litchi programmed flight paths too.
I’ll find your other post Mark and follow. I will say, before we close this out, that I am overall happy with the app as it performed on my two test flights so far. I will say that when I switched to the camera view, then back to the map view, there was a severe lag in the position of the aircraft on my screen. I just let the aircraft finish It’s mission with a little concern over what the battery level on the aircraft actually was.
I attributed it to the device (old Samsung S6 Active) and not the software. Further testing required.
@ Josh…
Just rechecked. App Store on iOS has PIX4D Capture 3.4.0 which specifically states “support Phantom 4 pro V2”… Her
I just tried on an ipad, it does show the V2.
I did not see the option to define mission by kml, like on android. Is that because I did not find it on the ipad, or because its not available on apple devices? thx
Re: the last 2 Wednesday posts, from Joshua and Mark… what’s the outcome of this? The tone of Joshua’s 2nd paragraph seemed to be, “Based on interest, we’ll determine if Pix4D ever supports the v2.” But, app store says it’s supported.
@Michael Kemper,
Its supported now on both android and apple devices. They may not track what they have said to us, but its clear they did decide and implement the update. My flight tests of it have gone well, no bugs in flight control using both samsung S8 and apple ipad mini.