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.