Today we started Labview programming and constructing walking TETRIX/LEGO robots. The original plan was to make TETRIX walking robots, but we could not figure out why the TETRIX DC motors/servo’s wouldn’t run. Neither I, nor Morgan could get them running, so we decided to make LEGO Mindstorms walking robots. The robots were to not use wheels and simulate walking. The two general ideas were to make a robot that actually walks, like Lawrence’s “horse” idea or to make a robot that drags itself, like Dean/Jess and Sarah/Briyana’s dragging bots. For the Labview programming, Morgan gave a 1.5 hour-long programming demo and introduction; thereafter we made our own sample codes and eventually used these codes of the walking robots.
Horse bot: Lawrence
The goal was to make the robot run like a horse, but figuring out the timing and the power levels of the front/back NXT motor was a nightmare. Eventually the robot ended up working with an awkward sort of dragging/limping motion, rather than a smooth gallop.
Destroyer bot: Sarah/Briyana:
Destroyer Bot – Short Demo
Originally a more complex robot; upon testing it, it broke a few connections and accidentally formed this robot, which rolls along the floor much like the Destroyer droids in Star Wars (hence it’s name).
Also, ultimate frisbee with other CEEO employees at noon.
Dean: Walking robots: Didn’t do it, instead, built the Tank. Destroyer robot and horsey was pretty cool though. Labview: reminds me of mindstorms NXT program; boring.
Lawrence: Labview programming was not the greatest thing because it was time consuming and boring. The result of the programs we made is really what is great about Labview because some of the programs are really fascinating like the buttons one. The buttons one was programmed to make the NXT like a controller. We had the middle button to go forward and the right button to go right an the left button to go left it was actually really cool and not that hard to program. The Horse Robot that I made was really simple and cool. It was a disaster but in the same was a success. My intentions were to get it to walk without falling. It didn’t quite work like that though it just fell and started to drag itself with its 2 front legs and it went straighter than I expected. I also got it to flip itself so that the legs that were being dragged before actually were doing the dragging now. This ended up working even though it wasn’t intentional. The only difficult part about this robot is the controlling because I used the buttons controls to run it and once you get the hang of it works well. Also during lunch time this day I played my first game of ultimate frisbee with the CEEO colleagues and it was really intense and fun.
Jess: Both making a walking robot and programming in labview came rather easily. In my robotics class at school a group of friends and myself had had a no-wheels robot race, and so most of the robots had been non-standard vehicles that dragged themselves like half-paralyzed, demented vertebrates. So I just attempted to recreate an idea I had had then. Labview was somewhat similar to the Mindstorms programming, which I also had background in, so it was somewhat easy to explore and discover. Within an hour or so I managed to accomplish my goal of making a robot that would start when its touch sensor was pressed, drive straight until it spotted darkness, t hen back up and turn right before going straight some more. I suppose it was a line-avoiding robot. Ultimate frisbee was pretty awesome.
Briyana: I originally wanted to make a walking robot with four equal length legs, that didn’t work at all. Then I took two of the legs off, had a base for the NXT brick, which fell off anyway. Then made the last two legs shorter. When I tested the robot it worked quite differently then I had first planned, but it still worked. Programming is definitely hard, I’ve done it before but nothing this advanced. I mostly had done programming but mostly just getting the motor to move around with different sequence pattern and have the sensor stop if it sees black tape, for example.
Sarah: It was extremely hilarious to watch the destroyer bot destroy itself on the first run. Creating walking robots was difficult to do using pieces provided and the robot also had to the hold the heavy NXT brick, which was a problem for balance.
Today we started the science intro and finished the holding bots. Also, at 1pm, Jim Hoffman,
the Machine Shop Coordinator, took us on a tour of the Machine Shop in Bray.
For the science intros, I reviewed the Massachusetts engineering design process and it’s 8 steps. Also, we researched possible NASA science ideas and came up with a list of possible ideas. The list included physics project ideas and a PH analyzer, but mostly was different rover ideas. We decided the final groups would be Dean and I, Lawrence and Jess, and Sarah and Briyana. Lawrence and Jess decided on an Axel Rover, Sarah and Briyana decided on a crater detecting rover, and Dean and I decided on making a combined Space Elevator/Lunar Lander. For that idea, the students would build a TETRIX robot that climbs a nylon cord, simulating climbing a space elevator. A fan would simulate wind in the atmosphere and an ultrasonic sensor would slow the robot as it approaches the ceiling. On the way down, it would have to slow down and land on an uneven surface.
We also finished the holding robots, focusing on the design process.
Lawrence/Briyana’s final robot worked well; previous version’s had a glitchy grabbing arm for holding onto other robots. The only flaw was that the omni wheels provided by the TETRIX kits were so wobbly that no matter how they were attached, the cup of water would spill. The CD was held in place by rubber bands forcing a pressure fit of two metal parts: strong enough to hold the CD but weak enough to allow a CD drive to pull the CD into itself.
Dean and Sarah’s final robot worked incredibly well: the wrench could spin 360 degrees, the Nintendo game was securely attached, and the change was held in a simple, modular compartment; it could be easily attached/detached and easy to build.
Jess and I’s final robot was unfinished since we hit the maximum build time. The calculator was easy to mount as the edges of the TI-83 slid perfectly into the metal pieces; the width of the metal pieces is the same size as the gap on the edge of the calculator. The screwdrivers were also easy to mount; their handles were larger than their shafts, so they could be slid into place and then suspended higher up with spacers. The pencil/pen/sharpie however was a disaster as they were seemingly impossible to mount at first. When we finally came up with a solution (by rubberbanding them in place), we ran out of time. -Nicolas
Holding Project’s Design Process
1. Identify the problem
2. Research the problem
3. Develop possible solutions
4. Choose the best solutions
5. Construct a prototype
6. Test and evaluate prototype
7. Communicate the solution
1. Hold calculator, writing implements, screwdrivers
2. Trial and error with designs
3/4/5/6/8. Frames for calculator slots, tubes for screwdrivers, tube clamp for writing implements (the tube idea ended up being thrown away later in the design process (redesign). A lot of trial and error went into the design phase. Ideas were thought up and then mocked up sans screws, with some seeming better than others. The best ideas were individually constructed based on function. Putting them together is when problems arose. The tubes were shown to not work in this situation, as they didn’t attach well. A lot of complex ideas were thrown away for simpler ones. The wheels were really flimsy when we used LEGO axles, so we instead remade them with screws. Finally, the individual writing holders were abandoned for a single, rubber-banded stick. The only original idea to last was the calculator holder.
7. The only step we didn’t do is communicate, as we didn’t have time.
1. Finding a way to hold a CD without restricting the CD from being pulled out.
2. Rubber bands work to hold the CD in place. Wheels could also work to move the CD through (small/big)
3. Put two wheels together on each side of CD to guide through. Rubber bands hold in place.
4. Rubber bands and wheels to guide when pulled and hold in place.
5. Built around till we had a working prototype.
6. Holds everything; omni wheels however cause water to spill
7. Showed it off
8. Wrap rubber bands around prongs 3x for tight non-restraining hold. Don’t use omniwheels
1. The problem was that I had to make a robot that could hold a cup of water, a CD, and a crane to attach to other robots.
2. I didn’t do much research. I just did trial and error, which in retrospect was bad.
3/4. Our solutions were zipties and elastics because we needed the CD to be takeable, and they worked.
5. We made the CD holder tighter, we made the walls for the cup so it wouldn’t fall, and we made a long crane to attach to other robots.
6. The prototype holds CD steady and the cup is held securely, but when the robot moves the shaking caused by the omni wheels causes water to spill.
7. Handing in a written piece of paper containing this info (steps 1-8)
8. Kept having to move crane up and down and added sides to keep from sliding off.
Difficulties: Screws are sometimes hard to reach, sometimes stuck, and the edges of the nut hurt to screw into place. Also, not many pieces.
Process: After starting out with a base, the attachments were redesigned to work and fit together. The game holder had to be redesigned to accommodate the wrench pivot device. Upon realizing that the NXT brick had to be included, we had to find space on the base and we also tried out various brick support structures. The omnidirectional wheels were originally to be on the outside but we decided to place them inside to give a sleeker look and coserve space
Conclusion: The majority of time was spent building, rather than thinking ahead. This is both because people preferred to just build and use trial and error, but also because the unfamiliar TETRIX pieces take a long time to put together.
Dean: The machine shop tour was slightly boring and a little long, but the machines were cool. Science ideas: I thought the space elevator idea was pretty cool.
Lawrence: This day was an interesting day because we got to visit the machine shops and I’ve always been interested in different types of machinery. One thing that was really amazing Jim showed us was this robot that was built and it could drive in another room an it had a camera on it so that when you put on the virtual reality goggles you could see everything. It really amazed me when I saw it. Also during day 3 we found the YouTube video of the NASA Axel Rover that was awesome. We decided to make a prototype of it because it was so cool.
Jess: I hadn’t previously known that Massachusetts has its own engineering design process. I also found it a bit difficult to brainstorm ideas for a robot and then isolate one good one. Despite this idea generation being the goal of this day, the idea for the Axel Rover technically did not come on this day. Seeing the machine shop was also pretty cool. Since my school is so small, I have never been inside an amateur machine shop, let alone a university one with advanced machines like the CNC. The CNC was pretty cool.
Sarah: I had the idea to mount the wrench on our robot using an axle in a vertical position. When the robot was completed Dean decided that he was going to turn it into a tank using the vertical axle to hold the turret.
Today we finished the TETRIX bridges; Sarah and Briyana’s bridge was the second longest and most solid, Dean and Jess’ was the third longest and second most solid, and Lawrence and my bridge was the longest, but least solid, by far. The first two bridges barely deflected since they were the same basic construction (the metal u-sheets connected together). The final bridge was more outside of the box thinking: it used the battery charge cable to act as a flexible bridge. However, that ended up failing as the weights caused the cable to sag and the outer edges to collapse inwards. We attempted to make a SAM animation of the bridges deflecting under the weight, however the first two bridges did not deflect enough and the third deflected too much too quickly.
The rest of the day we worked on various connection types: figuring out the best ways to connect LEGOs, TETRIX, and everyday objects. We learned that LEGO axles and TETRIX shafts are the same diameter (except of course the LEGO axle is not circular: it’s + shaped), that the blue lego connectors can be pressure fit into TETRIX wheels, and that pencils and screwdrivers fit perfectly into the large TETRIX holes. Using this knowledge, we started the second exercise: object holding. Drawing three numbers from a bag determined what objects the constructed robot would need to be held. They had to have omni wheels, and had to be able to be pushed across the room without spilling their contents. Jess and I’s had to hold three different sized screwdrivers, a pencil, sharpie, and pen, and a calculator. Lawrence and Briyana’s had to hold a full cup of water, a CD, and another robot. Dean and Sarah’s had to hold spare change, a Nintendo 64 game, and a huge wrench that could spin free.
Dean: Testing bridges/SAM: SAM failed, didn’t really see point of it. Holding devices: good way to learn about TETRIX connections and useful knowledge for later. Thought of Tank idea.
Lawrence: The bridge was so much fun because we had an outrageous idea but it didn’t work that well. It still gave us enjoyment though. Later in the 2nd day finding connections for Lego’s to Tetrix was very useful for our remaining projects. The water holder I built was mainly out of Lego’s and it was really fascinating. I found a way to connect it securely and the project was mainly a success besides the omni wheels made the ride too bumpy for the cup of water. I also learned that day that you should always plan out things before you do them because I messed up the crane on my robot many times and it became a catastrophe but even though it got frustrating I finally got it right. Hahahaha.
Jess: Going into day two, I was looking forward to finishing building my bridge and seeing if we could win the challenge. It became pretty evident rather quickly that we didn’t have a chance. Then building the holding robots was pretty awful, since my group had to build one that would hold a pen, a pencil, and a marker. Tetrix really wouldn’t cooperate with that objective. I was pretty happy with Tetrix’s ability to hold the calculator, though.
Briyana: I struggled with building a CD drive that actually held the CD…I over thought the whole process. After I simplified my thought process I ended up using rubber bands.
Sarah: Connecting TETRIX and LEGO pieces requires a lot of jamming.
Nicolas: The SAM animation of the bridge testing was incredibly awful. I was hoping you could really see the deflection, but the bridges barely deflected and the camera setup was both awkward and not fast enough (taking a picture every .1 seconds did not allow showing the minute deflection)
Today was our first day. We started with a short name game with the questions, “What is your name?”, “Where are you from and what grade are you in?”, and “What is your favorite tech product?” The general conclusion under favorite tech product was the mp3 player, with a shoutout to Morgan’s “impact driver”. By the third day that product will definitely change to “air conditioning”. After that, we did a campus tour in the oppressive heat, looking at most of the major buildings, including the Engineering building, Anderson, and a few places to eat. Location-wise, we started in the basement of Brown and Brew, at the CEEO (Center for Engineering Education and Outreach), and moved to the Botlab when we started our team building exersice. The exercise originally had five parts, but we shortened it to three. First we had “team LEGO,” in which we built the largest possible tower with just 39 pieces in 30 minutes (the amount of pieces determined with dice). Each tower was at least two feet tall and stayed upright for at least 30 seconds. Then we had “solo LEGO,” which was the same thing except by ourselves; the success rate dropped significantly: only 1 out of 5 towers stayed up for the 30 seconds (and that tower had snapped in half). It was this exercise really where it was determined that working in teams is better than alone: you can divide the work, you have double the brainpower, and there’s enough to do that you don’t always get in the way of each other. The third part was “team TETRIX”, where we started to build the longest possible bridge that could still support two battery packs. -Nicolas
Dean: Already visited Tufts, already knew campus. Intro and TETRIX: The screws were annoying, took awhile yo a result. Mindstorm: Already used it, familiar with it. Towers: Fun, creative, good way to learn connections with LEGOs. Bridges: Good way to learn TETRIX kits.
Lawrence: The first day was exciting because I’ve never worked with TETRIX before or any type of robotics. I had loads of fun with the tallest tower project because I made mine so tall but it didn’t necessarily stand up. Then the bridge project was very amusing as well but wasn’t very successful as well. Hahahaha
Jess: The first day was rather awkward, considering the ubiquitous silence between all of us, with the exception of Nick. We started cracking open the new TETRIX kits in groups of three (from that instant they were never so neat again), and they didn’t seem so frustrating or complicated to work with in that instant. The team building exercises hardly brought further conversation out among us, but solving quick challenges using limited materials was pretty fun and interesting.
Briyana: My thinking on building a bridge was simply just making a strong, long and sturdy enough bridge so it wouldn’t tip over.
Sarah: It was really hot outside.