I have just closed a survey using Matrice 210/X4S/DJI GS Pro.
After first step and after adding GCP I still have an average 50m between the computed altitude and the real GCP altitude.
I noticed
The table shows the differences between gcp and pix4 computer position:
Pix4d is upgraded to latest version. It could be a problem into the Matrice 210 however I don’t understand why GCP does not adjust the altitude.
I noticed that exif data of photos show an altitude different from what is reported by Pix4Dcapture after importing them and the difference is about the same error between GCP and computed data.
I believe that the GCPs have not been taken into account. Please share some screenshots from the quality report of your project, so that we can better understand the problem
The number of keypoints and matches are very low. I see the Rapid setting and quite frankly a lot of errors can be expected, run normal settings in Pix4D.
You mention DJI GS Pro and Pix4Dcapture, which flight app did you use to collect the pictures? DJI is notorious for making altitude data fubar between flights so the flight app might not matter but will help diagnose the issue.
The project identified 2 cameras and that is likely from the two different flights, were these done on different days or different exposure lighting conditions?
When adding manual tie points, MTP or GCP, selecting only 3 pictures is going to leave Pix4D in a weak position. Try to select tie points in 6-10 pictures each.
You could manually change the altitude EXIF data to make them all the same…easy to do in 3rd party software.
You may have to process as 2 sub-projects and combine so each set of pictures “snap” to the GCPs…if the options above don’t fix it.
A side note, I would seriously consider upgrading your hardware away from Xeon and Quadro. Pix4D runs differently on different hardware and that might not be much of an issue but that setup is very slow compared to Core i9 and GeForce setups.
thank you for your suggestion. The error is present with any kind of settings so I moved to rapid settings in order to accelerate the process of testing new solution.
I used GS Pro.
I did two flight in order to have about the same GSD for the entire project because there are about 100m from one side to the other
See first comment. I used the minimun number of GCP in order to speed up the process. Behavior is the same with 3 or 15 pictures used
I can but I add some error and I would like to avoid and it doesn’t have any sense to consider GCP if the application does not use in fact!
No the problem persist even if I use a small set of pictures
Sorry I have several application and other will have bigger benefit using Quadro and Xeon. I consider acceptable the performance of my current workstation
I have tons of issues with DJI GS Pro…almost a great application but a real mess…
And I can’t imagine any possible scenario of Xeon and Quadro being better than Core i9 and GeForce but to each his own…
#6 is about using all the pictures but making sub-projects then merging. This is a standard procedure when lighting conditions or camera angles vary too much for Pix4D to automatically merge blocks.
I think I understand the project better…knowing that you intentionally flew different altitudes. My next guess is that you have such a low side overlap that maybe Pix4D is trying to flatten each “camera block”. I just ran a project last night with 3 GCP to tie vastly different camera angles together and it worked just fine, so I think the GCP function in Pix4D is okay in V4.0.25
Certainly a strange issue you are seeing…likely will need to send pictures and files to Pix4D so they can re-produce. I have done the same in the past to reveal hidden bugs that only pop up with specific picture sets.
Hi julie
The problem is with the last version of the software:
i reprocess an old project done with same hardware and I got the same behavior
I install a previous release and I got a perfect result
import of data is correct
From my experience the reason could be:
A) a problem in the latest release not documented
B) a problem in my workstation
C) an issue with dji x4s and sw
I will install the last version on a different wks to check point C and maybe I could do a survey with different drone for point C or you should investigate on point A
At the present time I am able to work using the old version available on your website
Looking at the Coordinate System settings in the Quality Report you provided it seems as if the error might be in there. Actually it would not be a problem of Pix4D, but of the chosen settings. The geotagging of the photos of the drones is very likely referenced to the WGS ellipsoid horizontal position and vertical height. Your GCP’s are in orthometric heights referenced to a geoid. I am not completely familar with your chosen coordinate system but at least it mentions EGM96 (a geoid).
P.S.: Having read other threads now it is stated that DJI uses EGM96 as height reference. This would prove my statement above wrong, however I have slight doubts about DJI using EGM96 heights from my experience which might also depend on your model, firmware and hardware version of your drone.
It is only stating senseFly drones and “default”. For “default” WGS84 shall be chosen and not WGS84(egm96). Again I am in doubt about the heights recorded by DJI respectively to specific DJI versions.
Please also consider the height reference of your GCPs. Are they referring to EGM96 or EGM2008? Both are globally used models which differ from models that have to be valid for countries or regions only. For example in Germany the “German Combined Quasigeoid” GCG2016 or GCG2011 is commonly used.
If not, please accept some observations from my side
I am not sure how the 50m error is calculated. In the shared Quality Report the errors look good:
Adam’s comment about running step 1 in Full mode is correct. This is the recommended mode for high accuracy results.
Boris’s analysis is also correct in the sense that wrong definition of a vertical coordinate system can lead to errors. DJI drones, normally, give altitudes above egm96.
Maybe your GCPs are in a local geoid (not egm96).
Looking forward to hearing from you. I am very interested in this case!
A workaround is found? Yes, remove last version and install previous version 4.0.25
Main issue: quality report looks good but the real error is different.
Please take a look at GCP position and position computed by Pix4D:
Hope I explain clearly the issue. The same error happens also with other projects converted to this version. If I took same data (photos, GCP, ecc.) to previous version I got excellent results.
As I said before it could be a combination of different factor (camera, drone, ecc.). I process at least two surveys per week with very good results (with version 4.0.25) so I’m confident about the steps done.
About other comments:
step 1 in Full mode. I said that I did more tests and to speed up I choose a faster method: nevertheless, with a faster process I agree to have lower accuracy not 50m error Other Adam’s comments are not relevant for this issue.
Boris’s analysis is very interesting and it give some good inputs for the future. However, if the survey has a problems I should get the same errors with both software version.
I can upload somewhere projects processed with both software version if you like or if you interested you can even connect to my workstation
I created a Support ticket for your case, so that we can better investigate. I will contact you internally. When the problem is solved (soon I hope ), I will also post here to inform the Community.
We came across this thread while researching the same issue. We can confirm that the same thing is happening in our case. GCPs are not being taken into account even after multiple reoptimizations and numerous runs of steps 1, 2 and 3. It seems that the model simply does not include any corrections from the GCPs entered. This is even displayed in the ray cloud as the projected points remain in their original positions and elevation following GCP addition, reoptimization and step 2 densification.
We are using a Sony Camera and survey grade GPS so it is not an issue with a specific drone. Additionally, our GIS specialist set our datums which have been confirmed as correct for our EXIF location datum and GCP location datum.
The interesting part, though, is that we are seeing this with 4.0.25. You said that you downgraded to 4.0.25 and the issue went away. However, being that your original post was in November, and that 4.0.25 was the current version at the time (the new version came out just yesterday, December 14, 2017) I am wondering if you misspoke and that you were using 4.0.25 and downgraded to the previous version from that. Or, were you testing the next version and downgraded from that?
We have contacted support but have not received a response as of yet.
Good day. Any results from this error? I have similar error. Been flying with Ebee plus and get 170mm vertical error when processing with ppk and gcp both. My report has RMS error of 0.005m. So report is perfect, but still have that 170mm to high when working with pointcloud. Thanks in advance
@Massimiliano, I agree with Christina and Boris’s comments that the most likely cause for the approximately 50 meter shift is that the project’s Ground Control Point Vertical Coordinate System and Output Vertical Coordinate System are incorrect.
The reported elevation for GCP13 is 380.32 meters but the Initial Position is approximately 50 meters lower, at 329.796 meters. This tells us that a 50.524 meter (380.32-329.796) geoid offset has been applied to your project’s ground control points. An annotated copy of the latest image you shared is copied below for your reference.
So that your ground control points are at the correct elevation, please set the Ground Control Point Vertical Coordinate System and Output Vertical Coordinate System to Geoid Height Above Bessel 1841 Ellipsoid [m]: 0.000. The project should be Reoptimized to achieve the most accurate results. Process Step 2 and Step 3 and you should be back in business.
Please let us know if updating the GCP Vertical Coordinate System and Output Vertical Coordinate System does not address the vertical offset.
@Jeffrey, the offset between reported and computed position may be due to a combination of the same factor that Massimiliano is contending with as well as a failure of the bundle block adjustment for select ground control points. Massimiliano’s project reports a very small Error to Initial GCP Position, compared to what would be expected if a GCP was not being taken into account as part of the bundle block adjustment.
@Hanno, I anticipate that an offset of 170 mm is likely not explained by the same factors that are causing the 50+ meter offset that Massimiliano is experiencing. An 170 mm offset is more likely due to the inherent accuracy of the densified point cloud and is probably not related to an erroneous geoid offset. To ensure that we stay on topic please either create your own post on our Community or contact support directly.
These cookies are necessary for the website to function and cannot be switched off in our systems.
They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences,
logging in, or filling in forms. These cookies do not store any personally identifiable information.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site.
They help us to know which pages are the most and least popular and see how visitors move around the site.
All information these cookies collect is aggregated and therefore anonymous.
If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
These cookies may be set through our site by our advertising partner (Google).
They may be used by Google to build a profile of your interests and show you relevant adverts on other sites.
They do not directly store personal information but are based on uniquely identifying your browser and internet device.
If you do not allow these cookies, you will experience less targeted advertising.
