Posted on

Team Status Report 02/22

This week was mainly dedicated to the team’s design presentation, which allowed for review and refinement of the project’s design. Michael took the lead in presenting, ensuring the slides conveyed the team’s progress while preparing for potential questions from faculty. Several design updates have been implemented to improve functionality. System diagrams have been updated for better clarity on which components are being used and how they are connected. The team has also streamlined the design by replacing certain components, including no longer using an FPGA, utilizing capacitive touch sensing instead of a keypad for movement, and removing computer vision since it no longer really fit our goals with the project. While these changes do not significantly increase costs, they require additional testing and validation to make sure everything is functional and integration goes smoothly.

The project has encountered some hardware setbacks, (MPR121 sensors and projector) affecting our ability to test the capacitive touch grid and projection. To address these challenges, the team is conducting some preliminary testing, refining the touch grid design, and developing software ahead of hardware arrival to allows us to integrate quickly and begin validation and testing as soon as possible. Given the delay with the projector, simulations using Pygame have been implemented to continued some development.

In addition to the software development and testing, research was made on feeding continuous real-time data into the Vankyo Burger 101 projector. While direct coding progress was limited due to competing obligations, a bit of research was conducted on communication protocols and data interfaces that could be used for this task. The team took into consideration both wired and wireless methods to ensure a steady stream of high-frequency data, while simulations of different data flow scenarios highlighted potential issues such as latency and data integrity. Although all this does is give us some idea but the hardware may function different. A draft technical document was created to outline possible architecture and API requirements, in order to continue improving projector usage.

The project schedule has been adjusted taking into considerations certain issues, with key milestones such as sensor testing, capacitive grid construction, and system integration experiencing slight delays. The team remains proactive in working around different challenges and is prepared to adapt as required. Recent achievements include a design presentation that refined the project’s approach, an improved touch grid layout, and preliminary projection software development. Moving forward, the team will continue testing and optimizing components as hardware becomes available. If delays continue, work will be focused on software elements such as the Sudoku solver and hint generation that don’t require the missing hardware.

Posted on

Michael’s Status Report 02/22

This week was dedicated to our design presentation, and I had to present. I spent a good amount of time preparing the slides, ensuring they were filled with robust about our project’s key ideas and progress. I also anticipated questions from the professor to identify potential weak points that the professors might raise, which pushed me to clarify and strengthen our core concepts. For example, I delved into the specifics of our testing approach for intensity and brightness, researching the use of a lux meter to compare lux values and making sure the ratio is over 3x, which I believe offers a reliable method for our tests. This whole process not only made our presentation more robust but also deepened my understanding of the project’s overall direction. In addition to preparing for our own presentation, I took time to provide thoughtful feedback on other projects via a Google form, further contributing to our collaborative environment.

After the presentation, I shifted my focus to furthering our project work by diving into research on how to feed continuous real-time data into the Vankyo Burger 101 projector. Admittedly, I was not able to make significant progress as far as purely writing code went due to many obligations, but I was able to explore various communication protocols and data interfaces. This included exploring both the realms of wired and wireless to determine the most efficient way to ensure a steady stream of high frequency data. I simulated different data flow scenarios to better understand potential challenges, such as latency and data integrity issues, and began drafting technical documentation to outline a suitable architecture and the necessary API requirements. I believe that this process gave me a further understanding of enhancing the projector’s functionality, and I’m confident that with further refinement, this approach will significantly improve our project’s performance. Overall, it’s been a aptly productive week as far as presentation as well as further exploration on areas of the project that I needed further research on.

Posted on

Winstone’s Status Report 02/22

This week was our design presentation week, which Michael volunteered to do. Our initial design changed quite a bit since our first presentation, so we focused on creating new diagrams that would make it clear how all the parts would work together. Class hours were dedicated to listening to other presentations and giving feedback on aspects of their design they can improve on, such as use-case and functionality. Everyone seemed to have taken in the feedback from the first presentation, as their designs were more functional and thought out.

My personal work went into focusing on the projection system. Last week, I had found the Pygame library to be the best option for me to work with, so I began testing some code after downloading the necessary packages. We still do not have the actual projector yet, but I wrote some code creating a new window with a blank Sudoku board on a computer. Based on what I found online, the projector we are looking at, the VANKYO Burger 101 Pico Projector, should work with the packages and Raspberry Pi.

Posted on

Moises Status Report 02/22

This week, I focused on determining the appropriate sizing for the capacitive touch grid, including the spacing required for a 9 x 9 grid system. Since our system only needs to detect one input at a time, rather than handling multiple simultaneous touches, I realized we could allow for slightly more spacing between the capacitors without sacrificing functionality.

Based on this, I designed a 12in x 12in grid using 1-inch-wide copper foil strips, with 0.375-inch (3/8-inch) gaps between each strip. This layout results in 1-inch by 1-inch capacitor squares, separated by 0.375-inch gaps.

Additionally, I plan to test different dielectric materials to determine which works best, including parchment paper and packing tape.

I do feel slightly behind schedule, as I had hoped to have the board built and begin testing with the MPR121 sensors by now. However, since the sensors have not yet arrived,  and I had a fairly busy week with multiple projects, exams and assignments I fell behind.

Therefore my next steps will be to:

  • Start writing pseudocode for the Raspberry Pi to prepare for debugging.
  • Build a test grid to begin preliminary experiments as soon as the sensors arrive.
  • If the MPR121 arrive, do testing as soon as possible and possibly begin working on implementing the full 9×9 grid.
Posted on

Team Status Report 02/15

For the three-part question: A (public health) was written by Michael, B (social factors) was written by Winstone, C (economic factors) was written by Moises.

This week, our team made a few major changes to our design – a major one is that we decided to remove the use of OpenCV and a camera for Sudoku board detection. Instead of relying on image processing, we will now load the Sudoku board file directly, simplifying our system and reducing unnecessary complexity.

In addition, we have improved the interaction method. Rather than using arrow keys to navigate through 81 cells – which could be tedious – we decided to implement a capacitive touch sensor grid. This involves laying copper foil and dielectric materials to create 81 capacitors, allowing users to interact naturally by selecting cells through touch. The projected Sudoku board will align with this grid to create a real-time interactive experience, where users can select a cell, enter a value, and seamlessly move to another.

Additionally, we had a team meeting on Friday to finalize the project’s direction and establish a more robust and reasonable set of key testing metrics – for example, we decided that the projection system should maintain an accuracy of within 1mm. To ensure that our project timeline reflects the changes we made to our design, we are also in the process of updating our Gantt chart. In terms of parts – we have ordered the Raspberry Pi that will serve as the core processing unit for our design.

Moving forward, our focus will be on implementing the capacitive touch grid system and integrating it with the Raspberry Pi. We will also continue refining the projection system to optimize accuracy and responsiveness. Our software development plan will be adjusted to align with these design modifications, and we will begin testing the board interaction mechanics before moving into full system integration.

Posted on

Michael Status Report 02/15

This week, I made several adjustments to the software design in response to our team’s decision to move away from using OpenCV and a camera for board detection.

Since the Sudoku board will now be loaded from a file rather than scanned, I had to modify how the software initializes and manages board data. This required reworking the logic for handling user inputs and ensuring that the projected grid updates dynamically as users interact with it. Additionally, I’ve been considering how to efficiently update and maintain a constantly changing 9×9 grid in real-time as users input values. One possible approach is using Matplotlib for rendering the board updates, but other alternatives such as Pygame, Tkinter Canvas, or drawing functions could also be explored to ensure smooth real-time updates.

Speed optimization is another critical factor, as we need to ensure that changes appear on the projected board with minimal delay. We are currently targeting an update rate of 10 milliseconds, so I will be focusing on implementing a lightweight rendering solution that meets this requirement. I’ve also ordered the projector, and once it arrives, we can begin integrating the hardware with the software and refining the display logic. Another key aspect I’ve been pondering on is the undo/reset functionality, allowing users to revert their actions efficiently. One potential approach is implementing a history stack, where each board state is stored, enabling users to step back to previous configurations.

Health (A):

Our interactive system promotes cognitive health by providing a real-time, projected Sudoku board with capacitive touch functionality and thus offering a more engaging alternative. Mentally stimulating activities like Sudoku can support cognitive well-being and help slow cognitive decline, making our system beneficial for brain capacity and mental health. To ensure safety, we are incorporating proper insulation, minimal exposed wiring, and low-voltage operation to prevent electrical hazards. Additionally, our design enhances welfare by making Sudoku more accessible and intuitive, particularly in educational settings, where it can help students develop critical thinking and problem-solving skills in an interactive, hands-on way.

Posted on

Moises Status Report 02/15

We identified a few components in our project that were difficult to justify and found better alternatives. One of these was the navigation method for Sudoku board selection. Instead of using four directional buttons (up, down, left, right), I explored different ways to implement a touch-based selection system.

The most promising approach is capacitive touch sensing. This would involve creating a 9×9 grid using a conductive material, such as copper foil tape, with rows and columns separated by a dielectric material. This setup effectively forms 81 capacitors. Each row and column would be connected to an MPR121, an IC capable of detecting changes in capacitance. When a user touches the overlapping region of a row and column (a makeshift capacitor), the capacitance increases, which the MPR121 can detect and process.

This solution is cost-effective, requiring two MPR121 ICs ($8 each) and copper foil tape which is approximately ($8).

Overall, I believe this approach will improve the project by making user interaction more intuitive. However, it also introduces new challenges in setup and integration. My next steps include gaining a deeper understanding of the implementation process and beginning assembly once the necessary components arrive.

Our interactive Sudoku system is designed with economic efficiency in mind, utilizing low-cost materials like MPR121 ICs and copper foil tape to reduce production costs compared to expensive touchscreen alternatives. By leveraging Raspberry Pi and open-source software like Pygame, the system remains affordable, scalable, and easy to distribute, enabling cost-effective replication for educators, developers, and hobbyists. Its modular design allows for widespread adoption in schools and learning centers, while its open-source framework supports a DIY market, fostering innovation without high development costs. Additionally, the system holds commercial potential in the  sector of education technology, where it could be produced and sold as an interactive learning tool that will make cognitive training more accessible while aligning with sustainable production and distribution models.

Posted on

Winstone’s Status Report for 02/15

This week, I had been testing some code with OpenCV on a random Sudoku board image I pulled from the internet. I made the image grayscale and applied adaptive thresholding to make the text black and background white. I was struggling with isolating the Sudoku board and detecting each cell before our team dropped the image processing idea.

After discussion with our advisors, our team decided that the camera idea did not make sense for our use case. Rather, we would implement a capacitive touch sensor grid that would make the Sudoku board more interactive and intuitive. This would give our project more hardware complexity and on the software side, allow us to focus more on the unique part of our project: the hint algorithm and projection.

My focus shifted towards the projection implementation after dropping the CV aspect. I am now looking into using Pygame, which is a Python library that already has tools for handling graphics, animations, and user inputs. It works with Raspberry Pi and GPIO inputs such as our numpad and buttons and updates the projection in real-time when the user makes an input.

The social factor that our project meets is for physical and cognitive accessibility. Individuals who may have difficulty with fine motor skills such as handwriting will have an easier time interacting with our board, and those with visual impairments can see easier on our large board display. Our Sudoku algorithm is aimed to help people of all skill levels and teach users how to work through a Sudoku puzzle and improve their problem solving skills.

Posted on

Team Status Report for 02/08

Over this past week, our team has made progress in researching what we need for our Sudoku solver, finalizing our hardware and software choices. We also changed our developmental approach after receiving feedback from our proposal presentation. Initially, we planned to put everything together at the end for our final product, but if this fails, then we don’t have anything. Now, our goal is to develop a minimum viable product as soon as possible and iterate from there. Once we order our parts and they come in, we will work together to get the hardware setup and then start testing the image processing.

On the hardware side, we researched potential display and processing options. The Vankyo Burger 101 is a compact and flexible projector for displaying the Sudoku board. For the Raspberry Pi, the Raspberry Pi 5 or Raspberry Pi 4 Model B are our likely choices for their HDMI output, processing power, and compatibility with OpenCV and Tesseract. We have begun initial setup and configuration for these boards, including writing pseudocode for pin initialization and display setup.

For software, we have started implementing the Sudoku solver using a backtracking algorithm with JSON input. The system tracks user moves with a history stack, allowing for undo functionality and input validation. A CLI interface is currently in place, with plans to integrate GPIO buttons for user interaction. Additionally, we researched image processing and digit recognition using OpenCV and Tesseract.

Moving forward, we plan to integrate the hardware components and test image recognition with real-world inputs.

Posted on

Michael’s Status Report for 02/08

I have been researching projectors on Amazon and identified the Vankyo Burger 101 as a compact and flexible display option.

Also, I was working on the actual Software – my idea of the Sudoku solver is one which takes JSON input, solves puzzles via backtracking, and enables user interaction through GPIO buttons or a CLI. The core algorithm employs backtracking to recursively fill in missing values while ensuring valid placements according to Sudoku rules. The software maintains a move history stack to track user inputs, allowing for easy undo functionality. A keyboard or potentially for sake of testing, CLI interface enables direct input. In theory, the software also logs each move to prevent invalid inputs and help users navigate back to previous moves. I believe that the basic skeleton of the program should work in this way, and I will potentially be adding features as needed going forward.