Month: March 2019

Personal Progress

The design review report took a lot of time. I realized that this was really the first time that I had to fill out extensive design documentation like this. There were segments in which I realized that I was repeating myself or not really answering the question to the level of depth required, so I had to revise the sections that I wrote sometimes, or Austin and David helped me. Writing the report definitely made me think more about the details of our project and how everything would come together, so it was a helpful process.

We realized that we hadn’t ordered an SD card for our project so I ordered one to my home and it should arrive soon. Once I install the OS, I plan to set up Ethernet communication with the pi for ssh, make sure that python runs smoothly, and start looking at code for reading inputs from the sensors. I hope to have all this done before the end of spring break.

Schedule

After I set up the pi during spring break, I hope to start looking at code to read inputs from the sensors. Once this works, I’ll start looking at controlling the muxes with the pi. The plan is to switch between reading from two sensors by the end of the week that we get back from spring break.

Deliverable.

By the end of spring break, I hope to have the pi set up for all the things that we need in the future like python, ssh, ethernet, etc.

Personal Progress

I spent a lot of time working on our design review and talking over some major design choices for our project. After meeting with Professor Mai, we were thinking about creating a hardware accelerator for stockfish. We determined that this would be too much for the time that we have. After that, we carefully looked through all the things we had to and shuffled around the responsibilities. The reason why Professor Mai thought that we should pursue a hardware accelerator is because he wanted more complexity and he thought David should have a bigger chunk of the project. I was struggling a lot with understanding the requirements for the GUI and selecting a suitable starting point, so I decided to turn over that portion of the project to David. I decided to take on David’s original part of the project, which was reading data from the sensors through an ADC, and converting them into a format that the GUI can recognize. I’m also taking charge of the networking portion of the project, which will allow us to eventually connect two physical boards to simulate playing remotely with a friend. This will consists of two pi’s connected via ethernet and running a master-slave model. David came up with the idea of a master slave model, and it means that one master pi owns the game state and logic, while the other slave pi simply feeds inputs into the master pi. I definitely think that these parts of the project better fit my strength and interest in embedded systems so I look forward to it.

I was also responsible for giving the presentation this week. That was a good experience and I hope to incorporate the feedback into future presentations I give. An important point from the questions was that UCI, the communication protocol that we are using to communicate with our chess engine stockfish, doesn’t require different strength magnets because it only takes in positions and assumes that the user started the board in the correct configuration. This is a point that we’ll have to discuss as a team. If we keep the different strength magnets, this will increase the complexity of my code as I will have to keep track of the different strengths. I’m hoping that we can stick to one magnet, so that we can put more effort into the gui and the networking portion, which I think will be more interesting.

Schedule

We’re a little behind schedule because of all the changes that we made during the design review. I hope to have a simple test for the sensor done before we go off to spring break, so that I can start writing the software for the entire sensor array when we get back.

Deliverable

I hope to have an update on the simple sensor test before we head off for spring break.

 

One of our top risks right now is the functionality of the hall effect sensors.  They arrived this week and Austin will be running tests with them tomorrow.  He discovered that he may have made a miscalculation in regards to the magnet strengths, so there is a slightly higher risk going into the testing that we might have to redo the squares.  He went back and did some more calculations to determine the next best magnets to get if the ones we got don’t seem to work.  In addition, we have begun to explore the possibility of keeping track of pieces in the software, based on the assumption that the users set up the board correctly at the beginning of each game.  Because this would greatly affect the complexity of the project, we are currently considering it as a viable back-up if the sensors struggle to differentiate between the different pieces, and will have a further update on this next week.

Currently the FPGA work is on the backburner. David will focus most of his attention towards getting the basic board up and running asap. The stockfish integration is still being hashed out, so depending on these next couple of weeks, we’ll have a better idea if its a feasible goal. The evaluate function of stockfish is the most computationally expensive in terms of CPU time, so that would be the first place to start accelerating stockfish specifically. This is a place that other accelerator’s have neglected, so it would be a relatively novel implementation.

Since we ended up reversing much of the changes we discussed last week, we are back to looking towards a very similar schedule to what we originally discussed, and are planning on sticking to the schedule that is on our presentation.

I put FPGA acceleration on the backburner for now. I’m hoping to use my time doing my research with Professor Lucia as a way to get some early experience using the fpga board I currently have in possession. Currently, my time is mostly concerned with how exactly we lean on stockfishes functions. Using dead reckoning with the magnet’s is the simplest (and therefore probably correct) idea. But then the magnet circuit becomes a somewhat glorified RFID system.  My oversight of the stockfish integration with the multiple magnet levels concern’s me to be honest. I feel like my novelty seeking behavior caused me to ignore parts of our project. I’ll need to put in more time thinking about our design.

Schedule

We’re on schedule. My task list is probably a little conservative and needs to have dependencies with the sensor input. In the meantime I have a good understanding of Stockfish’s high-level architecture, so I should be able to knock out a significant amount of tasks and help my team mates.

Deliverable

I want a full end-to-end test running on the pi by the end of the week, hopefully incorporating some jury rigged sensors.

Status Report

Austin Milford-Rosales

 

My primary goal at the front end of this week was to finish the hardware sections of the slides and effectively communicate that knowledge to Chris (our presenter) to make sure that the presentation came out well.  After starting work on them last Saturday, I continued on Sunday, making the block diagram in powerpoint (since my hand drawings are pretty bad and revising slides to communicate our goals more effectively.

In addition, we spent a fair amount of time working on finishing the definition of our project.  The previous week, Professor Mai had suggested adding in some FPGA acceleration of portions of a chess AI.  We held a prolonged team meeting sunday before we did our final edit run of the slides to determine the feasibility of that addition, and ended up deciding against implementing any FPGA component in the project.

After our presentations, I began doing some work on the design document, and reviewing some of my previous calculations.  Our first parts arrived, and I have laid out the kinds of tests I want to conduct with the hall effect sensors and began gathering materials (acrylic and wood of various thicknesses) to use when testing the parts.  In addition, I found a physics major friend of mine before the parts had arrived and went over my calculations with him, and I found a slight error. Although the magnets we purchased will work, they will only be able to create fields within half of the range that the sensors can detect.  If the sensors are not very precise, then this will cause additional problems, and we will have to order another round of magnets to test before getting all the pieces. I hope to have that determined by Sunday evening.

In addition, after our presentation, another member of the class approached us and mentioned he’d worked on a similar project for another class, and that he only detected the presence of pieces, but not which kinds of pieces were on which squares.  He then had the users affirm that the starting game state was accurate, and kept track of all piece placements in software. We are currently debating whether or not to switch to this approach in our group, and although it would make things much easier, I am a bit concerned it would decrease the complexity of the project a bit too much.  My ability to get the magnet sensors working appropriately over the next week will definitely play a role in our whether or not we switch our approach to this aspect of the project.