�

The team studied the kinematics of the arm to understand its motion.� The robot arm moves in 3-D space, so a natural instinct was to attempt to analyze its movement in three dimensions.� However, this method of analysis would have been very complicated and unnecessary.� The analysis was simplified to two dimensions, because only the movement in the plane of the arm needed to be considered.� The arm�s angle of rotation about its base was not important to the kinematics.� In other words, the orientation about the z-axis (vertical axis) was ignored.� Further simplification of the kinematics analysis procedure was still desirable.� The control strategy was to control the movement of the gripper in one direction at a time, either horizontal or vertical.� Therefore the kinematics needed to address the speed of the gripper moving linearly in one direction at a time.� In other words, the arm wouldn�t rotate about its base and extend the gripper at the same time.� Considering this from a kinematics standpoint, the kinematics of the arm was simplified to a three-link open chain.� The arm is depicted as a simple linkage in Figure C.1 in the Kinematics section of the Appendix.� The analysis is shown in detail in that section.

The team wanted to make the arm as simple to operate as possible for the user.� Optimally we would have implemented speed control at the shoulder, elbow and wrist joints.� Incorporating the ability to adjust motor speeds using the results of the kinematics analysis would have allowed the user to move the gripper in one direction, either horizontal or vertical, at a constant speed.� This would have incorporated equations (7), (11) and (12) from the Kinematics section of the Appendix, to regulate the motor speeds.� Using this control scheme would have required some way to measure the joint angles, such as encoders or potentiometers.� This control strategy was not implemented due to time limitations.

Another strategy for controlling the arm lies at the other extreme for ease of operation for the user.� This strategy is to control each degree of freedom individually.� No speed control would be necessary, and therefore there would be no need to measure the joint angles.� This control strategy was developed initially, and maintained as a backup.� However, a more user-friendly strategy was implemented in the final arm.

The control strategy used in the final design of the arm is a combination of the single motor control without speed control and the strategy of controlling three degrees of freedom simultaneously using speed control.� The team designed the controls similar to the single motor control structure.� However, the ability to control two degrees of freedom was added.� Using relationship (7) in the Kinematics section of the Appendix, the control code was structured so that the wrist bend would always function in unison with either the shoulder bend or the elbow bend.� This is a great benefit over simply controlling each degree of freedom individually, because it forces the grippers orientation with respect to the ground to remain fixed while the elbow or shoulder bend is actuated.� This has many benefits to the user.� For example the operator could use the arm to pick up a glass of water and the controls would make sure that no water was spilled by keeping the gripper level with the ground.

There are several disadvantages to the control strategy we used, however.� For one the gripper cannot be made to move only in a horizontal or vertical direction, but will always move in a combination both horizontally and vertically.� Also, the gripper�s linear speed is not fixed in this control strategy, and does not remain constant as the arm moves.

10.2 OOPIC AND CODE DEVELOPMENT

The OOP in OOPic stands for object-oriented programming.� In this scheme, objects are created and various properties of these objects are manipulated in order to achieve the desired output.� In the OOPic, all of the embedded controller�s hardware circuits are grouped into objects.� Now, instead of each of the controller�s circuits having to be called individually, circuits that will act together in the code are given one object name. This, once the programmer is familiar with the objects, can greatly simplify how the code is written.� This section recounts the process of learning object-orient programming and how the code evolved as the team�s knowledge increased.� It also touches on why control of the arm using the kinematic equations was not used and what multi-motor control is implemented using a simplified kinematic approach.

The first task was to become familiar with the basics of OOPic programming and operation.� First off, it was decided to program in C because that is the language that the team had the most experience with.� Then, as a test, a sample code that was provided by Savage Innovations (the OOPic�s manufacturer) was downloaded into the OOPic.� This code was to simply have a LED flash on and off once a second.

The next task was to modify the sample code by integrating a Virtual Circuit.� This again was provided in the OOPic�s manual.� It became evident early that Virtual Circuits would be the most important part of the control code, so it became vital to become familiar with their operation early in the programming phase.� A Virtual Circuit links a property of one object to the property of another.� This allows the code to constantly monitor a specific value and have this value continually updated in the code.� This is important for monitoring things such as joystick input and system feedback.� Virtual Circuits also allow the code to enter events, or subroutines, which are vital to the system�s operation.

�� After becoming familiar with the operation of the OOPic, Virtual Circuits, and event driven programming the team began to develop code for single motor control.� This code involved reading a joystick input, determining whether the input was for motor forward or backward, and then entering an event to carry out the operation.� At first it was built into the code to send a quick ramp up or down of the PWM signal being sent to the motor control board for starting and stopping the motor respectively.� It was later found that the motor control boards would automatically ramp the motor speed up as long as the motor enable switch was reset every time the motor was started.� This was integrated into the single motor control code along with a PWM step down for the motor slow down event.

�� The final phase of the programming considered trying to get all of the motors to act together through the kinematic equations and feedback using potentiometers.� The first test codes written were to test the potentiometers connected to the OOPic.� This was done by turning on various input/output lines depending on potentiometer position.� The potentiometers were then used to vary the PMW output to the motors and thus affect the motor speed.� Both of these codes worked very well.� Unfortunately, the time that it would take to implement a system with the potentiometers and kinematic equations was too long, and the team ran out of time to make an attempt at this.� Next year�s Gateway team should have an easy time starting where this year�s team left off and be able to construct a completed speed-control system with potentiometer feedback fairly easily.

�� In light of these problems it was decided that multi-motor control to keep the arm operating in one plane at a time was not feasible to accomplish by the end of this academic year.� It was decided, though, that a simplified multi-motor control scheme could be implemented with little problem.� This scheme would not require the use of a feedback system.� Basically, the simplified control scheme ensures that the gripper will stay level with the ground so that the orientation of the item in the gripper would not change after it has been grasped.� This is particularly useful when the user does not want objects, such as a glass of water, to be tipped when he or she is manipulating it.

�� One final feature that was implemented was a one second delay of the gripper actuation.� This feature is intended to protect against an inadvertent movement of the joystick that would normally cause gripper movement.� The benefit being that an accidental movement of the joystick will not allow the object in grasp to be released.

�� In order to implement the control of 6 motors in a user-friendly fashion, 3 joystick modes were used.� There are a total of 12 operations that are controlled by one four-way joystick and three switches.� A list of the mode operations is shown in Table 10.1 below.� These operations were assigned in an intuitive fashion to simplify use of the arm.� Note that the shoulder bend and elbow bend commands incorporate the wrist leveling algorithm.�

Table 10.1 � Control Modes

MODE	LEFT/RIGHT	FORWARD/BACK
1	Shoulder Twist	Shoulder Bend
2	Wrist Bend	Elbow Bend
3	Wrist Twist	Gripper Open/Close

Table of Contents

Section 9: Control Hardware

Section 11: Future Considerations

X