Robotic Arm Controller with Graphical User Interface
Wouldn't it be incredible....
....if we could control a robotic arm via a microcontroller?....if we could regulate the speed and direction of each motor?
....if the microcontroller could be used to move the various arm joints to precise angles?
....if we could extend the arm control to a 3D graphical user interface?
....if the GUI allowed the capability to manipulate the arm to any position and then send positions at the user's discretion?
....if the GUI further provided the ability to program a series of arm positions, to clear, update, load, or save programs as desired, and then send a program to the microcontroller to execute?
....if we could then add object recognition code to scan a Quickcam device for simple-shaped objects and send any data to the GUI and microcontroller?
YES, IT WOULD!
Well, that's what we were thinking when we went crazy with our final project for EE476. We had both always been interested in how to interact with Quickcam-like devices. We both found a liking to programming in Java3D. We both had always wanted to work with robotics. Simple solution: do everything to as much extent as we can so we can take in a little bit of everything.Jeff Vogel & Robin Glinton
Materials & Things Used
- Atmel AT90S8535 Microcontroller w/ Parallel Port interface
- LCD Panel
- 16-key Keypad
- Laptop Computer w/ Pentium III Processor
- Robotic Arm with 5 degrees of freedom
- Quickcam w/ Parallel Port interface
- RS-232 Cable for Communication between PC & Atmel
- Power Supply of 6V
- Trimpots (3)
- Clicker switch
- H-bridge - BJTs (2/2), diodes (4), 300ohm R (4)
- 5V reed relays (7)
- NAND/Inverter logic circuit
We looked all over the place for robotic arm kits that were not too expensive, but allowed a good range of motion and several different joints. We finally decided on the Robotic Arm Trainer 007 from OWI Incorporated. This arm kit was relatively easy to assemble (~3 hours) and was quite fun to construct! Here is what things looked like before we began:
The arm has five degrees of freedom and five 6V motors for each piece: the base, the shoulder, the elbow, the wrist, and the gripper.
The arm kit came with an el-cheapo control box, but we needed a more flexible circuit so that we could control the motors via the microcontroller. So we decided to build an h-bridge circuit with a pulse width modulation trigger and direction signal to control the forward/reverse direction of a single motor, and then we created a train of relays to select/deselect which motors to move.
We originally had thought that the best way to control the motors from the microcontroller was by using an h-bridge and a logic circuit of nand gates and inverters so that there would be 7 signals in total for the microcontroller: Pulse Width Modulation (the amplitude), direction of the selected motor, and 5 signals for the 5 different motors to control.
This proved difficult to work with, and a lot of problems we found (much) later were caused by low current on portB (arg!!) that could not drive the relays properly. So some of the motor controls had to "share" pins with the keypad on portC. More pins would have been nice, but we managed the best we could with what we had.
Below is the schematic for our first motor control circuit. When PWM and Direction are both high, the motor selected spins clockwise. When PWM is high and Direction is low, the motor selected spins counterclockwise. When PWM is low (amplitude = 0), no motors will move.
The arm has five degrees of freedom and five 6V motors for each piece: the base, the shoulder, the elbow, the wrist, and the gripper.
The arm kit came with an el-cheapo control box, but we needed a more flexible circuit so that we could control the motors via the microcontroller. So we decided to build an h-bridge circuit with a pulse width modulation trigger and direction signal to control the forward/reverse direction of a single motor, and then we created a train of relays to select/deselect which motors to move.
We originally had thought that the best way to control the motors from the microcontroller was by using an h-bridge and a logic circuit of nand gates and inverters so that there would be 7 signals in total for the microcontroller: Pulse Width Modulation (the amplitude), direction of the selected motor, and 5 signals for the 5 different motors to control.
This proved difficult to work with, and a lot of problems we found (much) later were caused by low current on portB (arg!!) that could not drive the relays properly. So some of the motor controls had to "share" pins with the keypad on portC. More pins would have been nice, but we managed the best we could with what we had.
Below is the schematic for our first motor control circuit. When PWM and Direction are both high, the motor selected spins clockwise. When PWM is high and Direction is low, the motor selected spins counterclockwise. When PWM is low (amplitude = 0), no motors will move.
We modified the control circuit to just a long train of relays, and things began to work a lot better! It was too bad we wasted a lot of time with the h-bridge, because it probably wasn't the best thing to work with in our case. Here was our new circuit:
m i c r o c o n t r o l l e r
Connections
PORT A - A/D Converter
Pin 0 - Potentiometer from Base Joint (range ~180 degrees)
Pin 1 - Potentiometer from Shoulder Joint (range ~ 120 degrees)
Pin 2 - Potentiometer from Elbow Joint (range ~ 135 degrees)
PORT B - Motor Control
Pin 0 - Forward base output
Pin 1 - Forward shoulder output
Pin 2 - Forward elbow output
Pin 3 - Forward gripper output
Pin 4 - Gripper click sensor input
PORT C - Keypad / Motor Control hybrid
Pins 0,1,2,3 - Keypad
Pin 4 - Reverse base output, Keypad
Pin 5 - Reverse shoulder output, Keypad
Pin 6 - Reverse elbow output, Keypad
Pin 7 - Reverse gripper output, Keypad
PORT D - LCD
Program
The microcontroller's main role is to deal with controlling the various motors of the robotic arm, and it is the central element that connects the software world (Java3D Interface) to the physical world (the arm).
There are 2 implemented modes that the microcontroller program can run in:
Mode 1) Local/Manual Control - the keypad / LCD can be used to select the appropriate joint to move, the speed of the movement, and the angle with which to move it. The joints will be moved as directed and stop at approximately the angle given. The ADC reads in the trimpots of the joint being moved if it is an angle-determined joint (base, shoulder, or elbow), and PIN B4 reads in the switch on the gripper if the gripper is selected to be closed (so as to be able to clamp objects).
Mode 2) GUI Control - the user manipulates the arm in Java3D and sets the arm at a desired position (in terms of the angles and status of the five joints), and then can transmit the info to the microcontroller for processing. The microcontroller must be set to GUI mode to receive incoming position controls from the computer.
There are a few other modes that were worked on but never got completed due to a lack of time and an underestimation of the difficulty in some areas. These are:
Mode 3) Programming mode - the user creates, updates, and saves programs on the GUI controller, which basically consist of a set of positions for the arm to move in. The microcontroller receives the program and performs the set of movements in the order specified.
Mode 4) Object Recognition mode - once a simple shaped object (ball) is placed in the view of the Quickcam, the object recognition code signals the GUI which incorporates the object into the graphical display. The user can then manipulate the arm to grab the object and so forth. The GUI could then signal the microcontroller of object in view.
The possibilities with this kind of stuff is endless!
t h e G U I
The GUI for the robotic arm control was written in Java3D because as a Java applet it can be incorporated into a web page for use with web browsers, and the structure of Java3D makes it easy to work with objects in 3 dimensions. The program consists of three different views of the arm, representing the three basic sectors that can be manipulated. The upper left screen controls the shoulder and elbow joints of the arm, where either joint can be grabbed and rotated between its extreme angles, and you can see the angles update live before you. The upper middle screen deals with the base joint, where you can spin the base as desired. The upper right screen deals with the wrist and the gripper. Left button spins the wrist, and right button click toggles the gripper. The lower right control panel deals with creating new programs (sets of positions), updating them (add a new position to the set), saving them as .ARM files, quickcam link to object recognition code (not fully implemented), and the sending of positions or .ARM files to the Atmel microcontroller.
Note: to run this software Java3D and JavaComm packages must be on the system by which you run it.
r e s u l t s
Well....
We probably set our sights too high when we decided to dive in to this plethora of projects. We started out by working a lot on the higher level code like Java3D and C++ routines to recognize objects via the Quickcam, which were very interesting to work on, but we underestimated how difficult it would be to control the motors and perform accurate position sensing. A lot of our schedule was built around the fact that the robotics kit that we ordered didn't arrive until 2 weeks before the project was due, so we had to get other stuff done earlier. By the time the kit arrived, we had some good working code on the software side of things, and the object recognition and Java3D program worked great individually.
But our main trouble had to do with controlling the various motors to the arm and other mechanical related issues. First, we created an h-bridge and logic circuit to select PWM, direction, and motor to move. This gave us endless problems. For some reason the current coming out of the h-bridge was too low to power any of our relays except 5V reed relays, and 5V reed relays are NOT PLENTIFUL in Ithaca!! These relays were the only ones that we found that were reliable, but unfortunately we only found enough to be able to control 4 out of the 5 motors.
Working with the 4 motors, everything went great! We were able to manipulate the arm in 4 different ways on the Java3D interface on the computer and send the positions to the microcontroller, and then the microcontroller executed the necessary moves of the joints to get to that specific position. We found that the motor speed was also a little too fast, so we slowed it down using a home-brewed PID control.
On a different note, it was very difficult to physically install the position sensors (trimpots) to the arm itself. We tried soldering, gluing, and all sorts of things. Finally we got a couple working but we ran into issues with trimpots not being completely reliable-- all this added some unreliability into what the arm actually did when we "told it" what to do. Not every signal sent to the microcontroller worked exactly- but it was definitely a sight to see when you program up the GUI and then the arm executes exactly what you specified! Cool!
ASM CODE:
JAVA GUI CODE:
ArmObject.java
ArmPick.java
ArmPositions.java
ArmRotate1.java
ArmRotate2.java
ArmRotate3.java
AtmelComm.java
IO.java
3DObject.java
ArmPick.java
ArmPositions.java
ArmRotate1.java
ArmRotate2.java
ArmRotate3.java
AtmelComm.java
IO.java
3DObject.java
0 comments:
Post a Comment