When I started setting up AOG, it was like jumping in at the deep end. My first highlight was when I got my PCBs shipped from China. - Few weeks before, I had no idea what a PCB was nor that it would make the installation so much easier compared to wiring as I had done in earlier projects.
Later, after soldering the PCB and connecting it to Motor + WAS and connecting the arduino to my notebook, I moved the WAS and … THE MOTOR MOVED! I will never forget that moment. It was one of many great experiences during my AOG adventure. I’ve learnt so much and continue doing so.
Since AOG is running on my first tractor, I use it for every possible task on the field.
When I called the government-owned RTK correction service in order to get the correction signal from their network, it seemed like I was the first farmer here doing so. The signal is quite expensive here. But now, Swiss politicians start to realize that precision farming is the way to move forward, and it seems like they are going to follow the example of Germany and Austria who provide free RTK correction service for their farmers. This will definitely pave the way for more AOG users in Switzerland. Both AOG and free RTK-correction services help farmers emancipate themselves. I am so glad I have the possibility to use precision farming tools that are transparent, open to modify, and that allow full control of what happens with data.
There’s so much going on in agriculture at the moment - I’m extremely happy to be part of this movement. Next year, I’m going to write my Bachelors thesis (Agricultural Sciences). I convinced my Professor to include AgOpenGPS into it. It has yet to be decided, in which form. But I might be able to contribute something and help improve AgOpenGPS.
My brother who is a professional video maker suggested to shoot a video in order to provide an overview of the PCB V2 based AOG hardware and the main software features. I was helped a lot by video tutorials when I started building AOG but was missing one which gave an overview of how all fits together and how a basic setup of AOG looks like. This might help make the entry less steep, especially for Swiss users. In addition, I’m thinking of a workshop for Swiss AOG beginners in which we’ll assemble the core parts of AOG together as a group.
As I come originally from Switzerland and now farm in SK Canada, I think especially for the smaller farms in Switzerland this open source application makes a lot of sense. You can’t spend $30K for a GPS on a 20ha operation but doing it yourself it would be 10% for a full blown RTK system and then suddenly it makes sense.
Keep coming with your videos it will help alot of people.
Thanks Marcus! It is exactly as you say for our operation. I never imagined having RTK guidance before getting to know AgOpenGPS. With the future version being simpler to set up and Andreas Ortner selling ready-to-install PCBs, many more farmers here will start using it.
Thank you Andi - beautiful video! This is one of the main reasons I started the project - to take the magic out of the magic black box. Really looking forward to what you come up with. Integration somehow into google earth would be cool, shape files, VR, many things. Antennas that correct for roll with built in imu would be a great project as well. Plenty to think about.
Danfoss ino is no longer a priority being the number of danfoss users is low and Brian is literally juggling dozens of other improvements. I tried to modify the code you wrote, to work with 4.3.10, but I haven’t been able to get pwm out to md13s via pwm1.
Though the numbers are low compared to phigits and solenoid guy, there are still quit a lot danfoss valves. Would you be willing to look at adding danfoss to 4.3.10. Brian agrees we shout make a danfoss only ino.
Yes, that is the code I am using with 4.1.12 and cytron driver. It works well, but not in the latest version. I have modified it but am missing something, as i said i get no pwm out
.I read your reply that you are working on a complete board with esp and ino. Sounds promising, cant wait to try it. Thanks
To make the program more modular. So it is easier to maintain, test and expand. It might be a good idea to restructure it so it manages the single responsibility better. And maybe some Seperation of Concern pattern like Model View Presenter
Maybe there are some other experienced C# developers here? Who can give their opinion?
Well, i’m trying to get the pivot to follow the line, even though i’m using the steer axle to position. It is proving quite challenging - but that’s the reason for the whole project.
So it end up being an integral of the pivot position error made by the atan of the steer distance over speed plus the error of vehicle heading and ab segment heading, then using the derivative of that to not oversteer when correcting the pivot xte added to the pivot integral which is also the atan of its value over speed.
@BrianTee_Admin will the new AgIO give options as to which PGN’s to send where with UDP? Would be pretty nice to be able to specify individual IP’s to send GPS/Machine/Steer controller etc PGN’s to…rather than just sending everything to broadcast… Reduce network load, and means when you have a network connected tractor like me, you can use everything on the steering system, on the native network, without it sending all the PGNS back across the entire LAN, I currently have it all on a seperate subnet with two ip’s on the ethernet on the tablet, to prevent that, but would be cool if we could specifically choose what goes where…
Maybe a huge ammount of work / not do-able, but just an idea…
AgIO gets data to the peripherals to where they are connected. The loopback network is the conduit between AgIO and AOG sending data back and forth. AgIO transfers data from the loopback and sends it out any connected serial as well as the external udp network
Bit late to this thread but thought I’d add my thanks to Brian for this software.
I’m just getting started getting it all setup and am amazed at its functionality. I run a couple of deere 1800s and Agopengps has all the functionality and way more.
I’ve watched some of the team meetings on YouTube and read a lot of posts regarding documentation. Yes it’s not the best but the resources on here and YouTube will fill the gaps.
Brian mentioned Linus Tovalds running the Linux kernel successfully. That got me thinking that a lot of Linux distros offer a long term support edition and a cutting edge edition. Perhaps that’s one way to help with agopengps. Perhaps lock down a release, PCB design and parts list as a long term variant. Apart from bug fixes, this version isn’t changed and will therefore work with hardware designed. Documentation for that version won’t need changing. It’s probably wishful thinking as no doubt everyone will want to run the shiny new version but if you had that stable long term release it might help those who are happy with what ever features it contains and not needing new ones to easily build a system.
