Owls in the Classroom, Pt. 2

By Marc Bucchieri

We left off in part 1 of this blog post after explaining how a team of intrepid STEM explorers at the Woodland school were introduced to the Owls and given the task of creating a game with them. Fast forward two weeks, and our WMSI staff were back at Meadowstone Farm to meet with the Olders again and hash out the details of their awesome interactive game. The students had been given a few constraints to help them narrow down the overwhelming realm of possibilities. Their game was required to be playable in less than 30 minutes, allow for at least three players at a time, use at least two Owls, and have a skill-based component. In order to help them pull these pieces together, they were shown a simple version of the design cycle (also known as the engineering design process).

Now just replace “problem” with “awesome game opportunity”.

The group met their constraints by developing a set of mini-game stations to be completed by a group (or groups) of players. These stations consisted of: charades, a math race, a field-sized shape-drawing challenge (called GPS Draw), and a codebreaking interactive Owl challenge that we finally dubbed “Flippy Flop”. There was some debate as to whether the game should be more competitive (student teams playing against each other) or collaborative (all students race together against the timer). In the end the group of Olders decided to run it as a collaborative game. Instead of competing against each other, students would complete stations in order to earn the combination to a locked chest containing the timer unit. If they completed all the stations and opened the lock in time, they’d be able to keep the timer from ticking down to zero.

Getting stoked on running and math problems

After spending their third session hashing out some details and testing the different stations of the game, students were finally ready to roll out their masterpiece for lesson #4. The game begin with a lively test of creative acting: the charades station. Each participant was given a prompt to act out for their peers, and the group quickly charaded their way through a clown, a racecar driver, a policeman, and a painter. Then it was on to a speedy test of their numeric skills: a math race across the farm! The Olders dashed past signs with pieces of a longer math equation (+4… -13… x22…) and then typed their answer into a python code-powered computer terminal.

This little python script checked their math skills at the end of the course

After the math race came the GPS draw station, which pushed our Owl tech development in ambitious new directions. The setup for this game station called for half the group to walk one Owl around a field and draw a shape with their path, pushing a button at each new point. Meanwhile, the rest of the group gathered on the edge of the field yelling instructions. To make things interesting the draw group wasn’t allowed to know what shape they were drawing- they could only listen to their teammates directions.  The “home base” Owl received the GPS coordinates of the button presses and drew the shape on the screen.

The toughest obstacle to overcome for this mini-game was the limited accuracy of our GPS boards. On a clear day, each unit can pick up its location within a 33 ft. radius. In order to achieve higher accuracy (e.g. for surveying applications) experienced users implement differential GPS techniques. This means placing one unit at a known, hard-coded location, and then comparing its known location to the location as reported by satellites. This information can then be used to refine the precision of other GPS units in the surrounding area. Sounds simple, right? Unfortunately our GPS units didn’t get the memo that this should work really well, and instead decided to fluctuate wildly with no relation to each other. This resulted in a pretty amusing situation, in which students would attempt to walk a triangle and end with a shape that looks like a bird:

In order to make this station more interactive (and less frustrating) the program was set up so that users could delete crazy points by clicking on them. By the way, all this cool visualization stuff was done with a very neat programming interface called Processing, which is used by data visualizers and artists the world over.

After a lot of shouted direction-giving and stomping around a wet snowy field our heroes were feeling ready for the final station of their game. “Flippy Flop” was inspired by the initial accelerometer demo (the one with the crazy pools of color), which showed how this amazing little chip can be used to sense the orientation of an Owl in space. This led to a game station in which the Owl screen displayed a coded message that students could interpret into one of six directions, coordinating to the six faces of the Owl: left, right, top, bottom, front, or back. When our team finally decoded and re-oriented through the 9 step process they received the final combination to the lock!

This coded message translates to "Left", or put the left side down.

Once the Olders had stormed back inside to unlock the treasure chest, they were faced with one more surprise challenge to disarm the ticking timer. Out of the Owl’s enclosure poked two loops of wire: one red and one blue. With the final seconds slipping away, the students had to pick which of the two wires to pull. One would stop the timer, while the other caused it to count down three times as fast! (Hint: always pull the blue wire). Fortunately, this group of STEM adventurers was as lucky as they were resourceful and successfully ended the game with a pent-up sigh of relief. Not only did they all get to win the game they had designed, but they met and surpassed the constraints we had set out for them: their final product was skill-based, involved the Owls, took about 25 minutes to play, and could enjoyably be played by at least 5 people (and probably many more). Yay for playing with technology outside!

Compost Sensor Development

By WIll Norton

Here’s the dream behind this project: Have a wireless temperature logger that can be placed in a compost pile, whether it be a classic home compost pile, a large industrial or agricultural compost pile, or possibly a rotating compost tumbler. Such a sensor set up could be a useful tool in a classroom to integrate practical everyday applications to data lessons, or be useful to improving personal or school composting systems.

Someone out in the vast world of the internet may sell exactly this, but it probably isn’t affordable for these home and classroom applications. So we turn to the resources we have close at hand at WMSI: a Walmart and a 3D printer, to try to make our own custom design. We found a $10 wireless indoor/outdoor thermometer at Walmart to do our temperature sensing.

Unfortunately the housing for the sensor we want to put in the compost has nothing resembling water-proofing, so the design work starts with building a new compost-proof case for the temperature sensor that others can easily recreate with a 3D printer and other common inexpensive materials.  

So far I’ve designed a couple of different prototypes for this sensor case.

Prototype I

Prototype II

Three problems with the first Prototype that I found were:

• The case does not have a strong enough attachment point between the top and bottom to stay together

• There was no way to attach the case to anything, in order to later retrieve it from compost

• The sensor had a dramatically slower response to temperature in Prototype I than in other close-at-hand containers such as a Tupperware container or Ziploc bag, as shown in Fig. 1

To address the first two problems, I added larger ridges around the top of the main case, larger grooves in the lid and a loop to tie a retrieval string to. I also left an open space for a metal junction box cover I found at a hardware store, hoping to give the case a side that would conduct temperature changes to the sensor better than the plain plastic case. The results from this test are shown in Fig. 2. As it turned out, the metal cover did not make a significant difference in the responsiveness of the case, so it is probably a feature I can leave out in future redesigns to simplify the construction.

This case also needs to be waterproof in order to avoid having gross compost juices leak onto the temperature sensor and ruin it. I tested the second prototype for waterproofing in three ways to see where, if anywhere, it would leak:

• I placed it open on a paper towel and filled each half of the case with water

• I placed a paper towel into the case and closed it and floated it in a bowl of water

• I filled the case with water and closed it and rolled it around to see where water came out

The result in all three experiments was:

Clearly waterproofing is something that needs more work. The largest leak by far seemed to be the connection between the plastic lid and the base, but water also leaked through the seemingly solid plastic of the case. Some solutions to explore in the future include different types of plastic for the printer, coating that would waterproof the plastic, and some sort of gasket for the meeting of the two plastic pieces.

Not to be outdone by a small flood of water leaking into my case, I put the sensor in a plastic freezer bag and put the setup in my home compost pile to get some temperature data and see if the sensor could broadcast through a pile of rotting food. The results are in the below table and Fig. 3.

*Other thermometers showed significantly lower temperatures.

The data shows a slight downward trend in the compost temperature as the weather got colder over the 6 days I collected data. However, more interesting than the actual numbers are two limitations of our sensor that I found. First of all, the indoor temperature sensor on the unit with the display which I used to measure the outdoor temperature seems unable to read below 32 degrees, since according to other thermometers the temperature was well below 32 after the seventh reading on the afternoon of March 3rd. The second limitation is that about half the time when I went to collect data, the display had lost wireless contact with the thermometer and had to be reset by removing and reinserting the battery, and in one instance was unable to reestablish contact for several minutes before I had to leave. It’s unclear what caused the loss of contact; possibilities include the compost interfering with the signal, or cold temperatures decreasing the charge of the batteries.

The takeaway from this experiment is that it is indeed possible to make a functional compost-proof case for a wireless thermometer for a small compost pile using 3D printing and easily available supplies. This setup worked just well enough for this simple experiment, but the unreliability of the signal would make it unhelpful in any sort of data logging setup. The case has some flaws such as not being waterproof on its own, and having a flimsy recovery system that wouldn’t help in a larger compost pile such as on a farm. With more redesign and research, these design obstacles may be overcome, and with more experimentation the cause for the signal loss could be isolated and removed if the cause is not the dense compost interfering with the signal.  If, however, the signal loss is caused by the compost, that may become an insurmountable obstacle.

Owls in the Classroom, Part 1

By Marc Bucchieri

It’s been awhile since our homebrewed Owl units were first introduced to this blog, and they’ve come a long way since then. In fact, the Owls just celebrated a major milestone in their fledgling career in the WMSI tech arsenal. Over the past month, the Owls were incorporated into a unit of lessons for the Woodland Community School at Meadowstone Farm. Tech development was pushed forward, games were designed, and ominous timer displays ticked (almost) down to zero.

Which wire to cut?!?!?

It all started when our Mobile and Instructor-Developer Corps coordinators made their way down to Meadowstone Farm one rainy morning to play a game with the Older students at the Woodland School. This was to be the first lesson of a four-part curriculum, and the game was intended to demonstrate the technological capabilities of our Owl units. After a quick tutorial on map and compass skills (you’ll see why in a second) the students were given their Owls and a sheet of coded clues. The clues, once decoded, hinted at different locations around the farm. Students then raced to each waypoint, where their GPS-enabled Owl released a compass bearing toward the final treasure. Once several bearings were plotted, the teams could begin to home in on their goal.

Students were given these coded hints to help them find the waypoints.

In order for this game to work, the Owls were enabled with several tech features that have been in the works for months. In order to release bearings at all the right waypoints around the farm, each “seeking” Owl had to be hardcoded with the coordinates of each waypoint and its location relative to the “hiding” Owl. In future iterations these bearings will be calculated in real time, allowing the hidden Owl to be anywhere within the circle of waypoints. The Owls were also equipped with two-way radio communication, so that the hidden unit could send time updates to the seekers.

Student maps looked sort of like this, if a bit more rain-smudged and gray

After successfully finding the hidden Owl (in a silo) the group returned to the classroom to brainstorm and design a game of their own. Back inside they were introduced to some other hidden capabilities of the technology, including the ability to read and transmit sensor data. Students watched in excitement as the readout from an accelerometer was displayed as shifting pools of color, then took turns moving and shaking the Owl to generate their own colorful patterns.

Our WMSI staff and students narrowly escaped without.. being.... hypnotized

Over the next couple sessions, Woodland students went through several iterations of planning, refinement, and testing to bring together an awesome collaborative game. As with most feats of engineering, this game was designed to fit a set of constraints. The game must allow for at least three players at a time (ideally six), take less than 30 minutes to run, and use at least two Owls. Most importantly the game should be skill-based, so that participants can improve the more they play it. Check back soon for the story of how math, silly acting, and GPS were all used to create a board game the size of a farm.