CPR 1 Spring 2014 - Technical Team - Part 3: Product/Service System
Hey All!
This is Ian! Sorry for the delay getting this written up. Been hard at work on our backend! Without further adieu, here're the remainder of the slides from CPR1!
In order to progress on a complicated and interconnected project, we make explicit assumptions about our system, and attempt to address these assumptions with varying complexity experiments throughout the course of our work. Our relevant assumptions are effectively our conditionals of change - the statements we need to prove in order to be confident in our theory of change. For the product system, these are essentially that our system is exists, is cheap, and and is effective. The existence of our system was addressed in part by experiments last semester. It's pretty cheap. We're running experiments to illustrate its effectiveness at growing various plants from seed.
In addition to stating assumptions, we also framed our work in terms of system requirements for the three main sections of our system, the control code / backend, the user interface, and the physical hardware. Nothing like our backend exists right now, but we have a hopefully maintainable, quite efficient, and totally libre software stack running on tiny computers.
The user interface, upon completion, should be readily scalable to systems of different sizes and configurations, should be intuitive to users of mobile devices, and useful enough to make a farmer weep of joy, rather than weep when hundreds of seedlings die from an unnoticed cold snap.
Our radio processing backend is run on a small form factor computer that can sit undisturbed in a quiet, dry-ish corner of a growing space. It needs to be cheap - with a target COGs of well under a thousand bucks, we can't buy a nice mac pro to run bulky stream processing software. It needs to be beefy enough to get the job done, but at the same time cheap enough to be throwable at a single problem.
The input devices (sensors) and output devices (120VAC wall outlet switches) should be dirt cheap, hard to break, and reliable. Fancy commercially available wifi-enabled products (looking at you, Belkin!) don't fit the bill at all.
Our backend is fundamentally a stream processing engine, just like simulink, labview, or gnuradio, but with radically different design ideas. Despite huge differences in scope and scale, they do share similar constructs - data inputs, data processing segments, and data outputs. We've abbreviated these as 'head,' 'body,' and 'tail.'
In reality, it's much more complicated than this, with some blocks not always fitting smoothly into one category or another, and all sorts of nasty forks and joins.
This software has a tough job to do. It needs to take in noisy analog readings from a radio receiver, massage them into a less-noisy digital bitstream, and parse them into high-abstraction information like a temperature or humidity reading. This information is fed into a set of self-contained control algorithms that in turn feed into a wireless transmitter and remote outlets.
All of this software is useless without the hardware to talk to the real world, and hardware's the expensive part. To get it cheaper, we've turned to China. Below are some of the pieces we've used to prototype, and their approximate prices.
In conclusion, and perhaps the thesis of my capstone work...
Signing off for now!
--
Ian Daniher
on behalf of ADE-MA