Difference between revisions of "SuperComputer Robot Controller (SCoR)"

From Lofaro Lab Wiki
Jump to: navigation, search
(How to)
(How to)
 
(20 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
[[File:SCOR.jpg|right]]
 
== Our Vision ==
 
== Our Vision ==
 
Our project is designed to change the traditional approach of a centralized robot controller and build a distributed series of robot controllers each designated on a joint of a robot. Our project will be most applicable in high DOF robots. There are various advantages of  having a controller at each joint instead of one centralized controller. First if the centralized controller breaks down then the entire system has become unusable. With our approach if one controller is broken then that actuator is unuseable but the system is still usable. This may limit the tasks the robot can complete but it still has the ability to complete some tasks compared to none. This allows our controller to be significantly more robust than other robot controllers. The next purpose of our project is that the tasks given to the controller will be able to be parallelized across the different controllers for faster processing power. This leads to the name of our project being called supercomputer because on a high DOF our controller will have a high level of computing performance compared to a single controller. With our controller we want the user to be able to add a joint to a robot and it then the robot gains more processing power. Lastly, our robot controller is being designed to work for three types of motors, DC brushed, DC brushless, and 4-wire 2 phase stepper with a single circuit that only needs a firmware update to change between the motors. The purpose of this is it gives our robot controller versatility by being able to work with three different motor types. Since only a firmware update is needed to switch between motor types this provides an easy use of our controller with the user. They will simply have to plug in different wires then software does rest. This approach shows using the technology available today to improve upon systems currently used.
 
Our project is designed to change the traditional approach of a centralized robot controller and build a distributed series of robot controllers each designated on a joint of a robot. Our project will be most applicable in high DOF robots. There are various advantages of  having a controller at each joint instead of one centralized controller. First if the centralized controller breaks down then the entire system has become unusable. With our approach if one controller is broken then that actuator is unuseable but the system is still usable. This may limit the tasks the robot can complete but it still has the ability to complete some tasks compared to none. This allows our controller to be significantly more robust than other robot controllers. The next purpose of our project is that the tasks given to the controller will be able to be parallelized across the different controllers for faster processing power. This leads to the name of our project being called supercomputer because on a high DOF our controller will have a high level of computing performance compared to a single controller. With our controller we want the user to be able to add a joint to a robot and it then the robot gains more processing power. Lastly, our robot controller is being designed to work for three types of motors, DC brushed, DC brushless, and 4-wire 2 phase stepper with a single circuit that only needs a firmware update to change between the motors. The purpose of this is it gives our robot controller versatility by being able to work with three different motor types. Since only a firmware update is needed to switch between motor types this provides an easy use of our controller with the user. They will simply have to plug in different wires then software does rest. This approach shows using the technology available today to improve upon systems currently used.
 
  
 
== Source ==
 
== Source ==
 
https://github.com/lafem61/SCoR
 
https://github.com/lafem61/SCoR
  
 +
Image of SD card in Zedboard used for the project:
 +
https://drive.google.com/file/d/0B9Mt7RREtuIXbUpqQm1yeS0ybmM/view?usp=sharing
  
 
== How to ==
 
== How to ==
 
   
 
   
Circuit
+
*[[Circuit]]
[[File:PCBlabelled.jpg|center|]]
+
*[[Motor Control]]
PCB of the H Bridge Circuit with Hall Effect and Encoder Feedback
+
*[[Inverse Kinematics]]
 +
*[[Compile Hadoop Source Code]]
 +
*[[Installing Hadoop on Zynq]]
 +
*[[Creating a Multi-Node Cluster on Hadoop]]
 +
*[[Xillinux and Xillybus]]
  
IO inputs and Outputs
+
== The Team ==
 
+
Adam LaFemina (Electrical Engineer)
1.
+
{|class="wikitable"
+
Sohail Mukhtarzada (Computer Engineer)
|-
+
| Motor Output 3
+
|-
+
| Motor Output 4
+
|-
+
| Motor Output 1
+
|-
+
| Motor Output 2
+
|}
+
2.
+
{|class = "wikitable"
+
|-
+
| Main Ground
+
| Main Ground
+
|-
+
| Vcc Power
+
| 5V Power
+
|}
+
3.
+
{|class = "wikitable"
+
|-
+
| Encoder A
+
| Encoder B
+
| Encoder Power
+
|}
+
4.
+
{|class = "wikitable"
+
|-
+
| Hall Phase A
+
| Hall Phase B
+
| Hall Phase C
+
| MircoSwitch
+
|}
+
5.
+
{|class = "wikitable"
+
|-
+
| H-Bridge 3 Enable
+
| H-Bridge 3 Direction
+
| H-Bridge 4 Direction
+
| H-Bridge 4 Enable
+
| 5V Encoder
+
|-
+
| H-Bridge 2 Direction
+
| H-Bridge 2 Enable
+
| H-Bridge 1 Direction
+
| H-Bridge 1 Enable
+
| Zynq Ground
+
|}
+
  
To use the circuit plug the motor into given ports show in arrow 1. For brushed DC motors any two of the half bridges can be used. This means that the circuit can control 2 brushed DC motors. The PWM is sent to the enable FET of the two half bridges used and the direction is sent to the bottom FETS. Since the two bottom FETs are PFET and NFET they will work oppositely thus only 1 will open given a high or low signal. This prevents any shoot through. There is driver circuitry that amplifies the signals up to Vcc to open the FETS. For brushless control plug the three phases into three motor outputs and plug the inputs into three H-Bridge inputs seen in arrow 5.The brushless signals work by sending three different PWM pulses each with a 90 degree phase difference. For the brushless circuit the Hall Effect inputs seen in arrow 4 will be plugged in. For the stepper motor all four motor outputs  and H-Bridge inputs needed to be filled. The way the stepper signals work is by creating two Full-Bridges and alternating between the direction on each one. All the code for these signals can be seen in the sources section. When setting up the circuit place the Vcc Power into the Vcc Power pin and give 5V to the optoisolators. The main ground covers the entire circuit and the Zynq chip is plugged into a seperate ground because it is optoisolated. If using Encoders there signals and power can be found in arrow 3. Also if the robot has microswitches there is an input for that aswell. Only a firmware update on the FPGA is needed to change the circuit between each motor type
+
Ayo Raymond (Computer Engineer)
  
----
+
Kyler Sparks (Electrical Engineer)
  
Inverse Kinematics
+
Robert Yu (Computer Engineer)
  
The inverse Kinematics algorithm used was the Inverse Jacobian. We used the Inverse Jacobian because it is highly parallizable which was a key aspect of our project because we wanted to distribute the calculations across different controllers. This algorithm also allows us easily preform inverse kinematics with a joint locked because we can remove that column from the Jacobian matrix. In the code all that needs to be done is change the desired target position's x,y,z,roll,pitch,yaw coordinate.
+
Faculty Advisor: Dr. Daniel Lofaro

Latest revision as of 13:55, 3 May 2017

SCOR.jpg

Our Vision

Our project is designed to change the traditional approach of a centralized robot controller and build a distributed series of robot controllers each designated on a joint of a robot. Our project will be most applicable in high DOF robots. There are various advantages of having a controller at each joint instead of one centralized controller. First if the centralized controller breaks down then the entire system has become unusable. With our approach if one controller is broken then that actuator is unuseable but the system is still usable. This may limit the tasks the robot can complete but it still has the ability to complete some tasks compared to none. This allows our controller to be significantly more robust than other robot controllers. The next purpose of our project is that the tasks given to the controller will be able to be parallelized across the different controllers for faster processing power. This leads to the name of our project being called supercomputer because on a high DOF our controller will have a high level of computing performance compared to a single controller. With our controller we want the user to be able to add a joint to a robot and it then the robot gains more processing power. Lastly, our robot controller is being designed to work for three types of motors, DC brushed, DC brushless, and 4-wire 2 phase stepper with a single circuit that only needs a firmware update to change between the motors. The purpose of this is it gives our robot controller versatility by being able to work with three different motor types. Since only a firmware update is needed to switch between motor types this provides an easy use of our controller with the user. They will simply have to plug in different wires then software does rest. This approach shows using the technology available today to improve upon systems currently used.

Source

https://github.com/lafem61/SCoR

Image of SD card in Zedboard used for the project: https://drive.google.com/file/d/0B9Mt7RREtuIXbUpqQm1yeS0ybmM/view?usp=sharing

How to

The Team

Adam LaFemina (Electrical Engineer)

Sohail Mukhtarzada (Computer Engineer)

Ayo Raymond (Computer Engineer)

Kyler Sparks (Electrical Engineer)

Robert Yu (Computer Engineer)

Faculty Advisor: Dr. Daniel Lofaro