Author: seking

The week before spring break, I started working with Theo on the serial code to get communication between the computer and the microcontroller on the manipulator device. Since the device connects using USB, it’s a matter of opening the serial ports and feeding commands at the right time to the manipulator device.

As for the program to automatically capture scans using the flatbed scanner, I’ve encountered. The file works fine before attempting a practical trial with the flatbed scanner. However, when I try to use the scanner with it I encounter a “lost connection with the scanner” error in the middle of scanner. I hear the scanner go off, but then it loses connection and doesn’t save the file. Online search wasn’t helpful, only suggesting to unplug and replug/restart the scanner, which I tried a few times unsuccessfully. I guessed it was something to do with file access permissions on my computer with the scanner, so I tried moving the project to more accessible file locations that definitely wouldn’t require admin, I tried running the script as an admin, I tried to see if there was an access permission the scanner was missing, I double checked that the device drivers were up to date, and nothing seemed to fix this issue. It’s extra confusing because I was able to scan and save just fine from the scanner’s native software and from the NAPS2 library software. I asked Theo to try downloading the project and running it to see maybe if it was an issue with Windows or my machine in particular. However, he encountered a lot of issues with trying to set up the dotnet project and the incompatibilities in the version of dotnet that the project required with his version of Linux.

So, in light of this I believe the best approach would be to pivot from trying to use the universal scan library of NAPS2 that requires a dotnet project. Instead, just a series of files instead that don’t rely on an existing framework. There would be a master file that receives the command from the Blender UI, checks the OS version, and then calls a corresponding file to make the scans based on the OS. This way, we would have a file for each OS version and each OS would be able to use a compatible scanning library. It also makes it so that we could incrementally ensure each OS works, ensuring one is done before moving on to the next. It would also ensure that something in general works, even if not compatible with every OS. Currently, I’m looking at WIA (Windows Imaging Acquisition) for Windows, SANE (Scanner Access Now Easy) for Linux, and ImageCaptureCore (Apple API) for Mac. Since two of these are native to their OS’s and Linux is generally good with setting up libraries, I think these will work out better.

This week, I added in a check for different OS to the scanner controller program. So far, it correctly recognizes and adjusts the scanning context based on the OS, since NAPS2 uses a different scanning context object for each OS. I also added a “scans” folder to save each scanned .png file to. Each scan process/cycle will create a new scan folder (in the format of scan0, scan1, scan2, etc.) in the scans directory in order to keep scan cycles cleanly separated. Each scan .png file will be saved in its respective scan cycle folder (in the format of scanPage0.png, scanPage1.png, etc.). So, for example if we take 3 scans of an object, then you could find scanner-controller/scans/scan0/scanPage0.png, scanner-controller/scans/scan0/scanPage1.png, and scanner-controller/scans/scan0/scanPage2.png to send to the image processing component. I would just need to make sure the program knows what scan number it is on, essentially passing a scan ID between functions.

Additionally, I  implemented an exception for if there are no scanners detected. I also did more research into the NAPS2 documentation and how to properly connect the scanner. I usually use WSL to run code that’s stored on my Windows OS filesystem and I can run the code fine through Windows, but I think I’ve found a way to get the scanner recognized in WSL too. So, I believe I would be able to test both the Windows OS and Linux OS environments from my laptop alone. Yon would just have to test the Mac OS version.

The scanner I ordered arrive. Next week will begin testing communication integration with it. I am currently on schedule.

I created a branch in GitHub for the scanner controller software. I also created the dotnet project and added the universal scanner NAPS2 library which took a lot longer than you’d think, the dependencies felt never-ending. I never worked with dotnet either that I remember, so figuring out projects and solutions was a difficult time. Additionally, I added simple scan sample code to ensure all needed libraries of NAPS2 were correctly identified.

I also worked on design presentation. I edited and added in most of the slides needed for this sprint and filled out my own relevant software sections, ensuring that the needed topics were covered in the presentation slides.

My next steps are to create mock data and unit tests for the scanner controller code to ensure the simple single scans are working before moving on to scanning multiple times with a delay between.

Most of my work time this week was spent on preparing the proposal presentation. Including fleshing out requirements and quantitative measures for it, diagrams, and creating the slides themselves. I worked with my teammates over calls to flesh it out. My team all agreed that I would be presenting the proposal presentation. I spent time practicing to make sure I explained the project in a clear manner, not just directly reading from the slides, and asking my teammates about their parts of the project so that I had a thorough understanding of all of the elements.

Decided on scanner and library – I did research on what software libraries could potentially work for our project, particularly what libraries were available to command scanners. I found one called Naps2 that should work for any popular brand of scanner. I also decided on a scanner to buy, it’s a 4800 dpi Cannon scanner. 4800 dpi is plenty of detail for the scans, Cannon is a very common brand, and the scanner is small and shouldn’t be too difficult to move or store. It’s also less than $100, which leaves plenty of budget for materials for the hardware of our device.

My progress is currently on schedule. Next week, I will start into using the Naps2 library and creating the software that would interact directly with the scanner sending commands, would receive those scans, and then send them to Yon’s image processing software. Depending how far I get, I could even start unit testing it. Hopefully it will be in a decent state by the time the scanner is ordered and arrives for practical testing.