# GPS tracker in Orchard Environment

Maybe you can’t get there from here, but I’m trying!

We (my son and I) are trying to build a GS tracking device that will show my location, relative to the numbered tree rows, within my Orchard. The rows are 15’ apart and run almost due north and south. What I’m looking for to start with is to have the display show 21/22 when I am driving between rows 21 and 22.

What we have done so far is to drive up and down (N/S direction) the middle of rows 21/22, 22/23, 23/24, 24/25 and 25/26 collecting the longitude and latitude on an SD card. Using row 21/22 as our A-B line we are trying to use a 15’ offset to have the LCD display show what row we are currently driving in: currently only within rows 21 and 26. When we drive east of row 20/21 the LCD displays EAST and when we are driving west of row 26 it reads WEST.

Currently we are getting mixed results with our row ID (i.e.21/22)…It always gets East and West right. But within the rows it is a mix of correct row reading, incorrect row reading and Blank. Here is a picture of the display. Speedometer works fine.

The hardware is:
Arduino R3 2560
Adafruit Standard LCD 20x4 Product 198 with i2C/SPI back pack
QGP waterproof 28dB Gain Antenna (Amazon)

Calculation Logic:

For this particular orchard, the rows are parallel and only 600 feet long with a total of 81 rows. Basis for our calculations is Y=aX+b to tell which row it’s in currently.

Assumption: Since it’s so close to vertical, say the slope is 0. When you calculate it out, there are three zeros after the decimal point before a number. It’s not going to change the answer to include this tiny number. So when we get rid of the aX we just have an offset equation. Is this valid?

I know the linear equation method isn’t really the best way to go with GPS data, but I was thinking the rows are short enough, parallel enough and vertical enough to treat them as rectangular. For such a small area can I make these assumptions? Should I use another method on the data? Is it the hardware limitation of the GPS I’m running into? Are there any tricks to improve our accuracy? Is there a more accurate GPS module I should be looking at?

Any and all suggestions appreciated.

Jan 3 gps-row-test-2018A.ino.ino (8.77 KB)

15 ft - that's about 5 meters. Roughly the accuracy you can expect from a GPS receiver, so you should expect it will usually read the correct row, but far from always. Being between the trees (orchard - don't know how thick your canopy is) is not helping to get better accuracy of course. Receivers may claim 1-2 meter accuracy but that's in ideal conditions: when a good constellation (spread out over the sky) of a good number of satellites and perfect clear vision to the sky (so no clouds or trees or so in the way). 3-5 meters is a more normal real world accuracy.

Best you can probably do is average a bunch of readings, and make the system assume you stay in a row for a while, at least until you reach the latitudes that mark the ends of the orchard or maybe some cross paths where you actually can move from one row to another.

Think of the cherry trees as Christmas tree shaped...wider at bottom narrowing as you go up...I'm thinking reception is ok... but I'm wrong alot...lol...averaging is a good idea....Hoping someone has done something similar.....Trying to stay away form all the curvature of the earth math...am way too simple minded for all that!

For normal orchards (those that end before the horizon) I don't think the curvature of the earth is of any concern.

When you can see the sky, reception should be fine, though even a thick cloud cover can be a problem.

There are lots of GPS examples out there, and I would expect more people have done the same. One thing you should consider is that your orchard is probably not perfectly north-south and that you may end up half a row off on one end. It of course makes the math a little more complex but that's not too much to worry about as for you it's a one off to program it.

Hi,
What are you using for an aerial and how high is it?
How many satellites do you receive?

Tom...

The main problem is that floating-point numbers only have ~7 significant digits. So when you specify a row's longitude like this:

``````    12120.31775
``````

... you are only getting this much precision:

``````    12120.31
``````

Not so good, eh? No wonder it has trouble distinguishing between rows.

Or it could be because you don't indent your code....

NeoGPS can remember 10 significant digits with integer versions of those floating-point values. They are scaled up by 10000000, so the comparison would be

``````   if (fix.longitudeL() < 1213386292L) // row 20/21
``````

Notice that this is not quite the same number as 12120.31775. That's because 12120.31775 is really 121 degrees plus 20.31775 minutes. NeoGPS lat/lon is just degrees, so you have to convert the 20.31775 to degrees by dividing by 60. That gives 0.33862916667, but round to 7 decimals, giving 0.3386292. Add 121 and multiply by 10000000 to get 1213386292.

Here is a NeoGPS version of your sketch. It uses an array of these row longitudes to "look up" the row number:

• If the lon is more than the first entry, you are "East"
• If it is less than the last entry, you are "West".
• In between, it adds 19 to the index to get the row number (and +1). Note: I might be off by one...

Voila! Like always, the NeoGPS version is faster, smaller, more reliable and more accurate than the Adafruit_GPS version.

Cheers,
/dev
(Apparently, I am in the "East" section... )

HighPrecision.ino (9.16 KB)

Oopsies! Corrections to the above sketch:

• Longitudes are negative values! Change comparison to > to match.
• Blank field written when no location available.
• Too many longitudes in table (you got an extra row of trees ;))
• Table size not checked correctly (new MAX_ROWS constant)

In before the bell, because it looks like you haven't downloaded it yet...

Cheers,
/dev

dev

I can only hope your fix of this sketch is as good as your last one when this project first started...your help then was HUGE for us and this probably is too...will try it.today...my son is the numbers guy. He corrected the negative values issue also...he talked about significant places in the numbers, but to this old farmer it all devolves into blah, blah, blah numbers to my ears....thanks soo much

I'm back...same hardware and the latest sketch is attached....

With Dev's wonderful fixes we now have the unit showing which row we are in, from row 1/2 to row 81/82 and East and West when out of the orchard.....totally awesome if you are of the orchardist persuasion...now I want more!!!

Specifically I want to add the odometer function which I will change to read as acres covered (tree rows are 15 feet apart, one acre=43,560 square feet, so each mile travelled equals 1.181818 acres ((5280*15)/43,560))...I have read the previous threads on this forum "Arduino GPS Trip Meter" and Dev's response in post #4 and its link to " Vehicle Tracking System" but it is a true case of "Pearls before swine" as my near total lack of programming skills render it useless to me....

I am asking for specifics of which lines of the "Vehicle Tracking System" sketch I can cut and paste to get an odometer working in my current sketch.

Ideally I will have an external reset button so I can reset the odometer Displaying acres covered on the go. This will allow me to see how much of an acre I have covered and how much spray solution I have put out and be able to adjust the sprayers output accordingly. For example if I spray one acre with a goal application rate of 100 gallons per acre and see I have only applied 66 gallons then I increase the spray pressure ±50%...as there is a nearly a linear relationship between spray pressure and gallons per acre applied.

Thanks in advance for any and all help.

Feb_15th_GPS_Test.ino (14.1 KB)

Hi,
Good to hear that you have accomplished what you are looking for and can see the other functions that are possible.

I calibrate a flow meter once a year for a "Weedkilling" contractor that has booms that reach out from his 4WD and over roadside "weeds".
The gear has GPS and flow monitoring of the "Weedicide :o :o ", "Herbicide". Knowing the boom length it has all the necessary parameters.

It does a similar thing and suggests a road speed to attain the desired coverage/hectare when doing blanket spraying, it is not super accurate, but gets him in the ballpark of the spray rate required.

It logs everything, so the contractor can email his "work done" report/invoice to the customer, and has record for next year, or to check results of spraying later on.

In Australia our national broadcaster ABC has a TV program called Catalyst, they recently had a FARM ROBOTS episode.

I hope this link works for you.

Tom...

I realize I am just scratching the surface of what is possible....we are constantly calibrating as our sprays are a combination of ever changing mixtures of granular nutrients, powders and liquids..I admit to being a sticlker for good calibration and a bit of a equipment junkie so this type of project really interests me and fits in well with all the Global Gap/Food Safety junk being implemented here in the States for fruit growers....This is child's play compared to what my cousins are doing with their gps guided 80' no till grain drills, lol...

Farmer1949:

I realize I am just scratching the surface of what is possible....we are constantly calibrating as our sprays are a combination of ever changing mixtures of granular nutrients, powders and liquids..I admit to being a sticlker for good calibration and a bit of a equipment junkie so this type of project really interests me and fits in well with all the Global Gap/Food Safety junk being implemented here in the States for fruit growers....This is child's play compared to what my cousins are doing with their gps guided 80' no till grain drills, lol...

Ohh. okay even highlighting then right click the non blue URL and selecting Go to http.
I'll see what I can do, it has an organic vegie farmer with some robot applications in it.
Tom....

Hi,
Try googling catalyst farmer needs a robot

Tom..

I am asking for specifics of which lines of the "Vehicle Tracking System" sketch I can cut and paste to get an odometer working in my current sketch.

Yep, pretty easy. Add these declarations at the top:

``````float                 odometer = 0.0;
NeoGPS::Location_t    lastLoc;
bool                  lastLocOK = false;
const float           MIN_SPEED = 1.0; // mph
``````

And add this odometer section to `loop`:

``````void loop()                     // run over and over again
{
if (gps.available( gpsPort )) {
fix = gps.read(); // get all GPS fields in one fix structure

if (fix.valid.date || fix.valid.time) {
// Convert the GMT date/time to the local time (PST)
}

// Update the odometer
if (fix.valid.location) { // && fix.valid.speed && (fix.speed_mph() > MIN_SPEED)
if (lastLocOK) {
odometer += fix.location.DistanceMiles( lastLoc );
}

// ...and save this location for next time
lastLoc   = fix.location;
lastLocOK = true;
}

printGPSdataTo( Serial );

updateLCD();

printGPSdataTo( logfile );
logfile.flush();
Serial.println("Log");
}
} // loop
``````

This calculates the distance traveled in miles, and accumulates it in the variable `odometer`. You would use that variable to calculate and display the acreage covered, as you described.

Notice that there is an if statement with some things commented out:

``````   if (fix.valid.location) { // && fix.valid.speed && (fix.speed_mph() > MIN_SPEED)
``````

This will accumulate distance traveled, even if the vehicle is not moving. As you probably know, there is a GPS "jitter" when you are stationary. That makes it look like the vehicle is moving a little.

As long as your vehicle is moving most of the time, you probably won't notice this small jitter. But if you leave the unit on for a few hours while it's stationary, don't be surprised to see that you have covered an acre.

If you want to avoid this potential problem, make the if statement more selective:

``````   if (fix.valid.location && fix.valid.speed && (fix.speed_mph() > MIN_SPEED)) {
``````

This will not accumulate any distance until the speed goes over the threshold. I'm not sure how fast your vehicle is going, so I can only guess at a minimum speed (1mph above). 2 or 3mph would be safer, if you usually drive at least that fast. If you're just creeping along, just stick with the first simple `if` statement.

-dev, thanks soooo much....just what I was hoping for....will try it tomorrow , how hard could it be?

Thanks again.

-dev:
If you want to avoid this potential problem, make the if statement more selective:

``````   if (fix.valid.location && fix.valid.speed && (fix.speed_mph() > MIN_SPEED)) {
``````

This will not accumulate any distance until the speed goes over the threshold. I'm not sure how fast your vehicle is going, so I can only guess at a minimum speed (1mph above). 2 or 3mph would be safer, if you usually drive at least that fast. If you're just creeping along, just stick with the first simple `if` statement.

Hi,
I did the same thing with a prototype forklift speed alarm for a customer.
His yard forklifts were being driven at inappropriate speeds will outside, so we fitted a GPS speedometer and speed alert to them,then interlocked it with the seatbelt switch to alarm if the machine was being driven without safety device.
It was surprising how far a forklift can travel in cyberspace.

Tom...

Speed alarms! That would cause a walkout here at our local packing houses where forklift racing is almost a religion!!! LOL

That is a great idea though....the uses for these things is only limited by one's imagination...but you already knew that

Farmer1949:
Speed alarms! That would cause a walkout here at our local packing houses where forklift racing is almost a religion!!! LOL

That is a great idea though....the uses for these things is only limited by one's imagination...but you already knew that

In Australia our OH&S rules are pretty concise and very strictly enforced.
To drive a forklift you have to have a license.
Even to use a scissor lift, you need an elevated working card.
I have one of these so I can repair equipment on some sites.

Tom..