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

Edison Aviles’s Status Report For 04/22

This week I mainly focused on the fabrication of our PCB. I was able to manufacture and finalize testing on 3 out of the 8 needed PCBs. We were able to use a custom made stencil in order to accelarate the process of applying solder paste on our PCB before installing our surface mount components, however it still proved difficult since very tiny solder bridges were forming between our mux pins. I was able to fix some of the PCBs which had this issue and I wasalso  able to finish soldering the through hole components. I wrote a basic script which looped through all the channels of the PCB’s 8:1 mux and held magnets close to each sensor to ensure the sensors were working as expected and the mux was outputting the correct voltage changes.

Although I wasn’t originally assigned to work with our PCB’s fabrication, I decided to help Juan to potentially start integration of the entire system a little sooner. As for my personal schedule, the communication of the entire system is essentially complete. We are missing some minor details that will hopefully be resolved once integration begins.

For the following week I will continue helping with our PCB fabrication as well as begin integration of our hardware and software systems.

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 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

Edison Aviles’s Status Report For 03/18

This week I worked alongside Mukundh to make progress on both the hardware and software aspects of the project. I utilized a large portion of the JavaScript code written to communicate with lichess.org from our web application, in order to communicate from our move validation script with lichess.org. I setup some of the endpoints that we will later call from our python script once moves have been validated. Mukundh and I made modifications to the existing python script to communicate with the JavaScript code and vice versa. We drew out some diagrams in order to better understand how we want information to flow and case based on the current chessboard state. This helped us understand our needs and better approach challenges that arose as we worked on the code.

Furthermore, I worked closely with Mukundh to debug, setup, and test our hall effect sensor circuit. We wrote a basic arduino script to measure voltage drop across and LED based on the polarity of the magnet and distance from the magnet to the sensor. I also setup two parallel circuits on a breadboard in order to test for sensor sensitivity, that is if the surounding sensors would pickup noise or the magnetic field on the neighbording tile. In order to accomplish this I simply measured the distance between the sensors to be 2 inches – which is the size of a tile, and varied the distance between the magnet and sensor. I found that after 0.5 inches, the sensor was able to detect a change in magnetic field and the voltage across the LED varied noticeably.

In terms of schedule, right now we have been able to start picking up on a lot of the areas we had originally fallen behind. With most of our basic sensor testing done and a better understanding of our hardware needs we hope to make large strides on our chessboard next week. On the other hand, with respect to software progress, we hope to finish most of the scripts by early next week according to schedule.

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/25

This week my main focus was to combine the concepts I was working with last week to display a live and interactive board on the website. This was a difficult process since I wanted to avoid using any unnecessary APIs since it would require reading more documentation and familiarizing myself with more libraries. However, after hitting a wall and not being able to figure out any way to embed the live game into our team website I decided to look into different chessboard APIs. I came across Chessground and Chess.js – Chessground is able to display an interactive chessboard on your website and Chess.js is able to add functionality to it. After learning how to create a pretty basic working chessboard I began learning how to incorporate lichess.org API calls to create a live copy of the actual lichess.org game. In order to accomplish this I establish a seek stream, which updates the page once a game is found by passing the unique game id into the page url – which I can then access. After accessing the game id I can establish a stream of all the moves being made on that specific game. I could then make moves on the local board, POST that information to lichess and wait for the opponent to make a move and then replicate that move on the board. The state update is limited to 500ms given lichess’s latency limit, so there is some slight lag between the live game and the game displayed on the web application, but it’s not very noticeable and we had already accounted for the limit in our system requirements.

I also contributed to project management by reevaluating the schedule and establishing weekly to do lists to keep track of what needs to be accomplished on a week to week basis.

Right now, I’m not behind on the web application process – I’d say I’ve made a lot of progress on this specific portion of the project. I do need to solidify some basic parts of the website, however I feel by focusing on board functionality and communication with live games I’ll be able to allow the rest of the team to progress and integrate while I finish portions of the UI and user experience.

I want to finalize all of the play game functionalities – seeking a game against a live opponent and seeking a game against a computer. Moreover I want to add the UI for the play game page and finalize implementing the mobile view designs. I would also like to start testing communication between RPi and web application to have a concrete idea of what has to be done once we return from spring break. I want to focus on making as much progress as possible on the web application before leaving for spring break since I do not plan on working that week.

Video of current state of board:

https://drive.google.com/file/d/1umWu0pNsFbKbg3nYzfbZqnBq-ESkGbsc/view?usp=sharing

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

Edison Aviles’s Status Report for 2/11

This week, my main goal was to conduct research on the API’s we plan on using in our project’s design. We had originally planned to use chess.com as our chess API, but upon reading the API’s documentation we quickly realized that it wouldn’t be viable since chess.com didn’t allow for POST requests for moves to be made in live chess games. Upon more research I came across lichess.org. After thoroughly reading their API’s documentation, I found that their API would be perfect for our project. Lichess.org’s API allows us to do various game specific moves through GET and POST requests, for example we can initiate games, make moves, and even surrender a game through the use of their API. By doing this research before starting to build the full stack infrastructure for our application it’ll allow us to make less mistakes and have a clearer understanding of what to do in terms of API calls.

My other focus for the week was to better understand hall effect sensors and how these could potentially be used to not only identify between black or white pieces, but also between specific types of pieces. I spoke with professor Gary Fedder on a potential solution that uses variations in electromagnetic field strengths to help us identify specifically what piece is placed on a tile. We can achieve this by varying magnet positions in each piece, varying the polarity of the magnets, or even varying the number of magnets in each piece. By being able to validate what piece is on each tile we can guarantee the integrity of the board at all times, even if pieces are accidentally knocked over. This research will help us in the near future while we finalize design plans for the project.

During next week, I hope to finalize designs for the software side of the project as well as starting to implement a local instance of our project’s web application.

 

Lichess.org API documentation: https://lichess.org/api

Hall Effect Sensors: https://www.electronics-tutorials.ws/electromagnetism/hall-effect.html