For this project, we had three objectives. The first was to build a robotic arm, capable of 2 degrees of freedom and actuation of an end effector, in this case a writing utensil (raised or lowered), and simply demonstrate its range of motion. The second was to move that robotic arm through multiple different positions and record the positions as points on the plane of motion. Our final objective was to write a program that could record manually input positions of the robotic arm and then play them back through motor drive.
As seen in the images below, we built our robotic arm as a series of two motors mounted in a linear fashion, mimicking a human arm with a shoulder that only rotates about a single axis. The arm construction of this was actually very simple, requiring only a few linkages to firmly connect each motor. There were two lengths of the arm controlled by motors, similar to the Humerus and Radius/Ulna in a human. Each length was measured using a ruler for future programming use.
The arm, being so far cantilevered away from the CPU, created a stability problem since the CPU is simply not all that heavy. In order to firmly affix our robot to the work surface, we lines each leg of the CPU with rubber bands, increasing friction and preventing unwanted rotation, and we built a small platform on which to rest heavy objects like textbooks, providing a counterweight to the heavy arm. We also added a roller ball to the end of the arm. When the pen was placed on the page, it takes the weight of the arm, but when it is flipped up, the roller ball is able to take the weight of the arm. These interventions greatly improved stability.
At the end of the arm, we placed a Medium Motor, and connected it to a specially outfitted ball point pen. Held into its Lego mount by many rubber bands, the pen could be raised and lowered by rotation of the medium motor a predetermined amount. This worked quite well to actuate the writing action of the robotic arm.
Fig. 1: Overhead view of robotic arm on drawing plane
Fig. 2: Off axis view
Fig. 3: Side View
Range of Motion:
As shown in the video below, the robot is able to move through a large, but abstract range of motion. When fully extended, the arm can move in a 35cm radius semi-circle, however, due to constraints imposed by the physical size of each motor, the robot can only complete a portion of the small semi-circle. This is difficult to describe, and best illustrated in the video below. Though it may be hard to tell, the usable range of motion is enough to cover an 8.5”x11” sheet of paper if placed in the right position relative to the CPU position.
Fig. 4: Code to move arm through largest and smallest range of motion
End Effector Position
The second objective listed above is the need to calculate end effector positions. To do this, we used a simple equation to calculate the x and y positions, shown below in the code for this section. We mapped out x and y axes on the work surface our robot was mounted on, measured in centimeters, with the first pivot point of the arm at (0,0). Moving the arm manually through multiple positions, we were able to output relatively accurate position information in our coordinate frame. We saw error of 1-3 centimeters in each measurement, but we attributed this to “wiggle” in the motors, only amplified with both motors mounted in series.
Fig. 5: Code to calculate end effector positions
The final objective was to record manually input positions of the robot arm and to play them back in sequence. In order to achieve this, we recorded position information in the form of motor angle data for both main joints every second for 5 seconds. During these 5 seconds, we moved the arm through various positions. This position information was recorded to a 2D array, concatenated with the new position every second. After a brief pause, the robot passed these values two by two to the motors in sequence, with enough of a pause for the observer to confirm correct playback location. Again, we saw some error here, but it was still on the order of 1-3cm in each dimension, likely attributable to wiggle room in the motors.
Fig. 6: Code to playback arm positions
Overall, this project was quite a success. Our robot was pretty sturdy, and able to perform all necessary functions without any deficits. The wiggle room in each motor contributed to a fair amount of error, but this was difficult to fix without gearing the whole robot. Given that we did not discover this would be a source of error until we had the robot functioning, it was much too late to implement a gearing system. In future robotic arm platforms, it would be wise to gear down the motors so that error like this is less apparent.