# Difference between revisions of "RobotArtist"

### Introduction

In this lab students designed a robot arm, controlled by MATLAB, that can draw pictures.

## Teams

### Team Blue Steel:

The Blue Steel Robot

Preliminary Designs

The purpose of this lab was to design a robot arm capable of drawing a square inscribed within a circle. To do this, we used servo motors, which sent pulses dictating the angle to which the arm of the robot would rotate. We built the foundation of the robot using a piece of aluminum, two bolts, and two washers. The foundation was attached to the table using a "c" clamp to ensure that the robot would not move while drawing. Elevated above the foundation was one of two servo motors bolted onto a platform. Screwed to the servo motor was an aluminum rod, which acted as the forearm, connecting both servo motors, which served as the elbow joint and the wrist joint. Attached to the second servo motor was a solid works piece which functioned as a hand and held the pencil using a screw. When we first ran the robot, we encountered a design flaw in that the marks the pencil was making on the paper were too light to be seen. To fix this, we tightened the screw holding the pencil in the hole in an effort to keep it in place. This was an effective solution because on our second trial the marks of the pencil became visible. Beyond this minor setback, no other design problems were encountered.

Proof of the Success of our Robot : Youtube Video Matlab Script File:ServoCalibrateBlueSteelAndrewAfternoon.m

### Team Unspecified Objects:

Lucas is excited for the Mini Project! :)
Bledsoe, Kara, Chen, Lucas, Gustavo, and Helen doing MATLAB

#### Write Up

##### Overall Idea:

After perusal of robot arm templates, Team Unspecified Objects (TUO) decided upon a generic design utilizing a three-bracket system. One bracket connects the lower arm to servo motor A and the base. Another bracket connects an additional servo motor B to the lower arm. The final bracket connects the upper arm (holding the pencil) to motor B.

Front View
Top Elevated View

For our code: First we input the x and y values that correspond to the circle inscribed in a square into the invKin function. This output is thetaA and thetaB. These values are the input for gotoAngles, which provides pcA and pcB. We send these PC values to the E5 shield , which get assigned to motors A and B. This moves the arms the desired amount in the appropriate direction, producing the intended picture.

##### Issues:
• Problem shooting with design: We had to adapt the original template to fit the pieces with which we were provided.
• Translating code from theory to actuality: We needed to utilize properties of inverse kinematics to obtain desired outputs.
• When attempting to access values using gotoAngles, we received an error saying: attempt to reference a non-structure array.
• The next MATLAB Error read: error using atan2, inputs must be real. This again was related to gotoAngles.
• After that, we thought that our code just stopped functioning.
• The drawing itself was slanted.
##### Solutions:
• Trial and Error with design: As the robot arm developed, we were better able to discern what components provided the best structure for the desired motion. Our design became more practical. It was based on the template but became more concerned with functionality. Each TUO member had a piece of the arm to construct, and Gustavo put the final pieces together.
• Cracking the code: We utilized properties of inverse kinematics to obtain desired outputs, keeping in mind the inputs and outputs required and produced by our functions.
• Righting the wrongs: When running a final draft of our script in MATLAB, we noticed a disconnect where the script stopped functioning. We brainstormed what we thought could be the cause of the abrupt end in execution. Lucas took charge of locating the error.
• Lucas and Gustavo brought up that using an angle with a degree value greater than the absolute value of 60 gave a pc value that was out of range for the servos. So we adjusted the x and y values so that they provided ideal numbers for pcs.
• Eventually we discovered that our issue was not in the content of the code, but in the execution of it. We did not give the robot arm time to pause between each movement, so it ran through all the points too quickly. After adding the pause the arm moved appropriately.
• We rearranged the motors so that their default positions were synched. When the script was run again, the picture came out correctly.

### Team GOAR:

Zip file:

File:E5 Lab 8 Code GOAR.zip The Artistic Robot Arm Team GOAR

Our Design: In designing our robot arm our goal was to have an arm with two different joints that could ultimately draw a circle inscribed in a square. We tried to find parts that went well together. Originally, we used a bracket to encase the motor and give the first joint of the arm its range of motion. During construction, the bracket seemed like the sturdier option. However, upon completing the arm, we noticed that it allowed for vertical instability; the first joint was not wholly rigid. Therefore, we decided to remove the bracket and attach the first arm to the motor with a washer.

The washer was then attached to a metal tube that made up the first arm. The other side of the first arm was attached to a metal shelf-bracket that held the second motor. The second motor, in turn, was connected to the plastic robot arm created earlier in the semester. This arm holds the pencil.

### Team Not the Incredibles

Initially, we were not convinced that it would be possible for the arm to draw a circle and square because of the limited rotation of the motors. We decided to position one at a right angle to the other, to maximize the range of points that we could reach. At first we had defined the metal arm as the second arm, but then realized that the plastic arm would probably not be long enough to support it. Structurally, we also had issues with the arm wobbling, so needed to use different screws. We had physical difficulties matching parts that fit together. We also encountered problems with malfunctioning motors and shields. In the end, the joint between the two arm sections was still too weak to provide sufficient support, causing the hand to sag. It continues to move shakily, scribbling as it draws.

```   Rounding errors were problematic in our code because when we tested the angles even the correct angle appeared wrong.  Because of inconsistent negation of angles in the code, the arm moved fast and jerkily so that lines drawn were incoherent.
```