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:
