Week 3 Update:
This week the HMI team met and decided to use a Raspberry Pi to create out HMI, as they are open source, and very simple. Raspberry Pi also has a touchscreen that is designed to work directly with a Pi which will simplify the complication interfacing two separate hardware’s might lead to. Josh currently has one which allows us to get started without needing to wait for the ability to order one. We decided to use a library called guizero which is an extension of tkinter. This allows us to use two different levels of capabilities to expand our usage of the HMI. We went through a quick tutorial webpage to learn all the basics of guizero, and were able to create a simple UI window. We found a way to make the whole UI window full screen but need to work on finding a straight forward way to close it (I will put the command in here once I have a copy of the code). We were also able to allow for additional popups that would prevent work on the previous screen until the popup is closed (Also will put the code snippet here). We also discussed the possibility of dropping 480V power into the lab room to allow for a standard ABB robot controller to work at spec. If this is not a possibility we talked to our sponsor to get a smaller controller to use. If this is the route we need to go we might not be able to use joint 1 (the base swivel) on the arm.
Week 5 Update:
This week we met and made some decisions as to what we think should be available on the HMI. We added a window that will show what pins on the I/O pins are active and labeled all the pins with a display that can change color if a pin is on. We also wrote some code to test if we could control the I/O pins from a python code, and additionally with the press of a virtual button on a window that is created with guizero. We were also able to get a robot from Flex Automation up here this weekend! The plan for next week will be to further decide what needs to be in the HMI screens and then we will need to start interfacing with the robot to determine what more will need to be displayed. If we make it far enough we can also work on sending signals to the robot next week.
Week 7 Update:
This week we worked a little further on making the HMI more professional. We restarted and decided to use the grid layout that guizero offers to try to get a better more legible layout. We restructured our second window and added a grid layout to show all of the I/O pins on the Pi. We also added a button to turn a I/O pin on and off and tested its functionality by connecting an LED to it. We also had CDR this week.
Week 9 Update:
The robot is HERE! Flex Automation sent up a robot arm that we can interact with. We were able to connect it to power and were able to spin the joints using the provided controller. We also did some solo research to try to learn more about our respective areas of expertise with the robot. I looked into changing the pixel colors on the second window to show when an I/O pin is on or off, and into being able to detect only when a button/the mouse is clicked, and not when it is released for better control of the I/O.
Week 11 Update:
We have started looking into what we need to do to connect the robot to a computer first before attempting to connect to the Pi. We started by looking into the ABB documents and trying to find what ethernet port to use. We tried just connecting the robot to the LAN and WAN ports but couldn’t get the robot to establish a connection. We downloaded WireShark to start reading the packets being passed between the controller and the robot. We haven’t found a whole lot of useful information. We will talk to the sponsor about more information they can give us about connecting at our next meeting.
Week 13 Update:
Talking to the sponsor they recommended someone they’ve worked with in the past, Terry. We reached out to Terry but couldn’t reach him. We called back the following week and found out Terry has experience connecting ABB robots to RasberryPi’s. We need a software option called “PC Interface” to be able to use the ethernet ports on the controller. This piece of software is roughly $1700 and although Flex is willing to pay that price they would like us to check with ABB to see if it would be possible to get a student discount.
START OF SEMESTER 2:
At the end of the semester the robot will be able to be controlled by our RasberryPi. The instructions to the robot will be configurable. The Pi will be housed in a case. This week we would like to meet with Shane to see what he can help with for the encoder problems. I would also like to call ABB and possibly email them again to get a response by the end of the week. My only concern is the response time of ABB.
Week 3 Update:
We called ABB and after a very lengthy phone call we were instructed to email ABB. We sent an email and in the meantime we will start working on repairing joint 1. We looked in the lower part of the robot and tried to determine what might be wrong, Josh had replaced the encoder while working at Flex to try to fix the problem, with no luck. We have decided to set up a meeting with Shane for next week to see if he might be able to assist a diagnosis.
Week 4 Update:
I called ABB again and was given the number of someone in sales to contact. When I called him he told me to send him an email with some information about the robot and our project. While waiting for him to respond we worked on the encoder. We cleaned the encoder disk and cleaned up the soldered wires before taking the encoder off and re-soldering the connections. Joint 1 seems to be working a little, which is better than before, but it is throwing up some errors that we need to look into. Next week we need to get a response back from ABB and we should take another look at the errors and try to find a solution.
Week 5 Update:
We took the encoder off the robot and tried to see what what was wrong. There were some wires that looked like they might be shorting, the wire was previously soldered together. We tried re-soldering to make the connection better. We also called upon Shane to see if there was anything he could tell was faulty from the encoder disk. He noticed some fingerprints that we cleaned off. When we re-installed the encoder we were able to move all the joint except joint 1. The error we get now is that there is too much force and the arm thinks it is pushing against something. Next week we will look inside to see if there is a problem with the brake release.
Week 6 Update:
We got a response from ABB, the PC Interface option would be $2006 and we could get a 10% student discount. Because the robot is not working properly, our sponsor would prefer not to pay this much for the faulty robot. Instead they are working on getting us a RobotStudio license that we can use to simulate the robot with a computer. We also took off some panels to look inside the robot. We checked for continuity and drew out a diagram of what we noticed from the input pins and compared to ABB’s documentation. They appear to match, however there are 4 pins that have continuity with the brake release. We tested through all the separate connectors as well to ensure that there weren’t shorts in the connectors. Next week we will apply 24 V across the four different possible combinations of pins to the brake release. In the meantime we will look more into documentation to see if one of the combinations is supposed to release joint 1.
Week 7 Update:
We applied voltage across the pins on the main power connector. We can hear and feel that the other joints are releasing but not joint 1. We disconnected the harness that goes from main power to motor 1. When we applied the voltage in the harness to motor 1 it releases the joint. We did some inspecting and found nothing. CDR is next week so we will ask then and see if anyone has any ideas or solutions.
Week 8 Update:
We were unable to meet at our regular meeting time and were unable to find a good time to meet as a replacement time. We scheduled a meeting for next week Monday.
Week 9 Update:
We tired looking through the robot to see why the brake isn’t releasing. We ended up applying the 24 volt signal to the harness to release the brakes, and just like before all but joint 1 released. We ended up measuring the voltage at the pins with the voltage applied and we were only getting a 9 V signal. Something in the wiring is causing the 24V input to drop to 9V as soon as the voltage is applied. At this time we are more worried about having something to show for our project, next week we will switch to Robot Studio to try to get the virtual controller to work instead.
Week 10 Update:
This week we met three times, we tried to use RobotStudio but forgot to add the PC Interface software option to our virtual controller. When we tried to recreate the controller it wouldn’t start. We tried calling ABB to see what the issue was and didn’t get anywhere with that. We ended up uninstalling and reinstalling with no luck. Eventually we tried uninstalling again, and realized that there is data that isn’t deleted in the documents folder. Deleting this folder after uninstalling, then reinstalling solved the problem and we were able to create a working virtual controller.
Week 11 Update:
We wrote code this week that we could run in RobotStudio, the language RS uses is called RAPID. We were able to move the simulated arm in RS. Then we decided to try to establish a TCP connection through local host on the same computer to send information between a python file and RAPID file running on the same device. After a little trial and error we were able to get it to work with simple inputs. These simple inputs could be programmed into our HMI buttons to send commands to the controller to control the robot. Next week we will try to connect through ethernet and the PI.
Week 12 Update:
We tried to communicate between the Pi and a laptop. We were unable to get a TCP connection established between the two devices. After some trial and error and googling we determined that it’s possible that there was a firewall rule blocking the connection. I created a rule to allow for ICMPv4 which allows for pings to be sent and received, this worked and the devices can tell they are connected. However they still aren’t connecting through TCP, I’ve created TCP connections in multiple other classes and can’t figure out what the issue could be. I created firewall rules for incoming and outgoing TCP connections on port 12345, which is the port we declared for communication. The laptop running RobotStudio is acting as the server and the Pi as the client, I reached out to Shane to see if he had any recommendations.
Week 13 Update:
This week we spent more time working on the layout/design of the HMI and on adding more capabilities to our robot simulation. We were able to add a gripper controlled on I/O signals, and physical blocks for the robot to interact with. Currently we have the ability to use eight different commands, we originally had these each controlling a joint for proof that all joints were controllable with our HMI, we then switched to replacing some to allow for the robot to interact with the blocks in it’s environment.