Computer Representation of a Seven Axis Kinematics Manipulator

Page | 10

Computer Representation of a Seven Axis Kinematics Manipulator

2/21/2013

Trevor Wilson

Computer Science

1227 NE Cardinal Dr. Lee’s Summit, MO 64064

– 816-679-4542

Erik O’Riley

Mechanical Engineering

205 SE Sherri Ln. Blue Springs, MO 64014

– 816-372-7540

Advisor:

Dr. Liou

Mechanical and Aerospace Engineering

Abstract

A novel graphical user interface (GUI) is described which calculates forward and inverse kinematics of a seven-axis manipulator. We present this technology as a solution to manufacturing engineering needs because it greatly reduces the time of calculations and the simplicity of the GUI allows any novice to use the software as well as an expert on the subject. The GUI is also very adaptable to other robots. One needs only to input the Denavit-Hartenburg parameters and computer aided design (CAD) files. The GUI also places blue dots on the computer screen to indicate to the locations where the manipulator can reach and red dots where it cannot. This action ensures safety and efficiency even before deposition.

Introduction

In manufacturing engineering there are lots of kinematic manipulators that perform a lot of specialized tasks but as new ones are made the olds ones loose relevance even though they perform their original function effectively and efficiently. This creates a market of old but effective kinematic manipulators that do not have any documentation to support customers. Without proper documentation on the kinematic manipulator in question it greatly increases the difficulty of the engineer’s job of making sure the kinematic manipulator is operating at nominal efficiency. An efficient kinematic manipulator is usually very big and cumbersome and to properly measure the link offsets and length of joints is not practical.

Our program fixes this problem by using only computer aided design (CAD) files and Denavit-Hartenberg parameters of the manipulator to make a visual representation and control a computer model. We have made a graphical user interface (GUI) that display a three dimensional model of the manipulator and has controls so that an operator can control either the x, y, z coordinates or the joint angles of the manipulator. The GUI also has the three dimensional model plot points as the manipulator’s end effector moves across the screen. It places blue dots where the end effector can reach and deposit and places a red dot where the end effector cannot reach or where the robot reaches a singularity. The points that the kinematic manipulator can reach are recorded and shown in a table on screen that can be exported through Excel into an .xls file for .csv (Comma Separated Values) file. The CVS file can then be read by any basic program and used to control the physical kinematic manipulator. As the program records values for you to later use the CAD file of the robot follows the path so the operator will see the model make the same exact movements as the physical robot. This could be used as a check in industry to ensure safety even before the robot moves.

Methods

The primary software for the displaying and running the simulation and running kinematics calculations was MATLAB 2013a by MathWorks along with the Robotics Toolbox created by Peter Corke (2011). Using this software made it easy to find the manipulator’s end-affecter position as well as run the inverse-kinematics to set the simulation to the desired position. This set-up also allowed for generating a user interface quickly to control the simulation effectively.

The project began from a simulated CAD (computer-aided design) demonstrating the motions of a Puma 560 robot created by Don Riley (2007). Because this base program only contained controls for joint angles, the controls had to be expanded to control and display the coordinate position of the end-affecter. This program also had no implementation of the Robotics Toolbox which had functionality needed for the project.

NX CAD by Siemens was used to create the models of the Nachi robot our project focused on. Once the model was produced, a nominal Denavit-Hartenburg table could be made for the toolbox to run calculations on. A file parser was made to read in the model data from an ASCII STL file type so that it could be displayed in MATLAB.

LOADING AND INITIALIZING:

The loading of the CAD files is handled by a separate program called LoadSTL(). The original code for importing the STL file came from Eric Johnson (2011) submitted to MATLAB Central under the file of STLREAD(). But since the code did not do exactly what was needed, the code was heavily modified to load in a file as a single set of vertices and faces. The code is as follows:

function S = loadstl(filename)

% open the file

fid = fopen(filename, 'r');

if (fid == -1)

error('File could not be opened.');

end

% initialize variables

n = 0;

vnum = 0;

while (feof(fid) == 0)

tline = fgetl(fid);

fword = sscanf(tline, '%s');

% add vertex

if (strncmpi(fword, 'vertex', 6) == 1)

vnum = vnum + 1;

V(:,vnum) = sscanf(tline, '%*s %f %f %f');

end

end

% make face array

fnum = vnum/3;

flist = 1:vnum;

F = reshape(flist, 3, fnum);

% format vertex array

V(4,:) = 1.0000;

% save solid

S.f = F';

S.v = V';

% close file

fclose(fid);

end

The resultant object that holds the faces and vertices of the cad file are used to construct a patch object that can be used with MATLAB’s plotting function. Before the patches are created, any transformation that need to be applied to the model links are done in order for the robot to be displayed properly. For the links to be modified during updates, the links are kept stored in their initial state and have transformation matrixes applied each update.

CONTROLS AND MOVEMENT:

The controls for the simulated model were created so there was an input box to set exact values as well as a slider to move to positions. When the user edits either the slider or input box for a particular control, the called function modified the corresponding control so the input was consistent. Because the joint angle controls are separate from the position controls, not all the controls need to be updated every modification. For example, when moving the end affecter along the X-axis using the X position control, the Y and Z positions do not change. Therefore, when moving by position, only the angle values need to be updated and conversely whenever the angle controls change, only the position controls are updated. The following function demonstrates how values are updated from one of the position control sliders:

function update_position_slider(h, ~)

% h = the object handle that called the function a.k.a. the

% control being updated

% ~ = dummy variable that is not dealt with in this function

% determine which slider is changing

index = 0;

for i=1:3

if (h == PositionSliders(i))

index = i;

end

end

% get value and set textbox

value = get(h, 'Value');

set(PositionTextboxes(index), 'string', roundn(value, -2));

% create array to store new position

Position = CurrPos;

Position(index) = value;

% move model to new position

GotoPosition(Position, 4, 'y');

end

The GotoPosition() function here moves the robot to the specified position from the “CurrPos” variable. The function also moves in incremental steps, updates the angle controls, and moves the robot to positions set. There is a GotoAngle() function as well that goes through a similar process to update the simulation. When the robot is moving to a position or angle, points are plotted: blue indicating the position is valid and red indicating the robot position is invalid or cannot go to the position.

VELOCITY AND ACCELERATION

Because the current instruction set for controlling the robot has non-standard settings for acceleration, any control over the robot speeding up or slowing down during movement would need to be software driven. The way to specify these values were to make the point positioning time controlled instead of being arbitrarily incremented. The movement is split up into three distinct sections: acceleration, constant velocity, and deceleration.

The only distinction that needs to be made in the code besides the three sections is to detect whether the constant velocity section is a factor (i.e. there is enough distance between points that the robot can reach maximum velocity such as the first graph). The algorithm detects this and finds the time boundaries as well as gets the change in position for each axis. The difference in positions is important because, as the graphs indicate, the functions used get the proportion of difference from the start point (0.0) to the end point (1.0). This proportion is multiplied by the change in position and added to the start position to specify the correct position at the time specified.

function GotoPosition2(Position, timestep, trails, maxVel, accel)

% set the sliders in case command did not come from controls

for i = 1:3

set(PositionSliders(i), 'Value', roundn(Position(i), -2));

set(PositionTextboxes(i), 'string', roundn(Position(i), -2));

end

% get the changes in position

dx = CurrPos(1)-Position(1);

dy = CurrPos(2)-Position(2);

dz = CurrPos(3)-Position(3);

dist = sqrt(dx^2+dy^2+dz^2);

% set time parameters

if maxVel^2/(2*accel)<dist/2

ttotal = maxVel/accel+dist/maxVel;

tstart = maxVel/accel;

tfinish = ttotal-tstart;

else

ttotal = 2*sqrt(dist/accel);

tstart = ttotal/2;

tfinish = tstart;

end

OldPos = CurrPos;

% loop timesteps until destination is reached

for i = 0:timestep:ttotal

if i<=tstart

f = accel*i^2/(2*dist);

elseif i>=tfinish

f = 1-accel*(i-ttotal)^2/(2*dist);

else

f = (maxVel*i-maxVel^2/(2*accel))/dist;

end

% create timestep position

pos(1) = OldPos(1)-f*dx;

pos(2) = OldPos(2)-f*dy;

pos(3) = OldPos(3)-f*dz;

SetPosition(pos, trails);

% set angle sliders for each point

for j = 1:6

set(AngleSliders(j), 'Value', roundn(radtodeg(CurrAng(j)), -2));

set(AngleTextboxes(j), 'string', roundn(radtodeg(CurrAng(j)), -2));

end

end

SetPosition(Position, trails);

% set angle sliders for each point

for j = 1:6

set(AngleSliders(j), 'Value', roundn(radtodeg(CurrAng(j)), -2));

set(AngleTextboxes(j), 'string', roundn(radtodeg(CurrAng(j)), -2));

end

end

The angle controls are constantly updated as the model moves while the position controls are set to the future position. This allows for the user to see the intermediate steps while still letting the user see where the robot is moving to. This method of control updating is also how the angle controls are set up with position incrementally changing and the angles displaying the end pose.

EXPORTING DATA

Our implementation for exporting data has a ‘record’ button for when data needs to be stored in a global object. This data structure can be modified to contain any array of data, the current implementation contains the joint angles of the robot at all positions. This can easily be modified to contain the speed, timing, position, or other derivable values. A check is done every time the model is updated as to whether more data needs to be stored in the object.

% save position

if update_record == 1;

data = getappdata(0, 'CSV');

data = [data; Angles];

setappdata(0, 'CSV', data);

set(csv_table, 'Data', data);

end

The data being stored, when complete, can be exported as a Comma-Separated Values file (.csv) and can be opened and manipulated by any spreadsheet application. When data is set to export positions and either velocity or time difference, the data can be formatted and sent to the robot to do the requested operations.

Results

The simulation could represent the real-life kinematic robot with approximately a 0.5% error and a maximum error of 1.16%. The model can accurately and fluidly move from positions, poses, and points to others. The operator can easily control the simulation by joint angles or end affecter position and export that data. The program could also read in and simulate path data and run through the points. For future research we would like to perfect the nominal values of the velocity, acceleration and jerk. In acquiring the nominal values we can use them to make the deposition process much smoother and efficient while depositing. In future research we would like to make the program open source and allow anyone to use to make engineering manufacturing more user friendly for anyone who uses a kinematic manipulator for laser sintering.

The ending project came out to be as hoped with required controls and interfaces that the user needs to successfully manage the robot. There are controls for manually controlling the robot as well as running through path data to simulate the model’s movement. There are also settings for the velocity and acceleration of the robot from point to point. Checks have also been implemented to account for incorrect movement and accommodate for it visually by displaying indicators for impossible positions. The project as a whole was completed as needed to meet the requirements defined.

Nomenclature

Our Nachi seven axis kinematic manipulator has a spherical wrist which greatly reduces that mathematics with forward and inverse kinematics because it allows us to decouple the positioning and orientation of an object to as great an extent as possible (Spong 18). Simply put because of the intersecting axes of our manipulator we are able to reduce our seven axis manipulator to three axes making the calculations faster and in further research efforts allowing to manipulator to be controlled in real time while extruding material.

One of the first things the team had to do when starting our research project was determine the Denavit-Hartenberg Representation for the Nachi seven axis kinematic manipulator. The Denavit-Hartenburg Representation or D-H convention is used because by only using four basic transformations you are able to establish any possible configuration of the manipulator. You use only four parameters length, twist, offset, and angle. We can do this because we have the freedom of choosing our own origin and coordinate axes for the system. Since we have a spherical wrist manipulator we can cleverly place it such that is reduces the seven axes robot to three axes (Spong 65-71).

Acknowledgements

We would like to thank Todd Sparks and Nandish Shivaprasad for all their help and support throughout the research process. Without their help we wouldn’t have gotten the modeling and values that helped complete the project. Nandish created the CAD models used to visualize the robot and Todd Sparks helped with analysis between our model values and the physical manipulator values to near acceptable values. Lastly, thank you Dr. Liou for being our research advisor, allowing us to get our first hands on experience with research and helping to make this project possible. Thank you again for all your help.

Resources

Spong, Mark. Robot Dynamics and Control. United States of America: John Wiley & Sons, 1989. 18. Print.

Spong, Mark. Robot Dynamics and Control. 1st Edition. United States of America: John Wiley & Sons, 65-71. Print.