Common:

We have made some models to better represent our system, what we want it to do and how it should be set up. Physical models showing the main components in the subsystems that they belong in and the different levels of tasks that we want our system to accomplish.

Maskin(Simen):

I did not get to print the parts for this meeting, had to improvise. The motor seems to handle it alright.

Although this is a very, very crude test (¡Improvised!), it shows both the bevel gears work and the stepper motor is functional/speedy at this weight. Action is coming. Continuing the conversion from axle to servos.

Elektro(Sondre):

The buck switcher has a LC filter that helps to smooth out the signal. The capacitor tries to smooth out the voltage while the coil smoother out the current. To avoid using large and expensive coils and capacitors, a high frequency is sent into the transistor which is called switching frequency, which is much higher than utility frequency (?). The downside is that the circuit generates more noise. Since the controller can radiate harmonic frequencies in the form of noise that can affect other circuits in the vicinity, the controller may need to be shielded and may need an EMI filter.  After a quick chat with Dag, it is not necessary to spend time on a power circuit to the system.

Data (Danial):

After receiving the servos from my fellow students, I have tested and debugged the code from last week and the test code. What I found was that it required a slightly different setup on Ubuntu so I had to source the correct map/file to be used in the program.

This week I have set up a publisher and a subscriber. And made a code that allows me to assign a given angle between 0 and 180 degrees that allows me to adjust as desired. To put several servos together, it is easy to just copy the code further and change which pin the servo is connected to. I had to use 3 terminals and Source correct folder so that the program worked as desired. This was a step forward. Now I will continue and make the servos work in a given position, and hard-code it.

Data (Azim):

Me and Bjørnar experienced a setback this week after we met with our group. The object detection model is still underwhelming in terms of accuracy, even after I took hundreds of pictures of the playing cards and labeled them all over again differently. The design as currently constructed, will only show half of the playing card and so the detection must be able to detect the rank and suit from that. The model however, struggles with this. It performs fairly well when it sees the whole card, but not with one half. Me and Bjørnar discussed this and decided to give ourselves a deadline to the next meeting of trying to modify the model so that it can go off one half of the playing card, otherwise we must make changes to the physical design, because we can’t afford to use more time on the model.

Furthermore, I will continue my work with the blackjack script so that when the robot arm is up and running the only thing remaining is the “robot” functions and that will make the integration process quick and easy.

Data (Bjørnar):

We are still having a lot of issues with how we want to detect the playing cards as the object detection models can be slow and more importantly inaccurate. I will until next time just run multiple models so we have different to choose from as backup. It will probably be best to create the final model when we have the contraption set up as we then know the exact circumstances of what the camera can see, the focus and the lighting.
I hope to get the andriod application up and running before the end of the next week so that it can communicate with the Raspberry.