With the physical build of the scanning platform, and the Arduino and C++ code figured out, the next step was to try to actually scan something. You can see in the video above that the scanning table rotates, and the VL6180 range-finding chip moves up. It may not be obvious from the video, but the chip only moves up after each complete revolution of the platform.



Before really scanning up the object, I wanted to get a sense of the differences in resolution. From left to right, you can see how the walls of the object go from being fairly fine to much more course. In each case, the overall shape is precisely what I'm going for.





Well would you look at that! It's not a perfect scan, but it definitely resembles the object! You can see all the triangles that were created for the .OBJ file. Those were created using tesselation.

In order to tesselate the scanned object, I had to pick a polygon that I felt would be simple yet detailed enough to handle curves in the object. Triangles make sense to me, so the uprights faces of the object are just a bunch of alternating right-angle triangles.

The basic format is:


[===== ROW 2 =======]
|---||---//||---|
|...||..//.||...|
|...||.//..||...|
|---||//...||---|
[===== ROW 1 =======]




Here, you can see how the object is being built, piece by piece. The first step is to lay down the bottom face, and then the code builds up by placing alternating vertical triangles. This particular example is 2-unit height rectangular box.




The next object to scan was a simple can. Well, I thought it would be simple, but as it turned out, this can of grease became the starting point of my discovery that the VL6180 might not be the best range finder for this project.



Here's the full scan, and you can see that it's... lumpy. It makes sense - we're dealing with 1mm units, and the machine has an accuracy of 1mm, so every single point of distance can be off by a pretty noticeable amount.



In order to make sure that this wasn't a one-off error, I scanned the can a few more times and got similar results. Even with varying degrees of resolution, there were areas that were consistently problematic.



In particular, take a look at that little notch that appeared at the bottom of the scan. It's on all of them!

As it turned out, the "notch" happened repeatedly because there is a small black square on the can itself, and the color of the square actually throws off the distance-reading! This would literally mean that if I had alternating black and white strips on the object I'm scanning, I would have that alternating variation in scan distance. That's terrible!



I tried the scan again with a uniform-colored object. I figured this candle would do a better job giving me a smooth cylindrical shape...



... but it turns out that translucent objects cause even more difficulty for the scanner, because the laser is able to penetrate the outer layer of the object, giving a very bad reading back to the scanner. This is quite comical, really.

I think the next step may be to get some kind of spray coating to provide a uniform, non-translucent surface for the scanner. But that's a future project. In the meanwhile, using photogrammetry may still be a good alternative.

Well, that includes this 3-part 3D scanning project documentation. This was a fun project, and I learned a ton about stepper motor controls, .OBJ file generation, and range-finding chips.

If you missed the previous entries, here you go:

Part 1
Part 2