Hacker News Reader

Comment by tomhoward | Hacker News Reader

In case anyone’s reading this who is interested in working on it:

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).

View on HN

$20 is a lot (I assume that’s the customer price buying them in volume). You have to save a lot of water / increase yield enough to justify that. That suggests a BOM well under a buck, probably less than $0.50.

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.

When you think about it, farming is the perfect physical application of scaling.

The Open Source Ecology folks have been working on this sort of thing for a while --- check in with them?

https://www.opensourceecology.org/

that website/project looks pretty dead

I’ve always been supportive of open-source and plan to make much of our tech open source [1], but I’m not seeing anything on their site that’s anything like what we’re doing (it alls seems to be large machinery, no microelectronics).

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.

In another comment I wrote that you probably need a BOM less than $0.50. At that price you don’t have a massive OS like Linux, you need something embedded that can run in a few KB.

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)

Well I already have a firmware version that can run in a few KB, which my father developed in Motorola assembly and that ran most of the soil moisture monitoring devices sold to the big-volume wine grape producers in Australia (mostly in Riverland SA supplying Treasury etc) from the late 90s till about 2010, after which newer products using Zigbee and cellular IoT took over (though we worked together on our own newer versions supporting Bluetooth LE and Cat-M1 up until his retirement a couple of years ago).

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.

BLE mesh and solar power should get your BoM cost below $20, but I don't see any way that you're going to hit a sub $1 price point. Assuming your mesh can cover the entire field (reasonable if you have one monitoring point every few plants), you can have one or a small handful of LTE-M basestation points to handle the data uplinks.

It's an interesting problem and I am sure reference designs already exist. Maybe talk to someone at Nordic.

Yeah I think that's right. It's a matter of trading off the water cost savings (and produce quality/yield gains) per plant vs unit cost per device, to determine the optimal density of devices.

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.

There's (relatively) lots of water in the Barossa Valley and it's worth growing a thirsty high value crop like grapes there. And even there the cost structure you say is unsupportable.

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!)

Can you use mesh networking? A solar panel and an Esp32, with mesh networking might be cheaper than an LTE module on each device, at the cost of needing more devices.

Yep, mesh networking is the plan:

https://news.ycombinator.com/item?id=40740278

Why must the device be so cheap? Is the intent to have one serve each plant? Why can’t one serve many plants?

Yes, that’s how it’s done now, but it’s a matter of the precision vs cost tradeoff.

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.

It seems very wasteful to me to have a lot of small devices sitting out in the elements, how resilient are they going to be?

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?

It’s pretty normal to have devices out in the elements now, it’s just a matter of how many. Yes having a device on literally every plant will probably always be overkill, unless they are so cheap and easy to replace that it doesn’t matter when one gets damaged. More likely it’d be optimal to have a device every x-number of plants - which is what’s done now but the number of devices per number of plants needs to be higher than is currently conventional to increase precision.

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.

For farming on a forest floor, I would expect overly complex variance.. For farming in a field, why isn't the deviance you calculate between the needs of plant location 1 & 2 on a frequent basis not a reasonable estimate to update the predicted needs of one plant every time you pass over the other?

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.

I wonder if in a large farm it will be worth running hoses and deploying a frob next to each device vs having an electric robot with a refillable tank walking the rows.

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.

My gut tells me that the robot will cost less in the long run. It also doesn't seem like a hard problem (yeah, easy to say) since row crops are planted at fixed spacings and detecting that the thing next you is a plant and not a rabbit should not be a difficult task. The combination of GPS mapping (planter knows where it was during planting), known plant & row spacing, and basic visual imaging should simplify the problem.

So why isn't it done today? Probably still cheaper to rely on the weather or center pivot irrigation.

Scale, I imagine. Orchards are big. How many robot waterers would you need when you have to spend time at each individual tree (or groups of trees) to water it/them? How far is it to the nearest refill?

Put another way, drip is massively parallel. Robot waterers, not so much.

Oh, I wasn't thinking orchards. I thought OP was talking about row crops which can't feasibly be irrigated with hoses.

> I thought OP was talking about row crops which can't feasibly be irrigated with hoses.

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?

1: https://www.youtube.com/watch?v=7j1lMs7fcIQ

Yeah, and I think you're right. I hadn't even given any thought to the massive weight of the water tank you'd need to do this. I was thinking of it more like a sprayer, which requires a much smaller volume to be useful.

The other issue is the ability to respond to extreme heat quickly enough.

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.

Row crops can be (and already are) irrigated with hoses. In dry areas of the world, drip tape is buried throughout the entire field because it allows farmers to make more efficient use of the water available to them. It does require the machinery has auto-steer (which is standard practice now anyway), because tearing up the drip tape with a planter is an expensive mistake.

https://whyfarmit.com/drip-tape-irrigation/

Really? I didn't know that. Just didn't seem feasible to have irrigation lines running for that distance.

Let's say the RoboWater(tm) rolls down a row of trees in the orchard, water hose unreeling behind it. At each tree, it dumps the calculated dose of water into a clay pot that is sunken into the ground near the trunk (from which the water slowly soaks into the soil). When the row is done - it reverses direction, reeling the hose back up in the process. Then some side-shuffling, and it's soon rolling down the next row of trees in the orchard, again dumping the calculated dose of water...

> The combination of GPS mapping (planter knows where it was during planting), known plant & row spacing...

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.

If you use an Olla, the plants self regulate their water intake.

See the book gardening with less water by David A. Bainbridge

Great for backyard tomato plants, not a commercial farming option for tens of thousands of acres.

Not the way farms are run today, sure. But if it’s worth it, farms will adapt.

It seems much more labour intensive compared to drip irrigation that essentially run long hoses in each row. Can you command on this comparison?

This sounds like the optimum use case for LoRa, doesn't it?

LoRa gets talked about plenty for ag monitoring, and sure it can be great for certain use cases. Optional support for LoRa is certainly something we want to support (via device variants or plug-on comms modules).

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/54xx 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.

Ha. Didn't see this post before I responded to your other one :-)

Are you not concerned about the battery life running edge ML on these chips? I imagine battery replacement will be a large part of the TCO for farmers.

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.

Yeah absolutely. You’d certainly need solar power on your devices, and the more data processing they’re doing the more battery and solar power you’ll need.

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.

Have you thought about sub Ghz mesh networking like 6lowpan with TI CC1310? If you don't need that much computing power then it's a good option, with way longer battery life.

Looks cool but I'm not sure how current those TI CC1310 devices are. I can see product release pages going back to 2015. Do you know anything about future support/availability for this model, or any newer models?

Reply on news.ycombinator.com