Team AC: Smart Chess board

Personal Progress

I was able to get the pi to sweep across several sensors with a mux for the demo. Professor Mai asked us to figure out how fast the pi can sweep through the sensors so I will work on that next week. We did encounter some inconsistency in how the mux worked during testing before the demo. Sometimes it would work and other times it would just read garbage from the sensor. I will try to solve this problem by figuring out how fast the pi can read from the sensors and make sure that we are giving the system enough time to switch between inputs and read correct values so that we don’t run into this issue in the future.

We ordered the 7 segment display and a new pi, so I will also being working on the smart clock and connecting the other pi for remote play as well.

Schedule

I was hoping to start looking at connecting the two pi’s right now but as long as I start next week, we will be able to stay on track.

Deliverable

I hope to have the time measurements for reading from the sensor done by next week. I also hope to have the code from reading from the full array of sensors done because I only wrote code for the smaller array of sensors for the demo. I will also start looking at the smart clock and connecting the two pi’s.

 

Austin and Chris have been working with the physical components of the electronics, namely the Raspberry Pi and the senors and magnets. Hopefully we’ll have some circuit read for our demo this upcoming Wednesday.

I’ve been mostly thinking about high level software architecture. I don’t think writing the game loop from scratch is the correct way to go, so I’ve elected to take a full fledged application and modify the inputs to our needs.

Risks

The biggest Risk is still integration. Personally, I’ve spent more time researching than developing in order to ensure that our software architecture is in as best of a place as possible. Austin has worked around the lack of circuit components in order to make progress in constructing the circuit and interacting with the Pi.

There’s been minor changes in the circuit components. The most major changes have been my numerous decisions on the software side. There’s a risk of analysis paralysis on my end, so by the demo Wednesday I’ll have to have a decision nailed down.

Changes to Schedule

None at the moment. We’re roughly on track baring any catastrophic miscalculations.

 

Personal Progress

I’m currently working mostly on the demo for next week. We received feedback that an appropriate demo would be a small grid and moving pieces that could be detected by the sensors. This past week, we were able to sense inputs from several sensors and determine the threshold that represented if the piece was present or not, along with which side the piece belonged to based on the polarity of the magnet. I’m still working on modifying my code to interpret the changes on the board in an array form and output a string that displays which piece was moved. A stretch goal for the demo would be to integrate my software with the gui, so we are working on that as well.

I have also started looking at methods for connecting the two pi’s. I’ve been running into issues configuring static ip addresses so I will continue looking at this over the next few weeks.

Schedule

Our demo is scheduled for Wednesday, so I am trying to get the pi code to translate the sensor inputs to a readable output by then.

Deliverable

For the demo code,  I want to make sure that it can be scaled for the final demo. So I want to create a standard method of switching inputs that can be modified for an increased number of inputs.

I discovered later last weekend that I ordered surface-mount muxes instead of breadboard-mount muxes, and that the breadboard-mount muxes are actually significantly cheaper.  Since our parts orders go in on Tuesday and Thursday, I went ahead and waited until class on Monday to talk with Anthony to make sure I didn’t mess up a parts order again. As a result, I am still behind on the full muxing.  However, I was able to get the appropriate capacitors from the 18-500 lab, and went ahead and made a circuit with multiple wired sensors at appropriate distances so that the magnets wouldn’t trigger the further sensors. I then wired them all through the ADC (which takes 4 inputs) and Chris was able to read across them from the pi.

I was really hoping the order would make it by Friday so I could spend the weekend soldering some of our actual squares that will go under the board, but it did not make it in before the weekend.  I previously put in an order on the same website with the same shipping option that arrived on Thursday, so I didn’t choose to go up, but I saw on the news that a mercury spill temporarily shut down a USPS shipping location in Pittsburgh, so I’m assuming that’s what caused the delivery to take longer this time.  Since our demo slot is Wednesday, I am hopeful that maybe I will be able to get them Monday or Tuesday and add in muxing and/or actual soldered components by the demo. In addition, I’ve been attempting to design some basic LED functionality that will not be representative of the actual LEDs we use in the final project, but should be able to show a proof of concept by the demo.

Over the last two weeks, I’ve been focusing on fleshing out the software architecture of the project. I spent some time thinking and coming up with how I would implement the project from scratch. I then went and searched around the internet for ideas similar to my own.

We switched from Using Stockfish, to Using python-chess, to using PyChess. I decided that the path of least resistance was to take an existing chess application, and add “hooks” and override the input events to it instead of using just a chess library and rolling our own gameplay flow implementation.

This will give pretty much all of the functionality we need, along with additional flexibility to roll our own implementation later on if we need to.

Austin Milford-Rosales

Status Report 5

 

This week, I intended to get multiple squares working together and begin the process of integrating them into the sensor board.  Chris and I were able to integrate the ADC and then read data through to the Pi. However, I messed up and got surface-mount muxes instead of breadboard mounted ones, which meant when they arrived and I wanted to get a partial board assembly on the breadboard, we were unable to do so.  Our ADC can handle up to 4 different inputs, so from that angle, we can do a very limited demo, but otherwise we will have to wait until the replacement part order can arrive to actually continue with implementation. This is putting us behind now, and I’m going to have to have to drop in some solid hours in next week to make up for this delay.  Fortunately, I just took my last test (before the final) in one class and just wrapped up a project in another, so I will have more time than normal next week to work on catching this part up.

Risks

The most significant risks to the project are if the code to read data from the sensors isn’t completed on time or if the sensors aren’t able to correctly determine whether the pieces are on the board. These components are critical to the project, because it would be bad if the game isn’t able to correctly detect where the pieces are.

To manage this risk, we have been working quickly to test individual components. We just confirmed that the hall effect sensor can work with the pi, so we will start to add additional sensors with a multiplexer to prove that the system can correctly read inputs sequentially from multiple sensors. We are looking at alternative options just in case certain components don’t work or function differently than hoped, but the general idea is to work quickly so that we have enough time to address issues should they come up.

Changes to System

None

Changes to Schedule

None

Personal Progress

We were finally able to get the hall effect sensor connected to the raspberry pi. There were a few hiccups on my end with getting the pi set up and the necessary modules downloaded, but we we were able to get it done. The pi can successfully read inputs from one sensor. The next steps will be to add more sensors, connect them to a multiplexer, and read from them sequentially. Ultimately, the pi will have to read from an array of sensors that represent the individual pieces of the board. I hope to have the code for reading the array of sensors done by the end of the week.

I tried to get the pi to run headless without a monitor or keyboard so that I could work on the project anywhere, but I ran into issues with configuring the pi and had to table this until a later point. I have access to monitors and keyboards in the ECE labs as well as at home, so this should be fine.

Schedule

We are slightly behind schedule because there were a couple hiccups with setting up the pi, but it is good that we were finally able to get that done. As long as I stay on track and complete the code for reading multiple sensors soon, I think we should be good to stay on schedule.

Deliverable.

I hope to have the code for reading from the array of sensors done by the end of next week.

Relatively slow week as I’ve been sick for the last few days. Not having classes will provide some much needed R&R to catch-up and get ahead of the work we need to do for the rest of the semester. I don’t have the Pi so an end-to-end system will have to wait until next week.

I decided that our debug gui would just be a svg image generated by python-chess. The board doesn’t need anymore complexity and python is a language that we all should be able to write in. Our gui would just need to loop at 60 hz to output any change in signal that the ADC read loop would pick up. A 8×8 overlay of voltages is pretty much all we need and I hope to quickly mock this up over the next few days.

Personally, I’m behind were I want to be. Ideally a hello-world would have been completed by this week. Since I’m the most experienced member of the team, it falls on me to hash out the ambiguity of the implementation.

This next week I hope to put a skeleton project together that Chris and I can add to.

 

The design review document forced us to flesh out more of our design. In retrospect, we probably should have spent more time drafting the report.

The most significant risk ATM would probably be the integration of all the components. I (David) will be spending sometime this break mocking up an end-to-end skeleton of the project in order to force myself to hash out the specific interfaces and responsibilities between the code I and Chris will be writing after we return to break.

No major changes were made to the design, but I realized while writing the design review doc that the ADS1015 had an on-board comparator for binary comparison. It’s conceivable that we could tune the comparator values so that the responsibility of interpreting the signal change is handled by hardware. This also could provide some de-bouncing capability via its queue function as well.  This is less general, and would be trading software complexity with hardware tuning, so I think our original approach is still sound.

No updates in schedule atm. I (David) should be able to provide a more accurate Gantt Chart for my work in the next few days or so.