AgOpenGPS - The Combine Forum

 55Likes
Reply
 
LinkBack Thread Tools
post #1 of 316 (permalink) Old 10-14-2016, 06:12 PM Thread Starter
Senior Member
 
BrianTee's Avatar
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 1,986
Mentioned: 0 Post(s)
Quoted: 743 Post(s)
AgOpenGPS

Download it at......
https://github.com/farmerbriantee/AgOpenGPS

Well it seems have had some time on my hands with it snowing so here goes, the introduction of AgOpenGPS.

Have a peak! Its a bit like watching paint dry, but i think the application has promise - considering its free. AB line, up to 5 sections GPS control, fully configurable and it actually works extremely well. Can not fool the section control as it gives very good recognition of unapplied areas.

My simulator only runs at 1 hz so its jerky a bit and slower, but was the only way to make the video. Using a real antenna and at least 5 hz, smooth as butter.

Click in the youtube icon at the bottom of the video and watch in youtube, this window has much lower resolution



lanwickum, chance2 and Snapper22 like this.

Last edited by BrianTee; 10-17-2016 at 12:11 AM.
BrianTee is offline  
Sponsored Links
Advertisement
 
post #2 of 316 (permalink) Old 10-14-2016, 06:31 PM
Senior Member
 
Join Date: Sep 2009
Location: S. AB
Posts: 1,888
Mentioned: 1 Post(s)
Quoted: 324 Post(s)
Looks great, Brian! How are you storing the coverage data? Are you using a GIS database of some kind? Even in its simple form it's at least as functional as the Raven Smartboom, but with a visual display. Even if you consider the cost of a windows tablet to run it on, it is still cheaper than the old raven unit.

This is a normal win32 C# app, right? I wonder how much work it would take to get it to run under Mono on Linux.

Would a GPS refresh rate of 5 Hz be slightly better or does it not matter in practice?

I was wondering what it would take to calculate where the implement is relative to the tractor during turns and so forth. I did some research into trailer path prediction algorithms, but never put anything concrete together.

Though in practice when using the Raven SmartBoom, which has no such turning compensation, it didn't seem to matter nearly as much as I thought it would.


Last edited by torriem; 10-14-2016 at 06:38 PM.
torriem is offline  
post #3 of 316 (permalink) Old 10-14-2016, 06:59 PM Thread Starter
Senior Member
 
BrianTee's Avatar
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 1,986
Mentioned: 0 Post(s)
Quoted: 743 Post(s)
Quote:
Originally Posted by torriem View Post
Looks great, Brian! How are you storing the coverage data? Are you using a GIS database of some kind? Even in its simple form it's at least as functional as the Raven Smartboom, but with a visual display. Even if you consider the cost of a windows tablet to run it on, it is still cheaper than the old raven unit.

This is a normal win32 C# app, right? I wonder how much work it would take to get it to run under Mono on Linux.

Would a GPS refresh rate of 5 Hz be slightly better or does it not matter in practice?

I was wondering what it would take to calculate where the implement is relative to the tractor during turns and so forth. I did some research into trailer path prediction algorithms, but never put anything concrete together.

Though in practice when using the Raven SmartBoom, which has no such turning compensation, it didn't seem to matter nearly as much as I thought it would.
Coverage, using the current fix position from the GPS and for each section am recording where that is. Next fix i'm recording the new position, so now i have 4 points - a quad. So in opengl i start a triangle strip - two triangles make the quad where i just was, and as the section moves forward it keeps adding new fix positions making more. When the section turns off, that group is added to an array of multiple patches. Each section does this. Fix is recorded in UTM WSG84 values - converted from latitude and longitude - so it can easily be converted and put into a shapefile or just saved as a csv. Could program it to simply record the fixes from the antenna location too and you would have all the data, saveable, and in any for you want. The beauty of open source.

The implement to vehicle pulling radius is an algebraic nightmare. I "got around it" by using a delay line of fix positions to emulate the turn radius of a pulled implement that is speed and fix rate calculated. It actually works extremely well. It does make me wonder for a tow between there is no setting in modern GPS for double hitch geometry. Its obvious the pros fudge it too - especially at the distance the fore/aft setting is. The best would be an antenna on the implement and an antenna on the tractor for guidance. It would be stupid accurate and would compensate for drift on hills.

5 hz is buttery smooth and accurate and is all that is required. Have driven down the road at 50 mph and it works flawless. Its not on the property page but i can set the look ahead time, must add to settings yet.

Yes win32 written in C# and Opengl. Haven't come even close to the 2G memory limitation on a 1200 acre field.

Started with 5 sections, but more could easily be added.
BrianTee is offline  
post #4 of 316 (permalink) Old 10-14-2016, 07:10 PM Thread Starter
Senior Member
 
BrianTee's Avatar
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 1,986
Mentioned: 0 Post(s)
Quoted: 743 Post(s)
As far as linux and other os's, oh man, this app has some very special programming using win stuff that i would have no idea how to do in other languages. Pretty sure the only reason this works is because c# and windows forms are extremely powerful especially for the non pro programmer. Not saying it can't be done, i'm saying i can't. Used to program games in c++, so not completely unfamiliar with it. 1 day of C# is like 3 months of C++ to do the same thing.

For giggles type "agopengps" into google. Until an hour ago, nothing came up.

Last edited by BrianTee; 10-14-2016 at 07:28 PM.
BrianTee is offline  
post #5 of 316 (permalink) Old 10-14-2016, 07:38 PM
Senior Member
 
Join Date: Sep 2009
Location: S. AB
Posts: 1,888
Mentioned: 1 Post(s)
Quoted: 324 Post(s)
That's really cool. When you get the code in shape for people to look at, I'd love to see it, just to learn about how it's working! So if I understand you right, you're essentially using OpenGL triangles to record the coverage and using OpenGL to calculate the collisions (overlap)? That's a very novel approach!

Seems to me that implement path calculation should be possible with some linear algebra (vector math). I was hoping to find some basic algorithm that could work it out, but I suspect it's more involved, as you are dealing with changes over time that are inter-related. I want to look into this more, but I seem to have too many unfinished projects that take my time and energy. I must be spectrum ADD or something. Nice to see you making so much progress!

I hear you about C# vs C++. Although actually C++ isn't as hard as people sometimes fear. I have to confess I do all my personal projects in Python these days (using PyQt for graphical user interface), which is the fastest language for development I've ever used. Though anytime you have to program a GUI, things get a bit more complicated.
torriem is offline  
post #6 of 316 (permalink) Old 10-14-2016, 08:04 PM
Senior Member
 
Join Date: Apr 2012
Posts: 317
Mentioned: 0 Post(s)
Quoted: 22 Post(s)
Nice work Brian. Interesting stuff.
RunninREDharD and SWMan like this.
hiway mike is offline  
post #7 of 316 (permalink) Old 10-14-2016, 08:05 PM Thread Starter
Senior Member
 
BrianTee's Avatar
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 1,986
Mentioned: 0 Post(s)
Quoted: 743 Post(s)
Quote:
Originally Posted by torriem View Post
That's really cool. When you get the code in shape for people to look at, I'd love to see it, just to learn about how it's working! So if I understand you right, you're essentially using OpenGL triangles to record the coverage and using OpenGL to calculate the collisions (overlap)? That's a very novel approach!

Seems to me that implement path calculation should be possible with some linear algebra (vector math). I was hoping to find some basic algorithm that could work it out, but I suspect it's more involved, as you are dealing with changes over time that are inter-related. I want to look into this more, but I seem to have too many unfinished projects that take my time and energy. I must be spectrum ADD or something. Nice to see you making so much progress!

I hear you about C# vs C++. Although actually C++ isn't as hard as people sometimes fear. I have to confess I do all my personal projects in Python these days (using PyQt for graphical user interface), which is the fastest language for development I've ever used. Though anytime you have to program a GUI, things get a bit more complicated.
In terms of detecting collisions, no i don't calculate a single thing. I asked a bit ago how how sections worked and one person joked well you have the picture, you can just see it. So it got me thinking. What i do is send the triangles to another opengl rendering window that is 400 pixels square that is in behind the main window. So 1 pixel is about 4 inches of section. I then draw a close up image of the area around the section or boom. There is a command in openGL that is gl.ReadPixel that can read a line of pixel data so i take a snapshot of a few lines at the boom up t0 what will be the "lookahead" point and then just look for a black pixel. Its black because triangles as placed make everything green where applied.

So i look for a zero color and turn on the boom if i see one. If all the lines come back as green, its already been applied so turn the section off. Collision is a nightmare because you can have little wedges of unapplied and to calculate those is very difficult.

In the main window the sections that are green are semitransparent. As you go over a second time the green's transparency keeps subtracting so it will look a little darker with every time a triangle gets drawn over the same spot. that way you get contrast of over applied and overlap.

The implement tracking is very complex as the tractor doesn't just make a turn, it can zig and zag and slide and..... Also, the boom will begin to back up at some point if turning too sharp. An implement will do exactly what the tractor does, except it will be delayed. It starts the corner late so if you chop up the path from the last 20 readings and average them, it takes time for the implement to see "the turn". As the tractor keeps turning the averages also start to pile up as changing so the implement now turns too but since its later, the arc is smaller. Tractor straightens out and now the averages start cleaning out so while the tractor goes straight a while the implement will continue to slowly straighten out. Using the fixes based on the section, you can easily "simulate" quite closely the implements turn without a single calculation.

Just like in writing a game, speed is of the essence. So the less calculations the better and if you can get to 90% of reality without any calcs at all its easier to code and is fast.
BrianTee is offline  
post #8 of 316 (permalink) Old 10-14-2016, 09:29 PM
Senior Member
 
Join Date: Sep 2009
Location: S. AB
Posts: 1,888
Mentioned: 1 Post(s)
Quoted: 324 Post(s)
Very good thinking on the coverage map! That's certainly a much simpler solution than I envisioned. And for this purpose it's an elegant solution.

I'm not sure how the big companies do coverage maps. I suspect they are storing periodic point data rather than coverage pixels because I can forget to turn off recording on my tractor and record paths all over my farm without consume a lot of space.

What are you currently using to interface with the implements sectional controls? Are you using an Arduino in the loop somewhere?
torriem is offline  
post #9 of 316 (permalink) Old 10-15-2016, 02:30 AM Thread Starter
Senior Member
 
BrianTee's Avatar
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 1,986
Mentioned: 0 Post(s)
Quoted: 743 Post(s)
i will be yes. That is the really easy part. Serial USB to the arduino with the extent of programming of telling 5 pins to turn off and on in sync with the sections. 5 power fets to switch the booms controlled by the duino. Cost, about 40$

For the antenna a Novatel Smart 6, About a thousand - not sure tho. You can get the dual channel ones the plug into a base for full RTK. They have tilt sensors already built in for proper slope tracking and even can connect via bluetooth. Bluetooth SPP is quite simple with Windows as it is just treated as another serial port.

A tablet or hybrid or Brix or like the lattepanda (my personal preference for about $100) running win 10 already installed and a touch monitor.

Seems silly to spend thousands for section control. Hoping this can go into the seeder setup which has autosteer with an outback S2 and RTK by reading the NMEA from the S2 This mapping and section control should make a nice addition for next to nothing. May put a Smart 6 right on the seeding tool as its tow between and a looooooong way away from the antenna. Then you could do ridiculously accurate anything you want.

I think the "big guys" are using shape files and using polylines and polygons. You still need to store an awful lot of data to keep track of all the green spots no matter the technique. I did a 1200 acre simulated field and saving showed only 80 MB of data, 3 sections. Given 32 bit win apps can manage 2GB of memory space at once, i'm thinking you could map half the country in a single field before running out of memory.

Long story short, it really seems possible this will work. A majority of the hard part is done. And i can use my tablet the rest of the year and not sit in a tractor for 11 months.

Its very easy to add another data stream to include seeding or harvesting info, that's where my other project, ag canbus comes into. No reason couldn't also program in variable rate for next to nothing.
adsinaus and chance2 like this.
BrianTee is offline  
post #10 of 316 (permalink) Old 10-15-2016, 09:31 AM
Senior Member
 
Join Date: May 2011
Posts: 115
Mentioned: 0 Post(s)
Quoted: 9 Post(s)
Great work Brian! I look forward to taking a closer look as soon as time allows. Just reading through the thread, this project reminds me of my attempt to do the same several years ago but I got hung up the 3D moving map and couldn't figure out the opengl code.

m_elias is offline  
Sponsored Links
Advertisement
 
Reply

Quick Reply
Message:
Options

Register Now



In order to be able to post messages on the The Combine Forum forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.

User Name:
Password
Please enter a password for your user account. Note that passwords are case-sensitive.

Password:


Confirm Password:
Email Address
Please enter a valid email address for yourself.

Email Address:
OR

Log-in









Human Verification

In order to verify that you are a human and not a spam bot, please enter the answer into the following box below based on the instructions contained in the graphic.



Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page



Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On

 
For the best viewing experience please update your browser to Google Chrome