Evan and I recently received official word that we are now the proud co-founders of an LLC: Savage Internet. We have yet to nail down an official mission, but we’re hoping to look at the space of educational technologies. In particular, many online education platforms (e.g. Khan Academy) focus heavily on STEM fields, since these have very simple processes and easy-to-grade right or wrong answers. But what does a MOOC (Massive Online Open Course) look like where the goal is to teach art, history, or culture?

We’re starting to explore that question with thr prototype we are launching in invite-only alpha. Our prototype is called expedition!, and the basic idea is to have a platform for people to ask and answer questions about the world.

A simple scenario is this: Evan and I have a friend named Anami who is a writer. The current novel she’s working on features airships, and she’s been doing piles of research on the various mechanisms of flight, both past and present. She had heard of the oldest air and space museum in the world, which is located in the northeast suburbs of Paris. She didn’t really have an opportunity to go there herself, but she knew that Evan and I were heading that direction for a conference. She asked us to photo document the museum for her, and bring back any ridiculous stories we felt were noteworthy. So we did.

We’ve implemented some basic game mechanics (badge systems, XP, etc.) for expedition!, but we’re not totally sure what the right mechanics are. We’re also kicking around ideas for a real-time component of the system (where, for example, we could chat or video chat live with Anami from the museum and probe deeper into things that she was really interested in). If you have any thoughts on the alpha, or if you want an invitation to play around with it, do let us know. :)

Evan and I will be implementing features and testing stuff out on our trip this summer to Southeast Asia. You can follow us on expedition! or on our new blog: Ramblelust.

Continuing my series of “things I’ve done in class before”, I wanted to write about the project I worked on with Jonathan Kummerfeld and Peggy Chi. This project was an extension of the aforementioned H2O IQ: we were exploring what could happen if we move from one device in a single user’s garden to many devices scattered through a community garden or small farm, all of which were being served by a single Raspberry Pi.

We had a few different tasks to balance:

1. Serving client requests for data via the web interface
2. Accepting client instructions via the web interface and forwarding them to the in-garden watering devices
3. Receiving updated readings from in-garden sensors
4. Performing machine learning on the sensor readings and watering instructions

We set up three scenarios to test in:

1. Single user : 1 client, 3 plants
2. Small farm : 1 client, 50 plants
3. Community garden : 50 clients, 150 plants

and we had six different scheduling algorithms to try:

1. naive - update the watering model as soon as a client makes a request for data from that plant
2. periodic offline - every 5 minutes, update all watering models
3. sensor-triggered - when new watering data are sent from the in-garden devices, update those watering models
4. hybrid - a mixture of the periodic offline scheduler and the sensor-triggered scheduler
5. low load scheduler - this scheduler watches client traffic, and when there are fewer than 15 client requests in the preceding 5 minutes, all watering models are updated
6. predictive scheduler - a second machine learning algorithm watches the pattern of client traffic: just before a peak is predicted to occur, all watering models are updated

We wanted low client latency and “fresh” models. We defined model freshness to be time_at_serving - time_at_last_update.

Our basic experimental setup included one Raspberry Pi and one remote Mac. We had the Mac running Phantom JS to simulate client requests and also to submit sensor data via a web endpoint. Our webserver and schedulers were all written in Python using Tornado.

The results were promising!

There are more details in the paper we wrote, but suffice to say for now that we were happy with the Raspberry Pi’s performance in general and that it would certainly be feasible and reasonable to use it as a machine-learning webserver in a Fast Response And Intelligently Controlled Harvest Environment. As usual, the code for the project, as well as some documentation, can be found on github.

As a little series of stuff, I’m going to write retrospectives on several projects I’ve done at Berkeley. I’m going to start with the recent stuff while I still remember it.

In Fall 2012 I took Björn Hartmann’s inaugural class on Interactive Device Design, co-taught with a member of the Mechanical Engineering faculty, (Paul Wright)[http://www.me.berkeley.edu/faculty/wright/] in the spanking new CITRIS Invention Lab. The goal of the class was to educate the software-inclined in physical manufacture and the physical-inclined in software. Students turned out from a few different places, with the makeup showing grads and undergrads from EECS, Mechanical Engineering, Information, and Biomedical Engineering. We worked through several homework assignments involving implementing games and basic controls in software and hardware, as well as performing basic modeling tasks in SolidWorks.

Ultimately we split into groups for our final course projects. I had the pleasure of working with Shiry Ginosar from EECS and Mark Fuge from ME. We had a series of discussions about projects that interested us, and the theme we ended up hitting on was physical devices that had some kind of “smart” configuration aspect, for example a pair of shoes with dynamically inflatable inserts that can adjust to the user’s stance, adapt when he changes from walking to running, etc., to reduce pressure on particular areas of the foot. These types of self-configuring products are becoming more feasible as internet connectivity becomes more ubiquitous and cloud processing cheaper, just think of the Nest Thermostat.

The project we finally decided to pursue was a water-conserving gardening tool, which we call H2O IQ. Inspired by water shortages in both California and Shiry’s home country, Israel, we set out to investigate what it would take to build a device that can be planted in the garden, attached to a drip irrigation system, and forgotten about.

It turns out, not that much. It also turns out that’s not what people want. As a part of the project milestones we were required to do preliminary user interviews. As it happens, gardeners enjoy the time they spend in the garden, and none of them liked the idea of a computer taking over. So much for our machine-learning self-adapting dreams.

Instead, we headed in the direction of a notification system. Our garden device would share soil with a plant and alert its owner when the moisture was too high or too low, prompting action on their part. It could also, of course, serve as a backup watering device in the case the owner is on vacation or otherwise unable to water.

We ended up with H2O IQ, which looks like this:

And works like this:

The 3D printed piece has a solar panel on top for power, a servo for controlling water flow through the irrigation system (connected at the nubs), an XBee for communicating with the Pi upstream, four buttons for changing the watering schedule in-garden, and a moisture sensor built from cast plaster.

The Raspberry Pi functions as a webserver, and can communicate with the device via XBee radio. It serves a website that allows the user to see a graph of the watering history of the plant, as well as perform a one-time automatic watering or set a schedule of future watering.

We didn’t actually have time to test the product in the course, but we made a final presentation at the end which you can see on Google docs. All of our code, SolidWorks models, and Eagle files for circuitboards (as well as a teensy bit of documentation…) can be found on Github.

It was an interesting course project that led into some territory I’d not explored before, but which I suspect I’ll need as I delve deeper into the world of hardware.