Maskin(Simen):

Got to see the 3d prints in action. Found that the bevel gears were not equal to their 3d designed size and didn’t reach each other to connect and spin. I did manage to solve the issue of the missing hub for the stepper motor, although due to size differences from 3d to real life it turned out a bit too loose for comfort (see gap in image). Will need to print a new cog with a smaller hole.

Elektro(Sondre):

This week we had the opportunity to discuss quite a bit of things that we need to sort out before we can start setting up the system, such as figuring out the SPI, motor control etc. Another thing that is crucial for the system in order for it to operate is the power supply. There are a lot of different components in the system, such as motors, microcontrollers, and sensors, that require different voltage levels. With this in mind, a buck switching regulator seems to be an appropriate type of switch mode power supply, since it is both efficient and also has a rather simple design. The buck switcher reduces the voltage input down to a desired voltage level on the output. I do recall learning about this type of voltage regulator, but I’ll need to refresh my knowledge on this since it’s been awhile, and I haven’t tried it in practice. 

Another thing is the voltage difference between the I/O-ports of the Arduino and the Raspberry Pi. The Arduino uses 5V on its pins, while the Raspberry uses 3.3V. I haven’t quite read into it yet, but maybe a simple voltage divider is sufficient in this case. 

For next week, I have to get an overview over every component in our system so that I’ll know how much power the system needs, and the different voltage needs. After reading up on the voltage regulator, a sketch of the power supply can be made. Lastly, I hope that we’ll get started on the SPI next week as well. 

Data(Azim):

This week i finished the python scripts for image processing with OpenCV, and Bjørnar got our custom object detection model up and running. So, when we met during our weekly session we could compare the different sub projects and present it in front of the group.

What we deduced from comparing was that using the image processing algorithm, the program was very fast. However, it was not 100% reliable and the camera had to be placed in a perfect angle because any juggling would make the playing cards unrecognizable. 

Comparing this to the custom object detection model, we found the model more reliable and also able to recognize the cards from different angles and backgrounds. The one downside was the fps which was very low, probably around 1 fps.

Ultimately, the custom object detection model proved to be better suited for our project and is what we will go forward with. Having said that, I recognize that we need to find a solution in order to increase the fps, because as the design is currently constructed, the fps performance will directly impact the overall performance of our project. I therefore played around with the model and realized that maybe the way I labeled the cards wasn’t done in the most efficient manner, so I took pictures of the different playing cards and labeled them all over again, but this time i labeled all elements in a single card, meaning every number and suit that is shown in a single card. Hopefully this, amongst other changes we are discussing will help increase the speed of the model.

Furthermore, I am simultaneously working on the python script for the blackjack game itself. It has come a long way, but there is still a bit of work left before we can apply finishing touches and integrate it with the object detection.

Data(Bjørnar):

This week I managed to get custom object detection models up and running on the raspberry and tested different models. The object detection worked worked way more consistently than our algorithm. The cards could be recognized from many angles on varying backgrounds. The biggest downside was way fewer frames per second. We noticed that even between different models we had trained the fps varied greatly, so we believe we can make it smoother by tinkering with the training of the model. It also seems that a model that had been trained more takes less processing power to run. The reason why I talk so much about the frames per second it that this will directly impact the speed of the machine. If it only manages to find out what card is placed in front of it every 4 seconds then it will take a minute to simply identify 15 cards. 

In addition to the object detection model I looked at how we could connect the raspberry with an Arduino over an SPI connection. I will hopefully get this to work before the next session by testing and talking to Sondre.