Firefighter: Finishing Up

I left on Sunday to go home so my partner was awesome and showed Lyn and Professor Berg our robot by herself.

Apparently there were some slight problems. Lyn changed the program for the servo motor so my partner had to change the angles for the motor so that it worked properly. She changed both the starting angle and the ending angle so that the cup did no try to go beyond the base/platform that it is resting on and so that it didn't go so far that it hit the middle sensor. Neither of these were problems before but I guess the angles got messed up when the program was changed.

She also said that changing to new batteries made the car so significantly faster although it still did not go as fast at the other cars.

Other than that, from what I heard our robot successfully put the fire out. I know that it can repeatedly put the fire out because I tested it many times before Monday. I have full confidence that, as long as the sensors are correct, the batteries are full and the candle is at a reasonable height, our robot will put out the flame. (It sounds like a lot of conditions but its really not that many... )

Firefighter: Everything Together

After got the shaker to work and everything assembled. We started our first test run with everything together. And it ended up being rather disastrous. The car fell over when the salt shaker went forward because there ended up being too much weight in the front when the cup went forwards. So we added weight to the back of the car in the form of other lego motors. This successfully solved that problem.

The next problem that we came across was that the car would continue into the next nudge and find2 loop before the previous putout process was over. We made the iteration of adding waits after all of the putout processes so that the program would wait until they were done until going on in the loop. We had to play with out how long the waits would be.

Another problem that we came across was that the car would start stalling during find1. We found that adjustments of the sensor angles fixed this. Because the program relies heavily on feedback from the sensors, the program is very sensitive to the angles of the sensors.

This is a video of our robot. It moves very slow...

Firefighter: Getting the Shaker to Work

After talking to Lyn, we figured out that we were using the wrong motor. Instead of the continuous servo motor, we had to use the regular servo motor. This was the motor that we could program to go a certain angle.

Lyn gave us this program.

Then, we just played with programming until we figured out how to get it to work and go the distance that we wanted it to. These are the numbers for the angles that we came up with.

Firefighter: To the Flame

We started the programming without the putting-out mechanism because we couldn't get the servo motor to work properly.

Luckily, when we started, we knew where we wanted the sensors to be placed and had some idea of how we were going to get the car to determine where the candle is. We used three sensors, one right in the middle, and one on either side of the car.

When looking at the car from behind:

Sensor 1 = left sensor

Sensor 2 = middle sensor

Sensor 3 = right sensor

We started out by getting a sense of how the sensors would read at different positions and at different distances. Programs to read each of the sensor readings at different positions.

We tested from close up what each sensor read when the car was looking straight at the candle, when it was turned right and when it was turned left. We did the same for when the car was 10 feet away. As we had hoped for, when the car was looking straight at it, the middle sensor read the highest, when it was turned right, the left sensor read higher and when it was turned left, the right sensor read higher. This was the information we needed for the car to guide itself to the candle using feedback from the sensors.

These were the simple procedures that we used at the foundation of our program.

The first thing that we decided was that the program had to be split into different sections. The first was getting the car to face the candle initially before it started heading towards the candle. So we made it spin in one direction until the middle sensor hit a certain number and then keep adjusting itself until the middle sensor hit a higher, more precise number.

Find1

It ended up that we probably didn't need the second part of this adjustment because in practice, the car usually just stopped after the initial turning and then went on to the next part of the program.

The next section of the program was the actual driving to the candle part. We didn't really trust any of the bang bang or proportional controls for straightness. So we decided to use feedback, not from the shaft encoders, but from the sensors to guide the car. We implemented a program similar to the bang bang control we used earlier. If either of the side sensors reads larger than the other one, the car will bear in a certain direction. This happens until the middle sensor reads a certain number and, since we knew that thresholds from the sensors are not very reliable, the count is above a certain number.

Go

Once it got to the candle we also added in a safety-net find program that would reposition the car so that it is facing the candle just in case it was not facing the candle after driving there.

Find2

We also knew that we needed a put-out mechanism but we didn't have one at this point because we needed to ask Lyn how to get that to work.

So we put it all together and ended up with this (only we did not have the waits at this point, those were an iteration that we added on after we got the put out mechanism to work). We figured that that the car did not get to the candle every time depending on how much it swerved. We programed the car so that once the 'go' function was over, it would nudge and put out until the sensors sensed that the candle was out.

One thing is that the car drives very slowly but we don't quite know why it does this.

Firefighter: Putting out the Flame

One of the first ideas that my partner came up with was using borox (which is a type of laundry detergent) to put out the fire. We also came up with ideas like using the spray bottle and smothering the flame. But we ended up just running with the borox idea.

We experimented with a bit of borox. When we mixed it with water we found that we didn't really need to hit the flame directly at all to get it to go out. The only way that we could think of for getting the dissolved borox onto the flame was using a spray bottle so we kept thinking.

We also thought of ways that we could just use powdered borox. We came up with the idea of just tipping over a cup containing the borox. We also came up with a clever idea of having a cup with holes at the bottom. We could then have a fan-like thing start spinning once we got over the flame so that it would hopefully disturb the powder so that it came out the bottom. One of the concerns we had for this design was the way that that the weight would be distributed. In this design, all of the weight from the mechanism and the motor are on the front of the car.

What we ended up with was a shalt shaker design. This consisted of caging a cup in with a delrin top that has holes drilled into the top. The caged in salt shaker would be connected to a servo motor which would carry the cup over the top of the car onto the flame in front.

This piece is what connects to the servo motor.

This is the second part of the cage portion. This one would line up perpendicular to the other piece and the notch on th bottom of this piece fits into the notch at the top of the other one.

The hooks on the tops of the previous two pieces would fit into the four rectangles at the top piece. This is what covers the top of the cup and acts as the salt shaker. My partner expertly drilled holes all over this plain circle using the drill press to make it into the salt shaker.

When we first printed all of the pieces out, we realized that we couldn't really get the pieces to all fit together because the cage was too tightly fit. We just needed a simple iteration for it to all fit together though. We just shortened the 'teeth' (that fit into the shaker top) of the first piece above (the one with the arm that connects to the servo motor) so that the cup would pop into the cage. It was a pretty frustrating problem that ended up being solved by a very small iteration. It was just a couple of millimeters off of that portion of the piece.

This is what the salt shaker looked like after it was all assembled.

We connected our salt shaker to a continuous servo motor (which we later learned was a the wrong motor we wanted the regular servo motor). In order to get it to go the distance we wanted we tried to use a time. But as can probably be predicted this didn't work very well. The angle changed every time the motor went back and forth and it was extremely unpredictable.

We knew that the servo motor could be programmed to go a certain angle because other groups had done it in the walking robot challenge but we couldn't figure it out.

So we just decided to go on and start creating the program for finding and getting to the candle. And then we could ask Lyn about the motor the next day.

Later on, the salt shaker ended up being a very useful mechanism because it allowed the car to try putting the candle out multiple times. The putting-out mechanism was not a one shot deal and this was good because our program ended up making good use of this feature of the salt shaker.

Final Logochip Challenge 9: All Together Now

This was out complicated program for combining the proportional straightness and proportional distance with nudging. As we said before, the straightness with proportional control did not seen to work very well and the same was true with this program. The distance was okay but the car did not seem to control its straightness very well.

Final Logochip Challenge 8: Distance with Nudging

This program would nudge the car until it got to the line. We needed to add this onto the proportional control for distance because the car would always stop short. This is because the motor would not have enough power by the end to overcome friction. With the nudging, the car power on the motors would turn on and off and the car would inch up the the line until the shaft encoders hit a certain number.

The program worked very well just on the ground of the lab. Going uphill the program worked reasonably well but was always a little bit short of reaching the full ten feet. The nudging also was very crooked on the uphill for some reason. The car was constantly veering off in its nudges. On the other hand, going downhill, the program seemed to always overshoot by a little but and also have some trouble stopping.

Final Logochip Challenge 7: Distance with Proportional Control

We created this program for distance using proportional control. It was hard to figure out what 'n' should be set as because the direction were kind of confusing to us. However, we made this our program. The distance was very close but would never quite get there because the power in the motors would be too low to overcome the friction. We could tell because we could hear the high pitched sound of the motor trying to turn.

Final Logochip Challenge 6: Distance with Bang-Bang Control

This was our first complicated program. We had a lot of trouble with this challenge and mostly because we were not doing the right challenge. We had thought that we needed to combing the bang bang straightness and the bang bang control so the program that we were trying to do was rather complicated.

However, we did eventually figure out that the program was for bang bang distance and was relatively simple. So this is what we ended up with. The distance was always pretty good but it would always overshoot or undershoot by a little bit.

Final Logochip Challenge 5: Simple Back and Forth

This program uses the shaft encoders to have the car go ten feet and back again. Works much better than using the time. It was similar to when we had the one wheel turn ten times and then turn back ten times only this time it was with both wheels on the car. The car comes very close to where it started. However, it does not come as close if it is going up and down hill. In an inclined situation, if the procedure is invoked three times, the car gets further and further from the starting point.

Final Logochip Challenge 4: Simple Distance

Controlling the distance with time did not work well at all. Especially if any of the other variables were changed.

If there was any slipping or sliding of the wheels, the shaft encoders would not be accurate in determining the distance that the car traveled.

Final Logochip Challenge 3: Straightness with Proportional Control

Final Logochip Challenge 2: Straightness with Bang-Bang Control

This was straightness with bang-bang-control. We liked this straightness control. The car does wiggle a little bit and more when there is friction on the wheels but the car does drive very straight.

Final Logochip Challenge 1: Simple Straightness

For this we just implemented the 'forward' function that we created in the previous challenge. The forward function goes fairly straight when there is no friction on either wheel. However, when we put friction on either or both wheels the car did not go so straight anymore.... at all.

Logochip Challenge 8 – MotorCar Construction and Programming

These are some pictures of our completed motor car.

And these are the procedures that will make the car go forwads, backwards, coast, brake, spin right, spin left, bear right and bear left.

Logochip Challenge 7 – Shaft Encoding

We finally connected to the lego motors for this challenge. Getting everything connected correctly was a bit of a challenge because we had so many wires in the board at that point. Once we got everything connected and working we realized that we had to use the oscilloscope. So we had to get help with that... again. Finally, after we got everything set up correctly, the program that counts the shaft encoding is in the upper-left hand corner.

The other stuff is a failed and very complicated version of getting the shaft encoder to determine the direction of the motor.

We ended up with this program which counts up when the motor is turned forwards and counts down when the motor is turned backwards.
The top few programs control the motor in making it coast, brake, go forwards (thisway) and backwards (thatway).

The program below makes the motor go thisway for ten revolutions and then thatway for ten revolutions. We did this by determining the count for one revolution and then multiplying that by ten. Then we had the motor turn thisway until the count reached ten revolutions and then thatway until the count went back to zero.

Logochip Challenge 6: Detecting Multiple Edges in a Single Thread

In this challenge we couldn't use the 'waituntil' functions because then the code would stop at the 'waituntil'. This means that it wouldn't read if the other switch was pressed. We had to use something else and the clever solution is the 'if-then' or the 'if-then-else' statements.

Logochip - Challenge 5: Shadow Detector

For this challenge we had to wire into the photocell which was not too hard. But was also had to use the oscilloscope again. Which was, again, a problem. I just don't think we are getting too used to this oscilloscope thing. But we had to ask for help again in getting the oscilloscope to work correctly. But after that things went smoothly. This challenge was really similar to detecting edges with a switch. We just had to read what the values were when there was a shadow and when there wasn't a shadow. For this challenge, we counted how many fingers passed over the photocell which was similar to counting how many times we pressed the switch.

Logochip - Challenge 4: Zero to Sixty

We had to wire a transistor into the board for this challenge. After that, actually making the program wasn't too hard. It was more of using the 'n' and figuring out how to effectively change the value of 'n' every time through the loop.

Horsebot - more more interation

Horsebot has been taped together for a long time now. So, we made the base of the horsebot tight fit into the sides. We had originally planned on heat staking the bottom on. However, we realized through the process that we need to be able to take the bottom piece off if we ever run into engine troubles or anything else ever again. If the bottom is heat staked, we can't move anything. In doing this, we, of course, ran into some laserprinter problems as we always do by my partner figured it all out in the end so we did eventually get the base to print.

We faced some technical difficulties today in regards to the battery. One of the wires that we had sodered broke so we had to soder the wire back on. However, when we stripped the wire down so we could re-sodder it, we discovered that there were many tiny wires instead of one wire. Hopefully this doesn't mean anything bad because we just soddered it on anyways.

The motor doesn't work very properly it tends to turn on and off even when the switch is flipped. We don't particularly know what the problem is but it doesn't pose as too much of a problem except for the fact that it turns off once in a while.

We realized that the motor has to be in the front to give the front weight so that the legs are all touching the ground and the horsebot walks forward instead of just falling backwards. In order to do this the motor has to be upside-down which doesn't really pose a problem at all.

We next tried him out on different surfaces. We found that he walks really well on the table tops and the lab floor. When we tried him on the carpet outside, though, the two front legs kept getting stuck on in the carpet because the two front legs just slid back and forth although the two back legs move up and down. So we decided to put something that would help the two front legs to slide on the bottoms. We put the cushionny double-sided tape on it and then covered it with regular tape. The horsebot now walks on carpet also but not as well as on other surfaces.

Logochip - Challenge 3: Counting Edges

This challenge can basically be broken down into two different sections. The counting section and the getting the light to blink section. And neither of us having had a cs or programming background, had no idea how to go about doing this. Actually, we didn't even know where to start. We set up the switch and the light but then we sat staring at combinations of two or three pieces that had no chance of working.

We knew that we still had to incorporate the previous challenge because we still had to face the problem of bounce. Beyond that we figured that it had something to do with the recording program so we went back into the tutorial to try and find that section where we created some sort of graph. We tinkled with a lot of stuff and eventually we got a lot of help from Lyn.

When Lyn came over he basically walked us through the logic of how to create the program. The logic behind making programs is very different from other things. It requires a different way of thinking and I think it'll take a little while to figure out the thought processes.

He explained to us that we need to set the program. So start the count and zero. And then we can start the sequence. The sequence was very similar to the one for the toggle challenge. However, what we had to figure out for this one was how to use the 'n' and the print blocks. These were basically what would count the number of times the button was pressed. One of the keys were having the 'n+1'.

Now we had to add the flash which was, surprisingly, simple. We just had to use the 'if' block and make the condition that n=5 and then have the light flash and reset n=0.

Programs always seem so much simpler when they are all done and working. However, they are far from simple to make and when a program doesn't work I find that it's really hard to figure out what is wrong or if the whole entire procedure is wrong.

Logochip - Challenge 2: Toggle Fix

We are trying to connect a switch into the input of the board which then supposedly makes the light (output) turn on and off each time we press the switch. The challenge was supposed to be to fix the switch bounce which was making this program unreliable. However, before we could get to the actual programing and the challenge we ran into many technical difficulties.

We figured out right off the bat that our motor wasn't working properly and so we had to get a new motor.

Next was to get everything actually plugged in and working properly. The motor and the switch were good. The problem here was getting the oscilloscope connected and functional and we ran into multiple problems in trying to do this. First off, our setting weren't right so we had to go through all of it fiddling with trying to get it to work. The only problem with this was that we were testing whether it was working properly or not by turning the circuit on and off but it wasn't connected properly to the circuit so it wasn't reading anything either way. Once had been struggling with this for a while we asked Professor Berg for help. At this time, Professor Berg basically set up the whole thing for us and while is do understand how to connect it better, I'm still not entirely sure I know how to work it and I still an not confident that I could do it on my own. But in better news, the oscilloscope was working now. And the switch-bounce looked like this.

One thing I did learn from this oscilloscope though, is that there are highs and lows. The high is the power source where the '+' is and the low is the ground where the '-' is. I realize that I probably should have know this before, but one step at a time...

So we figured out how long the switch bounce took we started fiddling with programs. First we started with the original wrong program that was shown in class and moved on from there. Actually our first idea was the one below (which actually is the right one) but it wasn't working. So we moved onto other complex (and wrong) programs that involved "if...thens" and other things. Eventually we had to, once again, call Professor Berg over because we were thoroughly our of ideas and frustrated. He walked us through it and brought us back to our first idea. Then it didn't work and Professor Berg we confused also. After which we figured out after all of this frustration that our switch wasn't working properly. So we finally got it to work and this is what the working program looks like.

Logochip - Challenge 1: Getting Started

This assignment is basically a large tutorial in which was are slowly learning how to put together our breadboard of wonderful lights, wires and other gizmos and how to use the picoblocks program.

So far, we have assembled our board with minimal problems. We got the lights to flash in different patterns and such and we connected a little sound maker/speaker device and we got it to play a little tune which was exciting.

The tutorial is not finished as of yet and we are just doing in slowly in between project. However, we have found that it is a little bit confusing trying to keep track of all of the wires and circuits that we have going on. It gets confusing trying to keep track of what we have finished using and what we still need.

More updates on this will follow....

Horsebot - starting to make him work

For some reason our little horsebot is not working as well as he did the first day that we put him together. We think that this is partially due to the fact that horsebot's legs are not moving as they should. At first we liked the fact that his legs didn't move at the same time because it made him more unpredictable and life-like but now it just makes him fall backwards all the time so we're not so excited about it anymore.

Therefore, we made several iterations:

1. We made the back legs with feet on them. If you remeber from the last post, we had taped on lego feet onto the horsebot so we were just making that into delrin. It does help the horsebot to balance a lot better than before.

2. We put a single axle through the motor so that the legs are moving at the same time in relation to each other. This helps with the balance also and this is what we originally wanted so this was a good change.

3. We played around with the weights and the balance of the motor and the battery. We discovered that the balance worked much better when a lot of the weight was on the front so we put the motor at the front end of the base and the battery on the back end of the base. This helps the horsebot to walk because it makes sure the front legs are on the ground to pull it forward instead of just falling backwards.

We still have to reprint the base to make it tight fit so that he can stay together on his own (hopefully) and not have to be taped together!

Horsebot - Building It

Our wonderful little horsebot works. We decided to go with the teflon rods because when we were manually turning the axel, the teflon rod one was easier to turn for some reason. We then proceeded to make our motor.

We need a motor that has one axle so that both of the legs turn at the same rate. This is because our design banks on the fact that the legs on one side opens while the legs on the other side closes. This creates the "horse-like" walking of the robot. However, we do not yet have one axle so the legs do not move at the same rate and so our hosebot falls over sometimes.

We placed the motor on the backside of the horsebot to give him better balance. However, when we also placed the batteries back there, it fell backwards. So we put the motor in the back end and the batteries in the front end this way the back end is still heavier than the front end but not so much so that it falls backwards.

and here it is....

As you can see in the video we were experimenting with putting feet on him. We discovered that putting feet on his back legs helped to balance everything out. So no we have to recreate back legs that have feet on them as well as get a single axel for the motor.

As you may also see from the video, horsebot is basically taped together at this point and time. This is so that we could fix the motor and other parts if we realized that there were problems. We were originally planning on heat staking the robot together. However, if we did that we wouldn't be able to get to the motor. Having made a rough version of the horsebot we realize that it would not be a good idea to heat stake everything together because that would mean it would be extremely hard to make any iterations or fix any motor parts if they came loose. We decided to make the sides and the base a "tight fit" together so that it would hopefully not come apart.

Horsebot - Printing out the Pieces

It came time to print out the pieces for our horsebot... and we encountered some complications.

Recall that we wanted to test out using the music wire or the teflon rod for the joints of the horse. However, the holes when using the music wire must be drilled for accuracy. However, we needed the laser cutter to make the specific measurements for where the holes would be on their pieces. We asked the ninja for a solution to this dilemma and what he came up with was this: create a teeny tiny hole in solidworks so that the laser cutter doesn't actually make a hole but just makes enough of a marker so that we can tell where the drill them ourselves. So on solidworks we made the holes .02 mm.

To make the comparison between the two joints we decided to make one side of the horse for each joint. But we can't keep the same solidworks pieces and print out the parts for both joints at once but we had to print out one side and then go back and changes the dimensions and print out the other side. This proved to be extremely time consuming because there is always a line for the laser cutter.

Another problem we encountered when printing the parts out was that our connector/"femur" pieces weren't turning completely red. It had a layer of red and a layer of grey/black and so the laser printer didn't read it just as a cut. As it turns out it wasn't too much of a problem but the laser cutter did etch the lines first before it went back and actually cut through them.

Once our pieces were all cut out we had to drill all of the holes for the wire. This was difficult considering we made our bushings so tiny and holes had to be drilled into them. Luckily my partner is very skilled at using this drill having used it many times before and was able to wonderfully drill all of the holes.

One thing we noticed with the pieces with the teflon rods and joints was that some of the bushings were put too close on the drawing because they somewhat melted into each other. That's one mistake we will be careful to avoid in the future. the circle piece was also melted slightly so we decided that that had to be enlarged to avoid this melting.

The next part in the process is assembling everything, making our motor, figuring out what joints we are going to use and printing out and building the other half of the horse. Not to mention all of the iterations and small changes that we have to do in the process to make it all work.

Horsebot - Solidworks

We decided to do the horse-bot. One decision we had yet to make was whether we were going to make the "joints" out of music wire or teflon rods. We originally wanted to make it out of music wire therefore we made of the solidworks parts to fit the music wire. These were the pieces we had to make:

1. base for the motor and battery to sit on (1)

2. sides that the axles of the motor to go through (2)

3. circles (2)

4. connecting "femurs" (4)

5. legs (4)

6. bushings (34)

+

7. joints to represent the music wires in the assembly (7)

All of the individual pieces were fairly easy to make because they are simple geometric shapes (circles and rectangles) but the hard part is making the assembly.

The assembly was extremely difficult to do. The center (motor) axis is a pentagon and for some reason you can't concentrically mate a pentagon to a circle or another pentagonal hole. We couldn't quite figure out how to mate up the motor axis with any of the other holes, so we couldn't get the whole apparatus to turn and function because the motor wasn't properly mated to anything else. Besides the fact that the motor wasn't connected to anything and the assembly didn't turn, we ran into other complications along the way as well. This was my fault but when I made the assembly I forgot that we needed bushings so I didn't include them and just mated all of the other parts to each other. Therefore, we had to go back and delete most of the mates to add the bushings in. We have yet to get the stimulation to work for this assembly.

Pictures will follow of the parts and the assembly!!

Motion Module - Another Iteration

We made another iteration of the motion module. The offset circle and the arm of the module weren't aligning very well and we needed a way to force them into the same line. So we basically printed out another base piece. We then smushed the arm and the offset circle between these two base pieces which gave it much more stability. This is what our motion module now looks like. The arm and the circle now have to move between the two base pieces and move in the same plane so that the circle effectively pushes the arm up.

Walking Robot - Models

This is the foam core model of the froggy. While making this we realized that the placing of the joints between the legs is extremely important to the function of the legs. We would have to be very careful about where the joints go and what the joints are made out of.

This is the final lego model. We went through several lego models before we were able to make the four legged model. However, we kept making the iterations on the previous lego models before we took pictures of the failed models. Each side is the same thing only flipped around and the two sides are offset so that the legs move opposite to each other. The motion of the legs mimics the motion of a four legged animal. However, the lego model horse-bot doesn't balance very well.

Some solutions to the balance problems that we came up with is adding feet to the legs which actually did help. However, another solution might be to add a tail of some sort that helps the robot to balance when it is in unstable positions.

Walking Robot - Initial Sketches

These are our initial designs for the walking robot. This is our horse-bot, we had initially looked at a six legged robot. First, we made the six-legged model on legos. We then modified it enough to come up with a design for the four legged horse-bot. It will use a DC motor to turn an axle which moves the entire robot.

This next design is aquatic and is dubbed the froggy. We it makes use of a servo motor that moves the legs back and forth. The legs are designed so that they bend in one direction but straighten in the other direction. This way as the legs go out, they bend and as they come back in, they straighten and push the water out.

This design is the spiral tail. It is a number of plates along a teflon rod. The plates would be placed so that they create a spiral pattern down and along the teflon rod. Hopefully, as the wheel turns, the spiral pattern will push the water out.
This is the scuttle bot. It was inspired by a crab. We were trying to figure out how to make a side walking robot. The bet we could do is this. We would have two squares on top of each other and the top one would be connected to a servo motor. The feet would only move in one direction and the robot would "scuttle" back and forth.
This is a simple rower, thus it is called the rower. It uses a DC motor to turn two circles and it turns the oars in a circular motion. The one concern that we had was whether or not the teflon would float on the water and whether or not we would actually be able to make a "boat" out of teflon.

Motion Module - Final Iteration

So, we are finally done with the motion module chomper. Due to my partner's awesomeness at computers making the iteration was fast and painless. We changed the size of the bushings and the offset circle from a 6.26 mm hole to a 6.2 mm hole which worked wonders. The washer/bushings and the offset circle no longer slip on the rod and stay in place so that the circle efficiently pushes the arm up. We did not change the size of the arm because while the arm was designated as a tight fit piece it doesn't have to function as a tight fit piece. It just has to move freely about the rod in order to move up and down. Since we tightened the bushings around the arm, it stays in place and functions just fine as the arm. The motion module looks the same as it did before the iterations, the holes around the rod are just slightly smaller. On to the next project!

Motion Module - Printing it Out

Our next step was to actually print out our motion module. To do this we had to put all of the pieces into a drawing consolidate it so it would print out well. We tried to do this but the laser cutter was having some problems and we had to wait a long time before we got to cut out our pieces.

Having printed out our next step was to put it all together. It was all going pretty smooth until we took one of the wrong pieces of rod which is apparently smaller than the ones we are actually using and as we tried to fit all the pieces in... they were way too loose. So we proceeded to get extremely frustrated and redid all of the dimensioning for a much smaller hole. As we were waiting for our turn on the laser cutter we cut out pieces from the correct rod and found that, hey it actually fits.... all of that re-dimensioning for nothing.

Here is our fully put together motion module. Simple and working.

One iteration that we might have to do is make our tight fit parts tighter because some of the parts and slipping now. We shall see how it looks tomorrow!

Motion Module - SolidWorks Assembly

Now we had to take all of the solidworks parts and combine them into an assembly, which we had no idea how to do. So we fiddled around with the solid works and eventually figured out how to get the parts onto the assembly. Yay!

Then we stared at the screen a little bit wondering what to do with these parts. One thing we did figure out on our own was that we had to make the rods as a part in solidworks so that we would have the rods to stick the pieces into. So we did that and then stared at the screen again.

We tried all of the usual things like trying to line them up my hand and hoping against all odds that the parts would stay like that when we started to rotate it, which of course it didn't. Then we overheard the ninja saying "..something something MATE something something..".

So clicked on the mate button, which worked wonders. We started to mate them to together using the concentric function. We made all of the holes that the rod went through, concentric with the rods. Now we had the parts onto the rod but the kept sliding back and forth and overlapping on each other.

At this point, the class tutorial on mating started and we discovered the coincident function. We then made all of the pieces that need to be next to each other coincident so that all of the pieces were now stuck together.

Our last problem was that the arm and the offset circle were overlapping in the assembly. We solved this by making the two surfaces that touched tangent to each other. We ended up with this assembly after a lot of tinkering and a lot of mating.

We then happened to see the simulation button and decided to try that one. We clicked simulation rotation and then chose the offset circle to be the one that rotated. And it worked wonderfully!

The most wonderful thing about this process was that it told us that the arm piece was too tall so there was a "collision" and it wouldn't work. So we went back and made that piece shorter so that it would work! Solidworks told us that out initial design wouldn't work and we were able to make the iteration before we printed out the pieces!!