Category: Uncategorized

This week, I faced an unforeseen hardware constraint involving the Raspberry Pi. Initially, the plan was to deploy our trained card detection model directly onto a Raspberry Pi 4. However, I discovered that the Raspberry Pi 4 does not natively support multiple camera modules. Attempting to integrate two camera modules with the Raspberry Pi 4 would require using a camera multiplexer, consuming approximately 21 GPIO pins. This presented a significant obstacle since our existing design heavily depends on these GPIO pins for other critical functions, and sacrificing them was not feasible without compromising our entire design. Consequently, we could not adhere to our original plan of deploying the card detection model onto the Raspberry Pi 4.

To resolve this issue, we decided to upgrade our hardware by purchasing a Raspberry Pi 5, which inherently supports dual-camera inputs without the need for a multiplexer, thus preserving our GPIO pins. However, this upgrade led to delays, as the model deployment activities were contingent upon using our finalized hardware setup. As a result, my focus shifted from generating deployment-ready models to preparing for rapid integration once the Raspberry Pi 5 arrives.

Meanwhile, my immediate tasks include generating a custom dataset tailored specifically to our hardware environment and training the refined model promptly. Once the Raspberry Pi 5 is available, I will deploy the model to ensure our project remains aligned with our timeline.

Now, we have a complete picture of how the machine will look like. We closely examined the required parts and their specifications more closely to make sure they all meet the design requirements we have set for this project. Admittedly, we did run into some problems due to parts we have bought/borrowed that actually did not entirely meet our requirement. However, we have accommodated those and are ready to build the machine starting this week. That is, unless the extra parts we bought arrive late. However, since there was one week gap for the parts to arrive, it would be unlikely.

As specified in the design report, the final size of the machine body will be a 20 x 20 x 6 cm  wooden box, made by combining mdf plates. The size was chosen after creating virtual images of the assembly as shown above, getting a general sense of the amount of space that would be required for all the parts to fit inside. Although we do not have the dxf file for the wooden plates yet, I am planning on quickly creating those this Monday and hopefully cut them by Tuesday.

Then I will assemble those in to a box and add the caster wheels so that I can adjust the placement of the servo for central rotation. Then, I will add weight in side the box to simulate other parts other than the uno to see if we need to buy a different motor shield to support external power supply or the servo. The one we have currently does not, so it will be drawing power from the Arduino, which is generally not a good idea. However, considering that the load is not too heavy, we thought that the servo may end up not drawing too much current.

In short, it was mostly final polishing of the design plan before moving onto the actual assembly.

We are on track in terms of schedule, and if the servo and the 3D printed dispenser case does not cause any trouble, we will very ahead of schedule by the end of this week (though that would be highly unlikely).

One thing that we failed to foresee is the cost of 3D printing. Whenever there were some parts that seemed ambiguous to purchase or required complex and custom design, we decided we would use 3D printing to make that. However, we only realized later that 3D printing will cost a lot, given the size of the parts we’re trying to print. As such, we would have to aim for reducing the number of trials and errors of printing. Our plan is to make the design as precise as possible to work as we intend it to be. To that end, we’re carefully considering the dimensions of the parts and trying to have a concrete overall design for our parts to assemble later.

No significant changes were made to the existing design of the system. After realizing that adding too much load to the servo may draw too much current, possibly causing problems with the arduino that will be powering it through the 5V line. So, we may decide to use a weaker servo for the dispenser to draw as less power as we can from the arduino, and we are planning to add 4 caster wheels to support the weight of the machine body for spinning.

This will mean additional budget use for buying the wheels, but it is minimal, and we have not used much of the budget so far, so it will be fine.

Motor control code ended early, so Andrew will be helping with building the dispenser and case. Hopefully, the dispenser will be done earlier than we expected.

We have confirmed that the servo works fine. Additional tests will need to be done to see if the 5V power supply from the Arduino will be enough when we add load to it. Such concern was the exact reason why we decided to add wheels to the design for additional support while reducing friction.

This week, I mostly worked on training a pretrained model on an existing trump card dataset. I thought it would be pretty straightforward to make an existing object-detection model (yolov11) to be trained on a card dataset and be capable of detecting cards. However, this was a oversight– the model, after being trained on 8000+ training data of cards, it struggled to perform on the test dataset. I had the plots for mAP50 and a couple other metrics, but forgot to save it on google drive, as I was running on google colab and were gone after I reaccessed it. However, the result was bad and made me think if we would need a model that is capable of classifying cards on general purpose. I instead realized that it would be a lot better for having a custom dataset that captures our own environment where the model has to see the card. Furthermore, instead of using a general-purpose pretrained object detection model, I realized it would be even better if I use a pretrained card-detecting model, then finetune it to be capable of detecting cards in our environment.

My progress is a little behind, since by this week, I wanted to have the trained model deployed on raspberry pi, along with the camera module attached. However, since the time was consumed as why was experimenting with how to train the model, I didn’t have enough time to do that. As such, I’ll have to dive right in and generate the dataset myself and train the model as soon as possible. Also, since I finally managed to borrow a deck of cards from the CMU Poker club, it will be viable to do so.

By next week, I’ll need to have Raspberry Pi that has the card detecting model deployed.

This week, I started working on fine-tuning the latest YOLOv11 model for our card detection task. I’m still familiarizing myself with all the APIs and researching how I could start off smart to later integrate and deploy easily on Raspberry Pi 8GB. Since we have 8GB of memory, I think I’ll have to wisely choose the model that would be the most efficient in terms of its size. My plan was to validate the model working and achieving validation accuracy ~100% by digging and incorporating more dataset. However, I didn’t get to train the model yet, since I didn’t have any Colab compute units. I’ll have to make sure if we are able to include the compute units for the given $600 stipend. By next week, I should have trained and tested the model, and just start thinking and learning about how I would deploy it on raspberry pi. Also, I’ll have to allow the model to receive input video/image from the camera module later.