Posted on

Edison Aviles’s Status Report for 04/29

This week, my main focus was to continue working on manufacturing the board’s PCBs. I was able to manufacture and test all 8 PCBs that would be required for the full board. We began putting together all the circuits this week and plan to finalize the board manufacturing and testing within the next day or two. This will give us a few more days to fix any potential hiccups on the hardware side and continue integration with the software system. In terms of software, I was able to write a testing script to ensure the functionality of the board once it has been put together – the script loops through all the 64 hall effect sensor outputs and displays changes in the output voltage. This way we can guarantee that the board works as expected as we begin to integrate all the 8 PCBs. However, the majority of my time this week was spent on debugging the PCBs as well as finalizing any missing components – one problem I frequently encountered with the PCBs was fixing solder bridges on the 8:1 muxes, this was a very tedious and time consuming task since I had to manually remove the bridges using a soldering iron.

We’re a little tight on time with our integration schedule, but hope to finish what is left by early this week, this will give us enough time to prepare for the final demo and the rest of the deadliens coming up this week.

By next week, I hope to finish manufacturing and testing our board as well as integrating our hardware and software systems.

 

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

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

Edison Aviles’s Status Report 03/11

For the past two weeks, my main focus has been updating the web application logic to load and update the displayed FEN entirely based on communication from lichess.org. This proved to be difficult since the formatting of the JSON strings being received from lichess.org isn’t in the form of a FEN, it’s actually being sent as an array of moves made during that specific game, ordered from first move to latest move. From this list, I then have to calculate the actual FEN to then display. From here I continue to receive moves in the form of an array of all the moves made in the game and filter out the old moves in order to apply the new moves on the displayed board. Furthermore, I worked with Mukundh to finalize some final tocuhes of the move verification script using Stockfish. We added some classes and methods to mainstream the code and make it easier to understand. Apart from this, the team focused a lot of time on working on the system design report which was submitted last Friday.

In terms of software on the web application portion and Stockfish portion, the team is on track to finish everything on time. This next week we want to push communication between the web app, lichess.org, and the RPi in order to make sure we can play an entire chess game from the RPi and view the game from our web application.

In terms of new technologies used – In order to complete the software portion of the project, I’ve had to learn how to use various libraries including Chess.JS, React Chessboard, Stockfish, and Lichess.org’s public API. I will also have to learn how to use the RPi and the available drivers in order to use the RPi speakers. The team chose to use these specific technologies, mostly based on the fact they all have extensive documentation and have previously been used in similar projects to the one we aim to complete.

Posted on

Edison Aviles’s Status Report for 2/18

This week, my main goal was to setup the project’s web application and gain some understanding of the lichess.org API. I started the week by working on some basic UI designs and flow diagrams for the frontend portion of the web application – these were for the most important portions of the project, i.e. the homepage, searching for game flow diagram, etc. After finalizing these, I began setting up the web application and opted to use a reactjs frontend connected to an expressjs backend – I chose these two frameworks since I’m familiar with both from previous internship experiences. After having a fullstack web application setup, I began tinkering with the lichess.org API with the specific goal of making moves during a live game. After lots of reading and a few lichess.org temporary bans (I was accidentally spamming the website with requests), I was able to make moves using standard chess notation from my local frontend application. I was also able to seek or create games and receive game updates to the backend.

As of right now, I’m on schedule with the tasks I have to complete. For the following week, I will continue working on the web application for the most part. I hope to be able to start, play, and view an entire chess game from our web application by next week and hopefully begin the process of adding OAuth or some Authentication to the web app.

Most of the principles I applied in the progress I made were taught in 17-437 Web Application Development. Although, the process of writing unit tests was not taught in the course, I learned all about the communication between the backend and frontend which allowed me to write concise tests for my entire system.

Posted on

Team Status Report for 2/11

Our knowledge on PCB Fabrication is very limited, and learning this skill and perfecting it to develop a correct PCB will be a challenge. For this, we have started with the PCB Fabrication step first, to give us enough time to perfect it with the help of our TAs (if needed). We also feel like there might be a slight challenge in understanding how the hall sensors might work, and distinguishing between individual pieces for each color based on the hall effect sensor. We are working with our TAs and also doing our individual research to get a better understanding of Hall Effect sensors. We plan to tackle our weak spots for this project initially, thereby giving us enough time to perfect the project.

In terms of design, we opted out of using chess.com’s public API since it did not provide the ability to make moves during live games. As an alternative, we have chosen to use lichess.org’s API since it provides a larger range of capabilities, such as making moves during a live chess game. We have also started contemplating the possibility of incorporating extra magnets in our chess piece designs in order to distinguish each individual piece in our smart board based on a variety of magnetic field strengths. This would allow us to guarantee the integrity of the board at all times, not just based off trusting the user to place all the pieces where they’re supposed to be.

Our project includes considerations for user accessibility, our main target audience is the community of visually impaired chess players who are seeking to experience online chess with the rest of the chess community. Through our project we hope to bridge the gap between the visually impaired chess players and the rest of the online chess community.