Posted on

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

This week I struggled with getting the C++ setup on my computer. The OpenCV library is not well documented with C++, and despite trying a ton of different OpenCV folders from various sources and different ways to link the necessary files together, nothing seemed to work with sublime. I ended up downloaded Visual Studios and trying a couple of other different resources and finally got it set up. I timed the same fragment of code in C++ and got a very satisfactory result that the code runs about 10x faster than in Python, running in about 0.007s. Given that I used essentially the same functions, the results were the same and I shall not bother reuploading the same images here.

That said, a slight risk factor that appeared is that C++ actually seems to take longer to import the image and resize as compared to in Python. What this means is that we might need to handle the video input carefully to ensure that we utilize the efficiencies in C++.

I am behind time in terms of getting coordinates, but this was mainly due to getting the Design Review Presentation up. Next week, I will be purchasing the camera, and testing with different images to see whether I can get coordinates effectively. The Gantt chart has been updated appropriately.

Posted on

Team Status Update for 10/11/20

This week, the team focused on putting together the design review presentation. Most our time was used towards generating diagrams and finalizing the interfaces (CV and Client, Client and RPi ).

Here is an updated schedule that accounts for the delay caused by the design review preparation:

Posted on

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

This week, I spent my time putting together the Design Review Presentation. I was able to look through multiple LED strip control libraries and concluded that the Adafruit Neopixel library appeared to be organized and compatible with the LED strip and RPi. The Neopixel library comes with general functions that run effects on the LED Strip (rainbow, waves, etc.) and allows users of the library to address each LED’s settings.

As a result of the presentation, the deliverables determined last week will be completed next week instead. 

 

Posted on

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

My task this week was to do some research on AWS and decide what kind of communication protocol we should use between the clients and the central server. I was going to create a server from scratch to handle authentication, and relaying information between clients, but I was doing some more research and AWS has a service called GameLift which helps manage client communication, authentication, and game sessions. I can then add onto the features already provided for the server so that it can store the game state of the boards as well as add any other additional features we want the server to have. This service could help make the central server more robust and probably decrease the latency. I definitely have to do more research on this service, but I think this is a good direction to take our project. In the following week, I’ll work on getting some latency measurements by sending something from a client to the GameLift server and measuring the round trip time to make sure that using this service won’t be a bottleneck for our overall game. If the latency is reasonable, then I’ll work on writing the script that the GameLift server will use and check that information is being relayed to clients correctly. The deliverables next week will be a running central server that accepts multiple clients and relays each of the client’s messages to the other clients that are connected to the server. Schedule wise, I think that I’m going to work establishing the communication between the clients and the main server before fleshing out the client side, so I’m pivoting a bit from the set schedule but I don’t think this should affect our progress overall.

Posted on

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

My goal this week was mainly to put in the purchases necessary to construct the LED (Hardware) portion of the Blokus board. I have been able to get my hands on a Raspberry Pi, Blokus board, LEDs, and power supply.

I made a comparison sheet for different types of LED strips suitable for our project and shared it with my project members prior to finalizing on the purchase. Here is a summary of the findings. We needed to choose between two variations of LED strips, ws2815 and ws2812b. Both have individually addressable RGB LEDs. We chose the ws2815 despite its higher power consumption and price because it is DC12V compatible. One main challenge of having a chain of 400 LEDs is the large power draw (roughly max 120W) needed to maintain consistent brightness and color throughout the strip. With a DC5V only strip such as the ws2812b, power injection at various points throughout the long strip would be needed to maintain consistency; given that most DC5V supplies have low power ratings, we would likely be required to purchase multiple power supplies. This would lead to a messier setup and higher costs. We have purchased a strip of 300 LEDs; if these are shown to work well, we will buy another set of 300 LEDs as we need 400, but the product only comes in sets of 300 (within U.S.).

The purchase took longer than expected to finalize mainly due to safety concerns (overheating, melting parts, etc.) with power supplies. Eventually after a lot of discussion with my team, we were able to find DC12V supply with a high enough power rating (360W) that had decent reviews from previous purchasers.

The parts just arrived today, 10/2/2020. In the following week, I will be setting up the Raspberry Pi, powering up the LEDs, and running some simple programs to control the lights with respect to brightness, color, and consistency. This will help me determine how the Blokus game board will need to be altered to accommodate the lights. The deliverables next week should consist of images/videos of LEDs functioning with the Pi. Schedule wise, I am so far on the right track with the hardware portion even though I am a couple days behind testing LEDs due to the purchase delay.

Posted on

Team Status Update 10-3

The costs for our strip LED was more expensive than expected. We still hope to be within the initial budget, but we will start testing the LEDs we got to ensure the light quality is as expected and that it will be able to partition clearly by squares as per required for our design. We are trying to minimize costs by doing appropriate research before purchase (refer to Nadine’s post on LED purchase) and by buying only a fraction of what we need and do testing before buying more. If the need arises and we are behind time for the LEDs, we will display in software first for testing so that the other components can still proceed in design.

No changes were made to our existing design.

Our schedule changed slightly. Jonathan is still working on image processing code and figuring out the optimal library to use in terms of both interfacing with the other components and speed. Jonathan also worked on choosing the appropriate camera. However, next week Jonathan will probably be working on testing with coordinates and multiple images first instead of camera integration, as that might expose changing camera needs (which is why we are holding off on buying the camera for now). Nadine has done research on the LEDs, Blokus and Raspberry Pi, and purchased appropriate ones for our need. She has also started delving into RPi libraries. Aria is doing research on the appropriate web server to fit our needs. She is also working on figuring out the best language to code in to interface between the different parts.

Posted on

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

According to the Gantt chart we created for this project, this week I had 3 main goals: Figure out code for image processing, Do time testing on stock images and Get a camera.

There is high cross compatibility when it comes to coding using CV libraries. In particular, Open CV is available on both C++ and Python. The first goal I had was to figure out a simple baseline code that could do image processing, and use that to determine which language to code in. According to our research here, we went in knowing that C++ should be faster than Python, but as part of the design process, wanted to test this out for ourselves.

Having bought the Blokus boards in a timely fashion, I proceeded to assemble a stock image to use for testing below. The main goals for this simple test were 1. different lighting conditions, 2. ability to detect both small and large pieces.

The Python result is shown below:

As you can see, Python took almost half a second. Using this information, we are likely going to use C++ moving forward, unless there are integration issues that come up. On the results side, it is good that we can detect pieces accurately, even the smallest one piece. However, this only shades the appropriate colors, and I will need to deal with a video stream, being able to resize images, and figuring out coordinates from a color image. In addition, certain parts of the image appear black, especially the parts that are too dark or too light, which exposes the issue of being able to accurately detect some coordinates later on.

On the camera side, we are looking at a simple Logitech camera. We have not bought it yet, as we do not believe that the camera is our limiting factor. In particular, there is a lot of testing that needs to be done on images, and we need the camera for video stream integration later on only. As such, depending on our needs which might change, we will hold off buying a camera till then. Based on our current needs, even a 240x240p might suffice to determine pixels (since that gives each square 12×12 pixels roughly, which is sufficient for detection).

I am on schedule for most of my tasks, delaying only the camera because we do not feel that there is a need to buy it so early and risk finding potential needs later on.

Next week I was supposed to be doing integration with the camera. However, I will be working on testing with different images first and seeing whether we can get coordinates effectively instead.