Archive for July, 2011
Today we had our demos, at the Dr. Albert F. Argenziano School. We left the Botlab at 9:30 and started our first demo at 10am. We did our demos for two classrooms, each demo was an hour long and identical (the students responses were not). We first started by introducing ourselves then Morgan explained why we were demoing. Next, I gave a brief powerpoint introduction on NASA science, robotics, and rovers in particular. We asked the students if they had any background on NASA/robotics, of which a few did, but most didn’t. Following the science intro each pair of high school students presented their project idea. Jess and Lawrence started with a powerpoint explaining more about their Axel Rover project and moved on to showing the Rover moving and finally talking about future plans. Next, Briyana and Sarah talked about their Carrier robot, mentioning what it does and what their future plans were. Following a short powerpoint, they demonstrated the ultrasonic detector by driving the robot on a table and having it stop when the ultrasonic detector saw the edge of the table (since the distance would increase beyond a certain threshold value). Finally, Dean and I introduced the iPad controller idea with a powerpoint. We gave our reasons for doing our project, our inspiration, and potential GUIs (graphical user interfaces). We then demonstrated a very simple iPad controller on the tank that Dean had built. In the first classroom, a few students were snickering, but all in all they were responsive and seemed generally interested. In the second classroom, the majority of the students seemed less interested, except for two boys sitting in the front row who wanted to answer every question and looked super interested. After finishing our demos to the students we returned to the Botlab, after having lunch. Morgan came up to me and mentioned we’d be doing demos to some TI (Texas Instrument) and LEGO business men/women, so we should be prepared. We made our powerpoints more professional and less middle-school like as well as making a modifications to the bots.
By the end of the day, we were for the most part ready for the demos tomorrow.
Dean: Visiting middle schoolers: Interesting to work with middle schoolers. Tank got most of attention, lol.
Lawrence: Today we had our demo’s for the middle students. It was very successful the only problem my group ran in to was that the wheels were too small for the body of the robot and the children wanted to see it run so in order to run it we had to pick it up first because it didn’t work. Then we had to explain to them why.
Jess: Demos went pretty well. The first class of kids seemed reasonably excited about what we brought in (as excited as I could have hoped for, anyhow). They liked things like the tank and our Axel rover, and were willing to participate in group sessions where they could contribute ideas to us. The second class was a bit more difficult, since very few of them spoke English very well. In hindsight, 80% of them couldn’t understand the presentation we gave, which makes it make sense that none of them really looked at all interested or even minimally affected. In the smaller group portion, I was able to communicate with a few of them in Spanish and basically answer their questions, if they would speak slowly enough.
Briyana: Went to the middle school and gave a presentation of our robots and power points and gave a demonstration and answered any questions they had. Then later on we modified our power points for the LEGO people, for the following day. Also we finished putting our final adjustments to the robots before we start the redesigning process.
Sarah: The middle school students gave us a lot of ideas for our robot. Halfway through the day a piece of one of our motors fell off, so the wheel would not turn.
Today was the last day before demos; we finalized and practiced our powerpoints, created a survey for the students to fill in, came up with questions to ask the kids, and finished construction. Some of the programming was shody, but worked. For example, the iPad program was just simple left, right, forward, and back buttons. However, when we switched from Morgan’s personal iPad to a CEEO iPad, the server connection required to run the program became buggy and only the left and forward buttons worked. Eventually, we made a Labview program that had an interactive front panel, to show the movement of the tank (forward, back, left, right) and the movement of the turret (left/right and up/down).
The Axel Rover had issues with wheels, as the provided gears in the kits did not have a diameter large enough to spin the robot without the battery pack hitting the ground. The current solution is to attach flat bars to the end of the wheels.
The crater detecting robot works, however the DC motors are so fast that sometimes by the time the crater (the edge of the table) has been detected and the robot has braked, the robot has already fallen off the table. When the speed is reduced (the motors are running at constant power, so reducing the speed means reducing the power), the motors became too weak to move the robot.
Dean: Tank: finished product: YEAH! Worked on powerpoint
Lawrence: This day started off with making the PowerPoint presentation which actually didn’t take that long but then we reviewed it so that we would look well when we presented it to the middle school students. Also we presented to Morgan today so we could have his thoughts on our presentation.
Jess: Writing the powerpoint up was pretty simple. Making some reasonable probing questions were somewhat difficult to come up with, since it was slightly hard to remember what the comprehension/vocabulary level of middle schoolers is, and we weren’t really sure how good their English speaking skills (we’re going to an ESL school tomorrow) were.
Briyana: Worked more on the powerpoint and questions. Robot would fall off table if power was too high and wouldn’t drive if too low.
Sarah: I was extremely happy when the crater-detecting robot worked; although when the power was turned down we had to give it a nudge to get it started.
Today was and tomorrow will be preparation for our demos to middle school students on Thursday. Today we wrote up our power point presentations; written so that middle schoolers can understand it. Also, we further developed and began to construct our demos. Dean and I dropped the Space Elevator/Lunar Orbiter idea as the TETRIX robot, requiring a heavy 12V battery pack, would be too heavy and unwieldy to climb a rope. Instead, we decided to create an iPad controller for the other two robots, one that would ultimately control nine independent robots. For the demo, we created sample GUIs (graphical user interfaces), and Dean, who had been working on a TETRIX tank, decided we should control that tank with the iPad.
Dean: Prepare Tank for Demo. Worked on powerpoint -> wanted to work on Tank.
Lawrence: Today for my group was mainly just thinking how we can finish our robot and make it better. The whole day we pretty much spent all of our time building. Today was a fun but stressful day because with our prototype of the NASA Axel Rover was difficult to make out of Tetrix because a lot of pieces that were necessary for our prototype were not located in the Tetrix kit so we had to find ways around these conflicts. At the end of this day we had pretty much finished our prototype but the huge problem was that the wheels were not big enough for our robot. 🙁
Jess: It was on this day that I searched NASA rovers on youtube and came across the Nasa Axel Rover. It seemed pretty cool and interesting, so that was the idea we decided to take and replicate with Tetrix for the middle school audience. After doing a bit of research on the rover, we started to mock it up in a very prototypic way. This was the first time I had actually tried to build something complete out of solely Tetrix. We ran into a lot of problems with construction, mainly since the motor mounts don’t have holes the properly match up when placed perpendicular to the majority of pieces, and since the biggest wheels/gears were far too small.
Briyana: Mostly just made a power point for the middle school students.
Sarah: All that our robot did at this point was detect craters, although I hadn’t yet written a code for that to work. So Morgan gave us the idea to make (in a future version) the robot able to hold smaller robots inside of it that it could deploy at specific times. That way the middle school students could participate and create small LEGO robots to put inside of the big one.
Today we spent the majority of the day working on Labview programming, since we figured out how to get the DC motors and Servos running. We realized that the NXT to RCX cables (attached to long RCX cables and then back again to NXT) that we’d been using were preventing the DC motors/servos from working. Upon using pure NXT cables, they started working again. We wrote a variety of code; code to test DC motors, code to test servo motors, code to test NXT motors. A sample code, btns_DC, is shown below. The code turns on the DC motors corresponding to the buttons pressed on the NXT brick: left button = left turn, right button = right turn, orange button = go forward. We attempted to create a switch to reverse motion by using the left and right arrow simultaneously, but the buttons became glitchy. Testing this code was frustrating because sometimes the NXT became buggy and the buttons stopped working; in order to fix this one would need to restart the NXT (but distinguishing between when the code was broken and when the NXT was broken was annoying).
Dean: Worked on TANK
Lawrence: This day wasn’t a very exciting day it was more on the boring side but that’s because all I did was mainly more programming so that I could learn more about it. The buttons code Nick had mainly made but I just finished it for him so that I could eventually make the code myself. It was just for learning per purposes.
Jess: I spent this day working on my walking robot some more. It had been pretty lame and broken when I left it for the weekend, so I fixed it up. I mostly just experimented with the Legos and Tetrix and Labview.
Sarah: Today I focused on basic programming of TETRIX motors.
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.