Category: Team’s Status Reports

This past week, the most significant problems we’ve encountered have been with the quality of the scans. As mentioned in Theo’s status report for this week, the stepper-suction adapter casts a black shadow behind the object that shows up in the normal map, and the rotation is still misaligned. The new mount has tighter tolerances that prevent it from sliding around, but it is still extremely difficult to place the suction cup directly in the center of the object (in order for each vector in the normal map to align). We’ve 3D printed a white stepper-suction adapter to see if that will help (it ought to blend in with the white acrylic cover sheet), and we’ve started looking into a software-level solution to the scan alignment issue. As detailed in Yon’s status report, we have two approaches to solve the alignment issue which we will test this coming week. These create very minor changes in our system, by introducing a small amount of complexity in the ‘image alignment’ step. If the image alignment goes well and creates better normal maps, we will then be able to move on to ensuring the height map turns out well, since the results are currently skewed from the misaligned normal map. There is a normal-to-height-map module currently as detailed in Sophia’s status report, but we may need to look for alternatives or edit it for our use case of small objects, since this module was normally used on larger cases.

As we continue to improve the manipulator, we’re also looking to begin testing with objects other than a quarter. Yon has designed a test object that we can start using when we’re ready, and the manipulator ought to be able to work with any object that fits in its 6inx6inx1in space. This also would be the validation of our system as a whole. When we compare the scan we take from the model, the original model we made, and the scans that commercial 3D scanners take, we will be able to calculate how close our scans are versus commercial scans using Hausdorff distance.

A scan from our current system and a normal map generated from it and its rotated counterparts. 

This past week was focused on testing the integration of our subsystems. We continued working on the Mac incompatibility issue but haven’t made progress yet. We’ve tentatively pushed it to the back of our task list, since it’s the least essential thing we’ve yet to do.

While Theo completed the manipulator and started testing for any issues, Yon and Sophia implemented the mapping code with the current control code. We were able to run a test where we ran an entire “scan,” with one of us rotating a coin on the scanner between each scan. Even with imprecise rotations and a scanner DPI of 100, we still observed decent a output map. Since the manipulator is completely working (besides some upgrades and adjustments mentioned in Theo’s status report), we will be ready to integrate everything we have so far on Monday.

We are still on track, with the next steps being to characterize and improve the manipulator while implementing our code in a blender plugin.

Currently, work on the manipulator hardware is on schedule. The newest 3D-printed mount slides up and down the manipulator smoothly, though it remains to be seen how well it will function when accommodating objects of different thicknesses. All that’s left for the manipulator is the stepper-suction adapter, which Theo plans to finish by this week. We won’t need to cut the stepper motor’s axle if we make the adapter longer, so we should be able to avoid accidentally damaging the internals of the stepper motor.

One new risk that came up this week is that the scanner API is having trouble running on our Mac. We found sources online that claim they’re able to make it work, but we’ve run into several issues so far. We did make some progress on this front and hope to be able to get it to work, but we may have to sacrifice mac compatibility if the issue persists, which would be unfortunate. This does not impact our schedule or our block diagram, but it could affect our benchmarks by excluding compatibility with mac systems.

Theo received the suction cup we were waiting on this week and began working on it. It can hold and let go of objects as heavy as a phone, and he was able to make a right-angled connection between the suction cup and the tubing. This is important for the last design component of the manipulator: a 3D printed part that connects the suction cup to a bearing on the stepper motor, centering it with the shaft. He’s already started working on this and will have it ready to print before Wednesday.

Sophia, with Theo’s help, solved what was wrong with the NAPS2 code so the scanner controller software works. She’s started working on the Main.py file that will connect together the scanner controller, the microcontroller manipulator device, the image processing, and the Blender add-on UI.

—

A risk that is coming to light in our design choices thus far is the 3D printed mount’s smoothness while sliding up and down the pillars on our manipulator. This issue is mainly due to the tolerances on the mount’s holes. We’ve needed to reprint it multiple times while making the holes larger, and this issue affects the holes the stepper motor will go into as well. If the holes are made large enough but the sliding still isn’t smooth, we are considering linear bearings on the pillars/mount to ensure smooth motion. We’ll weigh the costs and benefits of this change if it proves necessary.

The schedule has not changed significantly. Even though Yon’s subsystem is a little behind due to him being sick last week, we worked in some padding to the implementation of the entire image processing system which leaves the schedule unchanged.

Since we’ve all been on schedule so far, we took Spring Break off. During the last week of February, we made progress on our prototype and have moved closer to system integration/testing.

Theo built the prototype’s structure, and we’re now just waiting on the suction cup and its mounting components to finish it. See his section for specifics and a photo of the prototype on our scanner. He also made some basic serial code for sending rotation and pumping commands, as well as python code for interfacing over serial. He’ll be working with Sophia to integrate a better version of this in the final control software.

Besides the serial code, Sophia did trial tests of the flatbed scanner with the controller software and found that it had issues with no clear solution. After many attempts and guesses at what was going wrong with the scanner to computer communication, and Theo after attempting to setup the project but finding it incompatible with newer versions of Linux, she’ll be pivoting to a more modular approach that will use unique and more compatible libraries for each OS, keeping the individual OS scanning processes in separate files. This will mean a more incremental approach to ensuring each OS works well without jeopardizing the states of the other OS’s and it won’t rely on an outdated dotnet framework (NAPS2 needed version 4.8, was only supported at all to version 8, current version is version 9).

Yon finished working out the math for normal map construction and detailed his findings in the design report. He also identified 3D scanners we can use for qualification, which gives both Yon and Theo some work next week in designing and manufacturing a test object. Now that a basic python version of the normal map code is implemented and can be used for testing Theo and Sophia’s subsystems, Yon will turn to implementing the normal map math in the design report. He also still has to identify a normal map to depth map pipeline, which can be achieved either in a custom implementation, a C library, or externally through another blender plugin / tool.

A was written by Theo, B was written by Yon, and C was written by Sophia.

Part A: On the global scale, our project has possible uses in the fields of archeology, history, and design. There are no limiting factors in who across the world could access/utilize flatbed 3D scanning besides a possible language barrier in the software (which is easily translatable).

People not in the academic environment would be more likely to use this as hobbyists who want to get detailed scans of their art, sculptures, or other detailed objects. There is a small subculture of photographers who use scanners for their high DPI, and such a group would likely be eager to map their hobby into a third dimension that they can interact with via Blender or other .obj-friendly software.

There is an emphasis throughout our project on making the scanning process user-friendly and hands-off. While this is mainly meant to accommodate repetitive data acquisition, less tech-savvy people would only have to deal with a few more steps than when using a flatbed scanner normally (place manipulator, plug in cables, run software).

Part B: Our project implements a cheap and accessible way to 3D scan small objects. One significant area of application for this technology is in archeology and preservation where cheap, quick, and onsite digitization of cultural artifacts can help preserve clotures and assist dialog and discourse around them.

That said, all technology is a double edged sword. The ability to create quick replicas of historical artifacts makes them vulnerable to pop cloture-ification which could manifest in cultural appropriation.

Part C: Our project uses a low power draw, which is an environmental boon. Especially considering its competitors are larger, complicated machines that would use more energy. Our project also leverages an existing technology, therefore reusing devices and not requiring buying a larger version that uses much more material and energy in manufacturing and usage.

The simplicity of our project also lends itself to environmentalism, since we don’t use any cloud storage, AI features, or other massive energy consumption processes. We don’t even use a separate battery, drawing power from the computer through USB. Open source projects like ours are also generally more sustainable than completely commercialized sources.

Environmental organisms and discoveries can even be captured for future research and knowledge using our project. Since archaeology is a key audience, it’s not a stretch to extend that into general biology. Scanning small bones, skeletons, feathers, footprints, or other small biological features would be possible as long as they aren’t particularly frail. This contributes to the knowledge bank of biological organisms, furthering science’s understanding. The Smithsonian for example has a public access bank of 3D scans, so our project would be perfectly suited to its use for small, detailed objects.

This week has been one of preparation and prototyping. Our Adafruit and first Amazon orders arrived, and we were able to run a test circuit where we checked that both the stepper motor and air pump could be powered and controlled. Electronics-wise, everything is fine; we’ll be waiting for the rest of our orders to come in before we can build our complete prototype. The 3D printed electronics mount had too little clearance in all of its holes, so we’ll be re-printing it with an extra 0.25mm of radius this week.

Software-wise, NAPS2 is proving to be the correct library choice. Sophia was able to implement OS-specific functionality, and the preliminary work can run on Windows and Linux. There is also a consistent file system for saving completed scans. The next steps will be testing computer-printer interactions.

On the signals end, Yon has continued to make progress on the scan/object mapping and has found new research that we may be able to draw inspiration from.

As of right now, we’re currently all on schedule. The only foreseeable issue in the project right now is the possibility of an object with an abrasive surface scratching the bed of the scanner while rotating. We’ll tackle this during the characterization of our prototype, and the most likely solution will be motorizing the vertical movement of the electronics mount so that we pick up the object before rotating it and let it down before we scan it.

Started working on our individual components, specifically creating the device model in CAD, setting up the software project, and looking into more research for the signals processing. We decided to use a suction cup as our friction tip and set up the hardware and electronics necessary to use it in our first prototype. Instead of testing two different prototypes with different manipulators, we can simply test with the suction on and off.

We have ordered all parts that we believe will be necessary at the moment. We should get all of them by next week and be able to start prototyping and testing with them. The 3D printed part we’ll need is also designed and can be printed anytime.

Our next steps are to progress on our individual tasks to keep on track before attempting and testing integration of the components.

Our team created our proposal slide deck and presented it. This helped us flesh out more details of our project and how all of our parts will interact as a system. We considered how user-friendly we wanted the process to be, the maximum amount of time it should take to scan and generate a 3D model, and the scope of what objects would be scannable. We realized some limitations that real world conditions would present to us. We will have to test how much noise will occur from outside lighting and other real conditions with the flatbed. We will also consider different options for our mechanical arm based on how either rotating with a felt tip on a glass surface or electro-adhesion would work with different materials and geometries. Additionally, we need to see if it’d be necessary to place anything under the scanned object, such as film, to prevent scratching or if it would help/hinder rotation of the object.

Next week we plan on looking through the inventory list for components of our manipulator, and placing orders for a flatbed scanner and potentially any manipulator parts that we can’t find in the inventory.