Maskin (Simen):

Continued the design of the servo compatible parts for the arm. Trying to find a way to print these parts. Also making a way to place a spring into the hand to keep the cards under pressure, while also needing to make sure only one card is ejected at a time.

Elektro (Sondre):

This week wasn’t the most productive week since a lot of the group was quarantined and myself was placed in isolation at a hotel here in Kongsberg, which led to some difficulty when it came to working on the project. Thankfully I tested negative on the corona test, so I am back home in my apartment. 

One of the topics that we discussed during this week’s meeting was the issue concerning the recognition of the playing cards, and that the camera has to see the whole card in order to recognize which one it is. While discussing this issue, I had the idea to incorporate one of those card shuffler machines, and to mount the camera on the shuffler. This allows a deck of cards to be shuffled while the system records the order of the cards at the same time.

Pictured above is a card shuffler machine, and the idea is to put the camera in the middle so that it can see down on the cards that have been shuffled and to register them. The problem with this solution is that these types of card shufflers are usually very fast at shuffling a deck of cards. While that normally is a good thing, the problem now is that the system requires some time to detect which card it’s looking at. To solve this, one idea I have is to open up the shuffler and connect a circuit between the shuffler’s power supply and motors.

In the picture above, we can see a card shuffler machine that shows its internal components and wires. I’m not sure if my idea is as straightforward as I am hoping, but the general idea at the moment is to connect a circuit that works as a logical AND gate, where the inputs are from the power supply and from a clock signal. The clock signal will be determined from the speed at which the system can detect cards. For example, if the system uses 3 seconds to detect the value of a card, the circuit will stall the motors of the card shuffler for about the duration it takes to detect the card. I am hoping to discuss this idea with Dag in the coming week to determine how to best solve this issue. 

Furthermore, from experience I know that these card shuffler machines are prone to shuffle more than one card at the time, and that cards often get stuck during shuffling. It might be an idea to get Simen to check on these issues in case there are improvements that can be made, if he has the time to do so. The reason is that when shuffling the cards, it is of course important that the machine shuffles one card at the time so that our system is able to detect every card separately. If multiple cards get shuffled at the same time, the system isn’t able to keep a record of the position of every card in the deck.

Data (Danial):

This week I have looked at the charts from last week and together with the group have tried to find out how we want us to move our arm. We have found out that we want to have a maximum of 4 players in one round. Due to Corona, we have not been able to meet each other and therefore had a digital meeting. We were not able to explain the exact movement the arm, and will therefore try to meet next week. I have gained an overall understanding of how we want the robot to approach each player and hand out cards to each player. We were given a challenge in terms of reading the cards, we will try to find out at an upcoming meeting with a ramp on which the cards slide.

I have attached a picture of how I have set up the servos as well as extra power, since the servos are more powerful than regular Arduino servos, we needed 5V which Sondre has assisted with.

Data (Azim and Bjørnar):

After giving ourselves an ultimatum to the end of the week regarding the object detection, we now have a decision. We will in fact need to detect the whole card and therefore revisit our design. That is the decision we came to after weeks of modifying and trying to improve the model. During our meeting this week, we discussed this with the other group members and we figured out some workarounds with the design that would allow this to happen. 

We have come up with a temporary design for how to scan all of the playing cards into our system as we are unsure if we will be able to do it while the robot is in use. This design can be visualized like the self checkout in many Norwegian stores. The camera module is placed inside a box with a see-through top. This way we can put the downwards facing card on top of the box so that the camera can scan what card it is. This allows for more consistent scanning results and also decreases wait time while the game is going on. It does increase the time it takes to set up the game, but it is much better to spend a minute more for preparations than to wait 10 seconds every time the robot is going to hand out a card.

Data(Azim):

I purchased this cable for the raspberry pi camera and it finally came in this week. The cable we had originally was way too short, and did not give us the 20 cm+ we needed for an optimal camera focus angle. Due to me and two other group members being in isolation, we couldn’t physically meet up, so I will have to meet Bjørnar (he has the raspberry in his possession) and apply the cable to the raspberry the coming week.

Furthermore, this week i continued working on the game script, and thankfully it’s in the final stages. I am looking forward to finishing it in the coming week, and then all that remains will be to integrate it with the robot functionalities.