Sabah’s Status Report for 9/26

After a conversation with my TA, I realized the best course of action was to actually test out both sensor types rather than decide based purely on specs, especially considering potential magnetic cross-talk across adjacent squares. So, I have ordered a test-bunch (8 each) of both the digital and analog sensor alongside the exact magnets we will be using for the final project. Hence, testing will begin as soon as these materials arrive. In the meantime, we received our NVIDIA Jetson Orin Nano. This lets me establish exact hardware pin mappings which is helpful for considering how many GPIO ports I will have from the PCB. 

Since we are not sure about the sensors yet to stay on schedule, I developed the plan for two distinct 1×8 array PCB layouts. For our digital approach, I am pairing eight DRV5032FADBZR Hall-effect sensors with a 74HC165 Parallel-In/Serial-Out (PISO) shift register. I specifically chose a PISO register over a Parallel-In/Parallel-Out (PIPO), because a PIPO register has 8 output lines, while the PISO register has an output of a single serial data line. When scaled to an 8×8 matrix, daisy-chaining eight shift registers end-to-end allows us to read all 64 squares across the board while only using 3 control lines (data-out, clock, latch). 

For the analog validation design, I am pairing eight DRV5055A1QDBZR linear sensors with a CD74HC4051 analog multiplexer. Using three digital GPIO selection lines we can choose from (000 to 111) for the multiplexer choosing between sensor 0 and sensor 7. Although Jetson Orin Nano doesn’t have built-in analog-to-digital converter pins, so the multiplexer has to be routed to an ADC chip (converts analog to digital number) before transmitting the data to the Jetson over I2C or SPI pins. To scale this approach to an 8×8 board, I plan to implement a two-stage multiplexing. Each row of 8 sensors gets its own CD74HC4051 analog multiplexer. The three digital GPIO selection lines will be in relation to the columns, so if 111 is chosen then the column 8 sensor for each row will be selected. Then these 8 outputs go into a master multiplexer which is chosen through another three GPIO selection lines. This essentially results in a nested for loop one for the column, and the other for the row. 

I am on time with the schedule, as we have ordered all necessary components and I have designed the plan/schematic for the 1×8 architecture. I should be done with the PCB 1×8 prototype by next week. In addition I will be presenting for the design presentation next week, so I will be spending some time preparing for that. I hope to deliver that well :). 

Digital:

Analog:

When implementing the ADC (ADS1115IDGSR) , port (A) from the multiplexer will be allocated to the ADC.

Team Status Report for 9/26

The significant risks, mitigations, and contingency plans are the same as last week.
There have been changes to the existing design of the system specifically to the PCB and chess board. We decided to test different types of sensors along with different types of board materials. For testing one type of sensor the cost was approximately $13, now that we are testing two types it resulted in additional $13. We believe these costs are necessary as they directly impact a user requirement measurement (98% accuracy from sensors). Testing on a smaller scale also reduces the risk of producing a full PCB that does not meet this requirement, which would be more expensive to redesign and replace.
In the schedule (software development) we had to push back the task: implement camera capture + board calibration due to us not ordering the camera yet. We have not yet ordered the camera because we wanted to confirm the Nvidia Jetson availability first before ordering a camera. We received the Jetson on Thursday so we will be ordering the camera next week. To minimize offset in the schedule, we determined that working ahead on software development such as implementing digital board state + python-chess rules, move logging, time stamps. This way, by the time we have our camera setup, we can integrate it more easily with the software aspect.

We were recently approved and received an Nvidia Jetson Orin Nano board which will be our main computing platform for computer vision processing

A was written by Justin, B was written by Kevin and C was written by Sabah.

Part A: … with respect to considerations of public health, safety or welfare. Note: The term ‘health’ refers to a state of well-being of people in both a physiological and psychological sense. ‘Safety’ is the absence of hazards and/or physical harm to persons. The term ‘welfare’ relates to the provision of the basic needs of people.

Our project seeks to positively impact the physical chess playing experience for everyone on the spectrum of the visually impaired. This type of user has specific needs for their safety that the rest of the population do not. Specifically, our project involves active moving of chess pieces in a system with fragile electric components. To adhere to the safety needs of the visually impaired, we need to have all components external to the chess board very secured to the table in order to avoid failure of components and avoid injury from accidentally bumping into them. The chessboard and PCB itself will be secured to the table (perhaps with suction cups) to avoid being accidentally pushed. And external power cables will need to be secure to avoid anyone from tripping over them. With respect to physiological harm, as long as the game will be fair, even in the situation of non-visually impaired playing against someone visually impaired, there will be no possibility of cheating or foul play. Additionally, as long as the chess interface helps bring some of the automated features of online chess to the physical board, I foresee there being no physiological harm as opposed to the existing solution. 

Part B: … with consideration of social factors. Social factors relate to extended social groups having distinctive cultural, social, political, and/or economic organizations. They have importance to how people relate to each other and organize around social interests.

One of the key factors that were considered when designing our project was social accessibility and inclusion. Our group noticed that traditional chess can often create barriers especially when they need to rely heavily on visual information from the board. By adding features such as a braille incorporated physical chessboard with digital features such as move detection, move validation, and board state tracking, we believe that this would reduce barriers between visually impaired and sighted players. Overall, this would lead to a more inclusive playing environment that does not require either player to use a completely separate interface. On top of this, we also considered the importance of independence and equal participation. Rather than having to depend on another person to identify pieces and track moves, the system we set up is intended to provide this information automatically to provide accessible feedback. This way, visually impaired players and/or sighted players can both participate more independently in casual games without having to have someone looking over their shoulder to help them. At the same time, we realized that the system should not be providing an unfair advantage to one player so all assistance and game information is designed so that it is consistent for both players. Overall, the goal for this project was to make physical chess more accessible while also preserving the valuable social interaction aspect. 

Part C: … with consideration of economic factors. Economic factors are those relating to the system of production, distribution, and consumption of goods and services.

The smart chessboard we are making for visually impaired users meets the need for a board that helps them learn chess, since many cannot visually access digital resources. Although, we also need to consider the economic factors surrounding this product, including production, distribution, and consumption. On the production side, the board requires more materials and labor than a standard chessboard because it includes braille labels, raised black squares, and differently sized chess pieces. In addition, the smart board requires a camera, LEDs, a speaker, and an NVIDIA Jetson (or another single-board edge computer ), all of which must be wired together. The Jetson or another edge computer (SBC) is a necessary expense because the final product relies on computer vision to detect piece positions. This increases manufacturing costs and assembly time.  The cost of the SBC itself stays roughly the same regardless of production scale, although other costs, such as design and engineering (only done once), LEDs, and sensors, can be reduced when components are purchased in larger quantities. Hence the production cost can be justified with scale.

Another economic factor to consider is distribution. The board would likely reach its intended users best through schools, organizations, and assistive technology retailers that serve visually impaired people. I believe these are the best channels because visually impaired learners and their teachers are likely to find the board through them. We could also make it available online for teachers (from schools) to purchase. Finally, looking at consumption, the board has to compete with free chess apps and cheaper tactile boards that have no electronics. For our target users, however, apps may require constant use of a screen reader and can be difficult to navigate. Similarly, tactile-only boards do not provide feedback on moves, such as hints or corrections, without a coach. This makes it difficult for someone who does not already know chess to learn. The additional cost of the electronics therefore meets a need for visually impaired users by giving them a way to learn and correct their mistakes without a separate human guide.

Justin’s Status Report 9/19

This week, I spent the majority of my time preparing for the proposal presentation. I was mostly practicing how to allocate time for each slide while giving myself a slight buffer for the conclusion; time management in the presentation seemed to be the most challenging aspect that I was initially unprepared for. I also spent some time this week researching some of the challenges with running an OpenCV model on embedded hardware. From my research, I was able to confirm that the NVIDIA Jetson is likely to be the best option for running the model. Still, memory constraints will be the primary challenge I need to solve, since we will also be sensing using Hall-Effect sensors memory constraints will be stricter. In the next week, I need to meet with my team to see how big the RTOS will need to be to run the chess software and the routine for checking and validating moves.

Team Status Report for 9/19

One of the biggest risks to the project is a delay in ordering or receiving the PCB, as well as the possibility of the PCB not working correctly. To reduce this risk, we will test the components on a breadboard and build a small 1 × 8 prototype before ordering the full 8 × 8 PCB. If problems occur, we can continue software testing with the prototype while correcting the PCB.  Another significant risk is the reliability of the computer vision system. Things like lighting, camera position, shadows, or similar looking pieces can cause the system to incorrectly identify the actual board state or identify a move being made. To reduce this risk, we will have to test the camera under different lightning conditions and use a fixed camera position. We can also compare the detected board state with info from the Hall effect sensors to improve reliability.  The main software risk that we determined on was keeping the physical board state synchronized with the digital chess state. Incorrect detections, missed moves, or communication errors between different components might cause the digital representation of the board to be inaccurate. To manage this risk, the software will validate detected moves against the current board state and chess rules before updating the game. Individual software will validate detected moves against the current board state and chess rules before updating the game. 

No changes have been made to the main system design since the proposal presentation. In terms of schedule update, the component delivery task has been moved from last week to next week. This gives us time to review our order plan and component choices with our TA before submitting the order. 

Sabah’s Status Report for 9/19

This past week, I spent time finalizing the system’s circuit architecture, researching components, and planning my approach for the PCB. The final PCB board will use an 8 × 8 matrix of Hall-effect sensors and LEDs, but I decided to begin with a 1 × 8 prototype. This will allow me to confirm that the sensors work properly and meet our 98% accuracy user requirement before ordering the complete board. A major concern is crosstalk, where a magnet may activate a sensor on a neighboring square. I compared linear analog sensors, which measure magnetic-field strength, with switch sensors, which produce a simple ON/OFF output. Although analog sensors could help identify which sensor has the strongest reading, they would require more processing and could increase latency (another user requirement). Since both accuracy and response time are important, I decided to use a switch sensor. I selected the 20 Hz DRV5032 digital omnipolar switch because it is sensitive, responds quickly, and is omnipolar. I also want to test the sensors physically before finalizing the PCB, so I plan to purchase/find SOT-23-to-3-pin DIP breakout boards. These will allow me to connect the sensors to a breadboard and test the complete 1 × 8 setup using an Arduino. 

I am slightly behind schedule, although I completed this week’s main tasks: finalizing the circuit architecture and selecting the major components. The delay is mainly because I have not yet submitted the component order form. To catch up, I plan to meet with my TA on Monday to review my approach and component choices before submitting the form. Once the approach is approved, I will submit the order immediately and begin the PCB design while waiting for the components to arrive.

Next week, my main goal is to complete the 1 × 8 PCB array design by Friday. This includes designing both sides of the board, with the LEDs on the top and the Hall-effect sensors on the bottom. Since I have previous PCB design experience, I believe this is a realistic goal. In parallel, I also want to begin working on the design presentation, which is due next weekend. I will be presenting on behalf of my team, so I want to discuss each part of it with my teammates. 

Kevin’s Status Report for 9/19

This week I was focused on setting up the software environment side of the project. I started looking into the initial development environment and repo structure that we will use for the computer vision, board state tracking, and game logic components. I started some initial research into reviewing how the camera pipeline will interface with OpenCV and how we can calibrate the camera to identify the game state of the board. I specifically looked into mapping the captured image to the physical 8 x 8 chessboard. In addition, I started to look at how the computer vision output can eventually be converted into a digital board state and used alongside the ArCU marker detection and chess-rule logic. For next week, I will try to implement and test the camera capture and board calibration next week before moving into ArUco marker and piece detection.