Our project began with an idea of Jennifer's to create what she called a "natural alarm clock"-one which would respond to the arrival of daylight. Jennifer suggested that it look like a bird and flap its wings according to how light it was. She also suggested that the bird could move somehow and beep in order to actually wake the sleeping victim. This sounded like a great example of a scientific instrument in daily life, combining an unobtrusive display of light level with the functionality of a common household appliance-the alarm clock. We were both so enthusiastic about this idea that we actually didn't even discuss any other options and simply began building.
As we began to build, we considered the types of motion which the clock could employ. Jennifer had suggested that the bird's wings flap according to how bright a light was. We initially considered simply attaching a rod to a large gear and turning the motor on and off in each direction to get the appropriate up and down motion for the wings. However, I was concerned with a problem that I had encountered in my previous experience with crickets and motors-the timing for turning the motors on and off was very unreliable and would often lead to the motor traveling different distances during each run of the program. We thus tried to construct a different way of getting this up-and-down motion without switching the direction of the motor.
This was quite a challenge with
Lego pieces, because the Technic pieces primarily support turning motion, but
not linear motion. We encountered a number of problems during this construction
with creating an appropriate gear train at the correct speed. We quickly discovered
that we needed an even number of gears so that the outer gears-and thus the
wings-would move in the same direction. This was somewhat difficult to achieve,
but we eventually came to the design pictured at the right. This had the perfect
up-and-down, in-and-out that one would expect from a bird. We then confirmed
that the power settings available on the cricket would give us an appropriate
range of speed for the wings.
The turning head was very easy to construct, largely because we only wanted a rotational motion and the small red Lego motor was perfectly suited to the task. Here we also faced the problem of inexact motor timings, but here we decided the problem was not so crucial and we decided not to take any action to correct the problem. While we were struggling with the wing motion, we had suggested that perhaps getting the bird to move up and down would be too difficult (this also being an unusual motion for Lego) and that we could skip it. After attaching the head, we decided to give the jumping bird a try.
We had some difficulty constructing the legs because they needed to be stable
enough to hold the bird's weight without falling apart or becoming detached
from the base. We tried several ways of attaching the legs but finally achieved
a satisfactory solution. Creating the gearing to drive the legs up and down
proved even more difficult than the wings' motion had been. 
We
again needed to use an even number of gears, which proved difficult give the
separation between the legs that we chose. We also decided to use a worm gear
to drive the mechanism, both because of the large gear ratio provided and the
fact that a worm gear can not be driven backwards. This prevented our bird from
sliding down on the legs of its own accord. A picture of our final mechanism
can be seen to the left. Note the worm gear attached to the motor and the complicated
gear assembly between the motor and the legs (the vertical gray strips.) We
also eventually added feedback in the form of a switch to tell when the bird
had gone as far down as we wished to allow in order to circumvent the above-mentioned
motor timing problem. This was particularly important in this case, as either
the gears or the legs would likely be destroyed if the gears tried to push the
legs too far.
Programming the crickets for this construction was relatively easy both because Jennifer and I are both computer science students and particularly because I've been working with the crickets-including in-depth technical work-for a year and a half. The code we produced is at the bottom of this page, and is perhaps interesting because of a number of cricket logo tricks that were employed to get the desired behavior. As we were programming, we also added a "snooze" button to our alarm clock, which would make it keep still for fifteen seconds. If you hold down the snooze button for more than two seconds, the alarm shuts off entirely and the bird will not move again until the program is reset. Because we had three motors to control, we used two crickets communicating via infrared. Though we had not intended it to be part of the project, we also added a numerical LED display so we could correlate the behaviors we observed to the light level being read by the sensor.
We did make some interesting changes as we wrote the program-for example, though it seems intuitive that the head should turn faster as it becomes lighter, in fact this yields a strange effect: when we first had the head turn for a set amount of time and varied the speed, it actually seemed that the head moved fastest at low light levels, because it was just twitching back and forth, while at high light levels it made a large sweep. We changed this so that it would turn at a constant rate but for shorter amounts of time as the light level increased. In this and other investigations, the cricket logo command center proved very useful for iterative exploration of effective motions and behaviors.
After
we finished programming the bird, we began decorating it with feathers for wings
and puffy balls for its head. The aesthetic qualities of our creation were in
mind from the start, as one of the motivations Jennifer cited for her idea of
a bird was the fact that feathers had been available at our first cricket session.
Though we had to look hard to find those feathers again, after they were found
we put a number of them onto our bird. It was at this point that we began to
develop a personal relationship to the bird, much as described in the Beyond
Black Boxes paper, which emphasized the importance of "a spirit of creativity,
exuberance, humor, stylishness, and personal expression" provided by the blend
of scientific instruments with artistic materials. Our project seems to fit
the possibility cited in the paper that a scientific instrument might be "designed
primarily as an artistic creation-one whose scientific purpose is complementary
or incidental to its artistic purpose." (M.
Resnick, R. Berg, M. Eisenberg) Our decoration of the bird seemed to completely
change 
our
project, both in appearance and in our reactions to it. (A before and after
picture can be seen above and to the right.) This whimsical aspect of our project
was very motivating, from the initial concept to the final design. We even experimented
with the different hairstyles for the bird, as seen to the left. It seemed that
this aesthetic addition to the project was what made it truly successful, both
for us and for those we showed it to. 
While
people were interested in the motion of the bird and the idea behind its actions,
the comment "it's so cute!" was also quite frequent (not to imply that we were
immune from making such statements ourselves.) I even found myself attributing
a personality to the bird; I snapped the picture to the right because it seemed
that the bird was looking at me inquisitively as Jennifer talked on the phone.
I supposed that it just couldn't figure out who she was talking to, never having
seen a telephone before.
I would also like to discuss my experiences assisting other students during this project. I was in the unusual situation of having worked with the cricket system more than much of the course staff. Though this occasionally made it difficult for me to work on our project, I had interesting interactions with others as they asked me questions. Many other students in the class were new to programming at all, much less the cricket system, and though most people I talked with had some idea of what they wanted to do, they were generally unclear on how their notions translated onto the cricket's capabilities. It was often difficult to gauge what was needed. In some cases, it was simply a straightforward technical question, but others were more uncertain of how to proceed.
In one case, Sarah showed me a description of what she wanted her creation
to do-essentially respond to transitions between ranges of values. The answer
I initially gave her was that she needed to use a global variable, and I attempted
to explain how she would need to use it and what the cricket logo syntax was.
I could tell that this didn't quite do the trick, but she went back to her partner
and apparently worked on the idea for a while, because about an hour later she
showed me something very similar to logo code which would do what she wanted.
The difference was that her pseudocode was manipulating symbols, saving the
current state and checking it later in order to determine whether a transition
had occurred. My response was that this was what I had been trying to convey-the
place where she was storing the state was a global variable! Sarah, who I believe
had had only limited programming experience prior to the class, had constructed
her own representation of the cricket's actions and how she interpreted her
task. As I explained how to use a global variable to save her symbols, it was
as if we were translating between languages, and suddenly this strange notion
of a "global variable" seemed to make perfect sense. This exemplifies Norman's
emphasis on the importance of representation-once Sarah's 
representation
met the representation formed by cricket logo, the ideas became clear. Doubtless
the fact that she had come to the ideas on her own made them much more powerful
for her as well.
Another interaction that I recall was with a student (I must confess I forget
who it was) who wanted to know how to change the direction of a motor at a sensor
threshold. As we discussed the programming issues involved, I made the offhand
suggestion that it might be better to set a valid range instead of a single
value. This suggestion came from my previous experience with using crickets
in feedback situations, in which attempting to attain a single value leads to
the mechanism continually making tiny corrections as it skips around the desired
value. I don't think this suggestion had any effect on the student's subsequent
program because of its offhand manner in the middle of a technical discussion,
but in retrospect I regretted making it. It seemed that I was circumventing
the very process which using these computational tools encourages-finding such
problems (as I had) and discovering the solutions. In such situations, whether
working with children or graduate students, it seems that assistence outside
of technical grounds should be limited, allowing others to experience the same
discoveries that I had already made. That certainly isn't to say that other
comments should be avoided; indeed, an 
outside
perspective on a project can be very useful, especially when the builder has
become frustrated with a problem. But at the same time we must be careful not
to point out a "correct" answer to a problem. This removes both the joy of discovery
and the possibility of the novel solutions which often result from such challenges.
All in all, I greatly enjoyed this project. Though because of my prior experience I learned very little about the crickets, I did learn something about how to make novel types of motions with the Lego system and ways to deal with gearing problems. However, most of my enjoyment of the project grew from the whimsical nature of our project and the playful attitude that Jennifer and I had throughout the construction of our creature. The blend of computation and artistic expression was extremely motivating, exciting, and fun!
Leading Cricketto leader to flap-light to turn-head to beeper to snooze to tell-follower
to display-yel :num |
Following Cricketto follow to noop :num |
 |