I spent some time in this sector (at one company irrigation of almonds and stone fruit, another in wine) and the margins are very tight. Fortunately the farmers have sharp pencils.
Such a robot is still SF today, so deploying a frob with each seedling would be the only choice at the moment (or continue current irrigation practices). The frobs have to be cheap enough to be consumables.
So why isn't it done today? Probably still cheaper to rely on the weather or center pivot irrigation.
Put another way, drip is massively parallel. Robot waterers, not so much.
Are we talking about irrigation pivots[1] here? Because those are a known technology.
If we are thinking about robots driving up and down the rows and watering plants from a tank, and then returning to some central location to re-fill their tank that feels like a "carrying water for elephants" situation. I suspect the logistics won't work out. Could try to run some numbers on it of course. Is that how you are thinking about it?
We work with fruit growers in South Eastern Australia where temperatures routinely hit high 30s and even low-mid 40s (°C) a few days each year.
Those growers want to see our soil moisture data readings updated every 15 minutes so they can turn the drippers on very quickly as soon as the soil starts drying out rapidly.
It would just be too slow to rely on robots driving up and down the rows in those conditions.
This is not robust. Humans don't use GPS for this purpose (and anyway, the plants are closer than GPS resolution.
Looking and using the local data is the more robust approach. Trying to assume the real world is the same as your model has been the source of countless visual gags since the advent of movies.
The thing about this field that I’ve learned over the decade I’ve been involved is that creating the tech is less than half the challenge; the distribution - building awareness, selling it, installing it, maintaining it - is a huge undertaking, and a lot of money needs to come from somewhere to make that viable.
[1] I’d like to have a RTOS to run on these devices that is as approachable and familiar as common Linux distros like Ubuntu, for people to install and customise themselves, with a full open source license.
But a bunch of small devices can be managed by a huge device running Linux — maybe even something as expensive as a Raspberry Pi.
(Apart from some time trying to sell in the Ag sector I spent a lot of time on embedded devices)
I hear you that $20 is high - but the status quo in this business now is monitoring devices that sell for AUD $600+, and with LTE-M or LoRa comms modules that cost over AUD $60 alone.
I'm forever thinking about ways you could drive the cost down further. I'd love it if there were a way to get the on-plant modules under $1. Feel free to get in touch if you want to discuss further.
It's an interesting problem and I am sure reference designs already exist. Maybe talk to someone at Nordic.
As I said in the previous comment, right now, high-value crop growers like wine grape growers pay $700-$1000 or more per site (including reader/comms module and sensors), and generally only install one monitoring point per block (I have a system running at one of Australia's top boutique/biodynamic wine makers and at current prices he can only cost-justify having one 10 monitoring sites over his 70 acres of vines).
So, whatever we can do to drive down the cost to $20 or less should deliver big wins.
> Maybe talk to someone at Nordic
Yep, we're working with hardware engineers who are well connected to people at Nordic.
But the economics of farming in the Eyre Peninsula is quite different and they really have a water problem. From a food PoV these are the people we really need to help.
(I have family in both, not to mention in laws in Germany who also have a water problem...getting rid of it!)
Right now it costs about $750-$3000 to set up each monitoring site, so growers can only afford to install a low number of devices per acre [1], thus a high number of plants per device. In that case you’re not optimizing to anywhere the specific requirements of each plant, you’re assuming (often falsely) that all the plants in that area have the same needs as the one you’re monitoring.
The lower the cost per device, the higher your resolution and precision of monitoring can be, and the more you can accurately provide for the specific needs of each plant.
[1] Very often that number is zero.
Wouldn't a device that travels like a snail along a cable or something, while less glamorous than a self propelled (and navigating) device, deliver a reading for a whole line of plants every day without all of the eroding parts per plant?
Having machines moving around taking readings “each day” is insufficient, as during hot conditions the soil/plant moisture changes too rapidly. You need to take readings at least once every hour or even every 30 or 15 minutes in order to be able to start irrigating immediately when the moisture level starts dropping rapidly.
I can imagine that a lot of small devices becomes economically viable.. I find that unfortunate since I think it will be a lot of permanent ewaste lost in fields relative to very temporary water optimization benefits.
For the use case invoked in this subthread (an individual monitoring device on each plant), I don’t think it’s the best.
We’re currently working with Nordic nrf52xx/53xx modules, which have dual ARM cores and built-in 2.4Ghz radio, so, support for protocols like Bluetooth Mesh, Zibgee, Thread.
That means you can have a single module that can handle mesh comms with neighboring devices, as well as sensor reading, machine learning and output control. You wouldn’t need a separate comms module to communicate back to a base station or a high post and antenna for long-range comms. So it offers big savings on the device production side and the installation time/cost side.
When I've done similar projects in the past, we did the edge compute on a more expensive box that could be more conveniently accessed by users. It was also the system collected and summarized data into reports, so having the data locally helped.
So you’d centralize the more intensive processing on a unit with more power, and have smaller node devices on the plants doing simpler tasks - just reading from sensors and uploading data, and/or receiving commands to switch things on/off. They’d be solar powered too but the batteries and solar panels can be smaller.
These are all the trade offs you’re constantly working with in this game.
See the book gardening with less water by David A. Bainbridge
I’m building a company/platform that does a lot of this, particularly the “metering just the right amount of water for each individual plant” part.
The thing I have in mind is very low cost devices (sub-$20) with mesh radio comms, inputs to read from sensors and outputs to control irrigation, and TinyML running the devices to optimize everything in real time.
I have about 10 years experience working in the field (mostly with high-value crops like wine grapes, nuts, avocados) and several iterations of prototype devices and web software, but am keen to attract people who are excited at the idea of working on this kind of thing.
Anyone - particularly low-level programmers or hardware engineers - interested in working on it can contact me (email in bio).