Robot D-H Simulator Using Matlab Project

By Calvin Phillips

December 17, 2010

Introduction

A lot of simulators that have been made for robotic arms only show the simulation with premade parameters. For this project I decided to create a robotic arm simulator that allows for the creation of any type of robotic arm that has six joints or less. The robotic arms would be made using the Denavit-Hartenberg (D-H) parameters for the robot. The simulator will allow for the joints of robot to be revolute or prismatic. This allows for the user to create a simulator for an arm that has or has not been made before. It allows for testing of robotic arm movements before they are put into production.

In this paper I will talk about some of the background behind robotic arms. I will also talk a little about the (D-H) approach to solving the kinematics of a robotic arm. Then, I will give information about my approach to making the robotic simulator and why that approach was chosen. With the approach, I will talk about why my method for creating the robot simulator works. After that, the results will be shown to give my approach validity. In the end, I will wrap up everything that I have done, and talk about what needs to be done in the future to make the simulator more robust and efficient in simulating robotic arms for the user. Overall, I believe this project to be a success, but there can always be improvements made to make the program run better and more efficiently.

Technical Background

Robotic arms are programmable manipulators that have a lot of similarities to a human arm. Each of the links of the arm are connected together by joints. Unlike human arm joints, which are all rotational joints, robotic arm joints may have the ability to change the length of the link (prismatic joints). The end of the arm of a robot is usually called the end effector. It can be seen as the “hand” of the robot. End effectors are pretty much the work part of arms and can be designed for many different tasks. Robotic arms can be made to be moved manually and autonomously as well. It all depends on what the robotic arm is needed for.

TheDenavit-Hartenberg (D-H) approach is one of the most commonly used ways for creating a reference frame for robotic arms. This method was produced by JaquesDenavit and Richard Hartenberg. With this method, the transformation from one joint to the next is created by using the product of four simple transformations which are multiplied together from left to right in this order:

1.)A rotation (Θ) about the frame’s z-axis

2.)A translation (d) in the z direction

3.)A translation (a) in the x direction

4.)A rotation (α) about the frame’s x-axis

Each of the transformations uses the frame from the joint before as its starting place. These frames are made so that the z-axis is in the direction of the joint axis. If two consecutive z-axes intersect, the x-axis of the latter frame is the cross product of the two z-axes. If they do not intersect, the x-axis can be made to point in any direction as long as it is perpendicular to the z-axis of the frame. This is convention is used to create a minimal representation of the joints. Because the each joint frame is based on the frame of the joint before, the kinematics of each of the joints are much easier to solve for. This also makes it easy to find the position of the final joint as well.

Approach

For this Project, I programmed the robotic arm simulator using Matlab. I chose Matlab because it deals with matrix math nicely, and it has its own general user interface (gui) system built in. The program works by first asking the user if a .mat file is saved with the parameters need to create the robot. If the user says yes, the program gets the name of the .mat file and then creates the robot based on the parameters in that file. If the user says no, then it goes through the system of getting the D-H parameters from the user. Once the program has the needed parameters, the program creates the robot simulator with all of the user interface pieces that are needed.

Getting D-H parameters

In order to get the D-H parameters from the user, I decided to use the command window that is in Matlab. I chose to use the command window because it seemed like the simplest way to have the program interact with the user. I also thought it would be a little quicker to have the user type in all of the parameters for one joint all at one time as opposed to typing one parameter in at a time into a chart. When the program begins, it will ask the user for the number of joints that the robot arm will have. The program allows the user to put in a joint number that is less than 6. After the amount of joints is chosen, the program will ask for the D-H parameters for each of the joints. The parameters have to be put in joint by joint. After the parameters are put in for a joint, the program asks whether the joint is revolute or prismatic. Once all the joint information is given, the program then asks about the height of the initial joint. I chose to ask for the initial height, because it gave the user another degree of freedom when making the robot for the simulator. Here is an example of how using the initial height can change the look of the simulator’s representation of your robot.

Figure 1: Picture of a SCARA robot

After the parameters for the joints and the initial height are put in, the program will ask the user program will ask the user a series of questions to get the orientation of the initial joint. The program assumes that z-axis of the initial joint frame is either parallel or perpendicular to the ground. It also assumes that if the z-axis is perpendicular to the ground, the direction of the z-axis is pointing up with respect to the world. I made this assumption because all of the D-H representations of robots that I have seen so far do not have the initial z-axis pointing into the ground. The questions will ask about the z and the x axis of the initial joint and how they are orientated. Once it gets the information about the orientation, it will ask the user to input a name that will be the name of the .mat file that has all of the information to simulate the user’s robot. I chose to save out the .mat file because it allows the user to create a simulation for a robot that has been made before without having to reenter the parameters. This makes using the simulator faster in the long run.

Figure 4: Example of how the entering the parameters works

Creating the Work Area, Links, and Joints

When creating the work area for the robot, I took the height of the initial joint and the length of the links into consideration. The work area is centered on the position of the initial joint. The floor is set in the negative direction and is set at the negative of the initial height. The ceiling and the sides of the work area is set to 30mm longer than the sum of the all the largest length of the links. It takes into account whether the joint is prismatic or revolute. This is done because if a joint is prismatic, the length of that link could change.

The joints are represented by an xyz-frame. For each of the frames, the x-axis is represented by a red line, the y-axis is represented by a green line, and the z-axis is represented by a blue line. I chose this representation because it lets the user see how each of the joints is moving a lot easier than if there was no lines drawn for the axis. The placement and the orientation of each of the joint frames will be determined by the initial joint position and the D-H parameters given to the program. The length and the thickness of the axis lines are fixed sizes, but if the 2 of the joints have the same origin, the program will draw the lines for the second joint a little thinner and a little longer. This is to be able to tell the difference between 2 joints at the same origin.

Figure 5: Example of how the length and width of the lines for the axes are different if the origins of 2 joints are the same.

The links for the robot arm is represented by black lines. The line connects the origin of one joint frame to the origin of next joint frame. A line is also drawn from the floor to the origin of the initial joint frame if the initial joint is not on the floor of the work area. Because the joints can be prismatic, the length of the links can change. No matter the length of the link, the line will always connect the 2 joints.

User Interface

Once the program gets all of the parameters that it need, the user interface with the robotic arm simulator will pop up. On the user interface, there will be sliders and edit boxes for each of the joints that the robot has. If the joint is revolute, the slider is set to work from -180 to 180 degrees, and the edit box will only accept entries between -180 and 180. If the joint is prismatic, the slider is set to work from -400 to 400 mm. The edit box for prismatic joints only allows for entries between the slider settings as well. When the slider changes, the number in the edit box will change to correspond with what the slider is showing. The same thing happens the other way as well. If the number is changed in the edit box, the slider will change to correspond with the change in the edit box. Each edit box, slider set will be labeled based on which joint it controls and whether the joint is revolute or prismatic. If the joint is prismatic, the joint controls will have the label “d” and the number of which joint it controls. If it is revolute, it will have the label “Th” and the number of the joint.

The user interface also has a “go home” button. The purpose of this button is to have the robot go straight to its original position. The original position is based on the D-H parameters that were given to the program by the user or a .mat file. I decided to add this button so that the user could easily get the robot back to its original position without have to set each of the joints one by one. This will save the user some time.

The final thing that is shown on the user interface is the XYZ and the OAT positioning of the end effector. The positions are updated after one of the joint settings has changed. The positions that are displayed are the coordinates and orientation with respect to the world coordinates. I believe that having the position with respect to the world, instead of the initial joint frame, would cause less confusion with the user. Since the world’s origin and the initial joint frame’s origin are always in the same position, the XYZ and OAT are always with respect to the initial joint’s positioning, not its orientation.

Figure 8: Picture of what the XYZ and OAT outputs look like

Results

To test how well my robotic arm simulator works, I wanted to look at 2 aspects of it. The first is how the simulator’s robot looks in comparison to actual robots that have been built or robots that have been created in a drawing. This is to see if the way I chose to represent the robot allows for the user to imagine it as an actual robotic arm. To test this, I input the D-H parameters of previously made robots, and compared the pictures of the simulated robot to the pictures of the actual robot. The second part that I tested was the position of the end effector and the give coordinates for the end effector. This is to test and see if my simulator is actually moving in the right directions so that the end effector ends up in the correct coordinates. To do this test this part, I gave my program the D-H parameters for the Puma560, and compared the position that my simulator is outputting to the position that is given by the Robotics Toolbox for Matlab for the Puma560.

Testing the Look of the Simulator

Testing the Position of the End Effector

Table 1: The results for with all of the thetas being 0 degrees

all theta are 0 degrees
x / y / z
Toolbox Puma 560 simulator / .452 m / -0.15 m / .432 m
My program's Puma 560 simulator / 452 mm / -150 mm / 431 mm

Table 2: The results with all of the thetas being 30 degrees

all thetas are 30 degrees
x / y / z
Toolbox Puma 560 simulator / .084 m / -0.125 m / .449 m
My program's Puma 560 simulator / 83.8 mm / -124 mm / 449 mm

Table 3: The results with all of the thetas being 90 degrees

all thetas are 90 degrees
x / y / z
Toolbox Puma 560 simulator / 0.15 m / -.020 m / 0 m
My program's Puma 560 simulator / 150mm / -20 mm / 0 mm

Table 4: The results with thetas 0, 30, 45, 60, 90, 0

0, 30, 45, 60, 90, 0
x / y / z
Toolbox Puma 560 simulator / -.038 m / -.150 m / .347 m
My program's Puma 560 simulator / -37 mm / -150 mm / 347 mm

Table 5: The results with thetas 0, 90, 0, 45, 0, 60

0, 90, 0, 45, 0, 60
x / y / z
Toolbox Puma 560 simulator / -.432 m / -.150 m / .452 m
My program's Puma 560 simulator / -431 mm / -150 mm / 452 mm

Note: The reason that the last two set of pictures do not match up as much as the first 3 is because the axis values for the Robotic Toolbox simulator get inverted.

Conclusion Future Planning

Overall, the project went well. In comparing my simulator’s creation of a robot arm to a picture of an actual robot, I believe that were pretty similar. It does not look exactly like the actual robot and in some cases, my connectors do not look like connectors for the actual robot, but it always has the same joint movements as the actual robots. Also, not having a robot look for my simulator helps keep the imagination of how the robot should look up to the user. In addition, I believe showing the axes for the joint helps the user to see joint changes in all conditions. Without the axes, there may be some positions that the robot could get into and changes could become hard to see. With that I think that the project was a success.

Even though, most things went well, there are things that can be fixed and improved upon in the future to make the simulator work better. The first would be in how the parameter entry system works. I would like to add more error checking to the entry system that already exists. For instance, when the system asks’ a yes or no question, the program assumes no if it is not yes. In the future, I would add more checking so that if the answer is not yes or no, the system will ask again. Also, when the system asks for the name of a .mat file, the system may stop running if the filename was put in incorrectly. There should be more error checking in this part so that doesn’t happen.

Adding more than one way to let the user enter the parameters would be the next part that I would like to add to the program in the future. The program could somehow let the users decide on how they want to enter the information that is needed. I could add a user interface so that the user can enter the information like in a chart if that was the way the user wanted to enter the information. Another add-on that would help the user would be to have the system to allow for changes in an existing .mat file so the user can make a few changes without having to input all of the parameters again. Because I would like to give the user full control over all of the parameters, I would like to have the user be able to decide on the minimums and maximums for the joint movements. This would allow the user to be capable of seeing the robot simulated with the same restrictions that the actual robot will have.

The final part that I would like to add to the program is to have the length and width of the lines be created more dynamically. As the program stands now, these parameters of the lines are set parameters. This means that if someone was trying to simulate a larger robot arm, the axes for the joints will be a lot smaller in comparison, making harder for the user to see. If the axes were made to change in length and width dynamically, the lengths would be longer and wider as the lengths of the links became longer. This will help the user to see everything better visually.