Category: Hang’s Status Reports

This week most of the time was spent wrapping up various parts of my part of the project as well as integrating the different components together. Once Nathan was done training his new engine, I hooked the new engine to the backend server which was pretty seamless since I had an older version of his engine already hooked up. I’ve had to change how I save the game states to deal with captures in an easier way by simply reading in the game state from the physical board, instead of checking for the new move(s) from the read in state. This means that I had to save the board state at each move, instead of saving the move number in each of the board positions. 

For integrating the physical board, there were a few issues I had to resolve in order to get the integration to work. To read in information from the serial port on my Flask server on the RPi, I would have to have while true loop that constantly checked the serial port to see if any new data has been received, however, Flask typically doesn’t allow for this type of structure, so I had to spawn a new thread that did this check. Whenever this thread finds that the Arduino has sent new information, the new information is emitted to the web application via the “update_board” websocket. If the Arduino/physical board requested for a move suggestion, the request is emitted from the RPi to the web application via the “update”board” websocket, the web application then makes a request to the game engine endpoint to get the recommended moves, the recommend moves are then emitted back to the RPi via the “recommended_moves” websocket, and then the Flask server on the RPi writes the recommended move to the serial port. 

I’ve also spent some time helping Israel construct LEDS on the board in order to speed up the integration process.

My progress is currently on track: we’ve tested communication from the Arduino to the RPi and communication from the RPi to the Arduino (verifying info with minicom serial monitor). The only item left is to replace some mux components on the board since they were short circuited.

This week I was working on setting up a flask server on the Raspberry Pi, so that we can set up a websocket for wireless bidirectional communication between the physical board and the web application instead of wiring the Arduino to a computer. I had to spend some time setting up the Raspberry Pi in headless mode so that I could simply SSH into the machine instead of setting up a monitor and keyboard each time, and once that was done, I started moving the websocket code from the original server code into the Raspberry Pi. The image below shows the flask server being hosted on the Raspberry Pi, and the communication between the web application and the Raspberry Pi.

Since we changed the board to accommodate 9×9 games instead of 19×19 games, I had to change some parameters in my code to fit the new board. While I was working on this change, I also added row and column labels into the board, so that it is easier for players to read the recommended game moves when the row and columns are listed. Below shows the new board/ui.

I’ve also added the engine to the backend server, so the backend server is almost completely finished now as it takes in a game state and returns the top 5 moves with the probability of winning associated with each move. The only thing left for the backend server is to update the final weights once our new engine is completely trained.

The progress on the software is on schedule. The only important item left on the software side is setting up serial communication between the Arduino and the server on the Raspberry Pi, but this is currently bottlenecked by the completion of the physical board.

By next week, I’ll polish up some final visual items on the web application, and finish setting up serial communication between the Arduino and the server on the Raspberry Pi.

This week I spent some time setting up a websocket connection for the communication between the Arduino on the physical board and our web application. Since the physical board isn’t fully set up yet, the only thing I can test is the websocket communication. 

In the example above, the client-side is emitting {test: “1”} to the server, and the server simply prints out the message, and emits it back to all clients connected to the socket. The client side then prints out the message it got from the server. Once the board is finished, I can use python’s serial library to read in data from the Arduino and also send data back to the Arduino, and with the server’s websocket, the information can be transferred between the server and the web application. 

I also spent some time trying to figure out how to connect to the locally hosted web application and backend server from a different computer in the same network. It wasn’t difficult to do this since this was already taken care of by React’s npm command. For the flask server, I simply had to add another flag into the run command. In both cases to connect, it would need my computer’s IP address. The reason I spent some time looking into this is because it was suggested that we make the communication between the web application and the physical board wireless. As such, I’m planning on running a flask server on a Raspberry Pi connected directly to the Arduino. This flask server would have the websocket as shown above for wireless bidirectional communication between the board and the web application.

While my progress is technically on track since I’m working on the communication steps now, I had a pretty heavy fever for half of the week, so I didn’t get to work on the project as much as I planned to. The Raspberry Pi component currently isn’t a priority, as the building of the physical board is. I will need to help Israel with the construction of the board, however, by next week, I can still test out running a flask server on a Raspberry Pi.

This week I started working on the backend of the project so that the frontend can communicate with the engine (otherwise we would have to translate the engine code into javascript or set up some kind of hack to run a python script from the React web application). Since the entire project is locally hosted, I chose a simple backend framework with Flask. I ran into quite a few issues with CORs when attempting to make the request from the frontend to the backend, and spent some time adding different headers into my response in an attempt to make it work. After some experimentation, I got the request to work but only when I run the web application from Chrome instead of Edge which is my default browser.

For now, since the engine isn’t fully completed, I’m returning 5 placeholder recommended moves from the backend to the frontend (results displayed above).

My progress is currently on track. By next week, I will have some code for the communication between the Arduino and my web application, but since I can’t really test this out without the board being finished, I will have to help out Israel with the creation of the board to speed up its build process.

As for testing, I will write some pytests to unit test the backend service. For the frontend, I will time the response time for the communication between the frontend and the backend by simply using timestamps (use case requirement is that the response should take less than 2 seconds, engine needs some time to compute moves) and will also include jest tests to make sure that each page renders correctly.

This week, I spent some time making the UI look nicer and got the saved games to display on the site. I created a new page specifically for the saved games (all the routing done with react-router) and added the necessary button and dropdown menu for uploading a file and choosing a move number. I also spent some time making the board interactable specifically for the interim demo because we haven’t integrated the different parts yet, so after the board, go engine, and site are all integrated, I will remove this feature. 

My progress is currently on track. By next week, I will set up a local python server specifically for running the python scripts for the go engine, so that the frontend can make a request for getting the recommended game moves, and the server will return a response containing the recommended moves.

This week, I was working on displaying the saved game states. To do this, I needed a component that would open up a file finder, and it turns out this is a standard component in React called <input/>. After the user selects the file, I have to read in the content of the files into an array. The format of the file contents follow this: tile_type, move_number, and this repeats 361 times (19×19) with the. tile_type either being empty, black, or white, and move_number either being the move number of the tile or -1 representing empty. Since this entire content is read in as a string, I used split to convert the string into an array. I also spent some time looking into the React router so that the site can have different pages as I wanted to separate the page for live gameplay and displaying the saved games.

I’m a little bit behind schedule since I wasn’t able to display the saved game states yet. This is because I had a pretty large project due for one of my classes this week, so I spent most of my time focusing on that project. I’ll spend a little more time this following week to finish up displaying the game states.

My deliverables for next week will be displaying the saved game states,  and getting multiple pages working for the site.

This week, I focused on saving game states. Originally, I wanted to save the board for each move with the recommended moves from the Go engine, however, I’ve decided against this since the text file would be unnecessarily large. Instead, I’ll only save “one board” flattened into an array of 361 (19×19). Each element in the array will either be a tuple of (“E”, -1) or (“W”, some move number) or (“B”, some move number), where “E” corresponds to empty, “W” to white, and “B” to black. I won’t be saving the recommended game moves, instead, I would be reconstructing the board for each move selected to display, and then feeding that board state to the Go engine to get the recommended moves. While this will take a little more processing time for displaying the history of games, it’s worth the memory cost of storing large games/games with many moves.

My schedule is on track as I’ve finished saving game history. By next week, I should have the feature for displaying game history done.

While I have some frontend/UI experience as I have done a full stack internship before, most of my work was in backend. For this project, almost all of my work will be with React/frontend, and I’ll be creating new components with CSS which I haven’t done before. I’ll also be looking into how to do serial communication between the web page I’m creating and the Arduino board for getting the game states with Web Serial API.