The Combine Forum banner

1 - 20 of 4139 Posts

·
Registered
Joined
·
5,785 Posts
Discussion Starter #1 (Edited)
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

 

·
Registered
Joined
·
3,686 Posts
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.
 

·
Registered
Joined
·
5,785 Posts
Discussion Starter #3
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.
 

·
Registered
Joined
·
5,785 Posts
Discussion Starter #4 (Edited)
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.
 

·
Registered
Joined
·
3,686 Posts
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.
 

·
Registered
Joined
·
5,785 Posts
Discussion Starter #7
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.
 

·
Registered
Joined
·
3,686 Posts
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?
 

·
Registered
Joined
·
5,785 Posts
Discussion Starter #9
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.
 

·
Registered
Joined
·
372 Posts
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.
 

·
Premium Member
Joined
·
556 Posts
Its great to see this kind of a project started for ag. I've been peripherally involved (as a beta tester) with a similar project for ocean navigation. That project is OpenCPN | Official OpenCPN Homepage if anyone is interested but the reason for the post is to point out what I think is one of OpenCPN's strongest features. From its earliest stages the lead developer built in a provision for what he calls Plug-ins. I don't understand anything about the programming but the concept is that the plug-ins integrate fully into the underlying software to provide enhanced functionality. Often that new functionality is hardware specific so, for example, there is a plug-in which integrates Garmin radar displays on top of the underlying nav software and a different plug-in for Navico radar because evidently the output from those two systems is somehow fundamentally different. I've been involved with OpenCPN for just over 6 years now and the increased functionality of the core software has been matched by a profusion of plug-ins over that time frame.
 

·
Registered
Joined
·
5,785 Posts
Discussion Starter #12
It snowed almost a foot yesterday and cold days forecast so its looking like gonna have some free time for a while.

Bob, that is very true, and that is an amazing project! going forward i will really keep that in mind. I like the concept it can be done on any operating system. Torriem would love to see it in linux and i totally agree, but i would need to do a complete rewrite of the software in another language - and learn that language. But maybe, this will inspire someone who does know the language and go for it. Qt is the winner there.

One extremely horrible thing about ag, and i've whined incessantly about it, is the complete lack of any, and i mean zero, nothing, examples of other code, techniques, or discussions how about how many of the major techniques of precision ag are accomplished. Do they use lat/longitude or do they use UTM coordinates? No idea. How is data stored? no idea, all are proprietary binary files. How do they accomplish section control? Not a word in any book or exhaustive search on the internet. Canbus and isobus? You can't even talk about or you get sued if you put anything on the internet, and it cost 30,000$ to buy the "standard" first. Every topic it seems is that way. :52:

Navigation and mapping like OpenCPN has tons of code, examples, projects etc and while in no way easy there are many entire sites like combine forum and bigger dedicated to that one topic. Building a drone from scratch? No problem, download all the code for an arduino, order the list of parts, hook it up. Install the ware on your smartphone and voila, a 400$ full functional drone that retails for 4000$. It obviously comes down to the number of people involved, the more there is the more residual hackers in that crowd.

But in ag, its slowly starting. Matt and Torriem are working on exciting development for bin temp and humidity stuff. Exciting! Do i want to recode and figure all that out? No way, but you can have my code, and i can have your code and others can build upon it too.

Anyway, gotta get this packaged up so others can find bugs in the machine and look over the project and throw out ideas. Thanks for listening to my rants!

BTW, just got in the mail from a new Inertial Measurement Unit (IMU) that is a 9 axis gyroscope/accelerometer/magnetometer from Bosch. Adafruit has put it on a board along with an Arm Cortex processor in the chip it can do all the fusion to spit out roll pitch and yaw. Its 45$ and online is all the arduino code, windows code, and full writeup of tutorials. One huge step closer to autosteer. It's this:

https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/overview
 

·
Registered
Joined
·
3,686 Posts
I found most of the isobus documents online a while back... dark corners of the internet. Like most standards, isobus is exhaustively documented, if you can cough up the money for the book, but like most committee-standards, the documentation is missing a lot of things (I've been told anyway), hence a lot of mostly compatible implementations among the big manufacturers, but with lots of gotchas along the way.

Personally I think isobus has been good, but if I needed to control something on an implement now I think I'd be tempted to just use wifi. A lot higher bandwidth.

You might get in touch with the gentleman who started this thread: Steering a combine via GPS He built his own autosteer some years back. I'm not sure whether he ever released code or not, but I bet he'd be happy to talk to you.

I'm still waiting for sub $1000 RTK GPS receivers to be available. I think a couple are nearly there.

Picking a language to build things in has gotten more complicated in recent years because of mobile devices. If you want to go with the most native solution, you have to use Swift for iOS, or Java for Android. Neither choice allows you to port to another platform. Microsoft recently bought Xamarin's C#-based system that allows building apps that run on Windows, Android, or iOS. I believe there's some money involved to buy that system though.
 

·
Registered
Joined
·
5,785 Posts
Discussion Starter #14
Yes i have looked at their work, also a fellow named Stef from Europe i've been emailing with. So far, no code online. But maybe once mine is up......

If Microsoft bought Xamarin, well that will be interesting. In true MS style will they obsolete it or continue it.
 

·
Registered
Joined
·
3,686 Posts
MS is actually pushing Xamarin's stuff pretty hard to mobile developers. They're integrating their tools with Visual Studio and it will probably become their standard mobile toolkit. They recognize MS lost the Phone OS game a long time ago, and this is their only chance to position C# and .NET as a dominant development platform whether you're on mobile Windows tablets or Android or iOS.

So you should probably stick with C#. Really the hard work is in the algorithms and methods you're perfecting. The language is almost irrelevant. Code can be ported/translated later if the need arises. The only recommendation I'd have would be to keep your core logic and algorithms as separate from the UI code as possible. That makes it easier to port to other platforms later (such as Android or iOS). Of course that's easier said than done. I know you're using OpenGL for coverage and overlap detection, and that's fine since OpenGL is somewhat portable on its own.

Yes getting some code out there for others to chew on would be very helpful! I've already learned a lot just from you describing how you're doing things.

As far as bin monitoring goes, that's high on my list of things I want to do and if and when I get something put together I will definitely share like you're doing.
 

·
Registered
Joined
·
5,785 Posts
Discussion Starter #16 (Edited)
Good or bad, here it is.

https://github.com/farmerbriantee/AgOpenGPS

To download, click on the green "Clone or Download" and select "Download ZIP". It will be in your download folder (windows).

Installation isn't required, just unzip and run it right from the directory. It will create a fields directory in your MyDocuments and the setting file is created in AppData\Low\AgOpenGPS\

It will say COM99 doesn't exist and you should change in settings. Hit ok and it will run. Note, it won't do anything till you feed it an NMEA signal containing RMC. Almost any antenna/GPS receiver will work, just pick the right com port and baud rate. set the Hz to however fast the update is.

Source code is in the Source directory, obviously. Enjoy.
 

·
Registered
Joined
·
291 Posts
Very interesting. Shouldn't have dropped computer programming at college. So if some smart farmers can collaborate and build their own gps systems. Wow. This is just like farmers building their own farm equipment except here cash out is little and the welding rods are lines of code and algorithms.
 

·
Registered
Joined
·
3,686 Posts
I've downloaded a copy to play with here. Interestingly, it seems to run under Wine on Linux. Even without installing the official .NET runtime. I am going to set up a dummy gps feed to give it and see how that works. I'll post and let you know.

I tried it under Mono, but it's not working, but I didn't have time to investigate why.
 

·
Registered
Joined
·
5,785 Posts
Discussion Starter #20
I've downloaded a copy to play with here. Interestingly, it seems to run under Wine on Linux. Even without installing the official .NET runtime. I am going to set up a dummy gps feed to give it and see how that works. I'll post and let you know.

I tried it under Mono, but it's not working, but I didn't have time to investigate why.
Hey that's awesome. I stuck to OpenGL version 2.1 so yes Wine should be ok. Hopefully the serial ports work, if not, i know who has the source code. all it really needs is a RMC string to work.

Really cool if it fully works under Linux. Thx Torriem!
 
1 - 20 of 4139 Posts
Top