— Terry W. Virts (@AstroTerry) May 21, 2015
Every summer, I go away on holiday. If it’s a damp, wet week, I’m sad, but I come home happy because I know my plants will have survived. If its a glorious hot summer break, I’m happy, but I come home to devastation in the garden with all the pots and hanging baskets reduced to dry biomas
Not this year.
I have until the end of June to build an irrigation system that can keep my plants alive for one week, without me being anywhere near them. The problem is that I’m not really down with the idea of irrigation as a whole. If your plants won’t grow in your environment without piling on the water, then you are growing the wrong plants. As right-on and ethical my stance on irrigation is, I’m still going to come home to dead hanging baskets and that make me sad.
So the task is, how do I keep my plants alive for one week, assuming a best/worst case scenario of daily average temps of 28ºC while:
- not being there to turn taps on myself
- not being at *ANY* risk of flooding my house/garden/neighbours
- using no more water than I absolutely have to.
- using as many buzz words and new technologies as I can find
- Not massively over-engineering the project to the extent that I simply can’t finish it in the time I have given myself
The answer I have give myself is the “Garden of Things” or er.. “The Internet of Gardens” or perhaps “The Garden of Internet of Things” or something like that.
The high level plan is.
Environmental Sensing -- Decision Making -- Actuation -- Irrigation
The four components work together to provide a single solution.
The first element is the gathering of data about the environment. The principle sensor here will be a soil moisture sensor that works to determine how dry the soil is. On it’s own, this should be enough to allow the decision making component to keep the plants alive. But it won’t be very efficient. Soil temperature can also play a big part in how quickly a plant will get stressed so that will be an important data set. While these are local to the plants, we’ll also need to understand something about the larger environment, so a weather station of sorts would be really useful. On top of all this we should also feed the decision making component with with some forward looking predictive data, which we’ll have to pull from public API’s.
The Decision Making component takes in all these data sources, and scores them. It will boil them all down into a single integer value which is the Water Need Score. If this score exceeds a threshold that I will have to determine through trial and error, then it will irrigate, if not it stays dry. The Decision Making component will also need some health check capability to raise alarms if the is a problem with the effectiveness of the solution, or it’s ability to actuate the water supply correctly. It will use the forward looking data to apply a negative score to the Water Need Score if it has high confidence that there is a rainfall event due in the next 12 or so hours.
Actuation and Supply
The Actuation and supply component basically just controls the flow of water to the irrigation system. It will start simple (but like all the other components) will grow in complexity as my time allows. A water butt will collect rainfall run off from roofs and store it. Once commanded to by the Actuation system, water will be pumped from the storage through the irrigation network. I’ll monitor the amount of stored water, and again, in conjunction with the forward looking data, allow the system to re-fill the reservoir from the mains water supply if needed.
This component defines that actual network of pipes, drippers, sprinklers and valves that actually deliver the water where it’s needed.
I’ve got the Gimble mounted to the quad, and wired up to the main power bus. I’ve not yet plugged in the aux pan and tilt channels, but it’s working fine without. Just looking forward to flying it now!
I recently powered up one of my ESP8266 ESP-01 modules to start experimenting with the ArduinoIDE build for it. I knew that it sucks juice big time, in excess of 250mA for some operations. I’d also been warned that the cheapo FTDI adaptors from ebay can struggle to provide enough power to satisfy it. I wasn’t terribly surprised therefore when I started getting some really odd behaviour out of it.
I was connecting to it over the FTDI serial and trying out some AT commands. It was responding to the basics, “AT” returned “OK”, “AT+GMR” provided the serial number, but anything more demanding than that and the module just died, the FTDI dropped out too, reseting the COM port which became very irritating, very quickly.
I’ve got some 3.3v Vregs in a TO-92 package which are a no-brainer for breadboard use, but I like to take the path less travelled. I’d Noticed that Adafruit have a really nice breakout for the ESP8266 7/12s which uses an interesting 3.3 Vreg called SPX3819M5 3-3 by Exar which come in the most stunningly unusable package, a 2mmx1mm SOT23-5 package.
My idea was to solider some thin single core wires to the neccessary pins, a plan slightly complicated by the need to bridge pins 1 and 3 (Vcc and EN) while leaving Pin 2 (GND) unencumbered.
I’m pleased to say I was able to nail it on the first attempt, and now I have a rock solid 500mA 3.3v supply to feed the beast that is the ESP.