ME 469 Project 2: Puma Development Projects

Let's face it: the Puma is a little old and a little bit cheesy. The purpose of this project is to improve the robot and the computer control system for it. Groups can choose one of the following possible improvements for their project.

These project descriptions are intentionally open-ended, (like the "real world") and as such may appear incomplete. An element of each of these projects is actually determining the exact scope of the project, which will typically, although perhaps not always, require you to consult with the instructor. An important part of the project report will be clearly delineating what the scope of the project is.

Improving the GUI (Number 1).

Currently, the GUI has only slightly more capability than the terminal interface. One improvement would be to add some "intelligence" to the system that is not present in the terminal interface. Certain commands, such as DRAW or MOVE sometime crap out because the manipulator can not move in either a straight line in Cartesian coordinates, or a straight line in joint coordinates from the starting point to the desired end point. For example, if the end effector has to move through the body of the robot, or the trajectory takes it outside its workspace or through a singularity, it complains and gives some sort of error signal like "INVALID SOLUTION." We need to be able to recognize the error command that the robot gives us and to take "appropriate" action.

Required activities: You can divide the responsibility for this project in any way that your group decides is appropriate, but this project initially appears to have the following distinct duties, some of which are relatively easy and some of which are relatively hard.

  1. Determining what the error messages are and what they mean (easy -- 10 minutes).
  2. This project is "open-ended" to the extent that you must determine the scope of the project. Clearly, you don't want to program a response for every error message, and so you have to decide which error messages you will be able to deal with and what the appropriate responses will be. Determining whether the arm moves outside the workspace should be pretty easy. Whether it interferes with itself will be a little harder. Determining whether it goes through a singularity perhaps even harder.
  3. Determining the appropriate response. If a user wants to DRAW through the manipulator, is the appropriate response to determine some intermediate point such that a straight line path to the intermediate point to the final point is admissible, or should it be a circular arc or spline, or should the user be given a choice? (Harder -- this may require some thought). Perhaps a graphical input that would offer the user a choice would be appropriate?
  4. Writing the report. This probably will not be too short, so the duty of writing it will not be trivial. (Time consuming, but easy).

Improving the GUI (Number 2).

The GUI could also be improved by adding other higher order intelligence. It appears that the robot can only go in a straight line in Cartesian space or joint space. Other possibilities may be more desirable. For example, a trajectory that minimizes joint torques, joint velocities or stays far from singularities may be desirable. In such a case, the user should enter the starting and ending configurations, and the program would determine the trajectory.

Another possibility would be for a user to input a mathematical description of the path of the end effector, or to have a set of "basis" motions, i.e., circles, ellipsoids, etc.

Another possibility is to mimic a common manufacturing problem. For example, for spot welding, drilling, etc., which would require specifying a set of points and orientations on a surface, along each of which the tool must move.

Required activities: You can divide the responsibility for this project in any way that your group decides is appropriate, but this project does require rather distinct duties, some of which are relatively easy and some of which are relatively hard.

  1. Problem formulation: what trajectories are you going to implement? Why are they better than straight lines?
  2. Algorithmic implementation: what are the computations necessary to accomplish the desired trajectory, and how would you implement them in a computer program?
  3. Programming: you need to write a program that can be interpreted by the GUI to write the code to the VAL program. For example, if you want the end effector to move in a circle, you may have the GUI write to a file a series of DRAW commands that approximate the circle, which then could be transferred to the robot controller as a VAL program.
  4. Writing the report (Time consuming, but easy).

Other Possibilities.

If you think that all of these projects are stupid or otherwise undesirable, you can propose your own. The instructor is happy to consider alternative project proposals that are educationally substantive.

Return to the ME 469 Homepage.


Bill Goodwine (jgoodwin@nd.edu)
Last updated: February 28, 1999.