Conflicting sphere target distances Faro Scene 2022.1

Discuss FARO SCENE software here.
Post Reply
Scott
V.I.P Member
V.I.P Member
Posts: 1037
Joined: Tue Mar 29, 2011 7:39 pm
13
Full Name: Scott Page
Company Details: Scott Page Design- Architectural service
Company Position Title: Owner
Country: USA
Linkedin Profile: No
Location: Berkeley, CA USA
Has thanked: 206 times
Been thanked: 78 times
Contact:

Re: Conflicting sphere target distances Faro Scene 2022.1

Post by Scott »

lsf wrote: Wed Dec 07, 2022 6:25 pm @Scott

Did you place the targets using totalstation and were you expecting all the distances to match exactly? Or what does the "Test 1.jpg" tell us?
Good question. No, we didn't have a 'Total Station' handy at the time--general range, rather than precise distance accuracy was what this test was concerned with.
Last edited by Scott on Wed Dec 07, 2022 9:09 pm, edited 1 time in total.
User avatar
tadol
V.I.P Member
V.I.P Member
Posts: 126
Joined: Wed Dec 14, 2011 12:32 am
12
Full Name: Tad Laird
Company Details: Koppa Target Spheres
Company Position Title: Owner
Country: USA
Linkedin Profile: No
Location: Oakland, California, USA
Has thanked: 2 times
Been thanked: 4 times
Contact:

Re: Conflicting sphere target distances Faro Scene 2022.1

Post by tadol »

Well - it was kind of a test, and kind of an art project, and kind of just having fun while my friends warehouse was empty for a couple of days before it transferred to a new owner - and this was 8 years ago, using a 120. The targets were laid out in a rather Egyptian way, with a weight and a string with a knot in it to lay out the main circle, then divide that into 6ths, then laying out the semi-circles off that with another string to get somewhat equal spacing along those. Like I said, more fun and art project - something you do when you have very large numbers of target spheres easily available - ;-)

All the measurements Scene makes are based on calculated sphere centers - that calculation is going to be based on the number of points that Scene can get on a target, and how accurate those measurements and calculations are. I don't have the equipment to perform the kind of experiments I'd like, but I have long believed that the lighting conditions can affect the accuracy of target center determination, along with distance. If a target is in bright sunlight from one location, full shade from another, and half and half from a third, small errors in the measurement and calculation would be possible (IMHO) - just how that works or manifests itself in real world situations, I am currently unable to test -

But - that may change shortly, as the first of my retail prism base kits should be ready to ship in the next week or two. These are designed to mount a mini-prism at the same center point as one of my targets (150, 200, or 250mm) so that target locations can be recorded with a TotalStation, or targets can be accurately placed and measured over existing references. While I'm imagining that easily and inexpensively crossing the areas of scanning and surveying would be useful for a variety of applications, testing registration accuracy would be an interesting off-shoot. I may see if one of my customers would be willing to do a little testing with some newer equipment and newer versions of Scene to see what they are able to determine -

Tad

(And its hard to believe that I've been making these targets for 10 years now!)
http://www.KoppaTargets.com
Inexpensive Laser Scanning Targets & Accessories
for Architecture, Engineering, & Forensics
"We're right on targets!"
Augusto 3D
V.I.P Member
V.I.P Member
Posts: 436
Joined: Sat Dec 06, 2014 5:26 am
9
Full Name: C-Augusto
Company Details: 3d scanning
Company Position Title: USA
Country: US
Has thanked: 115 times
Been thanked: 30 times

Re: Conflicting sphere target distances Faro Scene 2022.1

Post by Augusto 3D »

Same issue I am having with the spheres...
C2C in the other hand works great (with and without the use of a RTS).

I anyone wants to buy our set send me a DM.
lsf
I have made 50-60 posts
I have made 50-60 posts
Posts: 52
Joined: Fri Mar 18, 2022 8:23 pm
2
Full Name: Las
Company Details: Sfee
Company Position Title: General
Country: USA
Has thanked: 6 times
Been thanked: 2 times

Re: Conflicting sphere target distances Faro Scene 2022.1

Post by lsf »

The image below shows the progress of my investigation. In summary, I am comparing spherical target to target distance values between multiple scans and Faro Scene gives worse results compared to PointCab (thank you VXGrid for pulling the 6 raw scans in PointCab and sharing the coordinates of all the targets from all of the scans). PointCab has 5 values that are larger than 1mm and Faro Scene has 10 values larger than 1mm. The largest variance of PointCab is 2.2mm and for Faro Scene it is 3.3mm.

The green values represent better/smaller distance variation, and as you can see, PointCab has more green values. I really thought that I would be able to have submillimeter precision at this stage (the stage where we are not registering the scans yet), but I am still left with a couple of bold values (>1mm) in PointCab scenario.

Also, it seems that in PointCab case the distance comparison between scan 2 and scan 3 (the comparison between left and right side scans) is not significantly better compared to 1 vs 2 or 1 vs 3 (center scan vs left/right side scans). In Faro Scene case the distance value comparison between center scan vs side scans was distinctively worse and distance comparison between left vs right scan was much better.

It would be awesome if someone could run the 8" sphere automatic matching command in AutodeskRecap or TrimbleRealworks or maybe other software that is able to do that, and share the coordinates of all the spheres from all the scans. So far PointCab has significantly better sphere detection algorithm unless I am missing something. I am very curious of your thoughts.

This means, that the next step - the registration - should be more precise with PointCab because the registration is nothing but positioning and rotating the separate scans until the known/shared 3D points between different scans match as close as possible. Of course, it would have to be tested.
You do not have the required permissions to view the files attached to this post.
VXGrid
V.I.P Member
V.I.P Member
Posts: 544
Joined: Fri Feb 24, 2017 10:47 am
7
Full Name: Martin Graner
Company Details: PointCab GmbH
Company Position Title: Research and Development
Country: Germany
Linkedin Profile: No
Has thanked: 160 times
Been thanked: 175 times
Contact:

Re: Conflicting sphere target distances Faro Scene 2022.1

Post by VXGrid »

lsf wrote: Thu Dec 08, 2022 4:53 am The image below shows the progress of my investigation. In summary, I am comparing spherical target to target distance values between multiple scans and Faro Scene gives worse results compared to PointCab (thank you VXGrid for pulling the 6 raw scans in PointCab and sharing the coordinates of all the targets from all of the scans). PointCab has 5 values that are larger than 1mm and Faro Scene has 10 values larger than 1mm. The largest variance of PointCab is 2.2mm and for Faro Scene it is 3.3mm.

The green values represent better/smaller distance variation, and as you can see, PointCab has more green values. I really thought that I would be able to have submillimeter precision at this stage (the stage where we are not registering the scans yet), but I am still left with a couple of bold values (>1mm) in PointCab scenario.

Also, it seems that in PointCab case the distance comparison between scan 2 and scan 3 (the comparison between left and right side scans) is not significantly better compared to 1 vs 2 or 1 vs 3 (center scan vs left/right side scans). In Faro Scene case the distance value comparison between center scan vs side scans was distinctively worse and distance comparison between left vs right scan was much better.

It would be awesome if someone could run the 8" sphere automatic matching command in AutodeskRecap or TrimbleRealworks or maybe other software that is able to do that, and share the coordinates of all the spheres from all the scans. So far PointCab has significantly better sphere detection algorithm unless I am missing something. I am very curious of your thoughts.

This means, that the next step - the registration - should be more precise with PointCab because the registration is nothing but positioning and rotating the separate scans until the known/shared 3D points between different scans match as close as possible. Of course, it would have to be tested.
Nice sheet.
So let's say the scanner has an error of 1 mm single point accuracy give or take.
If we now measure two spheres in one scan and two spheres in another scan, then the distance can be 2 mm off.

But your comment about which sphere in which scan is bad intrigued me so I had another look.
I don't know how sturdy these steel entrance gratings in the US are, in Germany they are really wobbly, so if I step on it once, in between measurements, the sphere will definetly move.
entrancegrate.png
You do not have the required permissions to view the files attached to this post.
lsf
I have made 50-60 posts
I have made 50-60 posts
Posts: 52
Joined: Fri Mar 18, 2022 8:23 pm
2
Full Name: Las
Company Details: Sfee
Company Position Title: General
Country: USA
Has thanked: 6 times
Been thanked: 2 times

Re: Conflicting sphere target distances Faro Scene 2022.1

Post by lsf »

@VXGrid
I heard the disturbing news about the arrests in Germany, I hope that will be the end of it and everyone is safe.
So let's say the scanner has an error of 1 mm single point accuracy give or take.
If we now measure two spheres in one scan and two spheres in another scan, then the distance can be 2 mm off.
Is it reasonable to assume the worst (1mm) error on such a short distance? Is there a formula to fine tune this possible error for a shorted distance? Isn't this error the max error @70 meters I wonder. I think this error should correlate with the distance. Plus that angle error.
But your comment about which sphere in which scan is bad intrigued me so I had another look.
I don't know how sturdy these steel entrance gratings in the US are, in Germany they are really wobbly, so if I step on it once, in between measurements, the sphere will definetly move.
Very good point! However, see distance 2-3 from the table, the variance is 1.7mm and both targets are on the concrete.

I see you used 200mm setting for the spheres, but when I bought them, the specs say 8"=203.2mm. This brings me to the following: If I were to write C++ classes and functions for Scene, then I would implement a logic where there would be some variance allowed between the sphere radius detected from the point cloud and the sphere radius indicated in the settings. The algorithm would find calculate the center point of the point cloud sphere and then insert the sphere defined in the settings. This means that even though if sphere sizes differ by say 5mm, the center coordinates would still match. So in this case when you used 200mm, I'm curious to see if we will get different results if 203.2mm is used.
VXGrid
V.I.P Member
V.I.P Member
Posts: 544
Joined: Fri Feb 24, 2017 10:47 am
7
Full Name: Martin Graner
Company Details: PointCab GmbH
Company Position Title: Research and Development
Country: Germany
Linkedin Profile: No
Has thanked: 160 times
Been thanked: 175 times
Contact:

Re: Conflicting sphere target distances Faro Scene 2022.1

Post by VXGrid »

lsf wrote: Thu Dec 08, 2022 4:44 pm @VXGrid
I heard the disturbing news about the arrests in Germany, I hope that will be the end of it and everyone is safe.
Oh I didn't hear anything...
Reichsbürger :roll:
lsf wrote: Thu Dec 08, 2022 4:44 pm
So let's say the scanner has an error of 1 mm single point accuracy give or take.
If we now measure two spheres in one scan and two spheres in another scan, then the distance can be 2 mm off.
Is it reasonable to assume the worst (1mm) error on such a short distance? Is there a formula to fine tune this possible error for a shorted distance? Isn't this error the max error @70 meters I wonder. I think this error should correlate with the distance. Plus that angle error.
But your comment about which sphere in which scan is bad intrigued me so I had another look.
I don't know how sturdy these steel entrance gratings in the US are, in Germany they are really wobbly, so if I step on it once, in between measurements, the sphere will definetly move.
Very good point! However, see distance 2-3 from the table, the variance is 1.7mm and both targets are on the concrete.

I see you used 200mm setting for the spheres, but when I bought them, the specs say 8"=203.2mm. This brings me to the following: If I were to write C++ classes and functions for Scene, then I would implement a logic where there would be some variance allowed between the sphere radius detected from the point cloud and the sphere radius indicated in the settings. The algorithm would find calculate the center point of the point cloud sphere and then insert the sphere defined in the settings. This means that even though if sphere sizes differ by say 5mm, the center coordinates would still match. So in this case when you used 200mm, I'm curious to see if we will get different results if 203.2mm is used.
Check the data sheets, but as I wrote in another post, the error components have normally a fixed value + a range influence.
And the 1mm should be at any distance + the distance influence.


Now now, if the sphere size does not match (and yes I used 200mm; 145mm and 200mm are metric standard values for sphere manufacturers over here), then of course the distances won't match, since the sphere middle point is not calculated correctly.
Strange that the sphere middle point estimation is in submm, but I am going to check that later together with a sphere diameter of 203.2mm.

Regarding your proposal to estimate the sphere diameter based on measured points and adapt it, this brings a lot of new pain points:
  • When searching for spheres in the scans you don't have a fixed size to search for
  • Scan point noise is not in your favour, because the sphere size will be modeled by the captured data (estimation), not the real value
  • The diameter might get estimated differently for the identical sphere in different scans (noise, distance, geoid formed sphere)
VXGrid
V.I.P Member
V.I.P Member
Posts: 544
Joined: Fri Feb 24, 2017 10:47 am
7
Full Name: Martin Graner
Company Details: PointCab GmbH
Company Position Title: Research and Development
Country: Germany
Linkedin Profile: No
Has thanked: 160 times
Been thanked: 175 times
Contact:

Re: Conflicting sphere target distances Faro Scene 2022.1

Post by VXGrid »

lsf wrote: Thu Dec 08, 2022 4:44 pm [...]

I see you used 200mm setting for the spheres, but when I bought them, the specs say 8"=203.2mm. This brings me to the following: If I were to write C++ classes and functions for Scene, then I would implement a logic where there would be some variance allowed between the sphere radius detected from the point cloud and the sphere radius indicated in the settings. The algorithm would find calculate the center point of the point cloud sphere and then insert the sphere defined in the settings. This means that even though if sphere sizes differ by say 5mm, the center coordinates would still match. So in this case when you used 200mm, I'm curious to see if we will get different results if 203.2mm is used.

So I used your convention to name the scans, the nice part is that I only need to change them in one scan :)
The automatic detection with 0.2032 m was a lot better, with that it found all automatically, with 0.2 I clicked a lot of them myself (which doesn't change anything in accuracy)
Here the values in the local scan system:

Scan Santana001
S6 1.2515072181401818 -0.7981478329368417 -1.6462187481764132 1.0000000000000000
S5 0.8412180760978974 0.9591950631131535 -1.6432156807970901 1.0000000000000000
S4 2.3779523447490116 1.0637937460437958 -1.6435559185168429 1.0000000000000000
S2 7.1557816537018253 -1.8334973446625096 -1.6895621286967009 1.0000000000000000
S1 6.5425720969639976 3.0354427130515025 -1.6942864592661973 1.0000000000000000
S3 5.2711596425345961 1.4713947477363367 -1.6814885196493925 1.0000000000000000


Scan Santana002
S6 -1.0670335100561648 1.1951788875591469 -1.6462992373078931 1.0000000000000000
S5 -1.5446572527546825 2.9329030634113002 -1.6470091948105923 1.0000000000000000
S3 2.8637649995215018 3.6168030321514815 -1.6969384216389864 1.0000000000000000
S4 -0.0126528080263553 3.0977179608353453 -1.6518715973658582 1.0000000000000000
S1 4.0740506904459526 5.2280404892345276 -1.7168490237035410 1.0000000000000000


Scan Santana003
S5 -1.4670554860132763 0.7045402461876510 -1.6484120109520275 1.0000000000000000
S6 -3.0123168126898476 -0.2209008354759583 -1.6586148398207541 1.0000000000000000
S3 0.3734426243671750 -3.3596402291801599 -1.6878429202981533 1.0000000000000000
S4 -0.8978571198563342 -0.7275002518272410 -1.6504050159045494 1.0000000000000000
S2 -2.1980795229416321 -6.1610738903244053 -1.7093590774695631 1.0000000000000000
S1NOTUSED 2.2538621192454369 -4.0999739112051623 -1.6989228095327755 1.0000000000000000


Scan Santana004
S1 -2.3499604679972501 -3.0134709083919771 -1.6230572655113051 1.0000000000000000
S2 2.5544532328962535 -2.8587268895275364 -1.5892804801948857 1.0000000000000000
S6 0.9682371814663018 -8.6392121591368429 -1.5177977528694317 1.0000000000000000
S3 -0.9122843840241769 -4.4270823110909809 -1.5930185894566806 1.0000000000000000
S4 -0.7772520863416817 -7.3448226481218599 -1.5344085467888757 1.0000000000000000
S5 -0.8168817869958608 -8.8830145016270556 -1.5235191092826303 1.0000000000000000


Scan Santana005
S2 -1.6495689167431882 -3.2483139821609126 -1.6675148688072854 1.0000000000000000
S3 -2.8207138855675211 -6.8659198350946724 -1.6752348636005563 1.0000000000000000
S6 1.5603284276686458 -8.3179249111612705 -1.6267830466673292 1.0000000000000000
S1 -4.8330533029251717 -6.9776791581713535 -1.6969261404090015 1.0000000000000000


Scan Santana006
S1 3.3401316068464952 2.1624545092637391 -1.6333412419864495 1.0000000000000000
S3 5.3558199273236475 2.1833947264140190 -1.6073916965103350 1.0000000000000000
S2 6.6880793310029496 5.7448971664530113 -1.5685976185205517 1.0000000000000000


And the spheres after registration:
Type Name Scan X[m] Y[m] Z[m] R_d[m] R_X[m] R_Y[m] R_Z[m] R_X'[m] R_Y'[m] R_Z'[m] X~[m] Y~[m] Z~[m]

Sphere S2 Santana005 -1.65647 -3.25187 -1.65367 0.00268 0.00249 -0.00101 0.00002 0.00249 -0.00101 0.00003 -1.65399 -3.25288 -1.65365
Sphere S3 Santana005 -2.82762 -6.86948 -1.64877 0.00153 -0.00119 -0.00090 -0.00033 -0.00119 -0.00090 -0.00034 -2.82882 -6.87038 -1.64910
Sphere S6 Santana005 1.55359 -8.32140 -1.61542 0.00223 -0.00004 0.00222 0.00023 -0.00004 0.00222 0.00023 1.55355 -8.31918 -1.61519
Sphere S1 Santana005 -4.84004 -6.98128 -1.66185 0.00129 -0.00125 -0.00032 0.00008 -0.00125 -0.00032 0.00008 -4.84129 -6.98160 -1.66177
Sphere S6 Santana001 1.55428 -8.31744 -1.61526 0.00188 -0.00073 -0.00174 0.00007 -0.00079 0.00171 0.00007 1.55355 -8.31918 -1.61519
Sphere S5 Santana001 0.53027 -9.80338 -1.61330 0.00107 0.00079 0.00041 0.00059 -0.00023 -0.00087 0.00059 0.53107 -9.80297 -1.61271
Sphere S4 Santana001 -0.58108 -8.73690 -1.61262 0.00058 0.00052 0.00004 -0.00025 -0.00032 -0.00041 -0.00025 -0.58056 -8.73686 -1.61287
Sphere S2 Santana001 -1.65241 -3.25287 -1.65407 0.00163 -0.00158 -0.00001 0.00042 0.00105 0.00118 0.00042 -1.65399 -3.25288 -1.65365
Sphere S1 Santana001 -4.84181 -6.98252 -1.66132 0.00116 0.00053 0.00092 -0.00045 0.00033 -0.00101 -0.00045 -4.84129 -6.98160 -1.66177
Sphere S3 Santana001 -2.82929 -6.87076 -1.64873 0.00071 0.00047 0.00037 -0.00037 -0.00004 -0.00060 -0.00037 -2.82882 -6.87038 -1.64910
Sphere S5 Santana003 0.53191 -9.80299 -1.61264 0.00085 -0.00084 0.00002 -0.00007 0.00076 -0.00037 -0.00007 0.53107 -9.80297 -1.61271
Sphere S6 Santana003 1.55342 -8.31945 -1.61469 0.00058 0.00013 0.00027 -0.00050 -0.00023 -0.00019 -0.00050 1.55355 -8.31918 -1.61519
Sphere S3 Santana003 -2.82987 -6.86979 -1.64904 0.00121 0.00105 -0.00059 -0.00005 -0.00071 0.00097 -0.00006 -2.82882 -6.87038 -1.64910
Sphere S4 Santana003 -0.58051 -8.73657 -1.61326 0.00049 -0.00005 -0.00029 0.00039 0.00016 0.00024 0.00039 -0.58056 -8.73686 -1.61287
Sphere S2 Santana003 -1.65369 -3.25347 -1.65389 0.00070 -0.00030 0.00059 0.00024 0.00002 -0.00066 0.00024 -1.65399 -3.25288 -1.65365
Sphere S1132 Santana003 -4.84790 -6.97703 -1.66544
Sphere S6 Santana002 1.55410 -8.31922 -1.61573 0.00077 -0.00055 0.00004 0.00053 0.00039 0.00040 0.00053 1.55355 -8.31918 -1.61519
Sphere S5 Santana002 0.53180 -9.80336 -1.61229 0.00093 -0.00073 0.00040 -0.00042 0.00077 0.00030 -0.00042 0.53107 -9.80297 -1.61271
Sphere S3 Santana002 -2.82962 -6.87012 -1.64935 0.00088 0.00080 -0.00027 0.00025 -0.00072 -0.00044 0.00025 -2.82882 -6.87038 -1.64910
Sphere S4 Santana002 -0.58056 -8.73711 -1.61290 0.00025 -0.00000 0.00025 0.00003 0.00019 -0.00015 0.00003 -0.58056 -8.73686 -1.61287
Sphere S1 Santana002 -4.84178 -6.98118 -1.66137 0.00076 0.00049 -0.00042 -0.00040 -0.00064 -0.00011 -0.00040 -4.84129 -6.98160 -1.66177
Sphere S1 Santana004 -4.84162 -6.98221 -1.66180 0.00070 0.00034 0.00062 0.00003 0.00068 0.00017 0.00003 -4.84129 -6.98160 -1.66177
Sphere S2 Santana004 -1.65273 -3.25270 -1.65361 0.00127 -0.00126 -0.00018 -0.00004 -0.00098 0.00081 -0.00005 -1.65399 -3.25288 -1.65365
Sphere S6 Santana004 1.55235 -8.31838 -1.61486 0.00147 0.00119 -0.00079 -0.00033 0.00022 -0.00142 -0.00032 1.55355 -8.31918 -1.61519
Sphere S3 Santana004 -2.82824 -6.87157 -1.64970 0.00145 -0.00058 0.00119 0.00060 0.00048 0.00123 0.00060 -2.82882 -6.87038 -1.64910
Sphere S4 Santana004 -0.58009 -8.73687 -1.61271 0.00050 -0.00047 0.00001 -0.00017 -0.00031 0.00035 -0.00017 -0.58056 -8.73686 -1.61287
Sphere S5 Santana004 0.53029 -9.80213 -1.61261 0.00115 0.00078 -0.00084 -0.00010 -0.00009 -0.00114 -0.00009 0.53107 -9.80297 -1.61271
Sphere S1 Santana006 -4.84118 -6.98079 -1.66251 0.00110 -0.00010 -0.00081 0.00074 -0.00014 -0.00081 0.00073 -4.84129 -6.98160 -1.66177
Sphere S3 Santana006 -2.82828 -6.87058 -1.64900 0.00058 -0.00054 0.00020 -0.00010 -0.00053 0.00022 -0.00010 -2.82882 -6.87038 -1.64910
Sphere S2 Santana006 -1.65464 -3.25350 -1.65301 0.00110 0.00065 0.00061 -0.00064 0.00068 0.00059 -0.00063 -1.65399 -3.25288 -1.65365

The worst sphere is S6 in Santana005, Yesterday I was already woundering if the glass and refraction is bleeding into the scan estimation.
Sphere6Refl.png
Sphere6Color.png
Sphere6DepthMap.png
The sphere middle point estimation variance says not, but I am not convinced.
You do not have the required permissions to view the files attached to this post.
User avatar
landmeterbeuckx
V.I.P Member
V.I.P Member
Posts: 1615
Joined: Tue May 01, 2012 5:19 pm
11
Full Name: Lieven Beuckx
Company Details: Studiebureau Beuckx
Company Position Title: Owner
Country: Belgium
Linkedin Profile: Yes
Has thanked: 183 times
Been thanked: 548 times

Re: Conflicting sphere target distances Faro Scene 2022.1

Post by landmeterbeuckx »

I've fitted some spheres in Riscan and found a diameter of 0.202m which is 7.9527 inches.

Image
LSBbvba
Surveying services - 3D Laserscanning
Tel : +32477753126
www.lsbbvba.be
[email protected]
lsf
I have made 50-60 posts
I have made 50-60 posts
Posts: 52
Joined: Fri Mar 18, 2022 8:23 pm
2
Full Name: Las
Company Details: Sfee
Company Position Title: General
Country: USA
Has thanked: 6 times
Been thanked: 2 times

Re: Conflicting sphere target distances Faro Scene 2022.1

Post by lsf »

The worst sphere is S6 in Santana005, Yesterday I was already woundering if the glass and refraction is bleeding into the scan estimation.
Yes absolutely, this one cannot be used because it goes through the glass and based on my test results, I am always ignoring such spheres. Below is an image for other folks who are following along.

How does PointCab generate the depth map and what does it mean, how to understand that image?
You do not have the required permissions to view the files attached to this post.
Post Reply

Return to “FARO SCENE”