Difference between revisions of "RobotArtist"
|(2 intermediate revisions by the same user not shown)|
|Line 17:||Line 17:|
*[[User: Dwilson1 | Wilson, Dionne]]
*[[User: Dwilson1 | Wilson, Dionne]]
For our project, we designed the robot so it would be right-handed robot with equivalently proportioned fore and aft arm lengths. Our design was pretty simple as was our code. Our code consisted of multiple segments of code that wrote to the servo for each pair of coordinates at a time, finishing the outside of the square before drawing the inner circle within the square. Although our code worked in the end, we initially had some problems getting the inverse kinematics function to work properly, and even after establishing the correct code to make the arm move, we had some difficulties getting the arm to draw the proper shapes because the jerkiness of the arms caused the drawings to be a little skewed.
===Team Blue Steel:===
===Team Blue Steel:===
Latest revision as of 18:43, 25 November 2012
In this lab students designed a robot arm, controlled by MATLAB, that can draw pictures.
For our project, we designed the robot so it would be right-handed robot with equivalently proportioned fore and aft arm lengths. Our design was pretty simple as was our code. Our code consisted of multiple segments of code that wrote to the servo for each pair of coordinates at a time, finishing the outside of the square before drawing the inner circle within the square. Although our code worked in the end, we initially had some problems getting the inverse kinematics function to work properly, and even after establishing the correct code to make the arm move, we had some difficulties getting the arm to draw the proper shapes because the jerkiness of the arms caused the drawings to be a little skewed. Unfortunately, we neglected to get proof that our robot functioned properly before disassembling it, so in the end you will probably just have to ask one of the eyewitnesses from the demonstration to tell you about it or test the code for yourself using the provided zip file.
Team Blue Steel:
The Blue Steel Robot
We used two servo motors to control our robot arm, which was comprised of a lower arm and an upper arm. The lower one was created on Solidworks, and the upper arm was a metal rod. Each motor sent pulses dictating the angle to which the arm of the robot would rotate. We connected the arm to the table using a "c" clamp to ensure that the robot would not move while drawing. When we first ran the robot, the pencil marks were too light to be seen on the paper. We then programmed the arm to run the drawing 20 times to darken the shapes. While this solution was effective, we still found it necessary to tighten the screw holding the pencil to keep it better in place. This additional change made the shapes even more defined. However, when we tightened the screw too tight, the pencil began to trace an oval instead of a circle. We had to find the right balance in tightness to ensure that the marks were dark enough and the pencil traced more of a circle.
Proof of the Success of our Robot : Youtube Video
Matlab Script File:ServoCalibrateBlueSteelAndrewAfternoon.m
The Sith Lords:
Our goal in this project was to design the arm such that it could draw a circle inside a square along with similarly complex designs. To do this, we had to write a number of functions. The first one we needed was the File:InvKin.m function. This function converts (x,y) coordinates to two angles for the two arms. The next thing we need to do was transfer those angles into pulse counts for the servo motors. We used to functions for this. First, the File:GetPCs.m function transformed the angles into pulse counts. This required calibration of the motors to find which pulse counts corresponded to which angles. Finally, the File:GotoAngles.m function used the GetPcs function to take an angle, convert it to a pulse count, and send that pulse count to the servo motor. These three functions allowed us to input an (x,y) coordinate, or a set of them, calculate angles to achieve that point, and then move the arms to those positions. We then wrote the File:MiniProject.m script which defined the x and y coordinates of a square and a circle, and then used the functions to move the arms through all of the points defining the two shapes.
Our final design did work. As you can see below, we successfully got a circle inside of a square.
Team Unspecified Objects:
It's about to get goar-y.
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. Inverse Kin function was giving us the right magnitude, but at times the negative value of what it should have been.Because of inconsistent negation of angles in the code, the arm moved fast and jerkily so that lines drawn were incoherent. Results of inverse sine or cosine imaginary, preventing us from being able to compute the sine or cosine of those angles.
Team No Name:
Change name of team in line above, add links to team member pages, and add a link to your writeup wiki page.
The goal of our project was to use our robot arm to draw a circle inscribed in a square. For our arm we connected a steel dowel to a servomotor, our “lower arm”, and a plastic arm, which we had designed on solid works and printed using a 3-d printer, to a motor as well, our “upper arm”. Using screws we connected the two parts together to create our arm. We then used a clamp to attach the arm to the table. The pencil was placed at the end of the plastic part. Originally, the mark the pencil made was too light, so we screwed the pencil into the arm and taped a wrench to the plastic part to add weight to that section of the arm. Also, our motors burned out a couple of times and the new motors we used were not calibrated properly, so our circle was more of an oval.
When we were calibrating and constructing our robot arm, we used a motor connected to an "upper arm" of 15cm, and a second motor with a "lower arm" connected to the end of the upper arm. We tried to make a right arm, but somewhere we messed up with the calibration so it is backwards which unfortunately does not allow as much motion. When both arms were at 0 degrees, the whole arm was straight out. Looking back, it would have been better if 0 was a 90 degree angle instead. When we were writing the code to test, we continually ran in to problems with motors and connecting to the calibration. We realized that we wanted to have a for loop that would update the position of the arms using the invKin function. Our invKin function worked before in the previous lab, but we often received errors when working with our actual robot arm. We had code for both a circle and a square, but they would not work properly. A major issue that we were unable to overcome was matching up the distance we put in and having the arm move the appropriate length. For example, we would type in for the arm to move a centimeter to the left, but the arm would instead only move a tenth of a centimeter. By the end, we were able to make a small triangle using a for loop and our functions. Given more time, we believe we could have worked out all the bugs so that we could make a larger circle inscribed in a square.
Team Cool Robot: