Scene - target based registration - influence of inklinometer

Discuss all Faro related issues here.
jakubjon
I have made <0 posts
I have made <0 posts
Posts: 3
Joined: Thu Sep 14, 2017 5:35 pm
Full Name: Jakub Jon
Company Details: G4D
Company Position Title: surveyor
Country: Czech Republic

Scene - target based registration - influence of inklinometer

Post by jakubjon » Fri Sep 15, 2017 11:29 am

I have locked cluster of 30 scans and external references (5 points equally spread around object measured with GPS). What is the difference between only target base registration (no sensor used) and target based registration with inclinometer turned on. When I use GPS points only, I got residuals up to 2 cm which I considered as OK. In case of inklinometer was turned on I got much worse residuals up to 7 cm.
How does the adjustment handle inclinometer data of all scans in this case? Is attitude of the locked cluster some kind of average attitude of all scans?

This is just theoretical question. In this case it doesn't matter. I am just wondering how does it work.

Thanks Jakub

User avatar
3DForensics
Global Moderator
Global Moderator
Posts: 1657
Joined: Mon Aug 03, 2009 1:52 am
Full Name: Eugene Liscio
Company Details: AI2-3D Forensics
Company Position Title: Owner
Skype Name: eliscio
Location: Toronto, Canada

Re: Scene - target based registration - influence of inklinometer

Post by 3DForensics » Fri Sep 15, 2017 3:45 pm

I believe that if you are telling Scene to not use the inclinometer data and to align the scans based on the GPS data, you should expect that Scene will try to balance the errors between the GPS data. However, if you choose to use the inclinometer, then this has much greater weight as the "true" vertical is known (certainly much better than GPS data, especially in elevation), so you get greater errors.

Having said that, it would be good to get some input from the more experienced Scene users in this area.

Cheers,

Eugene

User avatar
jcoco3
Global Moderator
Global Moderator
Posts: 1325
Joined: Sun Mar 04, 2012 5:43 pm
Full Name: Jonathan Coco
Company Details: Forte and Tablada
Company Position Title: AMM Division Leader
Country: USA
Linkedin Profile: Yes

Re: Scene - target based registration - influence of inklinometer

Post by jcoco3 » Sat Sep 16, 2017 5:16 pm

We spent more time than I want to admit figuring this out, and even after confirming these results multiple times with some willing individuals at Faro I still don't feel 100% confident that it is exactly as I describe.

Rule #1. Only external references can tilt a scan or scans(aside from doing this manually in correspondence view or via transformation dialog) from its original recorded inclination. So this means the inclinometer will always be preferred even if spheres or checkerboards that do not have external references would otherwise naturally influence the tilt of scan or scans. Scene will ignore that influence for the physical movement of the scans during registration, but may acknowledge and report the tensions in the registration report. Cloud to cloud should not tilt scans either.

So in your case the external references should be tilting the entire locked cluster to fit your control whether the inclinometer is on or off during registration. I would imagine that the cluster doesn't actually move between the two different approaches, but the reporting is different as you are adding the inclinometer data into the mix for more comparison.

Note: If you had the inclinometer off prior to the cluster's internal registration then totally different results after registering to your gps control should be expected.

Scott
V.I.P Member
V.I.P Member
Posts: 497
Joined: Tue Mar 29, 2011 7:39 pm
Full Name: Scott Page
Company Details: Scott Page Design- Architectural service
Company Position Title: Freelance
Country: USA
Linkedin Profile: No

Re: Scene - target based registration - influence of inklinometer

Post by Scott » Sat Sep 16, 2017 6:46 pm

re: Jonathan's post: +1

bananmac
I have made 20-30 posts
I have made 20-30 posts
Posts: 24
Joined: Thu Nov 13, 2014 10:58 am
Full Name: Maciej Banaszkiewicz
Company Details: Schenkel Vermessungen AG
Company Position Title: LS Technician
Country: Switzerland
Linkedin Profile: Yes

Re: Scene - target based registration - influence of inklinometer

Post by bananmac » Thu Sep 21, 2017 8:56 am

Jonathan is right.

I experience problems with inclinometer reading everytime when the scanned object is bigger than ~40meters. In my opinion the quality of the tilt sensor is just not what you expect it to be.

The most visible symptom of this problem is an "egg effect". If you look at the sphere in correspondence view from the side (front or left) you should see that the spheres are not perfectly round but one or more of them are slightly higher/lower than the other. It is because the inclinometer data is 1000 times important for registration than regular targets, even if is bad. Only external references have the same priority.

In addition to this, while registering the scans, all of the tilt readings influence each other. You can see this in scanmanager, that the inclinometer data is treated as a "correspondence" to any other from other scans. It means that even if you made a scan far away from the object and its inclination data is bad, it will cause distortions on the registration of the scan at the other side of your scansite. This is just my observation after hundreds of hours spent on hunting the registration errors in SCENE....

Usually the solution is to turn off the use of inclinometer data for particular scan (right click on scan > properties > sensors tab) and update the registration.

MALTBY
I have made 70-80 posts
I have made 70-80 posts
Posts: 72
Joined: Fri Nov 13, 2009 10:12 am
Full Name: Simon Judd
Company Details: MALTBY LAND SURVEYS
Company Position Title: Operations Manager

Re: Scene - target based registration - influence of inklinometer

Post by MALTBY » Thu Sep 21, 2017 11:27 am

Hello All

One thing that you might want to look at is forcing scene to ignore the Survey references for the initial registration process and rely on your inclinometer and artificial references (spheres and Checkerboards). This should give you a registration based solely on your scan locations and spheres etc. and how they relate to themselves (Local Registration) which you can then assess independently and how it fits as a whole to the survey control.

when registering, Scene will go hunting for references if you do not force it to ignore them. The reference points( Survey control) are deemed to be a high order correspondence and therefore scene will place a scan containing references to the survey control onto those coordinates with small tension values and this is when you likely to see elongated spheres in your registration.

The way to tell scene to ignore survey control is to place a reference folder in with the scans that is blank (contains no information), this will stop scene looking any further for a survey reference folder and only use the spheres and checkerboards etc contained within to perform its registration taking the reference scan as a start point. (important that this scan is level if using inclinometer)

Following the local registration (registration without survey control) you can lock the scan manager then place the scans cluster containing the blank reference folder into a new top cluster. If you then place your survey control reference folder into this new top cluster alongside the scans cluster and perform a registration you will now have a correspondence between the locally registered scans and the survey control without affecting the local registration so checking one against the other.

If you consider the scenario where your survey control contains errors then not having a blank reference will cause larger elongation ellipses to your spheres as Scene is treating the survey control as high order and correct and will place your scans onto that control, stretching the tensions to the lower order objects such as spheres. This of course bleeds in to some degree with GPS poinst based upon RTK observations and the accuracy of real time data.

This of course is not the only reason problems with the inclinometer can arise others such as moving scanner before the inclinometer evaluation has finished will cause problems and need a different treatment.

I hope that makes sense and helps in some way in solving some of the problems with registration

Simon

bananmac
I have made 20-30 posts
I have made 20-30 posts
Posts: 24
Joined: Thu Nov 13, 2014 10:58 am
Full Name: Maciej Banaszkiewicz
Company Details: Schenkel Vermessungen AG
Company Position Title: LS Technician
Country: Switzerland
Linkedin Profile: Yes

Re: Scene - target based registration - influence of inklinometer

Post by bananmac » Tue Sep 26, 2017 8:46 am

MALTBY wrote:
Thu Sep 21, 2017 11:27 am
(...)
The way to tell scene to ignore survey control is to place a reference folder in with the scans that is blank (contains no information), this will stop scene looking any further for a survey reference folder and only use the spheres and checkerboards etc contained within to perform its registration taking the reference scan as a start point. (important that this scan is level if using inclinometer)
(...)
If you want to switch off the "visibility" of the references folder temporarily, you can also rename it: "References" to "References1" or whathever you want. After local registration you can just go back to original name "Reference" and then the control points will be visible for the software.

MALTBY
I have made 70-80 posts
I have made 70-80 posts
Posts: 72
Joined: Fri Nov 13, 2009 10:12 am
Full Name: Simon Judd
Company Details: MALTBY LAND SURVEYS
Company Position Title: Operations Manager

Re: Scene - target based registration - influence of inklinometer

Post by MALTBY » Tue Sep 26, 2017 11:57 am

This of course is also correct but if you have multiple reference files residing in multiple clusters then the Blank reference approach will ensure that you do not miss a renaming exercise.

We sometimes have in excess of 20 Reference folders all containing different control for different areas and so for us a blank reference folder ensures that we do not accidentally pick up incorrect folders and therefore incorrect transformations

Simon

jakubjon
I have made <0 posts
I have made <0 posts
Posts: 3
Joined: Thu Sep 14, 2017 5:35 pm
Full Name: Jakub Jon
Company Details: G4D
Company Position Title: surveyor
Country: Czech Republic

Re: Scene - target based registration - influence of inklinometer

Post by jakubjon » Thu Oct 12, 2017 9:32 pm

Ok I see that all of us are spinning around the same issue. Thank you all for responses, but my initial question remains unanswered. Probably I didn't express myself properly.

Lets consider theoretical situation.

I am using the same procedure as MALTBY. I have locked cluster which was adjusted independently on external references using blank reference folder, but this is actually not important.. And I have only two external reference which is not enough to place the cluster. So I will turn on usage of inclinometr in place scans menu. Question is how does SCENE treats multiple inclinometr readings? Does it pick first one? That one which has lowest error? Or does it take some kind of average? Average or better median would be very useful in this case because it would eliminate random errors.

My recent experiences with SCENE forced me to not trust to this sensor, but sometimes there are cases when it would be useful to have back up in this sensor anyway.

And back to the answer of Jonathan.

1)
jcoco3 wrote:
Sat Sep 16, 2017 5:16 pm
Rule #1. Only external references can tilt a scan or scans(aside from doing this manually in correspondence view or via transformation dialog) from its original recorded inclination. So this means the inclinometer will always be preferred even if spheres or checkerboards that do not have external references would otherwise naturally influence the tilt of scan or scans. Scene will ignore that influence for the physical movement of the scans during registration, but may acknowledge and report the tensions in the registration report. Cloud to cloud should not tilt scans either.
I am not sure if I understand right but are you saying that relative correspondences are not able to tilt scan from its measured attitude (by its inclination sensor) during the scan registration no matter whether inclinometr is on or off? In this case why we have such option to turn it off or on? And wouldn't it be illogical if relative correspondences wouldn't have power to slightly tilt the scan to achieve better alignment of the correspondences?

2)
jcoco3 wrote:
Sat Sep 16, 2017 5:16 pm
So in your case the external references should be tilting the entire locked cluster to fit your control whether the inclinometer is on or off during registration. I would imagine that the cluster doesn't actually move between the two different approaches, but the reporting is different as you are adding the inclinometer data into the mix for more comparison.
I did a small test and I compared global coordinates of one point and there is significant difference in height between both approaches. So I don't understand what you mean.. Please see attached files to see related scan managers.

TEST Point
no inclinometr
342.953 812.979 296.384

inclinometr
342.951 812.983 296.516
You do not have the required permissions to view the files attached to this post.

jakubjon
I have made <0 posts
I have made <0 posts
Posts: 3
Joined: Thu Sep 14, 2017 5:35 pm
Full Name: Jakub Jon
Company Details: G4D
Company Position Title: surveyor
Country: Czech Republic

Re: Scene - target based registration - influence of inklinometer

Post by jakubjon » Thu Oct 12, 2017 9:45 pm

Do you have any suggestions what to do to gain better control over adjustment? Scene seems to be quite black box..
I am experienced user of Rigel RiSCAN and its MSA so I mean something like that. I tested Pointcab plugin, but this does not look very promising, due to limited possibility to set any parameters.
And I read description of Scantaxi plugin, but impossibility of automatic target usage scared me at the very beginning...

Return to “Faro”