Team B0: Seamless Autonotator

Carnegie Mellon ECE Capstone Fall 2022: Vikram Marmer, Patrick Joyce, Ryan Guan

Month: October 2022

Ryan’s Status Report for 10/8
Posted by : ryg500 Ryan's Status Reports

The time in class this week was spent peer reviewing team presentations. While we weren’t able to see the results of the peer review, we saw some good feedback on the hardware of our design. We will be further testing the possibilities with the chess pieces and what we can do to optimize accuracy with the chess pieces.

With regard to my progress for the week, I was able to catch up (from my illness last week) and create a rudimentary website that can take arbitrary notation. One small flaw that I found to be true over my progress (but should communicate with Byron and Alex) is that there is a need for a secondary notation legality check in the web app (following the reception of data in the API). This is to prevent users from sending flawed data to the website as well as allowing the check for errors.

All in all, I am currently still working on adapting the results of Patricks notation into chess notation (caught some bugs from my implementation last week) and should be able to have a demo ready by the end of next week! At that point, the majority of the software work will be done on optimizing the backend of the website for the database.

I am currently on track to complete the project in time, this week was quite productive!

Team Status Report for 10/1
Posted by : vtm500 Team Status Reports

This week, we worked on validating our sensing architecture as well as the chess board PCB schematics and layout. We also worked on incorporating Stockfish’s move generation into our legality checker.

The biggest risks that our project faces are part shipping time and part stock. We are managing these issues by doing schematics and picking parts early as well as by monitoring stock of any components that are low. We are also looking at alternative vendors that may have more stock. One contingency plan is that we can have a list of drop in replacements for certain PCB components. Another risk is that something is done incorrectly on the circuit boards. This risk is being managed by having all group members look over the design before ordering. We likely will have enough money left over to order a second revision if absolutely necessary, but the circuit boards themselves should have room to rework and modify the design.

One change we wanted to make to our requirements is going from simply being able to detect piece color to detecting each piece type using the hall effect sensors. This was initially considered as a change because the initial color detection is not enough to cover all scenarios of pawn promotion. Before we finalize this change, we will do more investigation into magnet choices to ensure this is possible. The cost of this is that we will spend a little more money buying components that may not be on the final product. This cost will be mitigated by saving extra money on PCB components where possible.

We are largely still on track with our original schedule.

Patrick’s Status Report for 10/1
Posted by : pjoyce Patrick's Status Reports

Earlier this week, I decided on using Stockfish’s legal move generation and spent time reading through the Stockfish source code and understanding the interactions of different structures and functions. I worked on incorporating their move generation into my legality check program, and will continue on this next week. Also, I decided to store moves as piece source and destination squares in the legality check to easily interface with Stockfish. The current plan is for Ryan’s database/web code to translate these to notation. This leaves me on schedule for the legality check and firmware development.

Our test batch of magnets and sensors arrived on Thursday, and I tested them with Vikram today. We tested 7 different types of magnets with the bimodal hall-effect sensor. The resulting output voltages are shown in this table.The bimodal sensor outputs 5V for a high strength magnet. As you can see in the chart, our highest strength magnet only resulted in a 3.4V output. We learned that our calculations for magnetic field strength at a small distance from the surface gauss and the height of the magnet were above the real quantities. From this, we know we have to find some stronger/larger magnets to buy if we want to distinguish between piece types. We should have an order in for those by Tuesday, and can do some preliminary tests with them inside the chess pieces next weekend.

Vikram’s Status Report for 10/1
Posted by : vtm500 Vikram's Status Reports

This week, I first designed and milled out a test PCB for our hall effect sensors. While waiting for the sensors to arrive, I began working on the schematics and layout for the actual chess board PCB. Schematics are nearly done, and layout has been started. While designing the chess board PCB, I began looking at costs. To lower costs, we will create the board from 8 duplicates of the same PCB that is large enough for one column or row of the chess board.

Once the sensors and test magnets arrived, I soldered the sensors to the test PCB and worked with Patrick to verify that our magnet choices will work for this design. We found that the diameter of the magnet mattered more than expected in comparison to the strength of the magnet. The results mean that our plan for sensing the color of the pieces will work well, but sensing piece type in addition to color may not work with our initial magnet choices. However, physically larger magnets (not necessarily stronger) are available.

Given this progress, I am back on schedule. However, I do have a large chunk of work set for the next week, so I will have to plan well in order to not start falling behind.

For the next week, I plan to have the chess board PCB and the BOM ready to order.

Ryan’s Status Report for 10/1/2022
Posted by : ryg500 Ryan's Status Reports

While the majority of this week was spent drafting up slides for the design presentation, I was able to spend some time designing and testing the latency for notation.

Fortunately, since the legality checker is done in C++, that section’s latency requirements were easily satisfied. On the other hand, while python is a much slower, interpreted language, the latency requirements for uploading to the website are much more lax, and as a result, the python string parsing and upload times still fit within the 2 second window outlined at the beginning. The only latency left is the

Unfortunately, I have fallen a little behind with some of the basic website work and want to catch up next week. I spent much of this week sick with an unbearable sore throat and cough. I am only now getting better and should be able to attend class, participate in team meetings, and contribute more actively. My next week is much more free and will allow me to make significant progress catching up to the work that my teammates have done.

Next week, I want to finalize the frontend of the website, and be able to add new games, delete old games, and upload chess moves (notation to the website). I also will be communicating actively with Patrick to work out some of the interfaces that my code has with his legality checker.

Recent Comments