Posted on

Nadine Bao’s Status Update for 10/31/2020

Progress and challenges: 

This week’s goal was to have a full 20×20 LED matrix constructed. The process of constructing the matrix includes cutting strips into sets of 20 LEDs and soldering them together. This step is necessary to form the matrix as the LED strip would not be able to bend and form a second row without wasting LEDs. After each 20 LED segment is attached to the matrix, it must be tested to make sure that it turns on properly. This is done by simply plugging in the power and seeing if all the LEDs still turn on. 

As of 11:00 pm, I have only been able to connect 8 rows which is short of the 20 rows that I intended to have connected. The soldering process is rather tedious as each end of the LED rows have 4 connections. All connections have to be tinned prior to connecting. I have documented images of the process in this doc. The doc will be updated once more rows are added today. 

Deliverables: 

Because the matrix is not finished, this week’s deliverable is 8 rows of the matrix rather than an entire matrix that was scheduled. 

Plan for next week:

The plan for the rest of the day is to continue soldering the rows together to prevent further schedule delays. For next week, a full matrix will be complete and installed into the Blokus board. I will work with Aria on the interface between the microcontroller and client software.

Posted on

Team Status Update for 10/24/20

We are on track for the project so far. Everyone has made substantial progress this week and everything is going relatively smoothly as we all work for finish all the components so we can begin the integrations process. The CV processing is going pretty well as we are able to convert image data directly into data that the game software can process. And game logic software is almost ready so we can begin playing a version of the game without the board. While there were some issues with the RPi, using an Arduino we were able to feed it parameters and light up the LEDs. We also tested what the LEDs look like under the board. So overall, there’s really good progress all around and we all have tasks that we are planning on integrating for the next status update.

Posted on

Aria Zhang’s Status Update for 10/24/20

Progress Update:

This week I worked on writing more of the code for the game logic side of the software. I think I’m deviating a bit from the schedule posted, but I think everything is still on track in terms of deliverables. If a player has a board then they don’t need a GUI for the game and it would probably slow down the game, but I was working on integrating a GUI that displays the board and lets the player put pieces down on the board because I thought that it would make testing easier. This also allows anyone to play our game even if they don’t have a board which is good feature to have. For the GUI I’m using OpenGL which was kind of annoying to set up on Mac and required me to use Xcode since VScode doesn’t support C++ for Mac sadly.  I plan to finish up the game logic by the end of tomorrow, all I have left is to write a simple server that just forwards packets along. The client software code is all written which includes the initial set up which reads in a csv of the 21 pieces supported and generates all orientations that each piece can take which we cache for later so that piece validation and identification can be super quick in-game. The move validation is also written as well as the software that keeps track of the game state. Also as I mentioned before, a GUI was also set up that lets the player choose pieces to place and visually be able to see where they want to place the piece and the GUI also shows the player the state of the board.

Change of Plans:

I wanted to elaborate on the decision to not use AWS Lambda and AWS SQS. I appreciated the feedback from the presentation regarding these two services, and we made the decision to stop using these services because 1) they are not provided in the free tier that students get and 2) our approach changed so now we are only persisting to the database after the game has been ended by one of the clients which means we do not need to trigger a Lambda function after each move is processed 3) the way that I was thinking about triggering the Lambda function would have actually been slower than just accessing the database directly. Overall, the lesson learned from this was that I need to do more research before insisting we should use a certain service, I think I also should have talked to someone who knew more about these services and I’ll be sure to do that in future cases.

Also another change of plan is that we’re going to use MongoDB because I’m more comfortable with it than Dynamo. I think I was really pushing for Dynamo before because it’s an AWS service and I thought it would be more compatible with EC2, but after a talk with Jiaqi, he recommended us to use whatever we are more comfortable with.

Also instead of using 2 ECS instances, one for the game manager server and one for the game session servers, we’re only going to encapsulate both in  one ECS instance. The plan is that the game manager server will be the first thread in the process running on the ECS instances. It will have a socket that listens to connection requests. When it’s received enough connections, it will then spawn another thread and pass the connection sockets for the group of players that want to play a game together, and this thread will be the game session server for that instance. This is a way simpler approach in my opinion and I think it’s a good change to make so that we can have a more robust server.

Deliverables:

Client Game Software:

  • Game Logic
    • Loading in pieces from csv
    • Piece orientation generation
    • Piece validation
  • GUI (OpenGL)
    • Display current board
    • Allow player to place pieces – they get a preview of the piece before they click to place it

Plan for next week:

I’m probably going to get this done by the end of this weekend, but I want to write the simple server and make sure that the game works well. I can play a game of Blokus and make any fixes.

If everything with the game logic looks good, then I’m going to move onto making the server more complex, like beginning to write some code for the game manager, since the “simple server” model I described above is mainly going to be the skeleton code for the game session server.

Posted on

Nadine Bao’s Status Update for 10/24/20

Progress and challenges:

This intention this week was to test out the Raspberry Pi with the power supply and LEDs. The monitor could not receive a signal from the RPi HDMI output. I went through some troubleshooting including altering the necessary fields in config.txt, switching power supplies, and switching HDMI cables, but could still not get it to display on the monitor. I also flashed the SD card multiple times with both Raspbian and Noob. I think these issues are a result of the RPi not booting since the ACT light does not ever turn on.  Because the RPi is second hand, there could be a possibility that it is an issue with the board. As of now it is hard to tell because I only have 1 SD card and 1 RPi to test with. I am using a 5V 3A adapter to power the RPi, so I don’t think it’s a problem with the power. 

To proceed with testing, I used the Arduino Uno as a microcontroller instead. Arduino Uno is also compatible with the Neopixel library, so it seems to be a good alternative especially because the setup has been less complicated (refer to doc). I also made sure to tune the power supply to output 12V. 

The setup process is documented  here.

Also included in the doc are pictures of the setup and an example of how the lights would show through the Blokus boards. Even when one RGB channel is at full brightness there is little bleeding; however, for the light to show through well, the LED has to be relatively close to the board which can lead to concerns of overheating. One solution is to drill holes through each square such that players can have a clearer indication of which square is lit. The holes appear to be necessary as having the LEDs in a confined space could also lead to overheating. Cutting the holes will likely require a rotary tool/ drill. 

Changes in design and schedule:

Installing LEDs into the Blokus board has been pushed back to next week to allow for more LEDs and supplies to arrive. 

Using the Arduino instead of the RPi as the microcontroller may be more feasible now considering I was unable to determine what went wrong in the RPi setup process. 

Deliverables:

The deliverables this week is a working test run of the LEDs (in terms of successful setup and ability to control parameters) as seen in the doc. 

Plan for next week: 

In the following week, it would be ideal to be able to receive the rest of the equipment necessary to fully integrate the LEDs into the Blokus board. Additionally, I will continue to program the microcontroller to light up and stay on based on incoming coordinate input. On Monday, the team will have a discussion to finalize whether to drill holes in the board or utilize an alternative cooling solution.

Posted on

Jonathan Nee’s Status Update for 10/23/20

This week started by getting coordinates out of an image. I did this artificially for now, by having a black dot marked on the top left and bottom right of the board. The current code reads in an image, resizes it, find the 2 black dots, divides the Blokus board into its grid, and scans each one for the color red. The image above shows the transformation after the red filter has been applied, and the left shows the coordinates where it thinks there is a red tile. They match perfectly, and match the original image too, within a decent time. The main issue is that the time currently EXCLUDES the time for imread and resize, both of which are very time consuming. A new method may be needed to get around this issue later, but I will reevaluate after working on camera images. I did a couple of tests under different lighting conditions, and it is generally stable. Progress looks good this week.

I was also supposed to be dealing with external objects like a hand. Dealing with external objects will be done by tracking for colors that are not red/green/blue/yellow/gray, and returning that the image is invalid. That has been done as well already.

There was 1 other thing to work on this week which was camera integration. The camera arrived late Thursday, and I did not get much time to set it up. I will only be able to work on that next week.

Next week, I intend to get the video stream working. The week after that should be integration and we are good to go for the CV side 🙂

 

Posted on

Nadine Bao’s Status for 10/17/20

This week I spent my time writing the design review report.  Unfortunately, that was all there was time for, so I did not get to make progress on the LED matrix board. Next week, there will be no paper due or project deadlines in other classes, so there will be adequate time to work on the deliverable.

Posted on

Aria Zhang’s Status Update for 10/17/2020

Most of the time this week went into writing the design document. This however helped a lot in finalizing a lot of the software communication designs that I was already thinking about. For example, the way that the CV thread is going to communicate with the Game Logic thread was finally hammered out clearly. Also some of the initial designs on the server side was scrapped for the sake of latency and simplicity which was unfortunate since I was looking forward to using some of those AWS services, but in the end it didn’t match up to the goal of the project which is low latency. Next week I hope to have the entire game up and running locally on software.

Posted on

Team Status Update for 10/17/20

No real risks that we have not foreseen that has come up this week, we think we are on a good track for the project so far, the report has really allowed us to flesh out our ideas and thinking behind our ideas more, which has been good in helping to settle some of the smaller details behind the project (e.g. flow for invalid moves). Working on the design report took us longer than expected, but we feel we were nice and specific, and were very thorough in our report. Hopefully you will enjoy reading it 🙂

There were no changes to the design nor to the schedule. Looking forward to another long weekend next week where we hope to get more progress done!

Posted on

Jonathan Nee’s Status Update for 10/17/2020

This week I placed the order for the camera. The end product will need 2, but we have placed an order for one first in case there are issues with processing the video stream.

A lot of the time this week went into the design report, which we are all very proud of. We think it provides a great foundation for our final report, given how detailed we were, and that it would save us time in the long run.

I had no other main tasks for the week, given we anticipated the time it would take for the design proposal, but given I had some spare time I started on the work for next week in advance. I started looking into generating coordinates out of images. I will start by marking the corners of the board with a black marker for gridding purposes, but we can work on that if we have time in the end. Also, assuming we want to detect the color red, given that all we need are the coordinates, we do not really need to do a dilation and mask back for the color red, but just need a black and white contrast of where the color is, so that might be easier to handle. I am also looking into whether choosing pixels directly and sampling perhaps 16 pixels for each tile might be more beneficial, and save time, because as the experiment last week showed resizing is expensive in C++. I will also look into if it is possible to sample nearer the edges where the pieces are more translucent and hence the color difference tends to be clearer. I have already taken the pictures for next week for testing, which comprises half valid new moves and half invalid moves.

Next week, I hope to be done with the coordinate system, and get started on video processing!

Posted on

Aria Zhang’s Status Update for 10/11/2020

This week I mainly worked on fleshing out the architecture of the software part of the capstone project. This involved a lot more research into AWS. Ultimately, I decided against using GameLift Servers as the functionality that it provides is not necessary for the scope of our project, and I was worried about the added complexity of using that technology. Based on a comment that our team got for feedback from the Proposal Presentation, I looked more into finding a way to reduce the latency of storing board piece information in the database and I think we’re going to use AWS SQS for queueing piece information and then adding a AWS lambda trigger for when a message enters the queue, which will update the database. This will help reduce the latency for updating the database which was a concern mentioned in the Proposal Presentation. I also worked on the design presentation, mostly creating diagrams for the system architecture.