Team Status Report for 10/10

One of the significant risks we identified in our previous progress reports was a delay in ordering the PCB, and this risk has now occurred. When we looked at the price of the PCB, we realized we could not afford to order two boards (in case the first one did not work). This created an additional risk, since it left us with no buffer. We had to weigh the tradeoff between two options, sending the PCB out on schedule and risking a mistake that we could not recover from, or sending it out a bit late after checking it thoroughly. We ultimately chose to send the PCB out one week later than initially planned. Although this may set our integration back slightly, we decided it was the safer choice for the project.

No changes were made to our design. This week we finalized the design spec of digital hall effect sensors, which is represented in our PCB design. This decision will require a working CV element to the system to detect specific types of pieces. However, this is still in line with our current design. 

Schedule Update:

We moved the integration back by two weeks in consideration of the PCB delay. 

Photos from Sensor Testing:

For both Analog and Digital Sensors we ran some distance testing (as cross-talking was our main concern). We ran each sensor with the magnet on top and in a 1/2cm distance.

Directly on top of sensor (7cm = 0cm):

1/2cm away from sensor (7.5cm =0.5cm)

Analog Results respectively:

Digital Results respectively:

 

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

Part A: The product solution we are designing will meet a specific need with consideration of global factors. 

Our project, while offering a much more accessible way to play chess for the visually impaired, is still limited in the global scope. Mainly because the braille and audio feedback features will be in English. This is a tricky barrier to cross in a single system because all major languages use a different writing system for the visually impaired. We suppose translated versions of the project may be created with little difficulty, although we aim to only help the English speaking visually impaired play chess more effectively. However, we do not require our users to be very tech savvy. The user interface on the web will be accessible to everyone on the local network, and on the device, we will have automated scripts that connect to known internet hosts upon startup. There will be equal accessibility to nearly everyone in the US and English speakers with minimal tech experience and access. With consideration to all global factors, language is a clear barrier that our project currently will not seek to expand on. Although with our target audience in developed, English speaking countries, we aim to provide a much more accessible way to play chess. 

Part B: The product solution we are designing will meet a specific need with consideration of cultural factors.

Our project is aimed to make chess more accessible to visually impaired individuals while also considering different cultural backgrounds and experiences of our different potential users. Chess is a pretty famous game played all around the world. While the rules are standardized, players may have different levels of familiarity with assistive technology and different preferences to how they would interact with the game. Additionally, players might even have different experiences and expectations for how chess is played. This may include how the chess community values fairness, independence, and equal opportunities. But in our current state of the world, because technology has progressed so much, online chess has become a popular mode of play. However, virtual play can often be limited to visually impaired players since they cannot see the screen or have any physical contact with the game. With the values of fairness, independence, and equal opportunities in mind, we are creating an accommodation for visually impaired players by incorporating tactile features so that they can participate in the same game as sighted players. Since chess is often played in a social environment, reducing these barriers between visually impaired and sighted players can help with play between friends, family, or even competition. By doing so, we are maintaining the social aspect of chess and encouraging inclusion within the chess community. 

Part C: The product solution we are designing will meet a specific need with consideration of environmental factors. 

In consideration of environmental factors we choose materials and designs to limit waste and conserve natural resources. The board surface is acrylic, which is both durable and scratch resistant, hence the board can last for years and be recycled at the end of its life. We are also considering 3D-priniting our chess pieces, in this case we will use a PLA. PLA is extracted from plant-based renewable resources and can be composted in industrial facilities. Our overall system is built with a modular design which allows users to replace the PCB, camera, speaker, or LEDs (neo pixels) individually instead of discarding the whole product. This design choice saves the raw materials used to manufacture these electronic pieces and additionally keeps the electronic waste to a minimum. Finally, the system uses little energy as the Jetson can run in a low-power mode, and the neo pixels only light up when giving feedback.  Lower electricity use means fewer fossil fuels burned to power the board, which helps conserve natural resources. 

Team Status Report for 10/3

Based on some of the feedback from the design presentation, it is going to be a priority for us to make sure that there is some benefit for the computer vision aspect of the project. As of now, it seems like it will be the most effective way to recover from corrupted game states, i.e. a hall effect isn’t triggered and the virtual state of the board becomes out of sync with the physical game. For the Jetson microcontroller, in the process of installing the operating system, we realized we need some form of persistent storage which needs to be ordered; the most affordable option seems to be a 128 gig microsd card. Once that arrives, we can boot the Jetson without the ISO image. This may set our software development back about a week, although we are confident that using a performant high level language such as golang will allow us to seamlessly manage concurrent processes safely and fast enough for our target requirements. Since go is also built with a nice networking interface, it should be also relatively easy to do the web backend with it; later down the line we need to decide if an on-device database or a cloud based solution will be best. Additionally, for the computer vision aspect, we are considering having the computer vision aspect to act as a secondary verification / recovery mechanism rather than having it as a primary means of detecting every move. We want to keep the hall sensors as the primary source for detecting board changes if piece classification is difficult to achieve under varying lighting or camera conditions.

One big feature we are going to add to our project is a website for logging the history of moves  which can be used by either a user who is able to navigate the web or a caretaker/ coach who could go through and analyze past games. This will be a simple add on to our software stack and requires no additional hardware or modifications to the overall software architecture. 

No changes have been made to our overall design since the design presentation, although some of the questions we received during our presentation have got us thinking about how the overall design may need to be refined. One of these possible changes is switching to a hardware-only product, by using analog sensors and magnets with variable strengths. We do want to create a smart chess board with as close to 100% accuracy as possible. So along with testing digital vs analog sensors this week, we will also try analog sensors with variable magnet strengths. If an analog hall sensing for determining piece types is very successful, we would prioritize development for this; it would also require ordering more magnets with more precise strengths and using some sort of ADC which would be integrated over I2C. 

As we just received the sensors and magnets we moved testing to this upcoming week. We have completed the full (8×8) matrix schematics for both sensors, so as soon as a sensor is selected we will move on to layout. 

Other updates to the schedule are to integrate ethernet much sooner, this would allow us to access our code base and download supporting software such as Jetpack 6.x for openCV. This will be completed with setting up the Jetson’s OS. Even though sensor testing and Jetson setup have shifted slightly, not all of the software tasks depend directly on the physical hardware so we are able to continue along the set schedule. During this time, we can also opt to use simulated board states to test board-state tracking, move detection, move validation, and move logging. Once the actual hardware is available, we can replace the simulated inputs with real sensor and camera data. 

This is our updated price sheet & ordered products:

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.

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.