Tag: Status Report

Tag needed for posts for status reports.

Team Status Report for 04/12/2025

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. 

Sophia’s Status Report for 04/12/2025

These two weeks, I added in a pop up UI window for the Blender add-on. After you press “Flatbed 3D Scan” in the menu, a window appears where you can select the file path (should be where you store Main.py and other files needed), input the number of scans to take (min of 3 and max of 12, but this isn’t supported in the normal map calculations yet), and the DPI for the scans to use (fully functional).

I also found an existing Blender add-on “DeepBump” that had a module to convert a normal map to a height map. I utilized some of the code and put it into our project to use. It currently is part of the overall system run and produces a height map, though not a very good one because of our alignment issues. We may need to look for a different height map method depending on how well it works on an aligned normal map. This one seems to utilize gradients from the normal map in the Frankot-Chellappa algorithm, but as our project focuses on very small objects, I’m not sure a gradient is the right way to go.

Verification so far has included mostly manual testing of running parts of the software system and ensuring they’re working  by running an individual file I worked on, then run it using Main.py, then run it using the Blender add-on, etc. It’s difficult to set up unit testing since many of the functions depend on external signals, image file outcomes, and what the physical hardware does, so running it plugged in usually provides a good idea. Checking that files are saved appropriately and investigating when there is a crash or error has so far led to getting a functioning software subsystem. Future verification for image alignment would be manually checking the files to see if they have properly aligned the object. Verification for the height map would be a visual check of if the height map looks accurate to what we’d expect from the scans. Importing it to Blender would utilize Blender’s built-in errors as well as a manual check of the files, seeing that the .obj is created and appears in the Blender editor. We also run all of these manual tests on Theo’s computer, testing them on a different system (so we ensure it works on systems other than mine and I didn’t build it to something specific to my machine) and on the Linux OS with his dual-boot laptop.

The next step would be to align the images, ensure the height map is accurate enough, and then figure out how to import it into Blender as an .obj.

Theo’s Status Report for 04/12/2025

This past week, I’ve spent most of my time working on the manipulator hardware. We 3D printed a new mount with tighter tolerances, and it’s done a good job at minimizing the mount’s movement. The tight tolerance makes it hard to slide up and down, so we’ll probably use the linear bearings in our next upgrade (they arrived this Friday). We also laser cut the acrylic sheet and used it while scanning. It does a decent job at blocking out the noise from the air tubing, but makes it much more difficult to align the suction cup on top of the object (even more so when trying to center it). The current issues with our manipulator are off-center scans and a shadow being cast by the black stepper-suction adapter. We’re reprinting the adapter in white so it can match with the cover sheet, and we’re looking into making the acrylic cover sheet thicker. We have an extra 1/8″ sheet that we can cut identically and lay on top.

Here’s what a single scan in the current process and the generated normal map look like. The black shadow behind the object is entirely due to the stepper-suction adapter.


Team Status Report for 03/29/25

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.

Theo’s Status Report for 03/29/25

This week was mainly spent working on the stepper-suction adapter, which would allow the suction cup to rotate with the stepper motor while still being connected to the air pump. It worked on its second iteration, and we were able to put together the entire manipulator. The suction and rotation work as desired, but we’ve yet to fully characterize what is and isn’t possible. All that’s left to do before demo day is make sure the delays in our serial python code are properly sized to let the entire physical rotation/suction happen. We’ll be able to do this within a few minutes on Monday.

I noticed with some of my first tests that the mount can become slanted on the guide pillars, which makes sense because those holes did not print out to the exact proper size. Rather than trying to get this right, I’m leaning toward implementing linear ball bearings that would function identically to the holes, but be properly sized, smoother, and sturdier than just a hole in our 3D print. I’ll order these on Monday.

The suction cup also sticks out relatively far down the manipulator, pushing the mount up the majority of the guide pillars that we planned to leave as slack/space for thicker objects. While this isn’t a point of failure, the remedy is as simple as having the stepper motor’s mounting hole stick less far down from the mount. Since we’ll be reprinting to ensure the linear bearings will fit anyways, one more print should solve both problems at once.

I’ve also continued work on the 3D-printed electronics housing that will be attached to the structure of the manipulator, but that is my last priority at the moment.

The two pictures attached below are the suction cup with the stepper-suction adapter, and the complete prototype demonstrating a slanted mount while resting on top of a coin. 

Sophia’s Status Report for 03/29/2025

This week, we tested the system from scanning, to if the stepper motor rotates, to saving the scans, to feeding it into the math in a python file to make the normal map. The system, after a bit of directory/save name tweaking, works, even properly starting and working fully from the Blender add-on. The only thing we didn’t test is the manipulator rotating the coin/object itself, Theo did it manually for the testing, because we were waiting on a 3D printed part to mount the suction part on the manipulator device. We were actually able to get a decently clear normal map of the coin, just a regular U.S. quarter. So personally, what I did was make adjustments in the software to be able to integrate in Yon’s math normal-map-making python file.

We’ve decided to put Mac-compatible software on hold, as there’s complications with Mac and the framework we were using to command the scanner. We’ll look into Mac-specific scanning libraries to use after getting the whole system including making the .obj working on Windows and Linux. Better to have at least one OS working completely than have it work only partially on all three.

Next step is expanding the Blender UI so the user can select a file path needed for the scanning process, the COM port for the microcontroller (though maybe we could do that automatically), and possibly the scanning DPI. Maybe somehow getting the command line messages we have with the scanning process progress getting displayed in Blender? Also we need to make sure the suction manipulation works in system run and integrate .obj 3D model creation. I’d say we’re on track and have a pretty good setup for the demos this upcoming week.

Team Status Report for 03/22/2025

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’s Status Report for 03/22/2025

This past week was mainly spent working on the 3D printed parts for the manipulator. The newest iteration of our mount finally got the hole size right, so it slides up and down relatively smoothly. It will be interesting to see how well it works once the suction cup is attached to the stepper motor.

The adapter for the suction cup and stepper motor is going along well. It seems like there’s enough clearance in the area that we don’t need to cut the stepper motor axle. The next iteration needs to be longer and have a slightly larger hole for the suction cup, but it should be doable. I’ll have the stl to Yon by Monday for more testing.

The last 3D printed piece I’ll be working on is electronics housing. It will be a long box along one of the T-channels on the frame, housing the mirocontroller and dc air pump. There will be a micro-usb port and a 12V DC adapter port. I’m leaving this for last once we confirm full functionality for the manipulator itself.

Everything is still on schedule, hopefully the adapter doesn’t take too many iterations to finish. It prints pretty quickly (40min), so I may spend an afternoon in our 3D printing area to prototype and get it right.

Sophia’s Status Report for 03/22/2025

This week, I started on the Blender add-on. I’ve successfully made an add-on with the name “Flatbed 3D Scan” to appear in Blender, and it runs the “execute” function that is inside of its Python file when clicked. So, next week I’ll be making it so it calls the Main.py file from last week which would run the scan. I need to look further into if there’s a way I can input arguments to the add-on, or a way to make a UI window pop-up to enter arguments in.

For Main.py, I refactored it a bit along with scanner-controller dotnet project and the serial_proto.py in order to put them in the right directories and directly call serial_proto from Main.py. So, the sequence looks okay. I need to implement try-catches to make sure the program doesn’t have unhandled errors. The dotnet project still isn’t working on Mac, so we’re going to look more into that next week as well.

So overall, next week will be adding in quality of life updates with the Blender add-on UI and bug fixing with testing the system.

Team Status Report for 03/15/2025

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.