Synopsis

This project is a PC and controller application that manipulates a Lynx6 Robot Arm. It was done as apart of my "Diploma in Electronics Engineering" at the Torrens Valley Institute of TAFE. What follows is a simplified technical discussion of how this project works and how it was developed.

The assigned task was to "make it carry a small object in a straight line of 10cm distance". With that, I went about design. I had never played with robotics before, so I first had to learn what actually made the bits of the robot move.

The lynx6 Robot Arm has 7 servo motors. These motors control the base of the robot, it's back (two motors control it's back), it's elbow, it's wrist (two axises of wrist movement), and it's grip (or "effector" as they call it in robotic jargon).

Servo Motors

"Servo's" are motors that will rotate and hold it's axial according to an inputted pulse train. If you were to look at this pulse train with an oscilloscope, it would look like this--

<--------------- 16.40ms --------------->
+-----+                                  +-----+
|     |                                  |     |
|     |                                  |     | Pulse train to Servo
|     |                                  |     |
|     |                                  |     |
|     |                                  |     |
+     +----------------------------------+     +----------....

It's basically a digital pulse whose voltage is low and then goes high for a very short period of time before going low again. The angle that the motor holds it's axial is determined by the pulse train's so called "duty cycle". Here are two examples of two pulses with different "pulse widths" and hence different duty cycles--

+-+                     +-------------+
| |                     |             |
| |  0 Degrees          |             |  180 degrees
| |                     |             |
| |                     |             |
| |                     |             |
+ +----                 +             +---------

In the servo motors case used by the Lynx arm, a very short pulse width tells the motor to maintain a 0 degree angle (say, turn all the way left). A very long pulse tells the motor to maintain 180 degrees (turn all the way right). Any pulse size in between will maintain an axial angle proportional to pulse width.

The Design

Due to the precise timing of the servo pulses, and the complex calculations needed to manipulate the robot, I decided on a Controller/PC design. I allowed myself only 5 days to do this project, so I designed it to be reliable, quick to implement and fail safe--

     +-------+             +----------+              +----+
     | Robot | <---------- |Controller| <----------> | PC |
     | Arm   |   6 lines   |          |    RS232     |    |
     +-------+             +----------+              +----+

If I got the PC to directly talk to the robot, even via some sort of high speed parallel bus, transmission errors and processing latencies would creep into it's operation.

The idea of a controller is to run the complicated "reverse kinematic" software on the PC, and then get the PC to transmit the servo angle data to the controller via a serial link protocol. Both the controller and PC can check the accuracy of the angles transmitted, and retransmit if necessary. The controller (which will be very close to the robot, hence transmission noise and latency will be kept to a minimum) will then send the pulses to the robot.

The Microcontroller

I used an Atmel Mega8 for the task. Unfortunately, this IC only has 3 PWM (Pulse Width Modulation) channels in hardware. I needed 6. So, I had to emulate these 6 channels in software. I did this by designing an ISR (Interrupt Service Routine) that produces 6 x 60.9hz pulse trains of a given Duty Cycle that are needed by the servo's.

The controller reads angle commands from the PC via RS232 serial link (2400 Baud, 8N1 discipline). The controller waits for a 5 character NL (newline) terminated frame from the PC. Within the frame is encoded an 8 bit CRC. When the controller receives a frame, the CRC value is checked against the actual frame. The controller then sends a 5 character acknowledgment frame back to the PC (which is also CRC'ed). This tells the PC whether or not it's command was received error free. The protocol is very similar to TCP protocol used in Internets TCP/IP. It ensures that when a servo angle is issued by the PC, it will be the precise angle sent to the given servo motor.

The PC End

On the PC, we run our complicated "reverse kinematic" software. This is robotic jargon which means "work out all the arm angles to position the robot hand at a given location". What you see in the screenshot above, is a top view of the floor area the robot arm works in. The white "X" is the current position of the robots grip (effector).

There is much research in this field. Infact, I was surprised to learn that much of the initial research was done before robots were invented !. One such research I studied was the "Denavit-Hartenberg model" [1]. After I simulated the algorithm on paper with a series of sketches, I decided that the "D-H" model would be overkill for my task. Instead, I used simple trigonometric techniques to perform the reverse kinematic process.

The robot arm has been developed to orthogonally work on a cube of space (600 x 500 x 200 mm). This is typically on and above a desk area that the robot has been clamped on. All arm movements can be broken down into 4 basic triangles. Their angles can be solved using basic trigonometric formula's (RHS, Pythagoras, sine rule and cosine rule).

First it works out the effector dimensions-- the reach length. It works out other internal angles. It then finally arrives at the base, back, elbow and wrist angles. You can set an effector angle (grip tip), or the height of effector (grip) tip above the base/floor while changing other variables. The algorithm will maintain all other angles while you change one or more of these variables.

For example, you can set the grip position at a given point and then adjust the angle of the grip (relative to the floor). The algorithm will maintain the tip of the grip at that coordinate as it changes the effector angle.

I had "component placement" in mind when designing this where you want to hold something at a given X,Y,Z position while changing it's (the object your are carrying) placement angle.

Once all the angles are calculated, they are then converted to Lynxs unique angle convention. The good thing about doing this is that it adds a "system dependent" abstraction.. while keeping your main algorithm conventional. We then convert these angles into servo PWM (Pulse Width Modulation) coefficients ready to be sent to the controller.

Sources--

[1] Chapter 2, Introduction to Robotics, By Saeed B Niku