We’ve talked a bit about her, but I think SUSAN really deserves a formal introduction. SUSAN stands for Sensors Using Sustainability Arduino Network, and is our robot that will help us keep track of our compost system.
SUSAN came about through two slightly separate thought processes. First, we realized that because of our group’s academic interests, we are placed in a unique position. We are a composting project, of course, but half of our team is studying computers in one capacity or another, and the other half is at least slightly familiar with the basics. In those first few days of the project, while holed up in our affectionately termed “glass box”, we decided it made the most sense to put the things we’ve learned to use in this project. So, in that way, we were looking for technical solutions to either “food waste processing” as a whole, or any part of it that could be improved.
The next part of SUSAN’s origin lies in my favorite creativity technique, called painstorming. There’s a lot of ways to do it, but in a nutshell, you look at a system or a process or a product and say, “what sucks about ____”. In a proper painstorming session, one would watch or take video of people performing tasks without their knowledge. The idea is that you are recognizing pains that most people wouldn’t self-identify. A classic example is the automatic trunk opener on a car. One would only have to watch a mother loading her three children into her van after soccer practice to realize that opening the trunk while managing her children and gear is a huge pain. Were you to ask that mother what the biggest issue with loading her kids into the van is, she would be more likely to identify her kids yelling or the fact that they have too much stuff, and not the trunk. For SUSAN, it was much easier to recognize our pains. While learning all about the science of composting, we identified a short list of data and measurements that would indicate the health of our pile. Logically, then, we looked into ways to measure this in real-time. There were are few commercial systems out there that did some or most of what we wanted, but we would have wiped out our budget even buying one part of them. So, we decided to build our own.
The construction of SUSAN follows a few guidelines. First, we want everything to be completely open source, both because we want others to be able to easily recreate what we have done, and because if we ever get stuck or something goes wrong, it will be easy to fix. Next, we want her to be self-contained and automatic, because it doesn’t make sense to only know the health of the pile when you are near the pile, especially because that is such a hassle on Lehigh’s elevationally segregated campus. To achieve this, SUSAN will be entirely powered by solar panels and will automatically send data over GPRS to Xively, our data aggregating website (assuming they learn to play nicely, that is). We want SUSAN to be modular: we want to be able to swap out components, easily upgrade her, and make her expandable. This will also help with maintenance. Should our GRPS board fry, for example, we can replace that one component without tearing the entire system apart. Lastly, we want her to be pretty. If you have the opportunity to create something, it might was well be visually interesting. We’re not quite sure what she will look like yet, but we have noticed that a scarecrow might help keep some of the birds away from our compost…
Wednesday we did a few key things. I soldered together a temperature sensor on regular 6 foot hookup wire but added a 1-microfarad capacitor in series with a 100 ohm resistor connected to both the ground and v-out wires. This should help get rid of "noise" in the wire, or things that make readings not precise. The difference in precision and accuracy is that accuracy is close to the answer, but not close to the other answers, and precision is that all your answers are close together, regardless of how close they are to the correct answer. With some of our temperature sensors, we were getting accurate answers but not precise. Meaning we would get all sorts of values ranging between 23 and 27 for example when reading the temperature in a room. We want the most precise answers we can get, and hopefully the most accurate. But precision is what counts. Making sure all the noise is gone, and we are getting consistent results. Today I will be working on some code algorithms to try and get the best readings using an average of about 20 readings, every half second. I'm trying to see how many readings we should take and average in that half second to get accurate and precise results, as well as have the best use of power. I need to find a happy medium in efficiency and power savings.
Ben got two sensors talking to Xively at once, which has been an enormous battle. Such smart. So computers. Much work. This means we can have two sensors running and sending data at once. His next goal is to get Xively to communicate with our e-mails and cellphones, sending us alerts about the data.
Alec is working on soil moisture temperatures. He successfully got long-distance sensors to precisely and accurately read with up to 25 feet of cable. Today he will be doing more soil moisture sensors. Not too sure what, but he'll find something. Maybe he can help Tori.
Tori has been working on getting Solid Works on her computer, and probably will be through the rest of the week. It's used to make models on the computer to upload to 3-D printers. 3-D printers are absolute genius. She is designing a prototype model for what we want the physical body of SUSAN to be. It might end up being something like a scarecrow, but who knows...
No comments:
Post a Comment