Final Project Ideas

List of Final Project Ideas:
My favorite: Pet Dog
This idea is based on the fact that dogs take a long time to learn commands when in the training process. This interactive dog will be programmed so that he takes a certain number of times to learn a command. And if he gets a treat (simulated by resistance sensors), he reduces the length of times it will take him to learn the command. If not to ambitious it would be great for him to respond to a person (perhaps light sensor or picocricket interaction) by following it around or something of the sort.

Idea # 2: Hogwarts
An interactive Hogwarts with a miniature Harry Potter which you could place in the rooms and perform a task. Each room will represent a different year in the Harry Potter series and a different interactive task to complete. This project will require a lot of sensors but should not be too complicated. The idea has yet to be more developed.

Idea # 3: Keyboard
Make a keyboard, with some buttons with preprogrammed songs. And the keys activate by sensors yielding different resistance values. The only downside is to figure out how not to use too many handy boards so as to make a huge mess of wires and such.

Everyday Sensors

Challenge:

Many sensors are embedded in machines, devices, pieces of equipment , etc. that
you frequently use. In your design journal, make a list of ten sensors you can
encounter on the Wellesley campus – e.g., in your dorm, classrooms, common
areas, outside, etc. You need not be able to see a sensor in order to deduce that it
exists. Try to avoid listing simple switch-like sensors, such as light switches,
mouse buttons, faucet handles, etc. The sensor may be embedded in a piece of
equipment or machine, such as an automobile or photocopy machine.


1) Brakes of  a car
2) Remote Control (TV) - infrared sensor
3) Motion Light Sensors
4) iPhone - ambiance sensor (background light changes depending on initial surrounding room light)
5) Laptop mouse - touch sensor
6) Motion sensors - motion activated light
7) Smoke detectors
8) Computer-device interactions: (USB...computer detects a device such as a printer or a camera or external mouse and acts accordingly)
9) Halloween bowls - the skeleton hand moves when you try to grab the candy
10) Microwave - light turns on when door opens

Auto Thresholding

The Auto Thresholding challenge was fairly simple. Auto thresholding is the idea that the robot should adjust to its surroundings especially if it has sensors that measures something about its surroundings. For example, a robot may use a light sensor to detect the light in a room and based on the input it gets from the light sensor, it will do something else. This robot would not function the same way in a different room with brighter or dimmer lights. In order to counteract this problem, one should auto threshold their programs to let the robot create a threshold in every room it is in, and then compare the light it is shown to that threshold. Auto thresholding allows  these types of programs to work in all environments.

Here is an example of the auto thresholding program that Kaity and I created:

This motion detection program is designed to detect the light in a room as soon as it is turned on. It saves this value in a variable, n and then the program compares the light detected by the sensor to the value of 100 + n. If we were only running this program in one environment, the if statement would read: if sensor4 > 100.... However, we use auto thresholding to allow this program to run in any environment. This way, the robot always detects that the light sensor value is 100 greater than the light in the room.

This program was successful, and Kaity and I had a lot of fun waving our hands in front of the sciborg making it chirp.

K^2 - The Dragster

Meet K^2, our beloved dragster:

Our challenge was to create a drag car that efficiently balanced speed and power using our knowledge of torque and LEGO structural design.
Originally we created a design with a gear ratio of 81. This drag car was powerful but very slow. The design of the car itself was also very compact. For our first trial run against other cars, our time was more than 27 seconds.

                                                     

However, after losing in the trial round, Kaity and I decided to change things up. First, we made our design longer, and put the weight towards the front of the dragster instead of the back. This way, the weight of the car is closer to the ground giving it more of a momentum when it is trying to go forward. We also changed our gear ratio from 81 to 27. Testing this out, we got our dragster to decrease its time down to about 17 seconds.

After many attempts of playing with the design, We finally ended up with a gear ratio of 15 and the long design seen in the top picture. This Design had the fastest time in the new trial rounds with a 7.05 seconds. 

K^2 is the one on the left.

However in the final round with everyone, K^2 got temperamental and decided to perform 2 seconds slower.

K^2 is the one on the right.

All in all, K^2 did pretty well. He certainly made a huge improvement. 

We're proud of you K^2!!

The Chomper and The Catapult

We used simple instruction to create two very cool motion modules: The Chomper and The Catapult.

The Chomper

The Chomper with some style eating a pipe cleaner....

The Catapult

The Catapult in Launch Position

These Motion Modules were created by Karishma Chadha (Me) and Kaity Schwartz.

The Indestructable Box

The Challenge:

By yourself, build a LEGO box that holds at least two red or black “weight bricks” and can be consistently dropped (at least twice in a row without any tweaks) from a height of 2 meters without coming apart. As usual, you can expect to go through several iterations before you achieve the goal.

Initially this challenge was very difficult. I kept making boxes that were breaking but as I continued making the boxes, I found new ways to make it sturdier so that some very strong chunks of the box would stay together. After many attempts at reworking my first design, I decided to start over but use a simple idea from this first box in my next one. I discovered while working on this box that the sturdiest designs were the individual blocks that were pegged together and another identical structure to attach on the built in LEGO connection ridges going the opposite way.

In my original box, I used this design for the top and bottom of my box, but the side walls and overall connection of the box was weak. I used a similar idea in my second box except I used this idea all through out and I connected the box together with strong reinforcing vertical LEGO blocks using the flat plates to equate the flus.

Farewell Whiney...=[

Farewell Whiney! This is the last challenge with the beloved SciBorg Whiney.

A-B On-Off

In the first part of this challenge, we had to create a program which uses two different switches to toggle the two motors on and off. When switch 1 is pressed, motor a turns on until the button is no longer on. When switch 2 is pressed motor b should turn on until it has stopped being pressed.

This program is just a simple forever loop telling the robot to turn motor a on while switch 1 is being pressed and to have it off when switch one is not pressed and the same for switch 2 and motor b.

A-B Reverse

The second part of this challenge was a bit more difficult. We were to create a program similar to that in the first part, except this time, pressing switch 1 should reverse the direction of motor a every time it is pressed and pressing switch 2 does the same for motor b.

Originally we attempted this program by creating a new block using the writing portion of the PicoBlocks program. We made a block to test if a given value is even or not. The thinking behind this was that we would use a counter to count how many times the button was pressed and if the button had been pressed an odd number of times the motor should turn one way and if the button had been pressed an even number of times the motor should turn the other way. This however, for whatever reason, did not seem to work out, so we decided to use a similar approach to this part of the challenge as well.

This code is composed of two separate, simultaneously run stacks. Both stacks are virtually identical except that one uses switch 1 to control motor a and the other uses switch 2 to control motor b. These codes use "wait until" statements instead of "if" statements because we now want to use level triggered logic instead of edge triggered logic like we used in the first part. In the first part we wanted the motor to remain running for as long as we kept the switch pressed. In this case, however, we want the motor to go in the reverse direction just after a single click of the button instead of holding down the button.

Both of these programs worked well, except the second program seemed to be temperamental.

It seems that Whiney, after working with us for so long and listening to us complain about how it didn't work, became very lazy. He also seemed to develop an attachment to Professor Berg, because a peculiar situation occurred in which, when trying to run the second program, Whiney only seemed to work when Professor Berg was around. To test this theory, we constantly asked Professor Berg to come near and go far away from Whiney. Our suspicions turned out to be true. Whiney has gotten so lazy that he only works when Professor Berg is watching. Either this is just a disdain for his friends (a.k.a us who have had "so much faith" in him this whole time) or it is sheer laziness in which he only works when he absolutely has to. Either way, the cause for this temperamental behavior remains a mystery.

----Sigh----

Farewell Whiney!!!