Category: David’s Status Report

This week I wrote and presented the final presentation. I also worked with Jason to debug the software. We also added more functionality to the website. The bugs surrounding displaying the score are now gone and we can now conditionally display cards based on the client’s role. For example, player 1 can only  view player 1’s cards and everyone else’s cards are rendered as an image of the back of an uno card. We moved everything to socket events to make everything more uniform and to avoid refreshing the page ever. This is to preserve the state.

I am on schedule. Next week we will work to add state correction as well as add support for variable numbers of players on the hardware (rotate variable amount).

These past two weeks saw a massive overhaul of the code base and lots of breakthroughs on the software side. Jason and I worked together on all of these changes. We finally finished moving over to a fully asynchronous execution model. This allows us to do full asynchronous IO and receive and send input to the website at any time. We also made large progress on the website. We decided to have the server talk to both the uno machine and the users over websockets. This allowed us to both host the server on a laptop instead of the raspberry pi as well as write simple code to handle updates to the game state at any time. We also added features for dealing with illegal user input and dealing with calling uno.We also removed the auto correction feature on a failed card deal as it was causing the arduino uno to brownout due to the current spikes. This is fine as it will just fall back to having a human intervene and fix the dealing failure.

We are on schedule. The plan next week is to continue refining the website interface and also allow for a variable number of players on the hardware side.

Additional Prompt:

There were many things that I encountered during the semester that I had never interacted with before. I had to read the documentation for both the Adafruit Motor Shield as well as the Raspberry Pi camera library. I also watched many videos with Thomas to assist in figuring out the mechanical design. I also looked at a lot of motor specifications and forum posts to find motors that met all of our power and strength requirements. I also learned a lot about web development as I have never designed a website before. I read official documentation, forum posts, and watched tutorials to navigate the muddy waters of javascript and html.

This week, I started work on the website interface. I researched creating dynamic websites using Flask and implemented some basic proof of concept work on the website. Jason and I also fleshed out the new architecture that we will be using for the design which will involve using async queues to pass tasks between the UNO game state, the hardware controller, and the website interface. We wanted all of the tasks to be preemptable so that we wouldn’t get stuck blocking on IO or having to poll the website/state for updates. If this new architecture doesn’t work, we can switch to an interval based polling model that does all the polling that needs to be done at the end of a certain time interval. Lastly, I also updated the card dealing routine to automatically retry on failure (this uses the ir sensor we just bought to check for a card leaving the dealer) and eventually wait for human intervention if retries also failed. This allowed us to continue the game smoothly even when a card does not deal successfully.

I am on schedule. Next week I will work on implementing the website and the interface between the website and the UNO game state.

 

For verification and validation, alot of tests have already been done.

On the hardware subsystem, all of the testing was dependent on having working drivers for the motors so that we could deal 1000’s of cards and also rotate the platform many times. We checked the error rate of dealing as well as how much error we accrue when rotating. These tests correspond to what we have laid out during our design presentation. We also timed the latency of these actions and they are not far off from our limits that we set from the design presentation.

In terms of the hardware controller software on the raspberry pi, this was tested by integrating with the entire UNO game state and playing many hands of UNO. This was similar with creating and running separate subsystem tests for the hardware controller as it was very easy to tell which subsystem was failing when we just played UNO. If a certain move would cause an error, then we knew exactly which function was erroring out. For the keypad, I did test this separately to make sure all of the pins were configured correctly to avoid damaging the raspberry pi. This testing also served as validation for the entire system as pretty much everything except the website had to work for the UNO games to run correctly.

The last thing we need to test is battery life. We have not done formal battery testing but we plan on simply playing uno and timing how long it takes the battery to run out and making sure it is greater than the target of 1 hr. However, in our informal tests of simply having the machine on battery as we develop with it, the battery life seems well within our requirements.

This week, I fully implemented the hardware interface for UNO. We were able to start testing full UNO games using the machine this week. We ran into several weird bugs involving the TkInter based GUI and the hardware IO as the GUI stopped working once we switched to using the hardware controller. Jason and I finally fixed this issue after we forced the Tk display to update in a blocking manner instead of non blocking as usual. Also, our current implementation relies on blocking IO which polls the various buttons and serial interfaces. We started switching this over to an async approach which spins up another thread to do the polling. Also, the issue with the GUI should go away once we switch to a website interface which will have its server running in a different process.

I am on schedule. Next week I plan to finish switching the code over to non blocking IO and to start work on the website with Jason.

This week, I collected a lot more data for the model.I took and labeled over 700 images.This was instrumental in increasing the accuracy of our model which now works great. I also assisted Thomas with testing the new card dispenser. After our testing, we realized that it’s basically impossible to avoid cases where 2 cards try to come out at the same time. Thus, we decided to change the card dispenser to just let the 2 cards out instead of having them jam the dispenser. This way, it’s at least very easy to recover from a fault.Lastly, I worked on implementing the uno hardware controller. I implemented the various commands that need to be sent to control the motors as well as doing the stuff to capture images and send them to the uno simulator. All code and labels for the images are in the git repo.

I am on schedule. Next week I will work on finishing up the hardware controller and starting work on the website.

This week I generated the data set for the card classifier. This involved taking around 500 images and then hand labeling all of them.I also worked with thomas to continue fiddling with the card dealer. We finally found a setup that gives us pretty consistent results.

I am on schedule. Next week I will integrate my code to control the machine into Jason’s UNO controller interface that he has created to make it simple to have the UNO controller code also interact with hardware. I also need to write drivers for the number pad that we are using for user input.

This week, I worked with the group on writing the design report. Besides that, I finalized the motor drivers for the arduino as well as the interface between the arduino and rpi. There are now commands for dealing a card and rotating the platform an arbitrary amount of steps. The rpi will wait for the arduino to send back a “done” message to ensure the two microcontrollers stay synchronized. I also wrote code for data collection for the card classifier.

I am on schedule. Next week, I will work with Jason on generating the card classifier data set as well as implementing the interface for the hardware controller. For generating data, generating images of the bottom is very simple as dispensing cards is automated. However, generating images from the top is more tedious as we need to manually place each card so we cannot automate the data collection process. This just means we’ll have to spend some time taking pictures.

This week saw a big step forward in the mechanical side of the design. I wrote drivers for the servo and dc motors for testing. We got the rotating platform working along with the stepper motor. We are getting a smooth and consistent rotation. We also got the card dealer working as we were able to use the dc motor to push the cards out with enough speed. We were unable to test automated card extrusion as the gear for the servo motor had not been printed yet. However, we were able to test just using our hands to turn the roller and we can test the servo motor tomorrow as the gear is now printed. We have attached videos in the team status report showing the subsystems working. I also tested the white LED’s we bought for lighting inside the chassis for card classification and they work fine. Lastly, I started working on the event loop that the raspberry pi will run during actual operation. I planned out the functions we will need to add as well as the control flow of deciding what to do on each turn.

I am on schedule. Next week I will work on finalizing the camera drivers and start automating data collection for our ML model. I will also work on fleshing out the event loop and modifying the UNO software implementation.

This week all of the parts arrived which allowed me to start testing the drivers for the motors and cameras as well as testing the batteries. I soldered the motor shield pins and got a proof of concept for all motors working. I also was able to get images from the Pi camera and output them to a jpeg file.

I also got UART communication between the Pi and Arduino working which will allow us to send commands to control the motors from the Pi.

All code I worked on this week is included in the UNOmatic repo that Jason shared last week.

Lastly, I tested the batteries and the voltage converter. We proved that we were able to power the motors from the 12v battery and get 5v for powering the raspberry Pi from the 12v battery as well. We also powered on the Arduino using the 9v rechargeable batteries.

I am currently on schedule. Next week, I want to get started in assisting Jason with collecting image data for the card classifier. We will have to decide on an image size and format. The picamera library provides support for outputting images as numpy arrays so that will be our first try. I also will work with Thomas to tune the motor parameters to get smooth rotation and card dealing.

This week I made and finalized the parts list and wrote up all of the necessary information for submitting the purchase requests. Choosing the particular motors was very important as we had to take into account the current limitations on the Adafruit Motor Shield V2. I will formally submit the requests before the end of class on Monday to ensure we can get our parts ordered in the Tuesday batch. I also assisted Thomas in designing the enclosure and fleshing out the card dealing system. I did research on controlling the stepper and servo motors using the motor shield: https://cdn-learn.adafruit.com/downloads/pdf/adafruit-motor-shield-v2-for-arduino.pdf.

I also powered on the RPI 5 and determined that 5V 5A can be supplied through the GPIO pins. This allowed us to finalize the power delivery system to the RPI 5 using a buck convertor to step down 12V DC from the battery to 5V 5A dc output, instead of using a separate power supply which would have required a slip ring in our design.

I am currently on track, and once we get parts delivered, I will be able to start implementing motor drivers and calibrating the movement as well as getting images using the RPI 5 and raspberry pi cameras. I am most heavily prioritizing getting motors power on so we can test if our gear system for rotating our platform is sufficient as well as estimate battery life.