Posted on

Winstone’s Status Report 04/26

This week, our team focused on final integration and testing. Continuing from my work last week, I finished building the housing. After all the electronics were positioned in the box, I took measurements of the top surface to laser cut. I cut the 81 individual squares for the user to interact with the capacitive touch grid and a hole for the numpad to fit through. The laser cutter had difficulty cutting through the entire material even with multiple passes, so I ended up finishing the cut with a boxcutter.

Other than the housing, I also worked on bug fixing our software program to communicate with the MPR121s. We had been iterating and testing on a computer for some of our newer features, but once we integrated it again with our hardware, the capacitive touch grid failed to properly communicate with our Raspberry Pi. Our newer code had some changes to the behavior of the selected cell, so I had to adapt the code to allow for the touches to interact with the selected cell. I plan on working on some minor changes to game functions to improve the user experience before our final demo.

Posted on

Team Status Report 04/19

This past week, our team focused on finalizing the capacitive touch design, building the physical construction, and working on software features.

With the capacitive touch sensor, the original grid approach was fundamentally flawed due to how the MPR121 sensor operates. Each time the sensor initializes, it sets a default baseline capacitance, which is significantly influenced by materials in contact with the copper foil tape. To address this, we shifted the design by offsetting the row and column layers and introduced rubber bands for the top layer. However, the rubber bands proved to be too insulating for a finger to trigger a reliable capacitance change. We solved this by wrapping each of the 81 intersection points with small patches of copper foil tape, which made a significant difference and enabled consistent touch registration.

On the physical construction of our project, we needed a container to hold all our electronics, including the Raspberry Pi and MPR121s, and encompass the capacitive touch sensor and numpad. We decided to use a 1/4″ MDF sheet as the base and 1/8″ MDF sheets for the sides and top projection surface. We used a CAD program and a laser cutter at TechSpark to cut out the box joints. We ran into some difficulty because the 1/4″ MDF sheet did not cut easily and caught fire.  We put it all together in the woodshop and it is mostly complete. We will have to laser cut holes on the top projection surface for the keypad and the capacitive touch sensor once we test all the components together.

With our software, we created the screen that will display text and give users more information on the game state. We also updated our hints algorithm so that instead of giving the number for a cell, it will first highlight the row, column, and 3×3 box with notes in our side screen telling the user what numbers can potentially go into the requested cell.

Posted on

Winstone’s Status Report 04/19

After the weekly meeting with our advisor, I put my efforts into the physical construction of our project. We would need a container to hold all our electronics, including the Raspberry Pi and MPR121s, and encompass the capacitive touch sensor and numpad. This container would also be the surface that the projector would display on. I decided to use a 1/4″ MDF sheet as the base and 1/8″ MDF sheets for the sides and top projection surface. These MDF sheets can be laser cut, is very resistant to warping, and sturdy enough to hold its shape and contain all our components. I spent time drawing out the cuts using a CAD program and used the laser cutter at TechSpark to cut out the box joints. I ran into some difficulty because the 1/4″ MDF sheet did not cut easily and caught fire. I had to use a box cutter to finish the rest of the cut. I put it all together in the woodshop and it is mostly complete. I will have to laser cut holes on the top projection surface for the keypad and the capacitive touch sensor once we test all the components together.

Posted on

Team Status Report 04/12

This week, our team made progress on multiple fronts despite facing some initial setbacks. We successfully developed a 9×9 capacitive touch grid with an extended border to improve wiring separation and structural rigidity. Though we tested 1/16-inch acrylic as a top layer, it required too much pressure for consistent readings, so we plan to revert to a thinner material. Unfortunately, one MPR121 IC was shorted during testing, and we’re waiting for replacements. On the software side, we implemented an enhanced hint system that highlights existing numbers in the selected cell’s row, column, and 3×3 grid, added footnote functionality for tracking potential candidates, and created real-time explanations of hint logic in the terminal. We also developed a side UI panel with placeholder sections that will improve the user experience and fits within projection width constraints. Moving forward, we plan to rebuild the touch grid, expand the UI with a zoomed-in cell view, add on-screen explanations for Sudoku constraints, create an introductory guide, and determine how to implement different functionalities in the side panel.

Posted on

Winstone’s Status Report 04/12

This week I spent time working on a side UI that we could use for different purposes such as displaying a home screen, displaying options, or showing more details for hints on specific cells. I was sick most of the week, so I was unable to progress as much as I had hoped to, but I was able to create a side panel next to the Sudoku board with a few displays that are non-functional.

The side panel I created has a simple layout with placeholder sections that can be customized based on what we decide to show there. I added some basic styling to make sure it matches the overall look of our Sudoku game. I made sure the side screen doesn’t take up too much screen space and will fit into our projection width. I will have to discuss with the team about how we would want to implement the side UI for different purposes before I can progress further. Specifically, we need to decide if we want the panel to change dynamically based on game state or if we can use our numpad for different functions.

Posted on

Winstone’s Status Report 04/05

This week we had our demo days to showcase what we have created so far. In terms of design, our current system is bare bones and not cohesive, but the core functionality of all the parts have been implemented. On the hardware side, the capacitive touch sensor is working, and the numpad and projector can communicate with our software. However, we do need to continue integrating additional features onto our software. Our hint system is not where we want it to be at the moment, as it only gives the user the answer to a specific cell.

Since last week, I spent more time on the hardware-software integration and finally got the capacitive touch sensor to communicate with the Raspberry Pi through Pygame. Now we no longer need the mouse and keyboard to interact with our Sudoku board. The capacitive touch sensor is used to select a cell and the numpad is used to enter numbers, delete numbers, and ask for a hint. I can now focus fully on just the software, and I’ve begun writing some code to have a multi-functional side screen next to the Sudoku board that we will use for displaying a home screen and options.

Posted on

Team Status Report 03/29

Our team has made significant progress on our Sudoku project, focusing on integrating hardware and software components for a functional minimum viable product. The software development has advanced well, with successful integration of the Raspberry Pi and Sudoku board software, including numpad input functionality and code modularization for more efficient row and column readings.

On the hardware side, we built a 9×9 grid using wood, copper foil tape, and cardstock, and successfully connected both MPR121 sensors. However, we encountered a challenge with the cardstock, causing inconsistent sensitivity in the capacitive touch sensors. As a temporary solution, we’re keeping both grid components separate while designing a new enclosure with acrylic sheets and considering 3D printed clamps for better material stability.

Our testing of the system has successfully projected the Pygame display and adjusted visibility and alignment using a stand. While most software components are ready for demonstration, we’re still working on consistent operation of the capacitive touch sensors to replace mouse input with touch selection. We plan to meet another time before demo day to finalize the touch sensor integration and prepare for the demo.

Posted on

Winstone’s Status Report 03/22

This week was dedicated toward getting our software and hardware components working together for a minimum viable product. After testing with the Raspberry Pi, I added to my code so that the Sudoku board would take inputs from the numpad. We were still having trouble getting the capacitive touch sensor to work consistently, so I could not test my code properly to get it to communicate with the Raspberry Pi and Pygame. We plan on meeting tomorrow before our demo day to work on this again and be able to select cells using the touch sensor instead of a mouse. Otherwise, we have put together the rest of our system and can begin final testing for our demo.

Posted on

Team Status Report 03/22

This week, the team attended an ethics lecture and participated in red teaming with other groups. Through these discussions, we explored potential risks associated with our Sudoku helper system, particularly the possibility of users becoming overly reliant on automated solving, which could reduce problem-solving engagement within the Sudoku community.

In terms of hardware, we made progress on improving the accuracy and reliability of the capacitive touch grid. The initial interference issues were because of the use of packing tape as the dielectric material. After testing alternatives, cardstock was found to be the most reliable solution. Using the two MPR121 ICs, a 3×3 functional grid was achieved. The next step will be scaling up to a 9×9 grid and developing methods for processing input data from the MPR121 ICs to enable precise point selection.

On the software side, the team made progress in both Sudoku logic and interface functionality. Using Pygame, improvements were made to the grid system, input methods, and visual feedback, including cell highlighting and keyboard controls. In exploring Sudoku-solving libraries, we tested the py-sudoku package. This will allow dynamic puzzle generation and solving without relying on a static set of boards, reducing repetition for users. Integration of this solver with existing projection code is planned for next week.

Posted on

Winstone’s Status Report 03/22

This week was focused on our ethics lecture and discussion and getting the solution solver portion of our system functioning.

After last week’s preliminary reading on ethics articles and answering questions, there was an ethics lecture this week to continue getting us to think about the potential impacts of our project. We had the opportunity to do some red teaming with another group, which gave us a wider perspective on how our Sudoku helper might have negative consequences. In particular, how people might become over-reliant on our system which could hurt the Sudoku solving community.

I also looked into potential Sudoku solving packages to use for our system. I began testing py-sudoku, which allows me to generate a random Sudoku puzzle of desired difficulty and create a solution to it. This would allow us to avoid having to store our own set of boards and create a mechanism to prevent repeating a board that the user may have already solved. I have not been able to successfully integrate the package into my existing projection code, but I will get that done next week.