robotics write ups

7/23/2019 Robotics Write Ups

http://slidepdf.com/reader/full/robotics-write-ups 1/13

Zac Canter ARM KINEMATICS Robotics F15

INTRODUCTION

The mechanical complexity of using one’s arm to grab a bookoff the shelf is largely ignored. To do this our eyes and brain

work with our body to calculate the angles our joints turn toreach an end point. In robotics, the study of arm motion is calledarm kinematics and the end is called the end effector.

In this challenge, we were given an end effector and had tocreate a robotic arm which could reach from a fixed center pointbase. The arms reach or workspace was required to have aminimum radius of 6 Lego Units, a maximum radius of 30 LegoUnits, and minimum two degrees of freedom or independent areas of motion. The challengecoordinates were (0,30) and (10,-14).

This challenge required a combination of trigonometry, product design, computer programming,a little bit of user interface design.

APPROACH

In the early stages we considered manydifferent types of setups. It became clearhowever that the dual motor, two equalarm setup would be the fastest and theeasiest to work with. Speed was anongoing theme for us.

By putting the Lego brain above the motorand allowing it to act as the first rotatingarm (the bicep) we were easily able to usethe small motor as a mechanism to turnthe second arm (the forearm). At first, thesetup was swaying too much but theaddition of a counter weight kept it stable.

The software relatively simple. Once themathematical equations were finished and we knew how much rotation was needed at each

joint to hit our end effector the program required only a couple motor rotation commands. Wewere able to start iterating immediately since we had our bicep built and our homework done

prior to the challenge.

We decided make a program which would involve some level of interaction and whim. To run,the user triggers commands from a button mounted on the side of the brain, and when finishedthe bicep will swing around 500 times and an elephant noise will play.



Zac Canter ARM KINEMATICS Robotics F15

CHALLENGES

Due to quick and often iteration the code became very disorganized. This was also partially dueto our adjustment into the Mindstorm IDE. In the future we will try to establish best practices andcleaner code.

Structurally, getting two arms that could rotate 360 was a challenge. Often things would collideinto each other. I don't think either of us anticipated the swaying and stability issues. Moreover,It was a challenge properly rigging the cables so that they would not interfere.

We also wanted to write a more sophisticated program but the Mindstorm IDE didn't havetrigonometric functions.

CONCLUSIONS

Learning how to calculate angles was a very cool experience and I can already see its use. Ihave largely avoided programming motors since my last real math class was eight years ago.

I was also very happy to work in a team with a product designer. I look forward to furthercollaboration as the class goes on.

I would also say having things finished early allowed for a lot less stressful design process.



Zac Canter WHEEL ODOMETRY Robotics F15

INTRODUCTION

This challenge required us (Devin Montes,myself) to build a robot and drive it along apreset course using wheel odometer or using

a robot’s wheels to determine where it is inthe world. In order to make this happen wehave to first make sense of the robot’s globalframe of reference (fixed frame in the world),location reference frame (fixed frame toitself), and origin (fixed point on itself). Usingthis information in conjunction with thecircumference of the wheels and the totalrobot turning circumference we are able tocalculate both driving distances and turningangles.

In this challenge we used open loop control or a type of control where a system behaves in amanner solely based on assumptions and prior knowledge of the environment. That is, wecalculated the distances and angles beforehand and had the robot execute them with no sense-decide-act loop.

As a class we engaged in a track competition judged on both speed and accuracy of the roboton the preset course. All in all, we came in first place although there was a team whichcompleted the course one second faster then us with less accuracy.

APPROACH

For the physical body we tried to go as light as possible.The addition of a straight pointer helped us better make finetuning decisions during testing. We used a caliper tomeasure the diameter of the wheel, but also found specsonline.

We decided to go with in-place turns (each wheel turns thesame angle inversely of each other) since we could leavethe origin in the center of the robot. We believed this wouldsimplify things.

The formulas we used required the individual wheel

circumferences as well as the robot’s turning radiuscircumference:

distance = totalRotations * wheelCircumferenceduration = robotTurnCircumference / wheelCircumferencepivotTurnDegrees = duration * desiredAngle // pivotTurnDegrees / 2 = inPlaceDegrees



Zac Canter WHEEL ODOMETRY Robotics F15

Our workflow started with a mini-program which contained the first few legs of the course at avery slow speed. Once this was fine tuned we added another few legs at a time until the coursewas finished. Once the entire course was complete we began to slowly increase the speed.

CHALLENGES

The major challenge of wheel odometry is that our knowledge of the environment is pretty

limited. This is especially true when we cannot accurately survey the terrain before hand in away that would help us account for its variances. This would mean that one small veer offcourse could over the course of the track be quite significant.

Additionally all the commands are based somewhat on thewheel circumference. Although we used a caliper to measurethe diameter, the tires morph slightly under pressure. Evenusing an average would be risky and we ended up using anumber found on a Mindstorm forum.

CONCLUSIONS

We also took part in the advanced challenge. This challengerequired us to drive the robot in a continuous circle. In order toachieve this we had to figure out the appropriate power ratiosof each wheel’s motor power. Then, we set them to the sameangle and had their motor powers vary to the appropriateratios:trackCirumferenceL / trackCircumferenceR = ratio

Both challenges were a lot of fun and we learned a lot!



Zac Canter CLOSED LOOP INTRO Robotics F15

INTRODUCTION

This challenge required us (Devin Montes, myself) to build a robot thatuses an ultrasonic sensor in conjunction with a closed-loop controlsystem to distance the robot 40CM from any obstacle in front of it.

This was a two part challenge requiring two different types of controltechniques: bang-bang and proportional; we will go more into depthinto these in the next “Approach” section.

In control theory or the manipulation of the inputs of the system torealize desired behavior at the output of the systems, closed-loopcontrol uses a sense-decide-act loop control structure which allowsthe robot to have a certain level of autonomy in the environment. Thisis opposed to open-loop control which is executed by a controller(usually a person) based on prior knowledge and assumptions aboutthe environment.

In order to properly complete this challenge we had to create a set ofcontrol laws or rules and equations to determine the proper control input.

APPROACH

The first part of the challenge required us to use bang-bang control. This control technique is anon/off control similar to a household oven. The sensor measures a value, checks to see if thestate is above or below the desiredvalue, then turns the output on or offrepeating the loop over and over again.It is also helpful to provide a deadband

or acceptable range of error so theoutput is not constantly going on and offwhen hovering around the desired state.

x = current statexDes = desired stateisOn = boolean for on or off

if (x > xDes) -> isOn = falseif (x < xDes) -> isOn = true

The second part of the challenge required

us to use proportional control in which the control input is proportional to how far away you arefrom what you want. An example of this type of control is the cruise control system in your car.The formula:

x = current statexDes = desired statee = error (amount off)u = control input (what you want to do)



Zac Canter CLOSED LOOP INTRO Robotics F15

K = proportional gain (rate at which current state will meet desired state)

e = xDes - xu = K * e

CHALLENGES

We encountered several mechanical challenges along the way. Firstly our brain wasn'tfunctioning properly and would not allow us to exit a running program. This required us to use abackup brain which did not have the proper firmware. The update took about 20 minutes.

Another mechanical challenge was the calibration of the ultrasonic sensor. We progressedthrough the challenge under the assumption that our math was wrong when all along our sensorwas way off. Although this was a mistake we learned how to calibrate and test our sensors

beforehand using the Mindstorm IDE.

We also had some non-mechanical challenges as well. Figuring out which K value wasappropriate took some trial and error. We ultimately decided that K = 3. Also, for the bang-bangcontrol challenge we had some difficulty setting a deadband programmatically.

CONCLUSIONS

I think more then anything we learned the importance ofchecking things before hand. If we had checked oursensors and brain before the challenge we would havehad a much faster and accurate final result.

It was fascinating to watch the robot embark on its firstclose-loop control system. One really does have to simplytrust the sensors and let it be. It’s a really cool process.



Zac Canter CLOSED LOOP CONTROL Robotics F15

INTRODUCTION

The line following challenge requiredDevin Montes and I to build a robotwhich used a color sensor to follow a line

utilizing closed-loop control or a sense-decide-act loop. This is opposed to open-loop control where a controller uses priorknowledge and assumptions about theenvironment to command the robot.

From a technical standpoint, the colorsensor read the color on the ground andreported back to the program. Dependingon the feedback, the wheels werecontrolled in a certain way. Differentteams approached the challengedifferently all with the goal of keeping thecolor sensor within the black line that marked the track.

APPROACH

The first program most teams wrote including us was over elaborate and required the robot runon a long string of logic. The first program was as follows:

loop {value = color sensor readingif (value = black) { Drive forward }

if (value = white) { Turn right 90 degrees, if value is still !== 1 turn 180 degrees left }

A much more effective way to control the robot was to follow the edge of the line instead of theline itself. This required no complicated logic and the robot accurately assumed turns. With thisprogram the robot bounces on and off the edge of the line controlling itself through the track.

loop {value = color sensor reading// Sensor on black lineif (value = black) { RightForward} if (value = white) { LeftForward }

The way we determined theRightForward and LeftForward speedswas through trial and error. We startedwith the smallest wheel base as possibleand the least aggressive turn angle andbuilt from there.



Zac Canter CLOSED LOOP CONTROL Robotics F15

CHALLENGES

The first program felt like the right way to go with although it quickly became clear that it washarder than it seemed. The robot needed a way to keep track of its orientation. This required

wheel odometry or a long string of logic that quickly became uncontrollable.

We discovered the proper solution early in the challenge but there was a feeling that it couldn'tbe that easy. The robot seemed to be make uncontrollable turns and it wasn’t until Rolandpointed out that the wheel base effects the sensors ‘bounce’ that we had a successful run.

Another major challenge was that one of our peers had copied our program. It was frustratingwatching someone take our code then beat us. It made us both reassess our privacy strategiesin future competitions.

CONCLUSIONS

I want to first say that it was a really cool feeling watch therobot complete the courses. When we put the robot on themore advanced course and it went round and round, it felt likewe had created our first real robot.

And, although our code was copied, the group that did it wasable to solve a problem we could not and beat us. This isremarkable and had we been a team, it would have been theperfect solution. However, we will definitely be hiding ourprogram when we go to test from here on out because theseare indeed competitions.



Zac Canter LOCALIZATION Robotics F15

Introduction

In this challenge we built a distance sensing robot that acted as a ruler driving forward until it hitan obstacle and then printed that obstacle’s distance to the display.

To achieve this required more advanced wheel odometry and localization techniques then in theprevious challenges. We use forward motion which involves keeping track of incremental robotmotions and accumulating values to determine an overall position.

Algorithm Approach

In this algorithm we first determine how much of a rotation the wheel must turn in order to drive1 cm forward; this becomes our step. We then use a counter to measure how many steps weretaken and in the end multiply the two and then add the distance sensor value:

// Find out how much the wheels must rotate in order to drive 1cm distanceCM = rotation * wheelCircumferenceCM1 = rotation * 5.6!

rotation = 0.57

// Store the sensor value into a variable sensorValue = read(ultrasonicSensor)

// Counter to keep track of how many times loop has run counter = 0;

// Begin infinite loop loop() {

// If the ultrasonic sensor has nothing in front of it for 10cm, (Keep Driving Forward)

if (sensorValue < 10) {

// Drive the wheels forward one CM in wheel rotation (our specified step distance) driveForward(0.57)

// Increase the loop counter by 1counter++

// (Stop driving and calculate total distance)} else {

// Multiply the counter and the specified step distance to get total CM counter * rotation = cmDriven// Add this to the sensor value and print the result to the display cmDriven += sensorValueprintToDisplay(totalDistanceTravelled)

} }



Zac Canter MOTION PLANNING Robotics F15

Introduction

This week we learned about motion planning through an obstacle avoidance challenge. In thechallenge we

In this challenge we built a distance sensing robot that acted as a ruler driving forward until it hitan obstacle and then printed that obstacle’s distance to the display.

To achieve this required more advanced wheel odometry and localization techniques then in theprevious challenges. We use forward motion which involves keeping track of incremental robotmotions and accumulating values to determine an overall position.

Algorithm Approach

In this algorithm we first determine how much of a rotation the wheel must turn in order to drive1 cm forward; this becomes our step. We then use a counter to measure how many steps weretaken and in the end multiply the two and then add the distance sensor value:

// Find out how much the wheels must rotate in order to drive 1cm distanceCM = rotation * wheelCircumferenceCM1 = rotation * 5.6!

rotation = 0.57

// Store the sensor value into a variable sensorValue = read(ultrasonicSensor)

// Counter to keep track of how many times loop has run counter = 0;

// Begin infinite loop loop() {

// If the ultrasonic sensor has nothing in front of it for 10cm, (Keep Driving Forward) if (sensorValue < 10) {

// Drive the wheels forward one CM in wheel rotation (our specified step distance) driveForward(0.57)

// Increase the loop counter by 1counter++

// (Stop driving and calculate total distance)} else {

// Multiply the counter and the specified step distance to get total CM counter * rotation = cmDriven// Add this to the sensor value and print the result to the display cmDriven += sensorValueprintToDisplay(totalDistanceTravelled)



Zac Canter MOTION PLANNING Robotics F15

} }

Algorithm Challenges

Algorithm Implications



Zac Canter FINAL CHALLENGE Robotics F15

Introduction

This week we combined our knowledge from previouschallenges to compete in an all out sumo challenge in whichtwo robots entered a 1 meter ring with the goal of completely

disabling or forcing their opponent out.

The challenge was a huge upset for us and we came in lastplace overall. It is important to note however that we had theleast amount of losses. We used a simple, no motion,armadillo-style approach with a shovel-flipping attackmechanism. In the end, we were unable to properly utilize ourattack mechanism and felt like we should have spent less timestrategizing and more time building and testing.

Software/Hardware Approach

Our overall strategy was to wait out our attacking opponent only to trap it. When the attacking

robot was in the prime flipping zone we triggered the shovel to very forcefully lift up. We figuredif we had the strongest shovel and heaviest robot nobody could impeded our attack. This washarder in practice then in theory. There were two main problems our hardware/software did notcomplement each other.

First problem: sensing when an attacking robot was in the prime flipping zone proved harderthen it seemed. This was difficult from a software/hardware standpoint because the prime-flipping zone was different for every robot depending on its size and pose in relation to ours.



Zac Canter FINAL CHALLENGE Robotics F15

While we did test the prime zone with our hand, we did not test it in practice with other robotsuntil the final challenge.

Second problem: while our shovel motors were definitely strong enough to flip any robot, theshovel did not have enough surface area to translate this power into a successful attack. Thiswas because the shovel was not long enough. When we did connect the flip, while strong, just

picked up the opponent for a second them put him back on the ground.

One nice complement was the cage in the rear of the robot. We were able to use it as aweighted container allowing us to outweigh other robots, thus we were nearly impossible tomove. This helped with the flip mechanism because if another heavier robot got on top of theshovel our robot would instead lift into the air.

Sensors

We used the ultrasonic sensor to determine if an opponent robot was in front of ours. Thisproved to be very valuable when an opponent attacked us straight on. The more an attack camefrom the side the less reliable our sensor was.

If we could have use any sensor available it would be some sort of tracking sensor. If we couldby magnet (or something) keep our robots pose head on with an attacker we could moreeffectively utilize the shovel flip attack. We considered rotating our ultrasonic sensor to try andachieve this but it proved very difficult, and it made our robot more vulnerable to error.

It was also difficult having only 2 large motors, although there also was a smaller one as well.Lack of motors meant deciding to drive or flip strongly. While some students did some creativethings with gears, we deciding our shovel flip needed to be the strongest feature.

Conclusion

All in all, it was a very fun experience. It wasn't particularly ideal to come in last, but I definitelyfeel it was a lesson in the design process. If we had spent less time strategizing and more timebuilding we would have finished higher in the rankings. It really reminds me the importance ofthinking with your hands along side your head.

robotics write ups

Documents