Posted on

Team Status Report for 04/08

Currently, we are waiting on our PCB, which would be our most significant risk, as none of us have experience fabricating a PCB or using solder paste and the oven. We hope to get trained for this as soon as possible and fabricate our PCB right after.

This week, our team focused on making substantial progress in our communication and hardware logic, as well as board and PCB design. In terms of our communication and validation logic, Mukundh and Edison focused on establishing connection from the Arduino and RPi while sending information through both systems. Mukundh added calibration logic to our arduino design which allows the system to calibrate the sensors prior to starting a game, by doing this we can establish a range for our hall effect’s idle voltage readings. Calibrating the sensors and allocating this information will help us solidify our piece detection logic in the near future. Mukundh and Edison were also able to send hard coded moves from the Arduino to the RPi and then to Lichess.org (once the moves were validated and if they were valid). This means that the software logic of the project is nearly done, our group would then need to focus on integration and testing. Juan spent some time designing our board’s encasing and redesigning our PCB – we had issues with patch sizes and needed to reorder our design in order to adequately solder the surface mount components onto the board. Mukundh was also able to 3D print all of our pieces and braille coordinates which will be glued onto the board encasing in order to help our users guide themselves across the board.

As for testing and validation, we will be individually testing and validating our systems. Once all of our individual systems have been validated we will run integration tests to guarantee data is being sent across the entire system correctly and the system is able to perform under the goal system delay. We will also be testing each individual hall effect sensor that is mounted onto the PCB, in order to guarantee the sensors are working as expected before testing the entirety of the PCB. In order to test the PCB and detection logic, we will manually move pieces across the board, simulating game moves, to measure how accurate the system is reading the infromation in order to achieve our goal system accuracy.

Posted on

Edison Aviles’s Status Report for 04/08

This week, in order to prepare for our interim demo, I worked closely with Mukundh to solidify our communication between our RPi and Arduino. I updated our NodeJS backend communication logic to establish communication with Mukundh’s Python Serial Module Script in order to initialize the board’s calibration state before starting a game seek. I helped Mukundh debug, test, and verify his code while finalizing communication on my end. By interim demo, we had a full cycle of communication happening from the arduino, to the RPi and then to lichess. All this information would also be reflected on our custom website. Furthermore, I made some basic updates to the website’s UI and added the display of moves made by the different players. Now that we are approaching MVP, I’m starting to reinitialize focus on our post MVP goals, like our website. Mukundh and I focused on establishing the logic for move detection and communication with the arduino. Right now, we hard coded a list of moves (since we do not have our finalized hardware system yet), which the arduino cycles through and sends to the python serial module script, the script then formulates a JSON object and communicates it to the NodeJS file which then validates the move through our validation script and sends the move to Lichess if the move is valid.

In terms of our software schedule, we are making great progress to finish everything leaving a good amount of time to integrate our logic with the hardware system once it is finalized. I, along with Mukundh, will be spending the next week finalizing our move logic, as well as finalizing piece detection logic, while also writing tests in order to validate each of our individual sub systems.

Posted on

Juan Mejia’s Status Report for 4/01

This week I was able to finish the Arduino code to take in the signal from all the PCB muxs and then cycle through all the different sensors using the select lines. I also set in the cases that whenever a signal on a specific tile changed it would use the Serial communication library to send a string with the corresponding chess coordinate. The other thing that I focused on was building and designing the actual physical board using laser cut and engraved plywood. I would say that I am on schedule with the encasing of the system, but had some delays with the Arduino Code.  I tried to insert a picture of the encasing, but the size is too big.

Posted on

Edison Aviles’s Status Report for 04/01

Throughout this past week I worked on various portions of our project. The first few days I focused mostly on finalizing the software logic with Mukundh. We worked on centralizing the entire software communication to our NodeJS system. The JS file is now the center of communication of all of our modules and lichess.org. Initially, when a game is started, a POST request is sent to lichess.org with some basic user information, once the game is started it is reflected on our custom website and communication with the arduino is started in order to await a move on the physical board. After a move is detected it is then sent to be validated through our python validation script, based on the result of the script we send the request to lichess and vocalize some information to the user in order to inform them if the move was valid or incorrect. If the move is correct it is reflected on the lichess.org platform and on our website.

Our PCBs were also delivered this week so I began attempting to solder some of the surface mount pieces on our board. However, I ran into a few road blocks considering the pins and patches for our muxes were incredibly tiny and required an advance level soldering skills in order to solder on the PCB whilst using a soldering iron. We decided to pivot and start looking into using the soldering ovens available in techspark. Furthermore, for the interim demo we decided to provide a proof of concept using a simpler circuit on a breadboard which highlights our piece detection logic as well as the rest of our software system.

By next week we hope to have an initial iteration of a full system where a user is able to play a game of chess with the incorporation of the entire system.

Posted on

Team Status Report for 04/01

The most significant risks currently are fabricating our PCB and soldering its surface mounts. This week we were able to try soldering our components, however, due to a lack of expertise, we fried two PCBs. We have contacted the ECE staff to get permission to use the soldering paste and oven to make it easier. However, if that does not work, we will use Perf boards and solder our components on it.

Instead of 3D printing our board, we decided to laser cut our board and the encasing. As for our braille notation, we decided to 3D print the portions of the board that would require braille and make a casing for these on the board. In order to differentiate between white and black pieces, we decided to incorporate a new design for the different colored pieces which essentially adds a point top to black pieces; this type of design is common in chess boards targeted for blind users.

Posted on

Mukundh Balajee’s Status Report for 04/01

This week, I was able to finish up our software module, upload our code onto the RPi and enable communication between arduino and RPi. Apart from this, I was also able to write arduino code, to help facilitate some sensor measurements and voltage checks for our hardware, before we pass data over to out software component. Apart from this, I was also able to write testing scripts for some of our scripts to help ensure optimal performance.

At the current rate, we are slightly behind schedule, however, we have our physical product in manufacturing, which would put us back on track to complete our project well ahead of time.

By next week, we hope to have a functional gameplay on the software side, and a proof of concept with at least 3-4 rows working, with the ability to detect different pieces and types of actions.

Posted on

Edison Aviles’s Status Report for 03/25

This week my main focus was to work on the validation script as well as the communication script. I worked closely with Mukundh to make sure we figured out a logical approach to writing the programs that will be ran on the RPi. We concluded on a model that is initialized based on a button press from the board, after that our javascript is called to establish connection with Lichess.org, once connection is established, we ask the user to input a move (currently the way moves are inputted are through the terminal – for testing purposes), once a move is entered it is validated on the python script and if the move is valid then we can send it to lichess. The Javascript will serve as a “hub” for communication between the user and lichess. In order to keep track of the current game state, we are passing a FEN string back and forth between the Python script every time a game state update is sent from Lichess. The Javascript sends the current state FEN and the last move made and updates the fen if the move is valid. We have made significant progress on the software side this week, we simply need to fix some minor bugs that are preventing move validation after a few moves.

I also helped test some of the game pieces that Mukundh 3D printed. I made sure that the magnets fit into the pieces and calculated the voltage drop across the LED while varying the distance between the piece and the sensors.

By next week I hope to fix the bugs that are affecting our validation and communication scripts. I also hope to have the scripts running correctly from the RPi. I also hope to have a better understanding of how the arduino will be communicating with the RPi script.

Posted on

Juan Mejia’s status Report for 3/25/23

This week the task that I was assigned to work on was getting the communication between the Arduino and the Raspberry Pi up and running. I was able to accomplish this using serial communication on the Arduino and using the the pySerial module on the Raspberry Pi. I was able to achieve a sub 2 second communication between the devices from start up. I am back on schedule with my work and currently waiting for the PCB to arrive in order to communicate the PCB with the other systems. This week I hope to communicate the Raspberry Pi with our Web-App.

Posted on

Team Status Report for 03/25

The most significant risk at the moment is our ability to vary magnetic strength precisely to ensure accurate piece detection. We have ordered different strength magnets and printed a couple of pieces and a chess board, to test our circuitry and sensors. We plan to use pre-made pieces which would compromise on the accessibility feature we plan to have.

Currently, we have no major design updates. We have been user-testing our hardware to get an understanding of what works best for our user given our budget and timeframe.

Posted on

Mukundh Balajee’s Status Report for 03/25

This week, I was able to finish modeling all our pieces and print a couple out to test that their behavior with the magnet and sensor is as expected. I was also able to determine the magnetic strength required for each unique piece and have our order ready to be placed on Tuesday. I was also able to work on the Software side with Edison to help ensure our code functions as expected. I was able to make a script to validate a user’s move made on the board and pass the information along through various other checks and finally over to lichess.org. I was also able to work on our arduino code, to help read the output of the Hall Effect Sensor.

Currently, we have been able to stick to our schedule, by making progress over spring break, and are a little behind on manufacturing the board.

I hope to complete the manufacturing of the board by next week, and also upload our code into the RPi. We hope to have full connectivity barring our hardware. This will enable full gameplay from a software application.