AgOpenGPS v7

[richardklasens]

How do we continue?
Let’s talk here and speak for yourself about your ideas how the future will look like for AgOpenGPS.

[FantasyTeddy]

Maybe let me try to give a quick overview of what happened so far.

Cross-platform

One idea that has been around, was to get AgOpenGPS to run under some other operating system than Windows.
There are projects out there that are already doing that, like QtAgOpenGPS (A C++ port of AgOpenGPS using Qt) but many people would prefer to have the application in C# because it seems to be easier to maintain.

I originally posted a Potential Roadmap for AgOpenGPS in the Discourse forum, that basically outlined how it would potentially be possible to transition AgOpenGPS from the current WinForms implementation to a more modern cross-platform Avalonia UI version.
That roadmap was then followed for some time by me and @J005t67 to get some of the separation of the business logic from the UI.

However, as it turned out it was much more work than anticipated, to get that separation where it needs to be.
Progress was slow and neither of us was able to put in the amount of work required to really get this done.

AOG_Dev

Basically at the same time, @farmerbriantee and @P00qwerty started working on AOG_Dev, which aimed to fix some of the more fundamental problems in AgOpenGPS. That version of AgOpenGPS (or AOG) originated from an "older" version of AgOpenGPS and therefore differed quite a bit from the latest state of AgOpenGPS itself.

The Questions

Based on that history, there are a few questions that emerged:

• Should work continue with creating a cross-platform AgOpenGPS version?
• What about the fundamental issues that AOG_Dev tried to fix?
• How can we align our efforts, in order to minimize work being done twice?

[Xyntexx]

In my opinion doing a jump to AOG_Dev code and dealing with the coding required to make it compatible with current ecosystems and the following extensive testing that everything works might be a too big of a task. During that task there would not be any updates to AgOpenGPS and the work already done after the branch needs to be transferred too.

Instead it would be better to do incremental changes where lessons, features, and improvements from AOG_Dev are taken and applied to AgOpenGPS piece by piece while simultaneously improving the code base, keeping the project alive, compatible, and rolling. Even though slower and the total work might be higher.

What do you think?

[Xyntexx]

One step towards that cross-platform goodness is migrating to .NET8/9 which is in progress.

[Pat-I]

AOG_dev is a huge project from @farmerbriantee and @P00qwerty. It is already usable. It has some huge improvements in the logic apparently. But no one else already looked exactly how easy (or hard) it would be to migrate these improvements

If we jump to AOG_dev, then AgopenGPS would have only fix updates, (or at least everyone willing to do PRs will know it's end of life)

[mirh]

Cross-platform really feels like a non-issue honestly. You can run AOG in wine just good.
Ironically going higher than 4.8 would kill windows 7/8 pcs (which I'd like to remind, could even be a 2016 tablet that you decided was too slowed down by W10).

If any the only thing that could trully make it worth, is if you could get android supported.

[benreu]

Adding the improvements learned in AOG_dev to AgOpenGPS might be best, since otherwise the jump might so large as to be almost impossible by those less knowledgeable (including me). I have not tried AOG_dev so far because it got released during the farming season, and I am working on other improvements that are not done yet.

[FantasyTeddy]

I also think it would be a shame to not at least consider AOG_Dev going forward (in whatever way suitable).
@farmerbriantee: Would you consider making the repository accessible again?

[WildBuckwheat]

On the topic of Should work continue with creating a cross-platform AgOpenGPS version?

It is my opinion that

• AgOpenGPS does not need to execute across platforms
• There is enough confusion already running AgOpenGPS in windows with firewall rules, registry edits, network settings, etc. Imagine the same amount of support for other OS's
• People will experience many roadblocks trying to use $80 Aliexpress Android tablets, 12 year old used tablets purchased locally, etc. Those people will experience various roadblocks that will either waste their money or result in them giving up on the project all together
• How will we connect? Wifi or USB to ethernet adapter? Neither are good options.

The only real tangible benefit of multi-OS is, in my opinion, the ability to use cheap Android tablets as a display. I think we can realize that benefit with an alternate approach: run AgOpenGPS on an SBC and have the UI be through a web browser.

Running AgOpenGPS on an SBC with web browser control has various benefits

• One OS, the best OS, Linux
• The hardware capabilities are controlled. "Run it on a Pi, at least a 3b, anything else and you're on your own"
• Ethernet supports existing steer boards
• Existing users can continue to use their Windows tablets, new users can use whatever.
• Second screen support
• Phone support and headless capability (once setup). Straight AB doesn't need a screen all day
• Very low screen processing requirements, no overheating android tablets

Again, it my opinion that AgOpenGPS does NOT need multi OS support. Keep it in Windows. And if the OS were to change, it should be to Linux on an SBC.

[hagre]

The end of windows 10 support will force us with old hardware to use Linux, so I think and hope that's included on the way ahead of AgOpenGPS. If wine Is the solution to use Linux, that is usable for me, but to assist the development, compiling under Linux would be preferred.

[richardklasens]

I thought some time about how to continue.. I think the best we can do.. split the UI from the business logic.. it gives at least the opportunity to get a more stable program and we can discuss about another front end as well.. maybe webbased is one of those things.

So… to me:
Get the issues fixed.. and please test your ass off this program (6.8.0.beta.X) like @WildBuckwheat did last days.. this is sooo helpfull. Personally I don’t care if it take one more month or so.. do it good or go home :)

[WildBuckwheat]

I believe a key thing that should be answered and understood by all is a Yes or No answer to the question below

Can the goodness of AOG_DEV be added to AgOpenGPS?

I was under the impression that the answer is No. AgOpenGPS has fundamental flaws that cannot be fixed by adding to. Remove the flaws and there is not much left. Yet I see others suggesting this as a path forward.

@farmerbriantee Can you weigh in on this?

[richardklasens]

Offcourse! No doubt about that. @farmerbriantee did a very good job about some fundamentals. It would be a loss if it would be forgotten

[FantasyTeddy]

Please also consider that we do not have unlimited manpower to develop that next version of AgOpenGPS.

Even though I would love to see a fully Linux compatible web-frontend solution, I am not sure that is going to happen (even with the help of AI).
I am looking forward to being proven wrong, however :)

I think we should stick with some of the more realistic options, like continuing to improve AgOpenGPS by separating front-end from back-end logic, or bringing the ideas from AOG_Dev into AgOpenGPS (or even replacing the current version of AgOpenGPS with AOG_Dev).

[Pat-I]

V7 means making breaking changes I think? Else It would just stay V6
Some changes have been done in AOG_Dev, but I think either we should cherry pick from it, or use it and do some more changes

Things that are already in AOG_dev:

• Like jobs (or should be called task?)
• It also changes how profiles are saved (but does it need to change?)
• Implement steering
• One product rate control (not necessary, there already an app)
• Complete new track calculation
• Maybe completely different workflow for less latency?
• New way to do section control?

Things that should (or could) be added that are not in AgOpenGPS or AOG_dev and that will also be breaking changes:

• A big cleanup in the PGNs, especially the machine PGNs,
• Some passive tool steering, with and without implement antenna
• If tasks (or jobs) are added, probably it should also be coded to have the ability to record more layers.(This would need more discution, most likely every extra layer would be drawn from a PGN bringing data for a specific pt (coordinate) either for the whole tool width or for each section)

What should be the release timeline for v7? Is there any rush? Could be in a year or more I guess?
AgOpenGPS v6 works pretty well

Using AOG_dev (moving it in AgOpenGPS official) and playing with, looking the code for a period of time (with some PRs) seems a good option to me. Then we would see what could be improved for a release, or if it should be abandoned and AgopenGPS should be used, incorporating some AOG_dev features.

Would it be in a different repository?

I guess very few people already have gone though the whole AGO_dev code?

[Davidwedel]

On aog_dev, the separate vehicle/implement profiles are very nice. And builtin rate control can only be an improvement over the user having to juggle another application. Oh and aog_dev Agio has builtin GPS out over serial-again, one less app.

I've hesitated to share my opinions on where to go from here since I don't have the time/knowledge to implement it, but seems to me the first step is to get down to one codebase with all the features. Then make the cross platform decision.

And on going cross platform, is seems there's a lot of interest when we consider that it's been talked about since '21 and there's two side projects that were/are trying to do just that. @P00qwerty had or has an AgOpenGPS android dev version.

If everyone combined forces the end result would get farther than everyone heading in their own direction.

[Xyntexx]

If we decide to continue with AgOpenGPS rather than migrating to AOG_Dev, I suggest the following approach:

1. Document features - List future features with descriptions and clear user benefits
2. Identify technical requirements - Document the technical improvements needed to implement these features
3. Select and prorotize - Select what's most important features for v7
4. Build a roadmap - Develop a clear development plan based on the selected features and technical requirements

For me, the purpose and benefits of some AOG_Dev features aren't clear, and I suspect some others may feel the same. Documenting features with clear descriptions would help ensure everyone understands what we're building and why.

How to do this in practice? Good question 😄
Maybe add an "AgOpenGPS v7 [WIP]" milestone and start adding features and technical improvements that you think should be part of v7.

What do you think?

[richardklasens]

What if we start from scratch…
It doesn’t have to finished in 2 months…

[lansalot]

This is an idea I'd floated in telegram channel - as you say, there's no rush at all. Realistically, how much code would be in a suitable state to lift-and-shift to a new program? Hopefully quite a lot, between aog_dev and the refactored code from agopengps.

As Brian says below, creating a software requirements specification is worthwhile, and that may guide us to cherry-picking what works from existing codebases.

[FantasyTeddy]

I am not at all against doing a complete rewrite and I think if we are going that route, it is important that we don't do it behind closed doors.

One important note would be, that even if we are going to abandon the current AgOpenGPS implementation, it should still be supported until the rewritten software is available to use by everyone.

That said, I think we should still think about the next steps for AgOpenGPS, because we cannot predict how much time it will take to develop the rewrite. And I think it is important to still have a version that is actively maintained in the mean time.

[farmerbriantee]

Adding more code to AgOpenGPS isn't the answer. It's time to put the programming keyboard down and create an SRS.

[richardklasens]

I made some Claude MD's to implement the Guidance classes and single trackfile class from AOG_Dev to AgOpenGPS. The plan is based to make it even better code-base wise. Especially by looking into the performance of the guidance control.
Guidance_CodeBase_Comparison.md
Guidance_Refactoring_Plan.md

[richardklasens]

I should say that i'm not actually planning to add this to AgOpenGPS. But if we take these kind of MD's and create an SRS from that, a Start-From-Scrath-based-on-what-we-have-now is something to consider

[double07killor]

Hey everyone,

I’ve been following the discussion and wanted to throw something a little different into the mix.

Over the past few evenings (maybe ~18 hours total after coming in from farming), I started drafting a new experimental branch of AOG that I’m calling AgOpenGPS-Nexus. It’s basically an experiment to see just how far we can push things with modern architecture and AI-assisted development — both in design and implementation.

I started with a full SRS (drafted with some help from AI and my own background in systems engineering and software dev), and have since been moving into ADRs and source code generation. The SRS itself is already a bit behind, but the ADRs are rolling fast and Codex bots are chewing through the code layer by layer.

The core idea behind Nexus is:

Native Linux SBC first (think CM5-based AIOs), with Windows supported out of the box.

Eventually, the same UI stack (written in .NET 8 + Avalonia) should be portable to Android and iOS — so your phone or tablet could act as a companion app, or even run simple field tasks standalone.

Completely modular architecture. Even mapping is a plugin.

gRPC for all inter-service communication between AgIO, Core, Frontend, and plugins.

AOG-Link (based on nanopb) handles MCU-side communication, running over Ethernet, RS-485, CAN, or serial, and bridges seamlessly back to the legacy PGN world.

If you want to dig deeper, this doc explains the differences from legacy V6 to the Nexus stack:
Legacy-V6-vs-Dev.md

And here’s the living ADR roadmap that guides how each subsystem is being redefined:
ADR-roadmap.md

This whole thing is very much an experiment — not something the community should feel obligated to rally behind yet. But if it pans out, it could really open the door for some cool new directions in AOG’s future — lighter cores, modular plugins, and native support across everything from tractors to tablets.

Always open to feedback on the ADRs, architecture, or just general thoughts on where this could go.

Cheers,
Jon (Fortney Engineering)

[Xyntexx]

Hi Jon!

Nice work so far.

I've been hesitant about a complete rewrite since that's usually how community projects die. But in this age of AI I might need to reconsider.

This looks like the future of AgOpenGPS and I'm happy to contribute in any way needed.

[double07killor]

Yeah, I totally get your point about full rewrites - they’ve killed plenty of great community projects before. Honestly, though, I think the current architecture has been doing the same thing in slow motion. Stuff like planter monitoring, for example, got left behind not because no one cared, but because there wasn’t a clean way to integrate or maintain it.

If I had to sum up the difference between v6/dev and Nexus, it’s really the meaning of the word itself — “a connected group or series.” The goal is to break as much as possible into independent, well-defined pieces. It does make organization a bit more complex, but in my experience (I build almost everything this way, even closed-source work), it actually makes development and maintenance easier in the long run. Updating or even completely rewriting one module doesn’t break the rest of the system.

This architecture should also make it much easier for all the “side projects” to finally have a home — things like rate control, Android compatibility, the Avalonia rebase, AOG-Dev etc that currently live as basically entirely different programs what dont work with AOG at all, could simply exist as plugins or replacement modules. Users could run the standard stack as-is, or easily swap out any layer for another implementation. Want a totally different front end? Fine — build it in a separate repo, install the same AgIO, Core, and plugin stack, and just use your UI instead of the “official” one.

The same goes for alternate OS support, experimental modules, or new communication layers — as long as it speaks cGCP, it’s part of the club. And just to clarify, cGCP is built directly on top of gRPC under the hood, so anything that already talks gRPC can plug right in with minimal effort.

That’s also why I’m not asking the community to put effort into this yet — I want to see if I can make it viable first. It’s one thing for me to waste my own time, but I don’t want to waste anyone else’s. Once things are working and stable, I’d love to see the community “adopt a highway,” so to speak — individual plugins or subsystems can easily move to their own repos and have separate maintainers or teams improving them independently.

Here’s the current draft of the Official Plugin Dependency Map (basically the ones packaged with AOG-Nexus by default — community plugins will be totally open-ended):
nexus-plugin-dependency-map.md

On the communications side — what the AI dubbed cGCP (core GPS Communications Protocol) can be thought of as PGN v2, but much more powerful. The modular ecosystem really demanded something more robust, so cGCP runs internally across the entire AOG stack — connecting AgIO, Core, UI, and plugins. It doesn’t talk directly to the MCUs.

From there, the same messages get wrapped into AOG-Link, which is essentially cGCP packaged for microcontrollers. It handles communication out to submodules (AIOs, rate controllers, section modules, etc.), just like PGNs do now. I considered staying with the existing PGN setup, but it felt like tying one hand behind my back for not much gain. Having the same protocol inside and out makes it a lot easier to keep things consistent — and gives the MCUs access to any data they might want.

There’s also a full bridge back to the legacy PGN system, so existing hardware and firmware will just plug in and talk normally — the bridge simply translates between PGNs and cGCP, which is easy since the data structures are already quite similar.

The repo’s fully public, so people can fork it if they want — just be warned it’s moving fast (50+ commits a day sometimes 😅). The best place to help right now would be reviewing or giving feedback on the ADRs, since those are what drive everything the AI is building from. Garbage in, garbage out — so nailing the ADRs early is critical.

At the pace the AI is hammering away, I wouldn’t be surprised if something “viable” (at least in prototype form) is up and running within a couple weeks. It’ll just depend on how much cleanup and fine-tuning it needs after the first pass.

If anyone wants to chat about ADRs or the overall architecture, reach out however’s easiest; PRs on docs are fine too, but with the rate I'm having AI create PR's and rewrite stuff, its probably best to talk through anything directly.

[richardklasens]

Since its 100% all about performance and timing in a guidance project, have you any analyzing done on the performance and speed to do a full guidance loop with an incoming GNSS sentence at 10 or 20hz?

[richardklasens]

Based on the last messages here.. the bot can do a lot for us, as in 80% of code. The biggest fear I have.. how do we maintain is? If you pick AgOpenGPS and let the bot do small precies of fundamental rewrites of the code. We can go to a MVVM project pretty quickly with the fundamental problems solved and keep releasing so people test and use it. It’s kind of start from scratch but multiple devs can work together using bots to do it. When the UI is fully uncoupled and all the business logic is working good, fast, with good layed out code bases.. we only need to build a new UI. To me that’s the last part. But we can keep throwing out releases from time to time without loosing functions and the whole community keeps working with it..

[FantasyTeddy]

I think we could also do both:

• Let's see where the Nexus project from @double07killor is going (which looks very promising in my opinion and I'm looking forward to a functional version).
• Continue working on the current version of AgOpenGPS, as if there was no alternative. That way we have a fallback option if the Nexus project (or any other new-built solution) fails.

If the Nexus project is succesful and ready to replace AgOpenGPS, we can still do that in the future.

[double07killor]

howdy... for now just figure theres a 1% chance of nexus succeeding from a source code standpoint and a 99% chance of it failing,

at least the first go of it...

The bigger question is can the SRS/ADR succeed from any method of development? I think the answer is yes, I tried to write the ADR/SRS to be the very best version of AOG possible... and I'm making an experiment at having a 100% AI workforce develop it... I have no idea how well the second half is going to work, but I think the first half is the important part for now... there can be other efforts to make source code out of it later if this experiment fails (I'll certainly be trying again if it does)

I think even if the source code effort succeeds theres a decent chance that we as a community decide to change enough in the ADR that I simply scrape the existing source code and have AI try again with the new inputs...

[Xyntexx]

I agree. Since we are not switching to Nexus any time soon, we should continue development with the current version of AgOpenGPS. And if we do the MVVM and switch to Avalonia, we could even copy the UI to Nexus.

I thought that running integration tests in the simulator would be impossible with the current codebase, but I gave it a go and got it working. Now I think that these, and unit tests are something we should invest in before making big changes, so we can ensure the quality of the software.

[J005t67]

I see a lot of important and high level discussions going on currently.

Nevertheless, I want to share (at class level) what I was doing during my refactoring work.
I think it is important to get these improvements right in the future versions of AgOpenGPS

This is a small overview of the things I started refactoring in AgOpenGps:

GeoCoord, GeoDelta and GeoDir
Currently the project AgOpenGps alone contains more than 1200 + 1200 code lines that read or set the individual easting
and northing parts of vec2 or vec3. More than 700 + 700 out of these line are actually cacluating and assigning to easting and northing, and a few hundreds lines need cosines or sinus to do so.
Especially the expressions with cosines and sines are hard to read:

• sometimes the cosines and sines switch places to account for a 90 degree angle;
• sometimes one or more signs are changed to mirror or rotate 180 something.
  The project AgOpenGps itself is about 12000 lines. So it seems that 20% of AgOpenGPS is manipulating parts of vec2 and vec3!
  With the new structs GeoCoord, GeoDelta and GeoDir, there is no need anymore to struggle with the individual northing and easting parts. Also we wouldn't need to stare at the cosines and sines when we try to solve a bug.

GeoPath, GeoPolygon
On top of the more low-level classes GeoCoord etc, I implemented a few classes for paths and polygons, that are a nice starting point for easy implementation of curves, tramlines and boundaries, etc. These classes will also help to reduce the amount of duplicate code (for example for computing aera's.)

Field aspects
I like to use the term 'Field aspects' for field specific things like Boundaries, TramLines, BingMaps, WorkedArea, ABLines etc.
I already prepared most new classes for these field aspects. (Typically these new classes make good use of the classes mentioned above.)
I also prepared the corresponding classes (subclasses of AspectStreamer) for saving and loading the field aspects . The various AspectStreamers make efficient use of the new classes GeoStreamReader and GeoStreamWriter. GeoStreamReader and GeoStreamWriter are subclasses of StreamReader and StreamWriter and add some basic functionality for reading and writing (lists of) GeoCoord's, etc. As a result the various AspectStreamer classes do not need much code to do their job.

Field class
All new field aspect classes are nicely grouped together in the new class Field. This also means that the various code parts that select or import fields, can simply return a new Field instance in the future, (and do not need a dependency to FormGPS to poke around in the field aspect variables there).

OpenGlWrapper GLW
Currently the project AgOpenGPS still contains almost 1500 direct calls to one of the functions of the OpenTK toolKit. This might become a problem if it turns out that we need to switch to a different OpenGL toolkit in the future. I started writing a thin wrapper layer on top of the current OpenTK toolkit to address this. Currently it contains functions for drawing OpenGL primitives and two Texture related classes, which I find very helpfull. All texture related code is already using the new texture classes and by now the number of direct calls to OpenTK has already gone down from about 1800 to 1500. Future version of the wrapper could also implement some sort of OpenGL error checking to make AgOpenGPS more easy to debug.

MVVM pattern
I already implemented the foundation for the MVVM pattern in AgOpenGPS. The base classes ViewModel and RelayCommand are already there. The contours of the overall structure are already emerging: ApplicationViewModel is the top of the pyramid of all ViewModels and MainWindow.xaml is the top of the pyramid of all views in the WpfApplication (that I wrote for testing only.). All Views and ViewModels are nicely separated in the code and only bound together runtime using databinding. All ViewModel classes must derive from DayNightAndUnitsViewModel, to make sure that the settings for Day/Night and Metric/Imperial are propagated to all ViewModels.
Surprisingly, (to me at least), it turns out that WinForms also support DataBinding and can bind to the same ViewModels that would be used for either WPF or Avalonia. (It would be good to prepare and finish a few pull request that show this.)
So, if we want, we can do al lot of MVVM related improvements already without abondoning WinForms yet. For example:
⦁ better separation between UI and the rest of the app.
⦁ split FormGps.cs and FormConfig in manageble ViewModels and Views