This is Not Mobile Mapping

Share videos from your recent projects here.
User avatar
jcoco3
Global Moderator
Global Moderator
Posts: 1724
Joined: Sun Mar 04, 2012 5:43 pm
12
Full Name: Jonathan Coco
Company Details: Consultant
Company Position Title: Owner
Country: USA
Linkedin Profile: No
Has thanked: 70 times
Been thanked: 157 times

Re: This is Not Mobile Mapping

Post by jcoco3 »

James, the term scan registration might not be accurate here since the scans are not exactly registered to each other, rather individually tied to survey control. On each of these projects an extensive survey control network was setup for a variety of survey work including scanning. An accurate control network is key to the success of projects as long as these, but on smaller projects you can achieve decent results from a single total station setup or a short open traverse...just don't tell any surveyors ;) A total station setup on control was used to shoot a prism mounted directly under a mechanically leveled laser scanner then a secondary prism mounted either under or in the center of a scan target(sphere in this case) was shot in to provide orientation for the scan. The scanner and sphere were moved as a pair every hundred feet or so depending on the area scanned, with the sphere being placed to the side of the scanner with respect to the total station. So if you consider a 1000' long stretch of road with the total station setup at the midpoint we would shoot back ~500' then move forward in increments of 100' until we were shooting no further forward than ~500'. Then the total station was moved forward 1000' and the process was repeated. While occupying an individual control point with the total station we determined that it was more efficient to capture all scans possible from that location instead of breaking it up and coming back later. For example if the total station was setup in the middle of a 1000' stretch of roadway that crossed another 1000' perpendicular stretch then we would scan 500' feet out in all 4 directions before moving to the next control point.

Prior to "registration" in Scene the coordinate file from the total station must be prepared in the usual way by making sure the format is point name, x, y, z,(truncated), but the z values may need to be adjusted by adding the the vertical offset distance from the prism below the scanner and or target to the center of the scanner or target. In the instance of target spheres used that have the prism in the center then no vertical adjustment needs to be made. Alternatively, the surveyor operating the total station could use an inverted rod height to add the offset in the field, but we just prefer to do it in post so a zero offset is simply used.

After importing into Scene all spheres that were automatically found need to be renamed to match their corresponding survey shot. This is necessary if you only have one sphere in the scanner setup, but I believe if you have two or more then Scene auto-renaming will take over and rename the spheres automatically. A way to make this easy is to have the surveyor name the shot to the scanner the same as the scan name and number and make the shot to the sphere the similar...so if you are shooting Scan_050 then the shot to the scanner recorded in the data collector would be recorded as Scan_050, and the shot to the sphere would be recorded in the data collector as Sphere_050. Make sure you have checked the box in the registration dialog to "find correspondences for scan positions" then click register. If all goes well then your scans will instantly be "registered." To avoid an error message from popping up it helps to right click on the scan folder and uncheck "cluster." Keep in mind that since the scans are not really interacting with each other there may be some orientations errors that need to be addressed if there were bad shots. Another thing that can be disheartening is the fact that most of the time this "registration" will result in a red(stoplight) registration regardless of actual accuracy achieved especially if you choose to use only one sphere to accompany each scan position. The report is not necessarily a great indicator of your actual registration...you just have to keep in mind that you are feeding Scene the absolute minimum amount of data points for it to process a registration but you are also not giving it any data that it can compare from scan to scan. On top of that Scene has no way of analyzing the survey control points for accuracy. In a nutshell we are simply using Scene to place the scans where they were shot in by the total station and it is not really performing any true analysis of the scans.(developers please see commentary below). From our experience the most we found was about a tenth of a foot of orientation error on a water tower located about 400' away from the area we were scanning, so not too terrible if you did everything right in the field. We did a fairly extensive study to document and analyze the vertical accuracy of our scans, and without getting into too much detail we found that this process produced results commensurate with what we could have achieved with a conventional total station survey in the roadway areas that were scanned. Basically the vertical accuracy of the scans is good on the roadway within about a 50' radius but then it kinda goes to hell with distance because you are relying on the inclinometer for level accuracy, but I don't think that is much different than most other scan projects unless an abundance of additional reference points are provided.

We have found that this process can produce really good results for the purpose of roadway scanning once you get the hang of certain things like the comfortable shooting distance to your prisms and also the distance the sphere is placed from the scanner which is a bit more complicated than it might seem on the surface. The main benefit is being able to spread out your scans positions and rapidly cover ground without the need for placing bunch of time consuming targets. You can also scan without continuity, meaning you can skip over non-essential areas or scan sporadic locations without a negative effect on registration. As I have explained before, I don't think this method applies well to every project, but it does appear to have its uses.

This post makes about the millionth time I have attempted to explain this method which I feel is very simple in practice, but extremely complicated when written out. I have also attempted some napkin sketches to graphically explain the basic geometry of the method, but to be honest I don't know if anyone I have explained this to really understands. Guys, please let me know if you have suggestions on how to make this clearer/easier.

There is much more information here from a very old post, but you might die of boredom before you finish reading it all :lol: https://www.laserscanningforum.com/foru ... 618#p24984
Also more information and some tutorial videos on:
www.scan-eye.com

*devs would it be possible to create a registration process where we would provide just the position of the scanner as shot from a total station on survey control then use Scene's cloud to cloud or top down to solve the orientation while keeping the scan position locked to the prism shot? Since we rarely scan without at least some overlap I believe this would save us the effort of placing and dealing with external spheres. Thanks
User avatar
smacl
Global Moderator
Global Moderator
Posts: 1409
Joined: Tue Jan 25, 2011 5:12 pm
13
Full Name: Shane MacLaughlin
Company Details: Atlas Computers Ltd
Company Position Title: Managing Director
Country: Ireland
Linkedin Profile: Yes
Location: Ireland
Has thanked: 627 times
Been thanked: 657 times
Contact:

Re: This is Not Mobile Mapping

Post by smacl »

jcoco3 wrote: Tue Oct 22, 2019 8:45 pmThis post makes about the millionth time I have attempted to explain this method which I feel is very simple in practice, but extremely complicated when written out.
Thanks for the post, highly informative. Most of our users doing roads and rail tend to use scanners that include support for survey control for both position and orientation, such as Leica P and C series, Topcon GTL 1000, Trimble SX10 etc... (I'm sure the list is much longer) Good survey control is absolutely necessary on large linear works where C2C registration will accumulate incremental error over distance for each setup due to lack of constraints. Pretty much like carrying out a traverse from a short base line and never closing it off. I like the idea to combine survey control for position with C2C for orientation as that would neatly solve this accumulating error issue.
Shane MacLaughlin
Atlas Computers Ltd
www.atlascomputers.ie

SCC Point Cloud module
User avatar
jcoco3
Global Moderator
Global Moderator
Posts: 1724
Joined: Sun Mar 04, 2012 5:43 pm
12
Full Name: Jonathan Coco
Company Details: Consultant
Company Position Title: Owner
Country: USA
Linkedin Profile: No
Has thanked: 70 times
Been thanked: 157 times

Re: This is Not Mobile Mapping

Post by jcoco3 »

I like the idea to combine survey control for position with C2C for orientation as that would neatly solve this accumulating error issue.
Glad somebody understands my mumblings :) We created(strong word for rediscovered as its roots were always in Scene) this method simply due to the fact that we had Faro scanners which are obviously not really setup well for occupying control points, and we already owned total stations. After years of use I believe it saves a tremendous amount of total station setup time, and the overall scan speed is quick using 1/4 res 2x most of the time, and only switching to 3x if traffic slows or possibly a half res or two at large intersections. Big drawback is that you need a tremendous amount of clear line of sight to make all these shots, but we have successfully combined this with other more conventional targeting and or cloud to cloud when neccessary to pick up the extra couple scans that may be out of line of sight("of a run"). By the way, the oreintation error is not accumulated. It is independent to each scan/shot, and does not propagate from scan to scan. Two scans right next to each other with opposing orientation error will magnify the effect, but since the scans share no direct correspondence to each other they cannot propagate the error. Basically any horizontal angle error of any shot, be it to the scanner or a sphere always manifest as a orientation error. If you think about the geometry between the total station and scanner, between the total station and sphere, and lastly the scanner and the sphere it will start to make more sense. Keep in mind that no matter what Scene is going to force the scan position to be directly on its corresponding reference shot due to its registration weight being much higher than any other correspondence(been a while since I checked this in Scene's registry). So even if the a shot to the sphere was "perfect" a small error with the shot to the scanner will still manifest an orientation error and that error can be magnified by the placement of the sphere if placed to close and not perpendicular to the line from scanner to total station. That is a fun one to wrap you mind around, but if you think about lever arms or backsights then it becomes clearer.

Ok so maybe this isn't all that simple. I should say instead, simple in practice once you understand the many intricacies :lol:
User avatar
smacl
Global Moderator
Global Moderator
Posts: 1409
Joined: Tue Jan 25, 2011 5:12 pm
13
Full Name: Shane MacLaughlin
Company Details: Atlas Computers Ltd
Company Position Title: Managing Director
Country: Ireland
Linkedin Profile: Yes
Location: Ireland
Has thanked: 627 times
Been thanked: 657 times
Contact:

Re: This is Not Mobile Mapping

Post by smacl »

jcoco3 wrote: Wed Oct 23, 2019 10:54 amBy the way, the oreintation error is not accumulated. It is independent to each scan/shot, and does not propagate from scan to scan
Possibly bad wording on my part. Where you get serious accumulating error is if you use C2C registration as the sole method of control on a long linear job. e.g. you setup on A, B and C. Points from A have no registration error. Points from B have a certain amount of error as part of the C2C registration. Points from C are registered based almost entirely on points from B so inherit those errors plus get an additional as part of the registration. As there is an orientation component to these errors the effect is multiplicative and can become very severe over a large number of setups.

I remember seeing a post on LinkedIn some years ago where someone was proudly displaying the results of their first scanned road job, which was visually very attractive and accompanied by some video. One of the first comments, which from memory came from that pesky Phil Marsh fellow ;) , asked how was the job controlled? The response was "what do you mean by controlled?" which led to a further flurry of agitated comments from more seasoned surveyors. The reason I think posts such as yours above, and the excellent recent series of articles by Daniel Wujanz, are so important is they highlight the often difficult yet critically important nature of control when scanning large infrastructural jobs. There seem to be quite a lot people entering this industry at the moment who lack the basic understanding or expertise to deal with this. Some of them aren't even aware the problem exists. For my money, getting good results on roads, rails and tunnels always comes down to solid technique and surveying expertise rather than pressing the right buttons on the latest and greatest piece of kit.
Shane MacLaughlin
Atlas Computers Ltd
www.atlascomputers.ie

SCC Point Cloud module
User avatar
jcoco3
Global Moderator
Global Moderator
Posts: 1724
Joined: Sun Mar 04, 2012 5:43 pm
12
Full Name: Jonathan Coco
Company Details: Consultant
Company Position Title: Owner
Country: USA
Linkedin Profile: No
Has thanked: 70 times
Been thanked: 157 times

Re: This is Not Mobile Mapping

Post by jcoco3 »

10-4 I understand you now :)
I remember seeing a post on LinkedIn some years ago where someone was proudly displaying the results of their first scanned road job, which was visually very attractive and accompanied by some video. One of the first comments, which from memory came from that pesky Phil Marsh fellow ;) , asked how was the job controlled? The response was "what do you mean by controlled?"
Haha that could have been me if it was old enough, but I don't spend much time online anywhere except this forum anymore. Where can I find some of these Daniel Wujanz articles as I would like to read some?

As far as the ignorance of people scanning/working on these larger projects without the neccessary knowledge, it goes both ways. I see everything from the point of view of the more ignorant scanning guy as apposed to the surveyor, but I have learned a tremendous amount from working with them and studying the skills and technology on my own. It would seem like as the equipment increases in ease of use and performance there seems to be a drop in technical know how neccessary to perform the work. I have worked with far too many surveyors that close a loop in a network, but don't bundle adjust or have any idea why they might need to. We only discover the issues in their network through conflicts in our own scan registration which is difficult to do. Admittedly, I am looking through a keyhole into their world, so its hard to be critical and I am glad I have competent surveyors close by.

The problem is just ignorance, but this forum and contributing members (like you) help tremendously :D
User avatar
3DForensics
Honorary Member
Honorary Member
Posts: 1979
Joined: Mon Aug 03, 2009 1:52 am
14
Full Name: Eugene Liscio
Company Details: AI2-3D Forensics
Company Position Title: Owner
Skype Name: eliscio
Location: Toronto, Canada
Has thanked: 13 times
Been thanked: 70 times
Contact:

Re: This is Not Mobile Mapping

Post by 3DForensics »

You guys always do quality work and your inventiveness and passion for new ideas and solutions never ceases to amaze me!

Thank goodness for telestrut! ;)
User avatar
jcoco3
Global Moderator
Global Moderator
Posts: 1724
Joined: Sun Mar 04, 2012 5:43 pm
12
Full Name: Jonathan Coco
Company Details: Consultant
Company Position Title: Owner
Country: USA
Linkedin Profile: No
Has thanked: 70 times
Been thanked: 157 times

Re: This is Not Mobile Mapping

Post by jcoco3 »

Thanks!
Thank goodness for telestrut! ;)
I should own stock in the stuff :lol:
User avatar
smacl
Global Moderator
Global Moderator
Posts: 1409
Joined: Tue Jan 25, 2011 5:12 pm
13
Full Name: Shane MacLaughlin
Company Details: Atlas Computers Ltd
Company Position Title: Managing Director
Country: Ireland
Linkedin Profile: Yes
Location: Ireland
Has thanked: 627 times
Been thanked: 657 times
Contact:

Re: This is Not Mobile Mapping

Post by smacl »

jcoco3 wrote: Wed Oct 23, 2019 12:58 pm Where can I find some of these Daniel Wujanz articles as I would like to read some?
Daniel posts here and on LinkedIn, see the following;

https://www.linkedin.com/pulse/taming-e ... el-wujanz/
https://www.linkedin.com/pulse/taming-e ... ap-wujanz/
https://www.linkedin.com/pulse/taming-e ... el-wujanz/

While going back a few years, for mobile LIDAR the following is also essential reading http://www.trb.org/Construction/Blurbs/168636.aspx
Shane MacLaughlin
Atlas Computers Ltd
www.atlascomputers.ie

SCC Point Cloud module
Post Reply

Return to “Video Gallery”