Posted on

Juan Mejia’s Status Report for 2/25/23

This week was mostly focused on the fabrication of the physical board tiles and pieces. I started designing the pieces from scratch, however Mukundh found existing 3D models and took over the work on Rhino. I designed a test board that has a 2×2 tile design to represent the black and white tiles( see attached picture). There was delay in the arrival of the hall effect sensors because we had to order new ones, so the unit testing that I wanted to do this week, didn’t get done. I have begun setting up the circuit for the PCB, need to call AutoDesk to ask for the correct library for the hall effect sensor.

This coming week I hope to finish 3D printing all the pieces for the board that we need for testing and finalizing the dimensions and design for the tiles and chess pieces. Once the hall effect sensors arrive, I plan on working with Mukundh to do the unit testing and finish designing the row PCB, in order to send it for fabrication. I also hope to get the micro SD for the Raspberry Pi, in order to set up the OS and connect it to our WebApp.

Posted on

Team Report for 2/25

We currently do not have the parts for our circuit, so this has set us back and affected our timeline. We are currently looking at different circuit options to help finalize our circuit. We hope to be able to have our circuit done and ready for fabrication by the end of this week (the beginning of Spring Break) in order to fix any possible mistakes on the PCB as soon as we return from Spring Break.

We have updated our team work assignments to take into account the delay of our hall effect sensors and PCB fabrication. We also had a few miscommunications that lead to the board design and pieces not being printed on time. In order to account for our schedule changes we have moved things around in our gantt chart and prioritized specific tasks. The top priority for this coming week is PCB fabrication, the reasoning behind this was to match delivery time with Spring Break and begin testing as soon as we return. This coming week we have divided up the work as follows:

Edison: Finalize move legality script and  its respective testing script, finish web application board and lichess.org live game communication.

Mukundh: Unit testing for the hall effect sensors, adding braille notation to 3D designs, begin and finalize autodesk design for PCB

Juan: Finish the 3D printing of two board and piece design in order to test for the best configuration. PCB design. Also work on piece vocalization using Raspberry Pi/Arduino

We had no major design changes this week. We had to order new hall effect sensors in order to test on a breadboard, prior to fabricating our PCB. This lead to an increase cost of $16 for the unit testing. The vocalization change cost has not been determined as we might be able to get a free speaker for the Arduino in a kit that Juan has.

We updated our schedule to account for certain issues that came up. We ordered the wrong part, so we had to push our circuit testing by a week, and move certain tasks earlier to account for the delay. The updated schedule has been attached here.

 

Posted on

Mukundh Balajee Status Report for 2/25

For this week, I was able to design our board on Rhino, and 3D print a test piece to make sure our pieces and board were as expected. I was able to access the Stockfish API and use it to generate and play a game.

This week, we had to reorder our Hall Effect Sensors as we initially ordered the wrong parts. This has set us back a little bit, so we were able to catch up on other tasks and get ahead on them to make up for this loss of time.

By next week, we hope to test our circuit and start/send our board for PCB Fabrication. We also hope to have our chess board modeled with Braille notations and spaces for external elements. We also plan on setting up our RPi and uploading our scripts to make sure we can proceed with further development of the accessible features.

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

Juan Mejia’s Status Report for 2/18/23

This week was focused on designing the test circuit in order to figure out the output for the hall effect sensors. The other categories that I focused on were researching the proper components from Raspberry and designing the chess pieces in CAD.  In order to achieve the connectivity, I requested the Compute IO board from ECE resources, but I have found it difficult to find an available Compute 4 Board. I might need to pivot to using a Raspberry 4 Board. For the CAD, I managed to design the rook and pawn pieces manually, but after the suggestion of Mukundh I am going to use 3D models for piece found online. After meeting with Will and Professor Gary, our team updated our schedule for the nest two weeks, so we our on schedule. This coming week, I hope to work with Mukundh to get a understanding of the hall effect sensors and start using AutoDesk for the PCB.

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

We are currently in the process of testing our circuit for the detection of magnetic fields, which is the most crucial part of our project. As mentioned during our presentations, piece detection is one of our big technical challenges. We hope to challenge this task with the help of multiple online resources, which have similar applications to our circuit. As a contingency plan, we think we hope to follow different circuits we have found online, and possibly add modifications to fit our requirements. We have also focused our energy to familiarizing ourselves with the lichess.org API we’re using for our web application backend and have made good progress at implementing some functions that will be necessary in future iterations of our board (i.e. making moves on an ongoing chess game).

Our team focused on two principles of engineering – testability and integrity. We want our design to be easily testable as well as guarantees integrity across the board. We did this by dividing the system into easy to test subsystems to guarantee integrity at each point of the design. By unit testing each component we can then focus our energy into testing the integration of all the subsystems as a whole.

 

Posted on

Mukundh Balajee’s Status Report for 2/18

This week, I worked with Juan and started working on our circuit to detect magnetic fields with the Hall Effect sensors. We decided to try mimicking the circuit on a breadboard, before sending it out for PCB fabrication. We were able to place orders for specific parts we need for our project, and we started working on designing our chess board. We are planning on making the current designs for the chess board, as accessible as possible (for our visually impaired users) by adding braille annotations.

 

Our progress for the project has been on track. We were able to modify our schedule and push our goal of sending out the board for fabrication a couple of weeks later. We instead plan on working on a breadboard, and perfecting the circuit before fabrication. Edison has been able to make a good progress on the website and has it connected to lichess.org currently.

By next week, we hope to be able to print out our board, test our circuits out and be able to detect pieces on the board on our web app (if possible).

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.

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