Big picture thinking about implements and integration

Hi,

So I’ll start off by saying the theoretical is insanely cheap.

I’ve been thinking a lot about implement integration and AOG. I’ve also been thinking about documentation and other things that are available in the commercial world. One of the things that I see lacking in AOG is separation of the implement controls from the Tractor controls. I realize I might be out of the loop in regards to the latest updates in the section control boards and whatnot, but I just want to get these ideas out there for pondering.

One thing that I see in the commercial world is the ISOBus VT. It makes sense on so many levels that I think it is one of the great advancements in ag in the past 20 years. I’m used to the Deere ecosystem at work and the implement can auto-populate certain fields in the documentation and guidance pages in the Deere displays. I’ll use the aircart that I’ve been running as an example. The cart has it’s own tool width setup and that changes the working width in the display for mapping. Under documentation, it auto-populates the rates for the front and rear tanks. There is a defined line between tractor and cart, but it isn’t a strait line. (ie. there are functions that go beyond just displaying a terminal)

I realize if ISOBus was this open loving community that wants to foster open source projects that this post wouldn’t be necessary by now, but I digress. I think striving to work with ISOBus implements is a good goal to have in mind, but for the home gamer, it isn’t practical to try and make their old equipment ISOBus compatible while also interfacing with a program that isn’t yet ISOBus compatible. All this to say that AOG should likely strike out on it’s own to make a “universal bus”.

Yes, I’ve seen this comic: https://imgs.xkcd.com/comics/standards.png

Perhaps an ethernet interface with UDP would be the best (I’ve seen multiple people post projects using UDP for their steering setups, so it seems to work well on tractors) or some form of Canbus where we define our own PGNs. I’m not trying to say that any one solution is easy, they all require work. I just see the ability to have consensus around an idea in advance of it’s development might benefit the development of said idea.

Sorry if this is a bit rambling, but it’s a complex mess of thoughts I’ve been having that I’ve wanted to post here for a while. I hope this is appreciated and I am so excited that a project like this even exists. :slight_smile:
Cheers,
Harrison

3 Likes

I quite like this idea but I don’t really know anything about how these things work so I’ll just say its sounds cool

After a nap and some digestion of the thoughts I’ll rephrase my dilemma this way. I’d like to add electronic functionality to older equipment kicking about, and I have to learn what I’m going to do from scratch. I don’t mind learning something to find out it’s a dead end, so I’m not looking for a golden ticket here. What I want to know and discuss is if there is consensus on a digital communications solution that is modular (ie. the computer for the implement lives on the implement and loads when plugged in vs. an application that you install into AOG kinda like a hardware driver in computing) and what said interface will be. If we want to be ISOBus compliant and all that goes with it, then I’ll look into embedded systems and VT designers. If it’s over ethernet I’ll look into HTML based interfaces. If it’s with smoke signals I’ll make a blanket :slight_smile:

I’m very open to learning, but I do have limitations on my time (as do we all it seems) and I want to make use of my time most effectively to advance AOG.

Cheers,
Harrison

1 Like

Yeah I really love the idea but as I’m not technowizard idek if it’s even possible

A post was split to a new topic: Implementation of Isobus with IsoAgLib