Final Day and Exhibition

The last class day, the day of the exhibition was a very successful one. The major remaining pending task, Fluffy's room, was finally finished. Tuesday morning, I woke up thinking that I would not be able to carry out what needed to be done for that room. The sensors were just not working even though I had made an identical working one for the room of requirements. I could not figure out what the problems were for this sensor or the harp sensor. I went back into the robotics studio about an hour before class started trying to work on the castle again with a fresh mind. Soon after I started working on it, I figured out the problem, it was right in front of me the whole time. I had forgotten that I had switched the sensor wires into a different port, thus the scratch program was simply displaying the wrong sensor value.

Kaity and I worked on fixing everything up together. We suspended my small laptop speakers with pipe cleaners outside Fluffy's room, and I transferred the program onto my computer.

The difficult part was taking the project upstairs. While picking it up off the floor and on to the wheeled cart, parts of it broke off. We took the castle up in two pieces. After transferring it upstairs, Kaity and I spent about an hour to an hour and a half putting it back together and setting everything up and making sure everything was still working. By 4:30, Hogwarts was ready to go.

The exhibition was great. Kaity and I had a lot of fun, and our project was very popular. Our table was crowded by kids, and we learned that a great feature about our project was that it was built for a wide age range. For the really young children, They really enjoyed talking into the microphone of the Gryffindor common room and watching the flames in the fireplace change color.The older kids enjoyed the challenge of the Red Light Green Light Game we had disguised as the battle between Harry and Lord Voldemort. Despite it's difficulties, the kids were determined to make guide Harry to the finish line. Kaity and I enjoyed the company of a kid who went through all the challenges of the castle at least three times. We could tell that he and everyone else were really enjoying themselves.

After the hour of fun, we were sad to see our robotics design days come to an end. The next class was spent taking apart our beloved Hogwarts, (but of course Kaity and I kept some souvenirs). This was such a fun class!! I will definitely miss it.

Unfortunately, videos of the project are unavailable on my blog. I have forgotten the link of the videos posted by Professor Berg. To see a video of our project, you can see my partner's blog here:

Kaity's Blog

Well this is where my blog ends. I'll really miss this class!!!

Final Week Or So....Finishing Touches

Over the final week or so Kaity and I took care of the aesthetics and fine details of our projects. I tweaked some programming and construction while Kaity created Fluffy the three-headed dog. I printed and meticulously cut out the house banners of each of the four Hogwarts houses as well as the Hogwarts Banner to put up in the great hall.

Hogwarts Banner

Hufflepuff and Slytherin House Banners

Gryffindor and Ravenclaw House Banners

We also fashioned out own Harry Potter LEGO minifigures by giving the original LEGO minifigures stylish capes and wands. The Voldemort minifigure also has a white face (fashioned with white electrical tape), with a truly evil look drawn in. The two figures truly look as if they are about to engage in battle!

Next I worked on creating the sensors for fluffy's room. These elaborate sensors require a number of creative looking devices. We need a harp with some sort of metal strings, a wand with some sort of metal tip (so that touching the tip of the wand to the correct harp string would complete the circuit required to make the program you saw earlier function properly. It also requires a sensor similar to that of the room of requirements that will be disguised as a carpet (covered from the bottom in foil which is attached to an alligator clip and another piece of foil attached to an alligator clip on the floor of the LEGO castle; a piece of paper folded like a zig-zag serves as the spring one will compress to press button trap that completes the circuit).

Sensor for the Room of Requirements
and my rug!! =]

Fluffy the Three Headed Dog

The Basilisk is in the process of being scaled thus pictures of him are, at the moment, nonexistent.

Pending tasks: The good news is that I have arranged for small speakers, I have small laptop speakers that can be suspended outside the room. However, we have a great task pending that is fluffy's room. Though I am making the sensors and such for the room, I have tested out several of them, and they don't seem to be working. I have created and repeatedly recreated each of the sensors and I am at a loss for why they aren't working. I have tried to trouble shoot potential problems in multiple ways, but I still can't seem to figure out what the problem is!! The exhibition is in two days and I don't know what to do!!

Final Stages of Design

The class before thanksgiving, I had to leave a bit earlier because of my travel plans. However, the amount of work I did on the project outside of class last weekend had more than made up for this fact. Kaity was very happy to see what I had accomplished, and we spent quite a while playing around with and marveling at the door. In class on Tuesday, we finally decided what to do with the Room we had been previously calling The Defense Against the Dark Arts Classroom or Umbridge's Office. We decided that both of those two ideas would no longer work with what our project had now become, so we decided to transform this room into "The Gryffindor Common Room," alluding specifically to the fourth book/movie in which Harry would sometimes talk to his godfather using floo network through the fireplace in the Gryffindor common room. When using floo network, one pours floo powder into a fireplace in order to contact whomever they wish to contact. When talking to the person, the flame turns green (because of the floo powder). We decided to incorporate this idea into our Hogwarts castle by creating a simple program that would change the color of a light from red to green every time someone would talk into it. This was simple and fun to play with once it was done.

Unfortunately however, I forgot to take pictures of the fireplace and the code for it. =[

Now all that is left for us to do is to put together the sensors for fluffy's room and take care of aesthetics (including somehow making a three-headed dog, somehow putting scales on our LEGO basilisk). I also need to find some kind of small speaker to use in fluffy's room because we will be using imported mp3 files in scratch, so we need to find a speaker that is small enough to be conspicuous and make it seem as though the sound is coming from inside the room.

All in all we seem to be making great progress. The castle is almost complete, and it is looking great, I am really excited for its results!

Happy Thanksgiving!!!!

The Next Few Days....

I Saw Harry Potter 7 part 1 on Saturday!! It was amazing!!! It makes me all the more excited about this Hogwarts Project!!!! 

Over the next few days of working on the project, I started spending a lot of time outside of class to work on this project. The programming for the Final Battle game was difficult. I was trying to design a red light green light game involving two crickets. Voldemort's cricket would just have a light sensor that changes from red to green using a random number generator. I manipulated the program so that the ratio of reds to greens was 6-4 making the game a bit more challenging. The program also tells this cricket to send out an IR beam every time the light turns red.

Harry's cricket was a bit more challenging to design. I spent a few days working on this, trying to figure it out. I tried out many different codes before I finally came up with the one shown in the picture in the previous blog. The program makes it so that one controls the rack, pinion system with a button that causes the structure to move forward. One can only move forward when Voldemort's light is green, because if the motor is on when the light is red (when this cricket receives an IR beam), the motor automatically moves backwards. The player must get all the way to the end to win. This was actually a very difficult game to play.

When I finally completed this program, and even in between, when I wanted to take breaks from thinking about this program, I was programming the other parts of the castle. I created the fluffy program on Scratch.

The Fluffy Program:

Fluffy is Hagrid's three headed dog that guards the Sorcerer's stone in the first book/movie. Kaity and I wanted to incorporate this into our castle, so we decided to create program that is activated by resistance sensors. We would create a resistance sensor that initiates a vicious barking sound indicating that Fluffy has awoken. In order to put fluffy back to sleep, one must play the harp (also using a resistance sensor) to stop Fluffy's barking (therefore putting him back to sleep). This was a relatively easy program to write. I wrote it in Scratch though, so that we could use actual sounds from the movie instead of the sounds included in PicoBlocks.

While this was happening, Kaity was expanding the castle. She built the Room of Requirement on top of Umbridge's office, and was planning to build Fluffy's room on top of that. We decided however, to make it easier on ourselves, and on our structure (taking into account size and distribution of weight) that what is now the "Room of Requirements should actually be Fluffy's room and that We would build a smaller Room of Requirements a bit behind it, kind of connecting the Great Hall part of the structure to the Fluffy part of the structure.

Outside of class, I was trying to figure out how to make the door of the Room of Requirements operate on its own with a motor. One of the problems with this was figuring out how to suspend the door we built from the actual door way in a way we could turn it using a motor. After brainstorming outside of class for a few days, I still had no working ideas. However, in a class period, I somehow came up with a brilliant way. I somehow created a door hinge using LEGO pieces in an innovative way. Finally coming up with the solution to this problem was HIGHLY satisfying.

The next problem was that we needed the motor to turn a vertical rod, and usually we use motors to turn horizontal rods because we can't effectively orient the motor to turn vertical rods. After thinking long and hard about this problem and trying to solve it in many ways, failing each time, we decided to once again consult Professor Berg for suggestions. Assessing the situation, Professor Berg suggested a red motor, (I forgot what these were called, they are the small red motors that stand upright and one can put a vertical LEGO rod into it). This small motor was the PERFECT solution in every way. One of the great aspects of this motor was not only that it solved out problem, but that we were able to hide it well inside the room of requirements. It worked perfectly. By this time however, class was over so we did not get a chance to install it, but I came back outside of class to work on it myself later that evening.

During this time, I installed the motor for the door, I wrote the program to make the door turn using a resistance sensor that has been pressed three times, and I created and tested the resistance sensor, door and program until they worked. What a productive evening!! =]

Our Supports and their reinforcing crossbeams....
Hopefully this will be able to hold our castle up...

This is a side view of the old Room of
Requirements (What is now Fluffy's Room),
and Underneath it is Umbridge's Office

Inside the New Room of Requirements.
This is a close up of the clever door hinge I created

Room of Requirements and Staircase

Aerial View

Room of Requirements Program:
When the sensor is pressed three times, the door opens,
stays open for a short while and then closes.

Testing..... Changing....The Uncooperative Gear

Most of this day was spent on changing the gearing for the rack and pinion system. When I tested the structure at the beginning of the class, I discovered that the motor of the rack and pinion system turned considerably slower when trying to move backwards. This was both a programming, and a physical torque problem. The gears did not have enough torque to move the structure, so I decided to change the gears on the structure to make it stronger. This, however, was not as easy as it sounds. It took me the whole period to figure out how to make the LEGO pieces fit together because somehow the gears did not want to align with the LEGO Flu. I'm still not quite sure how I managed to get everything to fit together but after trying the same few things about 10 or 15 times, the gears finally decided to fit together. (This did not happen during this class period but the next one).

I also changed the programming for this motor a bit, which I wrote in the text interface of the PicoBlock's programming language, because this was easier to do with the complicated program I was writing. I am also more comfortable with text languages because I took two years of Java Programming and also did a lot of work with Python. I have used "block-languages" like the PicoBlocks language. Specifically I used the LEGO NXT Mindstorms language, which is a bit different from PicoBlocks. It can do a lot more than PicoBlocks too........ahhhh...one thing I hate about PicoBlocks: THE LACK OF WHILE LOOPS!!! =[

I changed this program

To this program:

The parts about the IR beams refer to changes I made later that

correspond with the cricket for Voldemort so that the two crickets

can communicate for the final battle program.

Further Progress:

Supports For Umbridge's Office

The Uncooperative Gear

The Rest of the Castle So Far, Umbridge's Office

The Epic Battle: Harry Potter v. The Dark Lord

I missed class on Friday because I was off campus because of a religious holiday. On Tuesday, I got straight to work on the mechanics of the Great Hall room. This room had begun to be built on top of the Chamber of Secrets, and in this room, Kaity and I want to stage the final battle between Harry and Lord Voldemort from the final Harry Potter book. Today, I worked on building the mechanics of it. I began by thinking of making another motion module, the one that goes back and forth. However, this seemed very impractical because I wanted to the structure to go farther than the 40 tooth gear allowed. When I consulted Professor Berg about this problem, he suggested a rack and pinion structure...(or at least that's what I believe it's called...). This was an innovative way to make the structure go farther forward. The problem here is that, the farther forward the structure goes, the farther longer it is, and the farther back it goes as well. We have limited space in the back, because if it goes too far backwards, it will run into another room in the castle.

The Castle So Far =]

Side View: Entrance to the Umbridge's Office (not yet built)

The Rack and Pinion Structure inside of the Great Hall
Harry will be standing on the Yellow platform zoomed in on in the next picture

The Platform Harry Will Be Standing On During the Battle

Motor and Mechanics behind the Rack and Pinion Structure

And The Winner Is............HOGWARTS!!!

So in the end, Kaity and I decided to work together after all to build Hogwarts in a tribute to the epic book and movie series that ruled our childhood. We are also paying tribute to what marks the end of this beautiful journey of Harry Potter: part one of the last installment in the series, Harry Potter and the Deathly Hallows. We began working on the chamber of secrets because we already knew exactly what we wanted to do for this room, and conveniently, this is the lowest room in the castle. For this project, Kaity and I agreed that since I really like programming whereas she doesn't enjoy it as much, and since Kaity really enjoys the LEGO aspect of the project, I am going to be doing all the programming for this while she builds most of the castle. I will also be helping her with the building at times.
As Kaity began building the room, I was creating the motion module that would become our Basilisk, for those of you that are not huge Harry Potter fans, and may not know what I am talking about, the Basilisk is a snake-like monster that Harry had to battle in the second book/movie of the series. The basilisk resides in the chamber of secrets, an underground dungeon. When Harry battles the Basilisk, he defeats it by stabbing the Basilisk through its mouth. The Basilisk should look something like this:

To create the Basilisk, I created a "Reach" motion module using the instructions, this motion module was programmed to move back and forth and stop when a button was pressed. Kaity and I plan to put this button inside the mouth of the Basilisk to reference the story. Here is the code for the Basilisk:

When I finished with the basilisk, I helped Kaity with the building portion, by reinforcing all the walls so that our walls don't break down. Here are pictures of The Chamber of Secrets =]

The Chamber of Secrets

The Basilisk......or at least his skeleton...

The Chamber of Secrets

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!!!

Whiney Goes Sober!

Our next challenge was to help Whiney pass the sobriety test. Our original line following program did help Whiney follow a line, however Whiney didn't walk straight or smoothly but he followed a rather crooked path along the line.

For this challenge, Whiney had to smoothly follow this path.

 This challenge was a lengthy process. We had many versions of how to do this and many of them failed in some way or the other, but we tried to learn from our mistakes and we finally created a program that worked...(for the most part).

We started by writing simple stacks that defined for Whiney how to turn.

We implemented these turn blocks through out the code we wrote for this new line following program telling Whiney at which circumstances to go straight, turn right, or turn left. Professor Berg suggested a model to help our robots walk in a smoother, straighter line. Using his method, we implemented the turn counters in the wheels to count how many times each motor/wheel is turning. If a robot is going completely straight, each of its motors (left and right) should turn exactly the same number of times for a given time period or distance. However, due to effects of the physical world (friction of the wheel, something caught in the motor etc) sometimes one motor turns more than the other. Thus, as in our own driving, the robot starts to drift to one side instead of going straight.
When we are driving, we use our eyes to notice that we are drifting and we correct this behavior by adjusting our wheels to turn towards the direction opposite of our drift. For this challenge, we want to write a program that does a similar auto-correction when the robot is drifting. To accomplish this we used the counters to compare how many times each motor had turned. Our program told Whiney to constantly continue checking if one motor had turned more than the other and if so, Whiney would turn the opposite way of the motor that had turned more. Since the program is constantly checking to see if one counter is greater than the other, Whine would not be making these turns for long because as soon as this other counter turned more than the original one, Whiney would turn back the other way. The computer performs this code so fast that Whiney is forced to walk in a straight line.
The challenge, however, is not yet complete. We have accomplished the task of Whiney going straighter, but we still have to make him follow a straight line. To do this, we implemented the ideas from our original line following program. However we included the code from this program in "if, then, else" statements instead of "wait until" statements. Thus, the code would constantly be going through all the "if" statements in the loop constantly, instead of slowing down and pausing to perform one step.
The challenge here was in how we placed these if then statements and how we set them up. Ultimately we created three versions of the Sobriety Test code. One of which worked much better than the others.

Version 1 - Winner

 This is the version of our sobriety test that worked the best. Here we have arranged the if statements so that the program checks for 3 different conditions in two "if" statements. The first "if" statement can be excecuted if either one of it's two conditions are satisfied. If count a [counter for the left motor] is greater than count b [counter for the right motor] then the robot is drifting to the right in which case the robot should auto-correct and turn left. If sensor3 [the value of left sensor] is greater than 700, then the robot sees the black line with it's left sensor thus the robot should turn to the left so that it is straddling the line. Since these conditions warrant the same reaction, we grouped them into a single "if" statement using the "or" operator. This "if" statement will cause the robot to turn left if either of these are true. The second "if" statement checks to see whether sensor 1 [the right sensor] has seen the black line or not, because if this is the case we want the robot to turn right. This program correctly checks for all the conditions, keeping Whiney's driving straight and smooth and also following a path guided by a black line.

The problem with this version however is that Whiney cannot fully make all turns. We could only start the Whiney from one side of the course because starting from the straighter side, Whiney could not make the last, wider angled turn. To account for this, we tried making two more versions of the sobriety test, this time implementing "wait until" statements.

Version 2 & 3 - SobFail & SobFail2

These two programs were essentially the same as the original sobriety program but this time the "if" statements are split up and we have now added "wait until" statements to two of the "if" statements. We added these "wait until" statements to allow Whiney to make more of a variety of turns, such as the large turn at the end of the track our challenge was based on. These "wait until" statements were added to elongate Whiney's turns so that at any given moment, if one of Whiney's sensors saw the black line, Whiney would turn the opposite way [of the way it had just been turning] and keep turning until that same sensor was off the black line. SobFail then tells Whiney to turn the opposite way of the turn it just made, while SobFail2 tells Whiney to now continue with the "forever-loop" to continue checking the other "if" statements. SobFail didn't work because we reealized we were wrong to make Whiney turn back in the same direction it had turned away from immediately after the sensor was once again off the line. SobFail2, on the other hand, was tempramental. When we first tested SobFail2, it had seemed to work, including the last turn and everything! The problem with it was that the path it had taken along the black line was no longer as smooth as we had in our original sobriety test. Whiney had returned to his original habit of zigzagging.

[Perhaps Whiney had reverted back to his addiction of alchohol?]

After we went back to try and fix this zigzagging error by increasing Whiney's speed, we tested SobFail2 again. However, this time, Whiney no longer followed the program correctly. Not only did Whiney still zig-zag, but he also did not complete the last turn. After changing back the speed to it's original value, we tested Whiney again. ALAS!! It seems that Whiney had gotten tired of going along that path time after time trying to please us. Whiney refused to work again! We tried this a few more times before giving up and reverting back to our original Sobriety Test which, ultimately, regardless of it's glitches [i.e. inability to make all turns], worked the best.

Whiney Sees The Light!!

Whiney now has eyes!!

For Whiney's next adventure, we were challenged to create a program that made Whiney hone in on a light source and then go towards it wherever the light goes. For this challenge, we essentially did the same thing we did to make the line following program. However, we ran into some different problems this time. One of our major difficulties was to account for the discrepancy between the two sensors and how they registered the same amount of light. However, we easily accounted for this difference by setting a variable n to be the approximate difference between the values of the two sensors when they were facing the same amount of light (approx. 125), plus the value of the sensor that gave the smaller value (sensor 3). Thus n = 125 + sensor 3. We used this number n throughout the code in place of sensor 3.

Upon testing the program, we learned that we also had a slight problem with the physical aspect of the robot and the placing of our sensors. In order for our robot to correctly follow our program the way we wanted it to, the sensors must not overlap in the amount of light they see. In other words, the angles through which the sensor can sense light must not overlap or both sensors will be reading most of the same amount of light at the same time when our program relies on the fact that at any particular time unless the robot is pointing straight at the light, one of the sensors will sense the light more than the other depending on how the robot is turned towards the light. In order for us to account for this physical discrepancy, we had to create blinders around our robots light sensors. We used simple flaps of duct tape on the sides of the sensors facing each other to create a blinder down the middle. After we had accounted for all of these things, Whiney correctly followed the light as if it were in love with the lamp. =]

Here's a video of our love-struck Whiney:

Whiney Follows A Line

For our next challenge we changed partners and started with new SciBorgs. My partners for this challenge and the few others to follow were Shirley Doan (read her blog here) and Sarah Hitchner (read her blog here).

Here I introduce Whiney, our beloved robot for these challenges.

Our first challenge is to make Whiney follow a line. We used a simple algorithm to create this program. Whiney would turn until one way until the sensor on the side opposite the way he is turning sees the black line. Once this happens. Whiney turns the other way until his other sensor sees the black line. Though the algorithm seemed fairly simple, my group faced many problems along the way. For one, we discovered halfway through the class that one of our sensor ports on the robot was not working. We were trying, for a while, to figure out why our sensor barely detected a difference between black and white surfaces. We changed the resistors and still the error persisted and in fact got worse to the point where the sensor no longer detected any difference between the black and white sensors.

When we switched this sensor to another port, the sensor began working fine thus we inferred that sensor port 2 had malfunctioned. After overcoming this difficulty and other minor coding difficulties, we got Whiney to run a beautiful line following program as shown below.

Our Line Following Program

The code we used to test our "blackness" thresholds for each sensor

After running this program, Whiney was correctly able to follow a line.