Author: dhanna

Personal Progress

I integrated the smart clock into the game and verified that multiplayer and singleplayer works. At this point, we have a MVP of a board with software able to drive the game logic

Schedule and Deliverable

Were on schedule and should be able to demo our board tomorrow

We got the basic board working with my code, and I was able to play a minimal singleplayer game between stockfish and I.

I’m roughly up-to-date with my schedule. Most of the core is integrated and in place for a working singleplayer game, modulo some TODOs: and special cases that I may have overlooked. The GUI is pretty barebones and could have some debug output moved to it instead the console.

The biggest deliverable this week are the final presentations, and poster. Other than that I hope to get to the final TODOs I left in my code like en passante capture and castling.

Personal Progress

Integration is coming along with the sensor code and the QT framework. I spent most of Friday running through a few different implementations for all test code and real sensor code. I’ve been able to simplify the design quite a bit and integrate Chris’s test code. This is proving to be an exercise is dusting off my python and software engineering skills, which is useful.

Schedule

We are on track to be ready for our demo barring any surprises.

Deliverable

Hopefully we will have have our code fully interacting with the sensors and driving the LED’s by Monday.

 

See https://github.com/dhanna11/capstone.

Currently there’s not much to be done on my end.
I have the GUI and basic single player working, with multiplayer simply being a subset of the single player code.

At this point, we need to integrate our code with our hardware. It doesn’t make sense for me to add anymore complexity to our code until we have a basic board up and running.

I’ll see how I can help with making the board in the upcoming week. In the meantime, I’ve been reviewing my UML, and will be documenting our code for the final report.

 

My work is currently located at git@github.com:dhanna11/capstone.git.

Currently I have a skeleton gui running that repsonds to a selected move, run’s a stockfish analysis and responds with a move.

See commit messages and readme for more. I’ll post a more extensive update tomorrow morning.

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.

 

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.

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.

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.