Livestock Tracking and Management

[Roguewillow]

Hi Everyone,

I stumbled across this community while doing research for a livestock control system. We are looking for a way to manage stock on range without the need for fences. There are some companies offering prototype systems, but they are both expensive and laden with being closed source.

The concept is essentially what amounts to a two-way wildlife collar mashed up to an electric collar (typical with dogs etc.) To control your stock you simply train them to the e-collar so that they turn around when the tone is sounded knowing that a shock will follow.

I would like to be able to set virtual paddocks for the stock every day and have them move from one ‘paddock’ to another in a forced transition all remotely without having to ride out and see them. The concept is a the pursuit of a controlled rotational grazing system without the need for physical fences and one that ultimately can auto-generate daily paddocks from vegetation surveys and stock inputs.

If there aren’t any current projects along these lines, then I’ll probably start heading up one. I am much better at hardware integration and using GIS tools than I am at any in-depth software, so I know creating the management software will take some amount of learning. But I would think that if someone has already built geo-fence type implementations for a Meshtastic device that I would be able to stand on their groundwork for my ultimate pursuit.

Other dreams I have for this are that the mesh herd / flock / band etc. can be reprogrammed remotely (many km), their locations are relayed when asked for or on important changes in behavior (leaving a paddock, not moving for a long time etc), relaying health information like pedometer, nutritional and heat data. Current solutions for those are again expensive and closed-source. Additionally it would great if the collars were capable of remaining charged indefinitely (solar or in this case motion?).

I have a few of the TTGO modules with screens on the way for some practice and hands-on learning and I am excited to have found an active community developing something like this in an open way.

Thanks for reading!

Willow

[bigiain]

A few comments.

There’s a practical upper limit of around 30 nodes per channel, and a hard upper limit in the code of 250 (according to this post Theoretical Mesh Stats? ), so you might want to keep that in mind and compare it to how many head of stock you’d need to virtually fence in. (I think you can use multiple channels simultaneously, so if you need 100 head of cattle, you could maybe use 3 or 4 channels with disconnected meshes of 25-33 devices each? )

There’s a plan to implement a way to read/write gpio pins - but it’s not in the code yet. Discussion here: Extension of the functionality of devices Meshtastic

If I were approaching this problem, I’d wait for (or help out implementing) that remote-gpio-module, and then take the entire meshtastic hardware/software project as my “transport layer”, hand some minimal hardware off the gpio pins to drive the buzzer/e-collars/sensors (there’s about a dozen gpio pins broken out you could use), and do all the geo fencing and command/control stuff on a RaspberryPi or a laptop at “home base” using the Python APIs here: https://meshtastic.github.io/Meshtastic-python/meshtastic/index.html

Good luck!

[Spor7biker]

I touched on this subject in the following post:

LoRa signal-based positioning

In my not so humble opinion (sry!) any non GPS based location features shouldn’t be even considered until well after a 2.0 release. The time and effort required doesn’t really match the benefit gain for the majority of users and use cases. The best use case I can think of where this a significant benefit in hardware cost, size, and power consumption sans GPS would be tracking live stock. The collars could have a minimal radio package and the area they are located could have 3+ nodes around the…

I think it could provide some ideas on how, you could use Meshtastic as the long range connection for simpler devices.=.

[bigiain]

Ahhh, I guess I didn’t write that down too clearly.

Yes, 100% use the GPS positioning already available in V1.0

I’m assuming (based off the behaviour of the Android app) that all nodes receive position updates of all other nodes?

I’d use the API payloads containing those (assuming they’re available to the Python APIs - whichI’ll admit I have not checked…) and use that existing GPS based location stuff in a Python app.

Have the Python app do all the checking each reporting node is within it’s configured geofence, and sending whatever signal back to any device near the border or outside it’s geofence. My thinking there is don’t fork/modify the device code - at least not now while it’s in super-active development, because then you’d be assuming responsibility for maintaining your fork/modifications as the main code branch fixes bugs and adds features and hardware-support.

For me - the ideal here would be to run completely stock and up-to-date main-line device code (with the planned gpio module) - and have all the livestock/geofencing/buzzer/e-collar/other-sensor specific code in a Python app running on a machine with a mesh node attached. That way all the Meshtastic stuff stays “original” - and any custome livestock management stuff hangs off the side without requiring modifications to Meshtastic or risking breaking any of it’s code. The “Livestock” part of the project would be additional hardware plugged into gpio pins out in the field and a laptop/RaspeberryPi/whatever talking bluetooth to a meshtastic node at the farmhouse - listening to standard Meshtastic GPS location updates, and sending gpio instructions to the livestock end nodes.

[Roguewillow]

Thank you both for commenting and making a number of things clear.

I was not aware of the node limit beforehand, but the link to that thread from May discussing the theoretical and practical limits is very useful. I personally won’t have an issue limiting the individual herds to ~30 head each. I actually prefer that type of management since it allows for more precision in the pressure placed on a piece of land than trying to run an entire herd on it. Plus, most small-time farmers wont have more than 20 or 30 head regardless.

One thought to run a larger heard may be to have some animals connected to a long range, lower capacity channel and others set up on a short range, high capacity channel. It might require two devices connected via gpio on the translation collars to keep from forking the code, but on a cursory look that seems doable. Maybe there is an idea for general development in the future? Some sort of ‘tower’ infrastructure that allows a designation as a long-range low bandwidth node to give multiple local meshes the ability to link up? Definitely not my strong suit trying to decide how to implement that.

In the realm of this application I think always transmitting the livestock’s location all of the time is an excessive use of resources. And, if some sort of ultra-low-power pedestrian dead reckoning hardware can do most of the position monitoring, the GPS could remain off much of the time. I think keeping the livestock management one a separate ultra-low-power device which is capable of waking the Meshtastic node is a great idea. It would keep the power used by the mesh down since the network could go to sleep for a majority of the time and it would keep the power used in positioning down since the mesh device would only need to supply position data as often as the PDR device asked for it (which might not be very often if an animal is laying down chewing cud, for example).

I think my preference is that the management app would really only be there to set the perimeter and report the livestock positions. Ideally I’d like for the collars to be independent, storing a perimeter and checking the livestock’s position to an internal perimeter rather than shipping off that calculation to a central app.

I have 3 of the TTGO T-Beam devices with displays on their way, and today I am investigating a couple of low power dead reckoning IMUs right now. I have looked at few GPS-integrated solutions but they don’t have the low-power performance when they are off compared to some of the independent IMUs out there (I’m looking at some Bosch examples). I have 2 months before these devices get here, so I have some time to make up my mind and see what the community is able to develop beforehand.

[donblair]

@Roguewillow – love this idea!

I only discovered Meshtastic a few days ago, but I similarly immediately started wondering about using the Meshtastic infrastructure for off-grid sensor networks generally – for researchers, farmers, folks worried about flooding, conservation biologists tracking animals – and so I’ve been mulling over how to connect sensor / actuation hardware into the mix.

Sorry if I’m just repeating sentiments posted above; but as for myself, I’ve been thinking it would be easier for me to begin by using a separate, dedicated collection of LoRa widgets for sensing / tracking – low-power devices, specifically designed for asset-tracking / sensing, that send their data to gateways (perhaps Pi-based) that are located on towers / poles / sides of hills. No mesh networking for those simpler tracking devices, at least at first (would be fantastic, but it’s beyond my current skill set), just a simple ‘star’ topology; but since a node’s data could be received by multiple gateways, one could put together somewhat of a ‘cellular’ with gateways distributed spatially such that traveling assets would have their data received by at least one gateway as they roam.

Meanwhile, for the humans who might also be out in the field and want to receive any notifications or data from this system off-grid, I’m eager to try to use the Meshtastic Python API on the gateways to send out alerts / notifications to Meshtastic devices. I love the idea that farmers / researchers could chat with one another off grid, and also receive sensor data / alerts via chat from a ‘chatbot’ …

In case it’s useful: we’ve recently been experimenting with a cute little device called the Gnat (https://www.tindie.com/products/tleracorp/gnat-loragnss-asset-tracker/): STM32-based, Arduino-compatible, sleeps at a few microAmps, is intended for tracking small animals (we’re intending to track small turtles with it for a conservation bio project). If you need more pinouts, there’s the Cricket (same seller on Tindie). We’ve been using it to connect to Raspberry Pi- based, multi-channel LoRaWAN gateways (https://www.amazon.com/RAK2245-LoRaWAN-Application-915MHz-Raspberry/dp/B088873JTM?th=1), but we’re also hoping to experiment with simpler, single-channel LoRa gateways that would be lower-power and likely quite capable of handling 10s of nodes.

Let me know if any documentation / code would be useful & we can send along – we’re very much FOSS/H about everything; if we haven’t documented anything it’s just because we’re lazy / strapped for time & could use a kick in the pants to actually do it

Cheers for the question, thanks to all for the useful comments in the thread, and would love to hear of any progress folks make!

[Roguewillow]

@donblair - Thanks! A fence without having to build a fence has been the dream of many livestock owners for millennia!

The Gnat et al look pretty great! I like that they come with some selections of the Bosch IMUs already integrated. I’d like for there to be a version including one of the Bosch dead reckoning chips for better low-power positioning and a longer interval with the GPS off.

Right now it seems that the surface documentation is looking to use the IMU simply as a ‘wake’ or ‘rate’ trigger for the GNSS receiver. With dead reckoning on-board you can obtain reasonably precise position data between the GNSS positions and faster locks on wake-up if the GNSS will accept an external position.

You have alerted me to a fantastic idea though. In some cases you have to leave some more expensive infrastructure ‘out there’ for your livestock. Water troughs, fence chargers, sometimes even trailers as shelters are all left far out in fields. Being able to discretely track those items in case they start to walk off by themselves is something I hadn’t thought about.

We have experimented with a number of coyote prevention methods for stock. The smaller ones (sheep and goats) can be devastated by predators if they aren’t left with guard dogs or in an electric net. However, I know that many coyotes will react to various game calls by running away - especially sounds from larger predators. If a herd or flock could be left with a game call speaker that is programmed to respond to panicked movement of the stock, then it might be possible to scare away any coyotes that make it in the perimeter. Giant floodlights and a siren can also do a lot to scare away some predators but getting those to react to only a predator and not the livestock is a challenge…but maybe not with a flock of predator-sensing nodes all watching for danger!

Willow

[Nanovitruvius]

there is also a similar discussion in some of the posts here: Real World Use Cases, just adding for completeness sake.

[Roguewillow]

@Nanovitruvius Thank you for the link to that thread. It seems a number of people have the same sort of wants as I do. Sweet!

Willow

[Nanovitruvius]

There is a company here in Norway that sells something akin to what you seek: NoFence
However, in a MSc thesis I recently read on the subject, the price of most of the currently available commercial offerings is as high or higher than the cost of the sheep they aim to track/protect. That’s why I think LoRa, with no monthly carrier or satellite fees, low power consumption and low-cost hardware, really has an edge here.

[Roguewillow]

There is another company I found, Vence, which has a similar type of product.

LoRa really does have an advantage if you are nearer to your herd though. And, even still I would bet it is straightforward to have a LoRa to cell translator node that would give you access to the mesh from anywhere.

[bigiain]

If you’re still looking into this @Roguewillow - I just came across this:

Smart Cow Collars — Halter

and some interesting discussion on it here:

Smart Cow Collars | Hacker News

(It’s interesting to me how many of those comments say “taking experienced eyes off the herd by automating things will cost way more from missing providential health problems than the automation can ever save”…)

[nicsky]

I was immediately interested in livestock management when I saw meshtastic. I have got a set of three devices and was planning on a system that would provide
Head movement sensor
Temperature
Steps per sec
Velocity
Virtual fence
Anti stock theft
A small audio signal as a stimulus
The tag could be mounted on the neck or maybe ear or tail

I would like to work with someone on this type of project. I have experience in sensor design electronics Solidworks and altium systems.
I see this to be very useful for dairy but could be usefully in other pastoral apps even in remote areas such as northern territory Queensland
I expect temperature logging alone would highly usefully to look out for street or sickness in a herd member. I am very keen on Lora low power consumption as there is not many technologies that provide the range and consumption characteristics of lora

[gueux]

I’m also interested in simple livestock tracking. I think the most important thing missing for my use case is a way to log gps tracks on the livestock node (I would just have one, on one of the leaders of the herd) and have a way to see that the whole track has been pushed to the home node, before deleting it. I need to be able to see the complete gps track, in case one of my animals got lost for whatever reason. Do someone have ideas for this?

[Xanuman]

I am also engaged in animal husbandry. I have a flock of 60 sheep.
Sheep graze most of the time. Jackals live in the place where I herd them. And sometimes even wolves appear. It is impossible to fence off the territory. Therefore, LoRa-based devices that allow automated grazing are the best option for me.

For these purposes, the Meshastic is not suitable. Because it has many solutions that are not needed for livestock control. But they consume a lot of energy and increase the cost of the system.

Here is my idea for implementing large herd control.

LoRa and GPS devices cannot be attached to all animals in a herd, but only to some. Because such devices are more expensive and require more power. For instance:
You have 100 cows. Of these, 10 cows have collars with Lora + GPS + esp + executive devices (no. 1). And the rest have low-power cheap modules, in which only bluetooth + executive devices (No. 2). Number 1 provide control, management and long-distance communication with the farm. And number 2 receives signals from number 1 at short distances.

Also number 2 can send telemetry to number 1. And those, in turn, send telemetry of the entire herd to the server via long-distance communication.

[Spor7biker]

Welcome @nicsky

I’m not very useful as a programmer but if you want I can put on my project manager hat and we work on a set of specifications / requirements, document them well, provide the user stories to help developers understand how we want it to work.

A surprising amount of what this use case needs is available under the hood. And a lot of what is needed is also useful for people that want real time stats for boat and bike races.