Size of Coded targets for UAV aerial surveys taken at 400m above ground level

[rainman]

I am hoping to start using coded targets from now on in all my sUAV aerial surveys, as it is far less time consuming. We typically use 9mp/12mp cameras for data acquisition of our imagery within the payload of the sUAV and fly at approximately 400m above ground level. I have read through some of the discussions here but I cannot find anything that suggests how to estimate coded target size. I am currently using version 1.2.6 PS. Is there a equation or something that I should be using to estimate the actual size the coded target needs to be for it to be successfully used in PS?

Regards
Ian

[Alexey Pasumansky]

Hello Ian,

For aerial surveys it's better to use non-coded cross targets, even though it may be required to rename them after the detection process is finished.
Coded-tarted should be of a considerable size even for 100 m flight altitude.

[rainman]

Alexey,

We are already use non-coded (cross targets) in aerial surveys which are over 1m in width, so we are looking at printing off your coded targets at or around 1m, maybe even bigger and seeing if they work in ps. I think using coded targets will reduce the overall time spent in PS?

Ian

[BobvdMeij]

Hello Ian,

For aerial surveys it's better to use non-coded cross targets, even though it may be required to rename them after the detection process is finished.
Coded-tarted should be of a considerable size even for 100 m flight altitude.

I am sorry to step right into here, but you happen to touch onto a question that I have been having in a long time.

After one has used 'Detect Markers' (non-coded) and removed some false findings, one needs to manually change the IDs of every detected marker prior to importing the CSV file with in-field measured marker coordinates?

Is there no way to keep the IDs of detected markers as they are, then import a CSV file with marker coordinates, and let the software override the IDs of detected markers with the IDs of the markers in the CSV file? I mean, the software should be able to link easily link the set of detected markers with in-field measured GCPs as their relative positions regarding eachother are known for both.

OR an even better alternative would be to import your CSV file with GCP marker coordinates and then use the 'Detect Markers' feature. Again, due to the software knowing the relatively position of GCPs from the CSV file, it should be able to quiet succesfully detect plausible markers and filter out those that are incorrect.

[Yoann Courtois]

Hi Ian and others !

It looks coded-target size gives interrogations to many of us !
As I didn't get any answer around the forum, I've handled measurements and tests and detailled the results in another post (see below).

For your 400m height flight, your targets will be huuuge   and will directly depend on your GSD.
As an simple example, with our DJI Phantom 4 Pro flighing 35m above ground, the target should have a size of 35cm (biggest diameter) so that the center circle is 10cm diameter (10 x GSD which is a little bit less than 1cm for this UAV at 35m)

So, to plan a flight at 400m, we should need 4m-diameter targets

Hope to help you !

P.S.
I don't have handled any test with non-coded target for the moment. So I would like to ask what is your GSD when you flight at 400m above ground and how well it works with 1m cross targets !

Hi everyone !

After managing some tests with different cameras (UAV DJI Phantom 4, ActionCam GoPro Hero 4, ...),
I was able to define the minimal size a coded target should have in order to be detected !

Tests parameters :
I have handled my tests with 12 bits target, because they present, according to the user manual, the most ability to be detected.

Result :
In order to be detected, the center point of a PhotoScan 12 bits target have to cover a minimum of 9-10 pixels on the image

Application :
For instance, for a photogrammetric survey with a defined GSD of 1cm, the center point of the target should be around 10cm minimum (10 x GSD). As the global diameter of the target is 3.5 times the diameter of the center point, the whole target should have a minimum size of 35cm. (35 x GSD).

To be printed :
As the center point diameter should be egal or greater than 10 x GSD, the Center point radius should be set at 5 x GSD or more.

For non-normal view :
I didn't handled precise measurements but I can say the angle of view is not the main limitation in automatic detection. For UAV survey with nadiral images for example, the limit of detection will be the effective GSD on the target when the camera will fly away from the target position, and not the angle a view.

Hope it can help 

[Yoann Courtois]

To answer to BobvdMeij:

Your proposal looks good. However, and because buddle block adjustement includes so many parameters, you may firstly need enough accurate georeferenced photos and well-known camera parameters.

Indeed, adjusting a non-scale and non-georeferenced model on GCPs on a big step itself ! It would be for the moment to hard, to my mind, to add an automatic evaluation of which coordinates correspond to which non-coded GCPs.

But, if you already get quite well georeferenced model by using geotags, it may finally be just an adjustement between theoretical coordinates (given in your CSV file) and non-coded detected markers. But, in order not to get completly wrong adjustement, a main condition of this process would be that geotags accuracy would be very smaller than distance between your targets on field, to prevent wrong association between coordinates and target.

For the rest, we would need a piece of help for Alexey, who may gives us some starter advices if something looks possible (python scripting may be mandatory at this point !)

Regards

[BobvdMeij]

To answer to BobvdMeij:

Your proposal looks good. However, and because buddle block adjustement includes so many parameters, you may firstly need enough accurate georeferenced photos and well-known camera parameters.

Indeed, adjusting a non-scale and non-georeferenced model on GCPs on a big step itself ! It would be for the moment to hard, to my mind, to add an automatic evaluation of which coordinates correspond to which non-coded GCPs.

But, if you already get quite well georeferenced model by using geotags, it may finally be just an adjustement between theoretical coordinates (given in your CSV file) and non-coded detected markers. But, in order not to get completly wrong adjustement, a main condition of this process would be that geotags accuracy would be very smaller than distance between your targets on field, to prevent wrong association between coordinates and target.

For the rest, we would need a piece of help for Alexey, who may gives us some starter advices if something looks possible (python scripting may be mandatory at this point !)

Regards

That makes sense, but I reckon it should still work.

I have a dataset flown at 50m AGL and a GSD of approximately 1.3cm. We use non-coded cross targets measuring 35x35cm. The on board GPS we utilize is decent when it comes to XY accuracy (5M), but the Z component is useless. Hence we do use the GPS EXIF data for our first alignment, but then use GCPs (and turn off all photo's) to optimize camera positions.

I conducted a test run yesterday using the same data and aligning the photographs using High settings. Alignment worked out surprisingly well. Then I used 'Detect Markers' with a tolerance value of 50. Agisoft detected 40 markers, although we only placed 30 targets in the field. Out of these 40 markers, 8 were located (far) outside the studied region where not a single photograph was taken (strange..), and 2 were located within the study area although not anywhere near an actual GCP marker. I reckon I could get rid of these by changing the tolerance value, but I haven't tried this yet. The remainder of the 30 detected markers, however, was SPOT ON. I must say I was sincerely impressed.

Unfortunately, however, Agisoft names the detected markers in the order of 1, 2, 3, etc. whereas we named our targets 1001, 1002, 1003 etc. in the field using our RTK-GPS equipment. If I now import the CSV file with marker coordinates, Agisoft only compares the IDs of imported markers with those that are already created in the software. Due to naming conventions being different, Agisoft simply loads my CSV coordinates but does not relate them to the ones it previously detected.

I could, off course, remove the 10 incorrect markers and then visually locate the remainder (and correctly identified) 30 markers, after which I change their ID to the ones we provided them with in the field. If I then import my CSV file again Agisoft should identify a match and overwrite the (empty) coordinate fields of the detected markers with the coordinates in my CSV file.

Even though this would still save me some time, it should be possible to quiet accurately predict (and then relate!) which of the predicted markers relate to which GCP in my CSV file. I mean, the relative position of the 30 detected markers in my sparse point cloud is known (in a local coordinate system) quiet well, and so are the relative positions between the 30 in-situ measured markers in my CSV file.