16.10.20-23.10.20

Maskin(Simen):

Due to the larger than expected force needed to move the load, we found we needed more than a simple servo as a motor, at least for the base, so we found a stepper motor. While in theory barely providing the Torque needed, we met an unwarranted problem regarding the use of a stepper motor, which is the hub/mount. As most of the earlier users of the stepper motors were using it for belts, there were no traces of it, so I had to either buy it or make it myself. Choosing not to take the easy way, I aimed to design it in Solidworks and print it.

To thoroughly make sure we had enough Torque to move the arm at its most vulnerable, I used a gear exchange, making the speed go down, while the torque goes up.

In addition, making the gears bevel allows for the stepper motor to lay horizontal, which avoids an unwanted height change for the base of the arm.

I am still working on the rest of the arm for conversion from shafts to servos.

Elektro(Sondre):

There wasn’t any real progress on the SPI front this week since I had to discuss it with Bjørnar, who’s in charge of programming on the Raspberry Pi for the most part, but because of limited time this week there wasn’t any opportunity to get started on it. 

Instead, Simen and I worked some more on the actuators of the system. We had the chance to check out a couple of larger motors, so while Simen took the dimensions of them and worked out how much torque they can produce, I did a little research on them since these were stepper motors, which I haven’t used before. 

The stepper motor that I tested was a Nema 17 bipolar stepper motor. A stepper motor is a DC motor that moves in small steps. It contains multiple coils that allow the motor to rotate one step at the time when these coils are energized. They can achieve high torque and precision, which is what we are looking for for some of the motors on the robotic arm. 

To run this motor, a motor driver is needed. The driver powers the motor as well as limits the current that the motor draws. Without a limit on the power that it consumes, it can draw a large amount of current if there is a lot of torque on the motor. The driver that I used, a TB6560, also allows the use of microsteps on the stepper motor. Without any microsteps, the motor has 200 steps per revolution. As we can see in the figure below, this driver allows for up to 1/16 of a step. This means that there are 16 microsteps in one full step. With our motor this means that we can have up to 3200 microsteps per revolution. 

While this does increase the accuracy by quite a bit, the downside is that the speed and torque of the motor is decreased. In the picture below we can see a Arduino Mega 2560, the stepper driver, and the motor itself.  

After looking up the datasheet for both the driver and motor, I connected all of the components together and wrote a simple code to test the motor. In the video below we can see the motor running without any microsteps, using only full steps. 

Continuing, the next video shows the stepper motor running on 3200 microsteps. 

As we can tell, there is quite the difference in speed in this test between the different step settings. For the purposes of this motor, the plan is to use it near the base of the robotic arm, or the base itself. Because of the movement it is meant to do, we prefer speed and torque over precision on this task since we’ll want the system to hand out the playing cards rather quickly. Also, even though we plan on using full steps for this motor, 1 step is equal to 1.8 degrees, which still is relatively precise given the speed we are getting out of it. 

Moving on to next week, Simen and I have agreed on trying to fit some of the actuators to the arm to check how much space they need, and hopefully we’ll be able to try to move the arm with the motors if Simen can make the motors connect to the joints of the arm. I also wish to discuss the use of SPI with Bjørnar and how we should approach it. 

Data(Danial):

This week I have not had much work with the servo motors due to other tasks at school. I have looked at how a node and a master node should work. The servo motors are made in a folder inside another folder and implemented there. I have started on the development of a servomotor, but will continue to work on how it will rotate based on what we want.

This week I have been able to use the servo so that it has rotated at a given angle. It has been a real challenge since I was not aware that the code was a “subscriber” and therefore needed a “publisher” to make the code work. “publisher” will send messages to “subscriber” about what to do. I will now start by looking at the possibility of implementing more servos and get these to rotate as desired. 

Data (Azim):

We realized that in order to detect and identify the playing cards as efficient as possible, we could go about it two ways. Either, training a custom object detection model or creating an image processing algorithm. Although this is time consuming, we are both interested in finding different paths to solve a problem, and this has provided us with a sufficient workload. We will still work together, but we decided that Bjørnar would focus on getting the model up and running as soon as possible, and that I would continue modifying and testing the script in order to make it more reliable.

Bjørnar and I cooperated through this sprint. He had the hardware in his possession and we agreed that when I was finished with the necessary scripts I would send him it so he could test it. This included finishing up the python scripts for identifying the playing cards and also going over the image labeling process since there were some formatting issues that needed to be fixed. Later on in the week we met and managed to test the scripts on the raspberry pi as you can see below. 

From the testing we took away some key points. Firstly, the camera position must be mounted properly and the angle of the camera must be vertical to the card in order to recognize it, otherwise the camera module won’t focus on the card.

Secondly, we did some testing with different backgrounds and as expected the program doesn’t respond well to a white background as it is intended for a dark background.

I am not yet satisfied with the performance of the program because it is still showing inconsistencies in the identification, so i will continue working on this in the next sprint.