Arduino Day 4 (Sciborg Part 2)

Today, we learned about and experimented with three new feedback mechanisms: motor encoders, touch switch sensor, and ultrasonic sensor.  Then, we will use these sensors with our sciborg to implement two types of control: bang-bang control and proportional control.

Motor Encoders

The following sample code for encoders measure the number of rotations of the motors.  The encoder reads the current position and these values are printed.  In the sample code, the wheel moves backward and forward, and the encoder reads the current position of the motor.  The starting value for the encoder should be zero because we reset the encoder to zero in the void setup when we have "m.set_pos(0)".  The end value is not zero because we don't reset the encoder to zero within the loop.




Touch Switch

There is a touch switch on the front of our sciborg.  This can detect when the touch switch is activated and when it is not (e.g. the sciborg runs into an obstacle).  The touch switch is wired to a digital pin on the Arduino and also to ground.

Wiring for Touch Switch and LED

The following sample code includes the LED and the touch switch. When the touch switch is pressed, the LED turns on, but stays on forever and will not turn off when we let go of the touch switch.  Our job was to fix this and make the LED change according to the touch switch. We wanted to modify the sample code to make the LED turn on when the touch switch is pressed down and turn off when the touch switch is not pressed down.  All we have to do is add an else statement to the if statement.




Touch Switch with LED

At first, the LED did the opposite of what we wanted.  It would turn off when the switch was activated and stay on when it was not activated.  We weren't really sure what was happening, but played around with the code and wiring to see what was going on.  The code below is what we had for our first attempt.

Then, we modified the code once we figured out what was wrong.  The code in the loop is identical from the previous picture, but we think it had to do with the mode of the touch switch in the setup.  The mode in the first attempt was just "Input" (we're not sure what happened there?) and in the following code for the second attempt, we changed the mode to back to "Input-Pullup".  This switches the input. Additionally, for some reason it would not work when we wired the touch sensor to the LED, so as you can see in the comments, we took that wire out from our first attempt.  In the video, we have the LED turning on and off with the touch switch.




Ultrasonic Sensor

The ultrasonic sensor measures the distance from objects surrounding around it.  For example, if nothing is in front of the sensor, the printed values are large, and then as the sensor approaches a wall, the values become smaller, indicating there is something close to the sensor.  As you might guess, this can be useful for helping our sciborg avoid obstacles.  The following is the sample code for the ultrasonic sensor.  The sample code here gives value in the serial monitor that corresponds to distances.  A low number indicates something is near to the sensor and a large number indicates the sensor does not sense anything near it.  The sensor can also pick up readings from the sides, not just straight in front of it.




Feedback and Control

A. Fixed Distance, bang-bang control

In Day 3 of Arduinos we made our sciborg travel 10 feet by determining the time it would take and setting out motors to stop after that given amount of time.  In this bang-bang control task, we were able to get our sciborg within a few centimeters of 10 feet.

**Explain testing of values

Now we are using our new sensors to have the sciborg stop in different ways.  We used the ultrasonic sensor to control the point at which our sciborg would stop in front of an obstacle.  In our testing, we found that using the ultrasonic sensor, our sciborg would stop about 10cm short.  We could lower the parameter of how far away it should stop, but the ultrasonic sensor also isn't very steady.  A very lower value doesn't the sciborg to stop in time.



This code is a combination of the ultrasonic sensor code and basic motor sciborg code.  We have the ultrasonic sensor reading values and the motors are controlled by those values.  If the sensor does not sense anything in front, meaning the sensor values are greater than 30, the motors are set to forward at full speed and if the sensor senses an obstacle, meaning the values are less than 30, the motors set the speed to zero.



B. Fixed distance, proportional control

First we had our sciborg travel 10 feet using bang-bang control, and now we want to use proportional control.  Proportional control means that, as the sciborg gets closer to its goal, its speed will be proportional to the remaining distance.  Thus, it slows down as it gets closer to 10 feet.

Using proportional control means we need to do some calculations.  Here in our code the equation we used was Speed = distance * gain, where distance is the distance remaining or error (goal - actual) and gain is a constant that we calculate.  We find the gain constant by taking the maximum speed of the motors 255 and dividing by the total distance.  In this case, we are using the distance 13000 because that is the number of rotations (measured by the encoder) needed to travel 10 feet.  We determined this value by testing different encoder values for the sciborg.  Our gain constant is 0.0196.  Our encoders count down from 13000 to 0, so we take the current reading from the encoder and multiply this by the gain constant. So when the sciborg is at the beginning, it's position is 13000 and this multiplied by 0.0196 is the maximum speed 255.  (This is because we divided 13000 by 255 to get the gain constant in the first place).  Then as the sciborg continues, the current encoder value is decreasing and multiplying by the gain results in a smaller number for the speed.  Therefore it slows down.

There is a typo in this code.  In the last if statement the gain constant should be 0.0196, not 0.02125.  Originally we had a higher gain constant, but later re-did our calculations.  The sciborg in the video is running the correct code.

You might notice there is a function in our code called nudge().  In proportional control, one issue is that around 9 feet, the speed has been getting smaller and smaller, so the sciborg is moving very slow and at some point can no longer move.  However, it hasn't reached 10 feet.  As we found earlier, the sciborg has a minimum speed where the motors are no longer able to move the car.  This value is around 50 for our sciborg.  To solve the problem, we created a function that nudges the sciborg to the end when it can no longer move under the proportional control.  If the speed of the sciborg gets lower than 70 and the sciborg has still not reached its goal, we call a function called  nudge.  This function turns the motors on and off and will continue to do so until 10 feet is reached.






C. Conga Line

Next implemented bang-bang control and proportional control in a different task.  This is the conga line, where we want the sciborg to follow something in front of it.

For bang-bang control, we decided to have the sciborg turn left or right.  Here, if the sensor doesn't sense anything the car turns left and if it senses something it turns right.  This way, when we moved our sheet of Delrin in front of it, it moves forward and slightly right, and then when we moved back with the Delrin it moved forward and slightly left.  This allows our sciborg to 'search' for objects in front of it to follow, while also (somewhat) traveling in a straight line.



At first, we didn't think about doing bang-bang by just having the sciborg move forward.  We could do this by having he motors turn on when nothing is in front of the sensor (meaning the Delrin is further in front of it)  and turn off when something is in front of the sensor (when it's really close to the Delrin).

When we coded for the the conga line with proportional control, we had our sciborg just traveling straight.  Proportional control for the conga line involves having the sciborg move faster when the Delrin sheet is far away and slower when the Delrin sheet is close.


Our next step is using bang-bang and proportional control to have our sciborg follow a white line on the floor.  We are going to use a new sensor that measures brightness!

Arduino Day 3 (Sciborg Part 1)

On Day 3, we started building and programming sciborgs, which are small cars run by 6-AA battery packs.  We attached the battery pack, the Arduino, and the protoboard to the sciborg, and then put a cover on top of the Ardunio that allows us to attach motors and sensors.



SOS Example

We used this example to learn about functions in Arduino.  In this example, there are two functions that are later used in the loop.  Using functions saves time and code writing.




Single Motor

Then, we attached the motors to the Arduino and ran the example program Single Motor. This program runs only one motor and results in the wheel moving backward and forward. We took this program as a starting point and modified it to create our next programs.



Double Motor

This program runs both motors at the same time and speed, so that the wheels of the sciborg move together and it will travel in a (hopefully straight) line.  We modified the original Single Motor program by adding the second motor and setting its speeds exactly the same as the first motor.



Minimum Speed

Next, we tested out different speeds on the sciborg.  We determined the lowest possible speed that made our sciborg still move was around 50.


Here is our sciborg moving incredibly slow!



Hard Turn

Now that we had our sciborg moving in a straight line, we had to figure out how to turn it.  First, we made the sciborg do a hard turn, essentially spinning it around in place.  To do this, we have each motor running at the same speed in opposite directions.





Gentle Turns

Since we don't want it to turn so abruptly, we needed to find how to implement some more gentle turns.  First, we had the sciborg go forward, turn a little, go forward, turn a little, and repeat.  This was successful, but resulted in a somewhat jerky turn.




The next gentle turn we tried out was smoother than the first.  One motor was set slightly faster than the other.  The result was the at the sciborg turned in a small circle.





10 feet

Next, we programmed our sciborg to travel exactly 10 feet.  We initially did this using the delay, finding just the right amount of time for the vehicle to move 10 feet.  After this determined time, which we found to be 9 seconds, we stopped the motor.  In our testing, the sciborg traveled the 10 feet exactly almost every time.  If it was off, it usually was short of 10 ft by about 2-3 cm.




Motor Button

After creating and testing some basic programs, Olivia and I started work on our biggest task of the day: when the sciborg hits an obstacles it backs up, turns, and continues on its way.

First, we needed learn how the Lego motor button worked, so we ran the example program Motor Button on our sciborg.  When the button is pressed, the motors stop, and when it is released, the motors start again.  In the following video, the motors have been set to opposite speeds, so the sciborg turns one way direction, then when the button is pressed and let go of, it turns the other direction.



Hitting a Wall

Now that we had played around with the motor button, we started on the code for hitting the wall.  This code makes the sciborg move straight, then when the button is pushed (it hits the "wall"), the sciborg backs up and turns.  Then the loop restarts and the sciborg continues straight until it hits something else.  For testing, we attached the motor button to the front of the sciborg.





Arduino Day 2

The second day of Arduino work introduced us to Servo motors and potentiometers.  We learned two new example programs called Sweep and Knob and modified them to control the motor and an LED.


Sweep program


The sweep program is used to control a Servo motor.  First we have to include the Servo "language" so that we able to use a Servo motor.  There is a variable that creates a Servo called myservo and then a variable called pos that we can use later to store the Servo position.  In the void setup(); we attach the Servo to pin 9 on our Arduino board.  The loop then tells the motor that when the position is is at 0, move to 180 (degrees) and when the motor is at 180, move back to 0, and do these motions in steps of 1 degree.  The delays waits 15 ms for the Servo to reach the designated position. We don't want the delay to be smaller than 15ms because the motor needs enough time to reach its final position.










































Modified Sweep Program

We next modified the Sweep program to have to have to motor do a different motion.  This helped us learn how the programing for the Servo motors works.  For our modification, Olivia and I made the motor move only 90 degrees.  We also changed the delay and the steps, and thus made it move differently on the second loop.  If we increase the delay (as we did here with 3000ms) for the second for loop, you can really see how changing the 'steps' affects the motor.  It will move, in this case, 15 degrees at a time until it reaches 90.  Our video was taken before we made the change though, so the 'steps' aren't seen here.








































Knob program with Servo Motor

Another example program for a Servo motor is the Knob program.  For this program, we use a potentiometer to control the movement of the motor, i.e. when we turn the knob on the potentiometer, the motor moves at the same time.  We connected the potentiometer to the analog pin A0 on our Arduino and ran the program.  The value is read from the potentiometer pin (potpin) and then that value uses map(); to change the scale of the potentiometer to the scale of the motor.  This makes the motor have the same motion as the potentiometer.
















Knob with LED


Our final task of the day was to use the potentiometer to control the blink rate of the LED, meaning it blinks slower when you turn the knob one way and blinks faster when you turn it the other way. We took our program for the servo and changed it to fit the LED. We again used map to scale the potentiometer reading to the LED rate.














Arduino Day 1

For this next unit, our class is working with Arduinos!  I'm working with Olivia Gada for these projects.  On our first day of Arduinos, we learned what Arduinos were, how to use the software, and how to write code to modify the Blink program, which makes one or more LEDs blink on and off.


The Arduino Uno

Here is an Arduino Uno board, the ones we use in class.  The digital pins at the top are the ones we use for LEDs.  It is important to note that one of the pins  - digital pin 13 - has an LED built into the board itself.  We use this pin to begin with because we don't need to connect an LED to the separate protoboard.
































Blink program

Arduino is an open source software company, meaning anyone can create, share, and change programs used for the hardware.  There are hundreds of example programs, so we use many of them to learn the basics and then modify them to create new programs.  We started by looking at the basic Blink program in the Arduino examples, so we could learn how to write code for our Arduino.  The Blink program makes an LED blink on and off.  It seems simple, but it was important for us to completely understand the code and syntax.

Arduino programming basics: The void setup() runs when the Arduino is connected.  This includes things that you want to happen once, like initializing pins on the Arduino, as we see here.  It's telling the Arudino that we're going to connect something to pin 13 and make it do something.  Then we have the next section void loop().  A loop, as its name suggests, goes through the code again and again and again until you stop it.  We use a loop here because we want the blinking to keep going, not just turn on and off and stop.  First, we set pin 13 to HIGH.  This tell the LED to turn on.  Then delay(); takes an amount of time in milliseconds.  Here we tell it to wait 1000ms (1sec).  Then we write to pin 13 and tell it to turn LOW, which turns the LED off.  And because of the loop, it now returns to the beginning where we tell pin 13 to turn to HIGH.  The final result is the LED blinks at 1 second intervals.








































Modifying Blink program to change blink rate


Next, we wanted to change the LED to blink differently to learn how the delays and times work.  All we need to do here is change the delay time. After we turn the LED to HIGH, we delay 2000ms, or 2 seconds, before turning it to LOW, and then delaying 500ms, or 1/2 of a second.  So now the LED is on for 2 seconds, off for 1/2 second, and keeps going   Again, it seems elementary, but seeing this code for the first time can be confusing and it's important we learn the basics.






























Modifying Blink to create a pattern with 2 LEDs

We now wanted to add a second LED using the protoboard.  In the code, we must initialize the second pin as an output and for this program we used digital pin 12.  Then, we just add some code to make a pattern.  In our program, pin 13 is on for 500ms. There is a short delay, then pin 12 is on for 500ms, then 50ms, 50ms, 50ms, with short delays between each. This creates the effect of a long blink(on 13) and then long, short, short, short (on 12).  And of course, because of the loop it keeps going.



Here is an image of our Arduino and protoboard.  The LED on the protoboard is connected to digital pin 12 and we used the pin already on the Arduino itself for pin 13.  The red wire goes from pin 13 to the same row as the LED, then we have a resistor after the LED, and the black wire connects back to the ground pin.






Modifying Blink to create a pattern with 4 LEDs

Next, we wanted to make a pattern using 4 LEDs. We connected 4 LEDs onto the protoboard and connected them to digital pins 2, 4, 7, and 12. Again, we must first initialize these 4 pins as outputs in the void setup(); Then, we created a pattern that goes up the row of LEDs and back down. The LED in pin 2 is on for 500ms, then LEDs 4, 7, 12, 7, 4, in that order, are on for 50ms each.



















































Here is our protoboard and Arudino with 4 LEDs connected.  Each LED has a wire from its pin on the Arduino and a resistor after it.  Then all of the black wires go to the negative column on the protoboard and a final black wire connects that back to ground on the Arduino.




Blink Without Delay

Next, we learned about the Blink Without Delay program.  With this program, we don't use delay(); like we have previously.  This means that other code can run at the same time without being interrupted by the LED.  We use millis(); and count the number of milliseconds to check if it is time to blink the LED, instead of using delay();.  This program is where we learn how to write if/else statements to control the LEDs.  This program will be important because we might want to use other things with the Arduino that won't be affected by code for the LEDs.















Modifying Blink Without Delay to create a pattern with 4 LEDs

Our final task for the day was to create pattern using 4 LEDs by modifying the Blink Without Delay program  We needed to create variables for each LED in each pin and also for each LED state.  In void setup(); we initialize those four pins as outputs.  Now we come to our loop:  here we used else if statements to tell the LEDs to create our pattern.   Else if statements specify a new condition if the first condition is false.   If LED 1 is off, then LED 1 turns on.  Then if LED 2 is off, it turns on and LED 1 turns off. This continues on so that one LED is off while the three others are on, and the one LED that is off appears to travel down the line.









Lego Racer

Our next project was to design a Lego vehicle with a single motor, powered by a PicoCricket, that can carry a 1.0 kg weight as fast as possible on a 4 meter course.  For our motors we had to use the old Lego rectangular motors that do not have internal gearing, so that we could learn how to make our own gear train.  For this project, my classmate Angel and I worked together! (Here's her blog: http://angelengr.blogspot.com/)

1. Motors and Gears
2. Our Lego Racer and Engineering Analysis
3. Reflection

Motors and Gears


Motors

We first learned about the different types of motors.  The one we had to use for our project was the 9V Lego Motor 2328c01 (which are the "old grey motors").  We compared this to the "new grey motors".  The old motor has a very high speed and low torque because there are no internal gears, and thus it is easier to stall the old one.  On the other hand the new motor is a little slower and has a bit more torque because it has internal gears, so it's harder to stall.

Torque is an important concept when working with motors and gears.   As you can see on the graph, torque and speed are inversely related.
 At one end, you get high torque, but a very slow speed.  And on the other end, you have high speed, but little torque.  So on either end, the vehicle will barely move. Thus, our goal for the project was to find the middle ground.

Also, consider the equation for power: Power = Torque * angular velocity.  We can see on the graph that this middle ground produces the maximum power.

Gears

We then learned about gears and gear trains, which is putting multiple gears together so they move and work together.  Adding gear trains increases the torque of the motor.  There are four types of Lego gears we use in this project:  40, 24, 16, and 8-tooth gears.  To start with a simple example, if we have an 8-tooth driving a 24-tooth gear, the 8-tooth will have to turn 3 times for the 24-tooth to turn 1 time.  These ratios can give us the gear ratio.  In our example, the gear ratio is 3:1 because of 3 turns:1 turn.

This brings up an important point:  Going from a small gear to a big gear lowers the speed and going from a big gear to a small gear increases the speed by a factor equal to the gear ratio.  Not only does the gear ratio affect speed, but it also affects torque.  Going from a small gear to a big gear increases the torque and from a big gear to a small gear decreases the torque.

We can also make longer gear trains, which is our goal for the project.  By starting with big gears and going to small gears, we can make the axle turn very fast.  But we have to think about torque at the same time.  Going from big to small gears will decrease the torque, and then our car wouldn't move!  This is why we need to find the right tradeoff of torque and speed.


Our Lego Car and Engineering Analysis


Angel and I started by experimenting with some different gear trains and measuring the speeds.  We made the body of the car with a simple gear train and the our iterations involved changing the gears to try to make it go as fast as possible.  Each time we changed the gear ratio, we timed the car to see how fast it went.  We went through 4 iterations. 


Gear Ratio:  2.5*3*5 = 37.5
Gear Ratio: 1.67*3*5 = 25

Gear Ratio: 1.67*3*3 = 15
 These gear trains gave us the following times:

      37.5:1     13.6 sec
         25:1     10.2 sec
         15:1     10.8 sec

We saw that as we got lower the time was going to go back up, so we wanted to make a gear train that was in between 25:1 and 15:1.



We took the 15:1 gear train and we changed the first gear to a 16-tooth.  This made the gear ratio 22.5:1.  When we timed the car it went significantly faster than our first tries, at 9.02 seconds.  We decided to keep this gear train for our final car.


Gear Ratio:  2.5*3*3 = 22.5    Time = 9.0 sec

Here is our final gear train on our finished Lego Racer.
We used two 24-tooth, one 40-tooth, one 16-tooth,
and two 8-tooth gears, for a total of six gears

A final change we made to our car was decreasing the amount of Legos we used as much as possible because wanted it to be light.  Angel and I tested it several more times and it finished the course in 9-10 seconds.  When we did a trial run with other students on Tuesday, it took 12 seconds which was longer than usual.  We think it was from testing it and the batteries were low, so we decided to change the batteries for our final race.

The final race took place on Friday.  We raced in pairs and Professor Banzaert recorded everyone's gear ratios and times.  Here is a video of our car:


Afterwards, the class looked at the results of all of our cars. The times are put in order from fastest to slowest.

          Gear Ratio  Time (sec)
              15:1            8.42
           22.5:1            8.92
           15.6:1            9.63
           20.8:1            9.68
           24.7:1          10.57
           20.8:1          10.93

So why isn't there a pattern to these times and gear ratios? We discussed several reasons in class why they is not, such as the size of the wheel, friction from gears and wheels, the number of wheels of the car, the distances of the wheels, and the weight of the car and the wheels.  Overall, it just the fact that we're doing this in real life, not as a computer simulation, and just like in all engineering, other factors come into play.





Reflection


We really enjoyed constructing our Lego racer for this project and are proud of our final car, which was the second fastest in the class!  There were a few interesting things I noticed when looking at the other team's times.  One was that the fastest car had a gear ratio of 15:1 and when we tested our car with a 15:1 ratio it was 2.5 seconds slower!  This really shows how the design of the car matters, like the wheels, the weight, and other aspects.  I think some improvements to our car could be using a larger third wheel instead of a small one.  We talked in class about how using larger wheels increases the angular velocity and this would probably make our car finish faster.  Another improvement would be trying to use the same gear train, but make the rest of the car as light as possible, by using less Legos, or lighter wheels. 

Our next project is very different than what we've been doing so far this semester.  We got out the Arduinos and will be doing some cool projects with them!

Mechanisms

Now that the class is working on our Lego cars, we've been learning about gears and mechanisms.  There are obviously hundreds of different mechanisms used in engineering and for this assignment, we explored Cornell's Kinematic Models for Design Digital Library (KMODDL) http://kmoddl.library.cornell.edu/index.php

There were so many mechanisms to explore that it was hard to choose one to talk about. One of the mechanisms from this collection that I found interesting was the Slider Crank Mechanism.  
http://media-3.web.britannica.com/eb-media/90/4190-004-4DAAB8E9.jpg

The description said this mechanism "may be the most ubiquitous mechanism in the world" because it is found in every internal combustion engine.  Now, I'm not really a car person at all, so the extent of my knowledge about combustion engines is that the piston moves up and down because of pressure from the sparks created.  I know now that the up and down of the piston is aided by a slider crank mechanism.


http://www.allsubjects4you.com/reciprocating-engine_files/image002.jpg

First, I'll explain how this mechanism works on its own.  Basically, it changes rotational motion into linear motion.  The wheel or handle is rotating, and in the image above, point A is fixed and the rod from A to B moves around point B in a circular motion.  The other end is not fixed, but slides back and forth in some type of guide.  Now, this crank has four links, and it can be modified four different ways, changing the part that is grounded or fixed.  So hopefully you can see where the combustion engine comes in. The sliding part of the mechanism is the piston on top and the rotational motion is below the piston. It's clear that this mechanism is extremely important for engineering because of it's many uses.



Well Windlass

Our second project was to build a small version of a well windlass.  There were many requirements:
  • The design has to span 12 cm, the width of the "well".
  • Limited to 500cm^2 Delrin sheet, 50cm Delrin rod, and 120 cm string.
  • The windlass must lift a 1L bottle 10 cm above the table without buckling, breaking, wobbling, or shaking.
  • One hand may be used to do the winding, and the crank or other mechanism must be positioned so it is not over the well.

1. Design Process
2. Engineering Analysis
3. SolidWorks and Construction
4. Final Product Testing
5. Accounting of Materials
6. Reflection


Design Process





My partner, Magdalena, and I began by sketching lots of ideas for windlasses. Our ideas included sides shaped like X's, triangles, rectangles, and more.  We brainstormed about ways to support the sides, ways to hold the rod, ways of attaching pieces together, and ideas for the crank.  



We eventually narrowed it down to a combination of rectangular sides shaped into a triangle, similar to the drawing at the very top of the image to the left.

Maggie and I decided on an overall triangular design because we thought it would stronger than a rectangular shape.  The design we chose combined multiple ideas.  The basic structure had two flat sides, two supports, the rod, and the crank.




The side pieces were rectangles that would lay together to form a triangle with notches to connect them at the top.  There would be two slots on each side piece for the supports to fit into. There was also one hole in the center of each for the rod. 



























We had to figure out how tall the structure needed to be to span the 12 cm and also bring the bottle 10 cm above the table. We went through some math calculations, as you can see in the scribbles on our sketches 
(geometry was a long time ago). We approximated about 15 cm for the height of the triangle because we needed the rod to be at about 12 cm to 13 cm height to ensure the bottle would reach 10 cm.




We originally approximated the triangle as a 45-45-90 triangle, so if the height was 15 cm, the side would be approximately 21 cm.  (Later when we cut the design out of foam, we concluded that the triangle would be more little more upright.  The approximate angle measurements are in our detailed sketches in the next section).


One of our original sketches above had the supports above the rod because we didn't want the supports to get in the way of the bottle as came up.  We later switched the supports and the rod, like the picture to the left, so that the rod was higher, but we made sure the supports were far enough apart to allow the bottle to fit between.




Engineering Analysis


We chose this design for many reasons.  The rod is at the top of the triangular design, so there is only a small part of the rod that supporting the force of the string pulling the bottle up.  The sides support the rod so it won't bend as the strings puts force on it (if the rod was lower, it would bend more and wouldn't be as strong because the sides are further out). We also thought the triangular shape would be more stable than most of our other ideas. 

The horizontal support bars hold the two sides together, so that they won't collapse.  The supports are put through tight slots on the sides, and then fitted on the outside with very tight rectangular bushings to ensure they will stay.  We originally thought about making a notch and heat staking the end of the support, but eventually decided on rectangular bushings instead.  This way the windlass could be disassembled if we needed to change a dimension or rebuild it.







After sketching everything out, we created a foam mockup of our windlass. Even with just foam, it was fairly stable.  We didn't cut bushings out of foam because they are so small, and instead just built them in SolidWorks.After seeing the foam mockup, we made a few small dimension changes.  We increased the length of the sides from 21 cm to 22 cm and we shifted the rod up about 1 cm more.  These dimensions changes are reflected in the sketches above, and are the dimensions we used for the SolidWorks design. 




SolidWorks and Construction

After we constructed our foam mockup, we started on creating SolidWorks parts and drawings.  Before creating the large final pieces, we made test pieces to test parts of our structures without wasting Delrin.




















Test Pieces:




Notches:  We made small pieces to test that the notches at the top would be a tight fit.  We made the widths of the tabs equal the first time, but this was too loose.  We changed the dimensions so that the tabs were wider, and the part the tab goes into was smaller.  This created too tight of a fit, even with some filing down, so we made a third test piece to find a fit between the two.


Slots:

We needed the supports to have a tight fit with the sides because they needed to hold the sides together and prevent them from collapsing.  We made a small piece with different size slots.  When we to print, however, we decided to use 1/8" Delrin when we had based measurements off of 3/16" Delrin.  This mattered because the width of the Delrin was the width of the slots.  We made a second test piece with corrected measurements.  We made a short version of the support piece, so we could test its fit with the slots.


Bushings:
We wanted these rectangular bushings to be as tight as possible.  The first test bushings were too loose.  We think it was because it was they were too thin on the outside,  so the material was bending as we put it around the support.  The second test, the bushings made a very tight fit with the support bars.

Holes/Circles:

We wanted the hole for the crank to be tight so the crank and rod would move together, not separately. We found that our test piece holes were not tight enough, so decided to just change this on our final piece (we made it slightly more small, so we could just sand it if needed).   
Also, the sides needed a loose hole for the rod to rotate in.  Maggie had a great idea to make it an ellipse instead of a circle. This way the rod wouldn't slide or move from side to side at the windlass was cranked, but the rod would be able to lie at an angle because the ellipse is tall in the vertical position.  We made a quick test piece to make sure it would fit right.  


After our dimensions were decided from testing parts, we sketched our final parts in SolidWorks.  We made drawings from the parts to print on the laser cutter.










We thought we were done when we printed our final pieces, but we had a few problems.  On CorelDraw, we couldn't make the ovals on the side piece hairline width, and when we hand-drew the oval in CorelDraw (and made it hairline) and ran it again, the Delrin had shifted or warped and made the holes in a slightly different place.  We had to reprint the sides a second time, and this time were very careful about placement.  Also, we had a lot of trouble heat staking the rod and the crank, and when we turned the crank it kept breaking off the rod.  We printed it a second time with a much smaller hole to try and fix this problem.


Final Product and Testing


Finally, we finished our well windlass!  We had time to test it once before the demo and it worked.  The class demonstrated our windlasses on Friday.  Ours worked and was able to lift the bottle 10 cm above the table without too much trouble and with only one hand doing the cranking.  Using one hand on the crank was doable, but a bit difficult.  Our structure was very strong though, and showed no signs of strain or breaking.  





It was also great to see the rest of the class's amazing designs!  It was a big step up from all of our one piece bottle openers.  As we watched the other demos, I took mental notes of certain design elements that were interesting, that worked well, and some that everyone struggled with.  Many designs had a spool for the string to wrap around when winding, larger than a single rod, making it faster to bring the bottle up the well, which I thought was a great design element.  Also, it was interesting to see some of the arched or rounded designs, which were aesthetically pleasing, and to see those that enclosed or supported the rod completely with Delrin parts so it wouldn't bend.  Some projects had multiple rods for their axle that were connected to the crank, and this not only made their axle strong, but also helped the crank move with the axle and not slip.  One thing that most designs struggled with was the crank.  Many were difficult, as with ours, to crank with one hand.  There are definitely improvement opportunities for the cranks.


Accounting of materials

Our limit for materials was 500 cm^2 of Delrin and 50 cm Delrin rod

Sides:        22 cm  x  9 cm = 198 cm^2 (x2) = 396.0 cm^2

Supports:   20 cm  x  1 cm =  20 cm^2 (x2) =   40.0 cm^2
Crank:       pi(2)^2 cm + (4x2) cm               =   20.6 cm^2
Bushings:   9.15 x 15.8 = 144.6 mm^2 (x4)  =    5.8 cm^2

Total:  463 cm^2 Delrin, 25 cm Delrin rod


Reflection

Overall, I'm proud of our design for working and meeting all of the requirements.  Our design was simple, and we were able to incorporate different ways of attaching Delrin together.  We also learned how to use many new power tools in the Engineering Lab and improved our skills with SolidWorks parts, assemblies, and drawings.


Some improvements I could think of for our design would be for the design to be a little more appealing and use less material.  For example, we could probably create the triangle shape without using so much material for the sides. Our overall design could be scaled down about ten percent because we had plenty of wiggle room in the 12 cm width as well as the 10 cm bottle height requirement.  Also, our crank and axle can definitely be improved to make it easier to rotate with one hand, maybe creating a longer handle or a different design.  Creating a spool for the string to wrap around would also be a good idea because we had trouble with the string wrapping all around the rod and not being able to turn it any more because the string hit the sides.



Also, Maggie and I worked really well together and communicated well.  We both made great design contributions to our windlass and we were able to combine and improve each others ideas.  (Fun fact: we figured out we took PHYS 107 together last semester, but we didn't really know each other at the time!)



We're now starting a new project, with a new partner (I enjoy changing partners and getting to know everyone in the class through projects).  Kasirha and I are working together for the next project, building a Lego racer.  When we started on Friday, we got super excited about gears and Legos and are eager to work on building our car!