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.

Design and build gripper for the robot.

This project would entail determining how the gripper is really actuated. When a OPEN or CLOSE command is given, you can hear a clicking sound. The gripper may actually be pneumatically actuated (the hole in the side of the arm may be for air pressure). Alternatively, it may be electrically actuated. You will have to consult the manual, and perhaps take the manipulator apart to determine this. A well-done project will actually have the gripper built and attached to the arm. Whether or not it is actually built, one component of a good design is that the gripper will have to be made from parts that are easy to machine or can be purchased and be comprised of available materials and components. The instructor will provide catalogs for the necessary catalogs for parts that would be necessary of the actual design. (We have some funds for the course that can be used for machining expenses, etc.; however, it can not be too expensive). An adequate project will end with a good design. Finally, it must not be too hard to attach and detach from the manipulator so that the current end effector with the "CSM cues" can easily be interchanged with it.

Required activities: You can divide responsibilities for this project in any way that your group decides is appropriate, but this project initially appears to be composed of the following distinct duties.

1. Feasibility study: before any major effort is expended, you must determine whether the project is even feasible. The manual is full of references to the gripper, but you must determine whether or not the Puma that we have can actually utilize one.
2. Interface with robot: is it pneumatic or electric? Does the interface device within the robot actually work? If not, can it be fixed? The gripper will have to interface with the arm in some manner, and we have to determine how that's done.
3. The actual design of the gripper: it must engage the manipulator and actually be able to pick things up. How small of an object can it pick up? How large? What kind of force can it exert? You will need to delineate in the the report what engineering design trade-offs influenced your design.
4. Building the gripper. You will have to work with the machinist to get this built. We have to work within budget constraints as well.
5. Writing the report. (Not hard, but time-consuming).

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. Perl/Tk programming. The GUI is written using Perl/Tk. Perl is a programming language that is commonplace for CGI web programming and other "system administrative" type programs. Tk is a set of "widgets" that make windows type programming easy. Perl/Tk is a "module" for Perl that makes a lot of the Tk widgets available to Perl. While Perl is somewhat "object oriented" Perl/Tk is very object oriented. Therefore, the group member(s) responsible for the implementation of the algorithms will have to dedicate some time to learning Perl. (Very hard, but will got LOTS of help from the instructor, and will learn a new programming language and paradigm).
5. 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.