Sprint 5: 18.09.2020 -25.09.2020

Due to scheduling difficulties and mainly sickness we weren’t able to have our weekly meeting, but we decided that everybody would continue their individual task for this sprint and we would then report back during our next meeting to assess the status of our progress. We will also look to finally print some of our main parts, and get the prototyping going so we can do proper testing and verification as early as possible.

Maskin (Simen):

After carefully changing the design, the arm is now more portioned, and easier to 3d print. I chose to use 3d printed shafts this time, as this will be the first 3d print, and I expect more. But in the complete product it is meant to use servos instead of shafts, so we can move the joints automatically. I have not made it like this yet because I focus on making the skeleton first, and then implementing engines according to calculations and experiments.

I managed to 3d print the parts with the help of the teacher, but I haven’t gotten to them yet because of home isolation in relation to a known virus.

Image of the design, Before (The last design):

Here we can see how the parts are significantly simplified to make 3D printing easier. Fewer fillets, less elevation in parts, more clunky, with my new goal in mind: Function over Form. In addition, the necessary complex parts have been divided into several parts to be able to 3D print without problems, such as the hand itself (a clear split along the part). These are meant to either be glued, taped or screwed together.

The “muzzle” of the hand is meant to hold a deck of cards. I’m still working on the development of the cartridge and the mechanism it must have to be able to easily push in and spit out a new deck. It is possible I have to use a solution similar to backpack clips and their release mechanism, with the insertion of a clasp and then release, but then I will have to come up with some solution that releases it automatically as well. The hole at the top will be our way of pushing cards one by one out of the cartridge.

Elektro (Sondre): 

There wasn’t any real progress this week on the electrical side of the project. After talking with the contact person for the electrical engineers about the use of a FPGA board for this project, it seemed that there wasn’t any real use for it and that it may be a bit excessive to utilize it instead of dedicated boards and what not. 

Moving forward from this, I struggled quite a bit this week trying to determine what to do next. It wasn’t quite easy figuring out what to do now since I am waiting for the calculations of the parts we need to determine how powerful the servos and actuators need to be. Other than that, the components and such of the system shouldn’t be that difficult to wire and connect with each other. 

In addition, this week was also quite busy for me with other things to do. The next week I hope to cooperate with the machine engineer some more in order to determine what kind of performance we need for the mechanical arm to function optimally.

Data:

ROS(Danial): This week I have downloaded and gained more knowledge about how to use ROS and make our system work. I have faced many challenges to download Ubuntu 20.04 as a virtual machine through VirtualBox, along with ROS. I have researched and found that we should use ROS Noetic (ROS 1), the reason is that it is the latest and best version for programming robots, at the same time there is also a lot of learning I can do by using my own experience and experiences from others on the internet.

It was a lot of challenges with downloading various software to start coding. VirtualBox went just fine to download, no problems. Ubuntu on the other hand was not as easy, it turned out that in order for everything to work optimally I had to allocate enough space on the virtual hard drive, I didn’t do it the first time and therefore did not get started when I had to do it the second time, I therefore had to delete this and restart the process. The second time I tried to install, everything went well, I allocated enough space on the virtual hard drive, I got into the virtual machine and used various functions. When I turned off the machine and the virtual machine, the virtual machine would not start up again, then the screen was just black. This is due to a “bug” that may occur when using this setup on Mac. I got this fixed and restarted Ubuntu, it has worked as it should since.

The installation of ROS Noetic has been very demanding, the reason being that the user guide on ROS ‘websites does not work for Ubuntu. I found several other methods to download ROS on Youtube. This has been successful and I have now started looking at how I can use ROS to make our robot work the way we want.

Data(Azim):

In similar fashion to my other group members, this sprint was a tough one. After downloading the libraries and training my data during the last sprint, I proceeded to set up the object detection model. During the final stages however, I ran into an issue where the model wouldn’t load and the error message didn’t make sense. After spending 3-4 days on this issue, and searching all over the internet, apparently there was a corrupt installation when i tried to install protobuf that caused this issue, so after fixing this i finally managed to setup the object detection model.

Finally, i could demo the object detection and test the pi camera module. Since I am not done with training my own model i used an existing one to in order to test performance. This turned out to be quite benefitial because i learned that in stead of using normal tensorflow I should use tensorflow lite. The normal tensorflow version uses more of the cpu and as seen below gives very low performance in terms of fps. So during the next sprint, I will be updating to Tensorflow lite without any issues hopefully, and then having my trained model implemented.

Data(Bjørnar):

This week I made minimal tangible progress to the application and communication system of our robot. The first problem was simply to get my python script running on the raspberry without any errors. It took dozens of tries, and several hours for the python script to not throw an error while importing the bluetooth module. I still have no idea what the error came from, but I finally solved it symply by installing blueZ and including it with the right commands in linux. It was after the python script ran that the real trouble began. My app and the python script both ran without errors, but they could not connect. The raspberry does not want to connect to an android phone unless it sees that the phone has a function, or a way of communicating with the pi. I noticed that for a small second while pressing the “test connection” button in my app the raspberry would connect to my phone, but no more than that second. This gave me hope that I was doing something right, but sent me down a long path of countless unsuccessful potential fixes. I believe the fix is to somehow get the raspberry to constantly listen to the bluetooth RFCOMM port, and for the phone to constantly transmit over the same port. This will make the devices aware that they can communicate and hopefully connect.

Since I don’t really have a progress picture this week I decided to include a snippet of the classical search history of a programmer stuck on a single issue.