THE DAY OF

                                        
The final view of the pokemon arena! In action, here under Pokemon, are several videos.

Several modifications we made: we created a "shield" around the liquid nitrogen to prevent splashes. This limited the amount of smoke, but in the interest of safety, was very useful. The control box did not have foam over it, as described earlier, but just the lego box and the pennies visible.

Horrifyingly, plugging in the picoboard to the computer caused the resistances to change. We could not get the physical aspects of the pokemon to work while the computer game was running.

However, this may have been a blessing in disguise. Most of the children didn't know what pokemon was! So the battle would have confused them further. All the special effects alone was really a better idea.

The final count of special effects!
Charizard:
Smokescreen: Water pours into liquid nitrogen, creating smoke
Flamethrower: Water pours into liquid nitrogen, creating smoke. Flame in mouth wiggles back and forth
Slash: Arm moves back and forth
Earthquake: Entire arena shakes! Rumbly noises happen.

Electrode:
Thunderbolt: Lights along the side of the arena light up!
Magnet rise: String connecting Electrode to the beam on top grows shorter, so Electrode rises
Explosion: Lights along the side of the arena light up. Entire arena shakes. Lights inside Electrode light up
Mirror coat: Lights inside Electrode light up

Day 23 and 24: Bringing it all together

The program in Scratch, to emulate the actual Pokemon game (complete with HP!) has an image that looks like the Gen II games.

This is the frame of Electrode! Wrapping it in tissue paper is still what we're planning on...

The red wires are the lights! I soldered four red light emitting diodes together, so we don't have to have individual lights on single picocricket wires. Now one picocricket socket lights up four lights!

Similarly, there are another set of four lights soldered together along the arena. Those are yellow.

Instead of our original idea of hanging the arena, we're now going to balance it on some boxes, and have this mechanism to bounce the arena up and down. As per Prof Berg's suggestions, I added another layer of legos on top so that the bouncing motion is more up and down.

                                       
Charizard has been assembled! This is the interior of its mouth, with the flame moving back and forth.

A couple views of the inside of its body. This is the arm moving mechanism.... It finally works! The original rubber band (to pull the arm towards the center of its body when the cam wasn't pushing it up) was too weak, and the other rubber band was too strong, so we used two rubber bands instead! Now it finally works, though opening the body tends to derange  the mechanism. Yes, it is duct taped to the side of the body >>

                                            

This mechanism pulls up the Electrode! A rather simple idea, and it worked on the first try! Yay.

Notice the beam holding the mechanism up. It's a bunch of legos pegged together, and used to be the frame of Electrode. It was reused! The beam is held up by a ring stand, so we don't have to worry about it falling over... Though the weight of Electrode makes the beam bend a little.

                                         
A final view of the water pouring device. It pours water fine!

Several other issues without pictures:
I soldered some pennies onto the wires for the control box. Now, instead of touching the pointer to a wire, you touch the penny instead. It didn't change any of the resistance values

Charizard's arm was too large for the mechanism to move, so we downsized. Instead of the laser cut piece being the center of the arm and then being held onto a lego piece via a screw and nuts, we used only lego pieces as its center. 

Day 21 and 22: the rebuilding of motion modules and the beginnings of Charizard...

Instead of the confetti for a flame, Charizard is now supposed to stick out a flame. However, the original motion for that is extremely difficult to expand, as I discovered. Prof Berg suggested this motion module instead, because it can be easily expanded to reach further. Yay!

Picocricket program is now 100% functional! All computer aspects are completely done. The programs are rather long though, so I will not post them

We've begun to build Electrode and Charizard... Through many, many trials.

Our electrode seems to be faring well with wire wrapped around a frame. Luckily, spheres are decently trivial to create. Illustrator easily creates circles, so the frame was simple. (This process actually involved a great deal more confusion than this implies. Hot glue was necessary.)

Charizard is not faring as well. After many attempts at frames for the body, we've given up. Charizard now has a box for a body. Its head is completely laser cut and hot glued together... And then we realized that the motion for the flame actually curves out in an arc instead of straight! After many trials, we settled for the sweeping motion, because of lack of other options.

Day 19 and 20: refining the program and the arena/controller

We taped up the arena, so it looks very pretty now: it's mainly poster board, so it's very light. Hopefully, light enough to be hung easily.

The controller is slightly problematic at the moment. When the picocricket and the scratchboard are both attached, the resistance both sense is not at maximum, even when the pointer isn't touching anything. It still gives distinct resistances though, so I just coded around it.

Our Scratch program is completely functional! Yay! Picocricket is semi functional: it works but is really inelegant. After a move, it will just emit 0s until another move is touched. It's just not an elegant way to code!

Day 17 and 18: More project stuff

On Friday, we built motion modules for all the motions we'll need:

A functional arm! It only opens ~90 degrees though. This may need some modification before it really looks like an arm moving down...

A pusher for the flame (we changed the flamethrower move: instead of confetti, a little flame is going to extend out and back in of charizard's mouth).

A really geared up pouring mechanism, so we can control the flow of water with time pretty easily. Hopefully, no one will use more than 4 moves that require smoke...

We also built an arena out of poster board and punched holes with an exacto knife to hang it up with. However, we don't have anything to hang it /on/, which is a problem

Then on Tuesday, I started coding the HP meters in scratch and encountered a major setback: we only had four resistance sensors but eight moves. Prof Berg suggested using different resistors for different moves, so we modified the controller to have all the moves together.

Shirley went to buy all the building materials we'll need for this.. namely, felt, wire and tissue paper. We changed our minds (again): charizard will be felt on a wire frame and electrode tissue paper on a wire frame

Day 15 and 16: more projects

Last week, we finalized our movesets for the two pokemon:
Electrode: explosion, magnet rise, thunderbolt, mirror coat
Charizard: flamethrower, slash, earthquake, smokescreen

And we planned out what effects each move required and where the effects should go. The arena needs to light up (thunderbolt), create smoke in two areas (explosion, smokescreen, flamethrower), shake (earthquake), create confetti (explosion) and lift electrode (magnet rise). Electrode needs to light up (mirror coat) and rise (magnet rise). Charizard needs to move its arm (slash) and blow out confetti (flamethrower)

We begun to plan out one specific effect: the smoke!

The cup will contain water, and it will tip over a controlled amount to pour into a container of liquid nitrogen. We looked at how much water is required to produce an appreciable amount of nitrogen gas, and realized that the original syringe idea (squirting water from a syringe) wouldn't produce enough... However, this pouring mechanism is extremely buggy. It doesn't really pour, it splashes out water, and different amounts of water each time at that.

We also tried to create a fan to blow out confetti from Charizard's mouth. We used model magic to mold fan blades, and attached it to a motor. It didn't dry enough to test yet, but it doesn't look promising: the air it blows seems rather weak.

Day 13 and 14: laser cutter and projects

Last Friday, we basically just played on the laser cutter...

We cut out another robot, this time with a <3 engraved and I cut out a companion cube! The companion cube didn't photograph too well though, because the engraved part is hard to see on the photograph, so no photos of that.

And Tuesday, we talked about projects!

The project I really want to do right now is a recreation of a pokemon battle. We could have smoke for anything fire-type related (using liquid nitrogen)! Potentially, we could also create bubbles, but that might be more difficult because the pokemon would have to be rather large. Electrical attacks could be simulated with yellow lights. Anything physical would be pretty simple, just motors moving the arms/pokemon/legs.
There are a couple issues right now: thinking of two pokemon with movesets that wouldn't blatantly favor one pokemon is foremost. Because of the limited movesets we can create while still being interesting, it's hard to find possible pokemon... The HP/stats would just be a slightly tricky programming task: we were thinking of having a control with four buttons, and then each button would connect to the pokemon and to a computer tracking the HP. (This by itself limits the moves too, since we can't use moves that have a delay)
Currently we have possible movesets for five pokemon, but really, those pokemon would never have those movesets in a real game. (The movesets are not the best moveset for those pokemon)

Another possible project would be a dinosaur chasing down small animals! With the left/right motor program from earlier, it wouldn't be hard to create a controller for the dinosaur. (A possible issue would be length of wire though!) The small animal could have impact sensors (and a random movement program), so it knows when the dinosaur hits it. A timer could be built in, to display the time it took for the dinosaur to track down the animal!
Alternatively, we could control the animal running away from the dinosaur. The animal could have a light (infrared or visible) and the dinosaur could be just following it.
This project would be much more programming based than the pokemon one, but it would also be generally simpler, with only one main function.

Finally, I was thinking of a chutes and ladders type game, but in three dimensions. There would be no need for the player to move the pieces, since they could be mini robots that could move to the next space. Once it needs to go up to the next level, or a chute/ladder, a part of the board could move to bring it up or down. There would be a lot of little motors and programs required though, and a lot of trial and error over where the position of the parts should be. It might also be less interesting, since even a simple game like this takes a while to play.

Day 12: improvements on the race

With pretty much the same sensor as last time, we changed the race. Now Gobo tries to go right, and the TRex goes left! If they hit each other, they bounce back and then resume their respective motion.

If the TRex gets to the left, he says that he wins; if Gobo gets to the right, he says that he wins!

Because of the way the bounce is coded, it's actually better if you stop right before you hit the other sprite, and wait for that sprite to bounce back. There's actually technique involved in this game...

Later, we also started working with the laser cutter. By which I mean, Casey drew the picture and I offered "helpful" suggestions. Pictures coming soon!

Day 11: creating a sensor

Today, we had to create a sensor. Our sensor was based on measuring resistance, so it had two clips.

We essentially took a piece of felt, wet it, and clipped one clip of the sensor to the felt. The other clip was movable: we would move it back and forth.

The program converts the resistance into a sound. The higher the resistance (ie, the further apart the clips), the higher the sound. We lowered the pitch of the sound by dividing by 2 (otherwise, the notes were really high).

Then we got a little bored, so we cut the felt in half, and created two instruments (with two sensors). We had to use two stacks though: if they were in the same stack, the instruments would alternate playing sounds. (The sound takes time to play, and the program wouldn't move on.) Each piece of felt had a different instrument. Interestingly, because of the way the sensors plugged in, you can put the clips on either piece of felt, and a resistance would be measured (ie even though the clips weren't on the same piece of felt)

Also, the sound got a little annoying after a while, so we added a line that changed the volume with the slider. That just made it easier to shut off the sound.

Then we decided to play with the programming language a bit more.. We made it into a race! Between the two sprites. The sprites would move to the right based on how high the resistance was.

Fall break: motion module and the rest of AB reverse

IT'S A DINOSAUR!! It's based on the chomper motion module... And then a foam dinosaur shape added on! Pretty simple, but fun.

Now, AB reverse is similar to the AB on off problem from Day 7. Except it took 10 hours to code. (Seriously. 4 hours Sunday, 4 hours Monday, and 2 hours today.)

The basic code didn't change... But some details did!

The first issue I ran into was the program behaving like it was level triggered (pressing the switch was one direction, not pressing was the other) instead of edge (pressing the switch turned the motor one way, and pressing it again turned it the other). The mysterious reason behind this was... rather subtle actually.

Professor Berg took an oscilloscope and attached it to the sensor (one end grounded, the other on the resistor associated with that sensor). The oscilloscope showed that the switch actually "bounced": for half a millisecond, the switch went on-off-on-off repeatedly. (This is called contact bounce, according to wiki). Since the computer is fast enough to recognize even this short a time, the motor sometimes reversed when the switch was initially pressed.

Luckily, this was easily fixed. A 2 ms wait was added after each waituntil, so that the switch settled down before the program proceeded. Clearly, humans cannot press and unpress the switch that quickly, so this will not create any problems.

The other problem was that one of the switches' wire was broken. Professor Berg soldered it together (which was super cool! Did you know that there's special tubing that will shrink when heated?)

Finally, the program was working! Except that when both switches were pressed, sometimes the motor wouldn't turn on when one switch was released. I realized that the boolean statement in the "both" block (for when both switches are pressed) wasn't exactly working, so I created my own boolean blocks using the text language. Then it worked!

SUCCESS!!!

Day 10: more fiddling with a weight bearing car

After trying  many combinations of gears... we discovered that 15x really did work better.

The images above are of a 18x ratio. You can see the intermediates (the 24 tooth gears) because the 16 tooth gear doesn't fit nicely with a 8. HOWEVER, it stalled.

...with a higher torque, it stalled. Yes, this makes no sense! I think the friction caused by so many gears slowed down the wheels. And every other ratio between 15 and 24 (ie, anything that required a 16 tooth gear and intermediates) was slower than the 24x car.

Still, our car (the MYSTICAL UNICORN, as Casey dubbed it) made it to the finals! It didn't win though...

Day 9: fiddling with the weight bearing car

The two views of our car!

We tried different variations of the gear train and of the wheels. The wheels we ended up using were the originals, though, since the back wheels couldn't increase in size and the front wheel only has an effect when it gets too thin (and wobbles).

Our fastest time was still with the 15x gearing. However, it is obvious that this is too small a ratio, since the car visibly accelerates as time passes. 27x (the next easiest gear ratio) produces a slower car. We attempted to increase the torque by using smaller back wheels (this required the car to be turned upside down and slightly modified), but it was also slower.

Currently, we are trying to create different gear ratios with a 8-16 tooth combination (instead of the 8-24, 8-40, and 24-40 we were using before), but this requires the gears to be placed diagonally to fit on an axle.

Day 8: a weight bearing car

Sadly, there are no pictures or videos today!

Our car is still in the process of being built. It's doing pretty well: the current iteration travels ~2 m in 10 s (an improvement from 12 s!)

Basically, we take a motor, and attach a gear train to it to prevent the motor from stalling. It has to carry 1 kg!

Our current gear train is a 15x gear train (one 8 tooth to 24 tooth, and another 8 tooth to 40 tooth). We have a triangular type car with a little wheel in front and two large wheels in the back.

We've discovered that 9x is too little, so next week, we're going to try a 12x gear train!

Day 7: Fixing Sobriety and an INDESTRUCTIBLE LEGO BOX!!

Basically, instead of turning on a single motor in order to turn, this version causes the opposite motor to reverse. This way, instead of moving forward while turning, it moves backwards, so it will be able to make sharp turns.

However, the original program looked more sober.

Afterward, we had some little problems to do.

This causes one motor to turn on when one switch is pressed and the other to turn on with the other switch is pressed. The motor is only on when the switch is pressed...

FINALLY. We made indestructible lego boxes!

The outside of the box...

And its inside!

Basically, it had to fall 2 m while holding some weights. The top and bottom of the box is held together by pegs (little sticks that go into the holes on the side of these special legos), and is incredibly sturdy. The sides are held together by vertical legos (using pegs). Originally, i only used the curved pieces to hold the top and bottom to the sides...

But it didn't work. So I extended the reach of the pegs so that two opposite sides held the bottom and the other two held the top. This worked much better! And the box survived the fall.

I was actually lucky because I had used 10 8 FLU (little studs) blocks to build the bottom, and 8 10 FLU blocks to build the top. So the holes were on opposite sides, and not much rebuilding was necessary.

Day 6: Sobriety (is difficult for robots)

There are at least five versions of this program! IT IS SERIOUSLY LONG.

The first iteration did not use the number of turns of each wheel to calculate distance travelled. As a result, the robot, while following the line, was not particularly steady. (It kept turning towards the weaker motor)

The current iteration was developed after several attempts at combining the original program (following a line) with a straight line program (correcting the robot's path by the counters). These can still be seen: the turn stacks allow the robot to turn when crossing the line, and the corr stacks keep the counters at the same number.

The program is not as elegant as it could be, since many fixes to problems were added, instead of fully incorporated into the program. The most obvious examples are the thresholds for sensing the line, which have the thresholds awkwardly added on. Additionally, the robot was moving too fast to turn efficiently, so its speed was slowed by decreasing the power. However, this causes the weaker motor to appear significantly weaker.

Predictably, there were many issues with the timing of the turns. As the last section of the video can attest to, the turns are still not perfect. As the robot turns, it is also moving forward. For sharp turns like the last turn, it cannot turn fast enough to get back on the line before it has already passed.

Essentially, this could be fixed by having the robot back every time it turned, to check if it fully crossed the line. However, the robot would look considerably more drunk.

Day 5: Following the light

The challenge was to move towards a light.

Two light sensors were placed on each side of the robot, both facing forward. We had slight difficulty with one light sensor being more sensitive than the other, so our first version of the program had the robot comparing the current light detected from one sensor to the light it had detected a tenth of a second ago.

However, not only was this incredibly complicated, it also had interesting issues. At a lower time interval, the robot would take a scenic path towards the light (but eventually reach it), and at a higher time interval, the robot would spin in a circle every time it moved forward 6 inches. The imbalance of the motors (one side is more powerful than the other) also posed a problem

So after testing the light sensors, we chose two new ones, that were of similar sensitivity.

Not only was this simpler, it was also functional!

There are still slight problems as the robot moves. Most are caused by the imbalance of the strength of the motor, since it turns more in one direction...

Day 4: Following a black line

This program made the robot follow a black line...

But it looks kind of drunk while doing it!

Basically, it goes one direction until one of the sensors on either side "sees" the line, and then it starts going the other way.

There were a lot of issues! For some reason, reconnecting each block fixed some of the issues.

Our right motor was weaker than the left. It looked really silly since it would turn really fast! and then really slowly, so we changed the power on the motors to reflect the imbalance.

Also, when the robot went too fast, it wouldn't see that it had passed the line, which we solved by slowing down the motors.

Day 3: Playing with toy cars

So there are no videos or pictures yet! But they will be uploaded soon.

The first program we wrote was pretty simple: just making the car back up if it hits something

This program just tells the car to stop after the tire turns a certain number of times! It took a really long time to figure out exactly how many turns are in 1.5 meters.

An easier way to determine when the car reached 1.5 meters was by detecting when it passed over white tape (the finish line)! We had some trouble with the resistors, because at first the difference between the floor and the tape was too small for the car to sense...

This navigates the car out of a maze! It stops when it hits something, and then backs up and turns a bit, before continuing. We tried to build in a step to detect if the car had hit something and was stuck, but usually the car would remain stuck, even if it tried to back out... But then the maze changed from boxes with edges that caused the car to get stuck to ones with flat sides, so it worked out!

ETA:

The stopping after a certain distance video:

The escape video was too large, but the youtube video is here

Day 2: More Playing with PicoCrickets

We got bored of the dance party (and were unable to improve on it), so we made a button counter and an arm that automatically hits the button.

It's basically just a button that registers touch, a display, and a Lego piece connected to a motor.

Not too complicated, but a little tricky with the coordination of the arm hitting the button. As the video shows, the button sometimes needs to be pressed manually to reset the arm when the arm fails to hit the button hard enough.

Obviously had we been more patient, we could have tested the times of the arm and so even if it missed, it would automatically try again. Or, we could have used a higher power on the motor, so the arm could hit harder.

But it's still pretty cool.

Credits: First and last picture by me; second picture and video by Hope

Day 1: Playing with PicoCrickets

A quick intro:

The programming behind PicoCrickets isn't very difficult. It's targeted towards ten year olds, after all! It's all pretty blocks that you snap together.

Basically, you have four outlets on the cricket. You can make stuff light up, play (basic) sounds, turn, or display numbers. It can (with the use of another outlet) sense light, touch, resistance, or sound.

And, it's made out of Legos!


My partner, Hope, and I made a dance party.

Sorry for the poor quality (and horizontalness), it was taken on a phone. :D

So pretty much it involved lights, motion, and sound, and was controlled via light. The light turns color based on the amount of light reaching the sensor; the motor reverses direction (this is hard to tell; pretty much the people change direction) when there is a momentary stop of light reaching the sensor; and the sound similarly stops when there is no light reaching the sensor!

The styrofoam ball is supposed to be a disco ball, but since it was held up via rubber bands, the bells were needed to balance the weight of the light. And the pipe cleaners are sparkly!

credits: images by me, video by Hope