Agricultural projects

Phishfry

Phishfry

I am looking around for any argo-based programs in open source.
For crop management i can't find much.
There are alot of half baked projects on Github but nothing I like.
I am conceptualizing what I think may be needed. I have some friends who farm and I want to see what I can do to help them out.
Learning C on a real project will help me advance my skills.

GrowMon- A field based data collector based on GPIO inputs like Rainfall, Sunlight and maybe moisture content of soil.

FarmHand- A data collector for different farm fields. Collects from GrowMon. Year end input for crop yields.

Somehow take that work and use hooks into an accounting system like GNUcash for accounting.
I plan on starting on GrowMon first in my garden and then work up. I need to put my GPIO experience to real world use.

This project is the best i can find. Drupal is not what I want to work with.
http://farmier.com/open-source
I like one feature that I overlooked. Livestock management. That would probably be a different program.

Please critique my ideas.
 
Please give me honest inputs on Drupal.
I could just attempt at making a module for farmOS

The bad thing about this approach is I have to learn somebody else's program. Versus fresh code.
Plus Linux GPIO and FreeBSD GPIO are not compatible. So 2 code bases would be needed.

I do hate overlap though. I always thought of Drupal as the ERP competitor. Not open farming.
 
Drupal is a Content Management System (CMS) and this can be used for combining any kind of content together in a web page to be presented to the user, you want to see this part as the user interface to your content. Now it depends on the data which you want to process and how the processed results shall be presented. In case you want to show a diagram of a time series of sensor data, then Drupal would be sort of an overkill. If it comes to join the data with other structural data e.g. number of animals, size of crop areas, etc. (I am not a farmer, so please excuse my ignorance - I would like to be one, though) then Drupal might be interesting because it is backed by a SQL database which can be used for this.

What I understood is, that a farmer would place a few dozens of autonomous tiny ARM computing devices (with some sensors connected) all over the farm's place. And somehow, these devices shall inform the collected data to the central system which would produce some sort of visualization which can be presented to the user, am I correct?

PS: of course the ARM devices shall run FreeBSD
 
obsigna said:
These devices shall inform the collected data to the central system which would produce some sort of visualization which can be presented to the user, am I correct?
Click to expand...
Yes. maybe not even visualized. just have the central DB there. (GPIO)Collectors in the field. Maybe solar with battery.
The rrd tools API you helped me with earlier seems to be an ideal candidate for a small database on the Arm or APU GPIO.
I need to learn more of it. So GPIO collectors(APU2,Arm, maybe both on FreeBSD) feeding a central database on the main system at farm HQ. Field machines dump to central DB daily. Alarms sent on motion or other triggers,
I think separate databases on each Arm would be nice for independence. Just in-case a node gets severed it still collects.
You could even sync with a mobile PC while in the area tending to the crops as an alternative. Tractor mounted comm relays.
Just thinking out loud. Maybe web application is best for data presentation.

What about long length cable runs. Many different fields are leased up to 3KM away. RS485 really comes to mind.
The field collectors data dumps should be relatively low byte transfers.
I just don't know if wireless would be reliable enough for the longer hauls. Plus power considerations.
There would be comms at least once a day. APU doesn't have RS485 so thats a issue with a dongle.
Arduino does seem to have OK qualities, I just would like to try some practical applications on more capable hardware.
For instance a instant crop report with a snapshot(USB or Pi camera).
Motion detection to tell if your cropduster is really doing what he is paid to do or animal crop damage reports relayed by pictures.
 
The project need to start with solving the network connection problem. For the energy supply, quite probably battery backed solar panels would be OK. Are we talking about a totally rural region or are the farm fields interlaced by small residential areas? In the second case the farmer could agree with the neighbourhood about the installation of wireless directional antennas which would traverse distances of up to 1000 m. More then 15 years ago I saw a system operating at 10 MBit/s over 500 m and it was very stable. The good thing about this would be that the communication would be IP based, which would facilitate everything. The ARM devices on the fields could be also configured as repeaters, and by this way it should be possible to setup a WLLAN (wireless local large area network).
 
Ubiquiti (airFiber) has some hardware for poit-to-point wireless for a reasonable price (specially compared with Ruckus and Aruba) and reliability.

Some old wireless only ISPs used to use (old versions) of Ubiquiti (and also Mikrotik) hardware to do that in here with success (about a couple kilometers) (in a very noisy and dense city).

EDIT:

You can also consider fiber, even in redundancy, if the budget allow.
 
The reason I wrote RS485 is although some 3Km distance to the furthest field, you could daisy chain through the fields to stay within RS485 spec.
Problem as you noted is incongruous parcels. Even if you trenched in some cable you'r at the neighbors mercy.
Yes this is a rural area with some non-paved roads. See here for the area. Here is another.
Wireless would add some to the complexity. Maybe forego the comms and do a daily manual sync.
What about cellular.Cheapest plan would be $25 month and you could just dail-out daily or on alarm.
That eliminates alot of the issues. Plus you really only need to have cell service 7-9 months out of the year.
That is $200 bucks per remote field, per year. Maybe they have some cheaper IOT accounts these days.
So really a combination of comms might be used. Ethernet in the fields up close.
RS485 on the further reaches and cellular on the furthest fields.
 
OK so lets say the program needs to be network independent. Meaning it will need to work with several different type interfaces.

Back to obsigna question about visualization, I missed the point about 'how do you really want to display the data'.
My thought was to just get up a simple GPIO web form like a FreeBSD example that vadot has up.
But looking at how farmOS uses maps too that is pretty tough to beat.
There does seem to be quite an indepth infrastructure on farmOS there already.
Maybe I could run the farmOS -Drupal App on FreeBSD central server and make a custom FreeBSD GPIO collector module.

So that might be a good way to go. Try and get this farmOS running on FreeBSD and see what it offers.
I don't think it's Linux only. I will try. But there is that GNU license........
 
Phishfry said:
OK so lets say the program needs to be network independent. Meaning it will need to work with several different type interfaces.

Back to obsigna question about visualization, I missed the point about 'how do you really want to display the data'.
My thought was to just get up a simple GPIO web form like a FreeBSD example that vadot has up.
But looking at how farmOS uses maps too that is pretty tough to beat.
There does seem to be quite an indepth infrastructure on farmOS there already.
Maybe I could run the farmOS -Drupal App on FreeBSD central server and make a custom FreeBSD GPIO collector module.

So that might be a good way to go. Try and get this farmOS running on FreeBSD and see what it offers.
I don't think it's Linux only. I will try. But there is that GNU license........
Click to expand...
I wanted to clarify the network question before coming to on what and how would be presented to the user.

Most user-friendly and most easy to implement would be if everything is online 24/7. In this case, the devices in the field would respond directly on demand per request of the user's web browser. To get started, the central web server would present an index page with sort of a simple table of contents (name it table of fields and sensors), and the user clicks a link and the respective actual data would be presented in a separate window, tab, frame, whatever you like. Later you could add the landscape as an HTML image map, no Google Maps is needed for this, since the fields won't change their position every day.

If the devices are not online permanently, then these need to push somehow their data to the central server. This could be achieved by simply transferring a data log file (WebDAV, ftp, serial), or also by submitting a POST request to a private form of the web-server which would then store the received data into the database backend, for later processing and evaluation. In this case the visualization needs to always present sort of a time stamp, in order the farmer does not act on non-current data, e.g. the last temperature transmission was at 3 o'clock in the morning reading 32 °F and the farmer sees this in his web browser at noon, when it is actually 45 °F.

PS: I had a closer look at the map which you linked in your previous post. I still think, that a wireless directional antenna comes more cheap than 3 km copper wire. Even if it would be the same price, wireless brings you 24/7, while with the RS485 wire you are stuck which the push scenario, and still would need to pay a cellular plan for data transmission.

You could offer to the high school nearby that a group of interested farmers would finance the (low budget) students project "Online Field Sensors" and the school places directional antenna(s) at the top of their building. The farmer(s) could then access their sensors via the DMZ of the schools IT infrastructure, perhaps at a reasonable fee - which would help the school and the farms around there.
 
You must log in or register to reply here.
Back
Top