Winter has arrived

What is the Drive version you all are talking about?

@BrianTee_Admin, just in case you feel like AOG is deadweight, don’t give up. A few farmers around me have an interest in AOG, and want me to pursue helping out with AOG on a paid basis.

This winter I hope to come up with some streamlined PCB’s for the AOG system I have going already. If I didn’t mention before, I design and manufacture embedded systems and PCB’s for a living. Algorithms and math fascinate me to no end. Sadly, so far I haven’t had the time to really dig into the AOG software. Not that there is an outstanding problem, but the geek in my would like to figure it out.

4 Likes

Glad to see you back. I’m using the code you wrote for danfoss valves. I believe Brian is going to implement that code into future versions of AOG. If there is anything helpful you can add to help him, I think all danfoss guys would be very thankful. Also I have switched to cytron md13s driver from ibt2, and had to max output and proportional to 165 to get fast enough movement. Going to try this module to see if it helps.
Screenshot_20201213-092900_Chrome
It has been suggested that the cytron filter may be different, and being danfoss uses analog input, maybe something with little or no filtering might work better. Any thoughts or suggestions ?

1 Like

Not giving up, Drive is just a lot easier to test/design basics in without all the “other” features.

I couldnt agree with you more!
I just found this project a couple weeks ago and I have been hard at work trying to learn everything there is to learn, but it is a STEEP curve. lol so many in’s and out’s as well as all the components and what they do. That on top of all the diy that the farmer needs to figure out for each tractor, (turning motor, sensors, communication etc).
side story: back in 2016 I got interested in FPV drones, and at the time it was still a young open source project (cleanflight, betaflight, INAV), but in just a couple years some of the biggest improvements was in the hardware. they started to produce parts that were made for the FPV drones and it help make the barrier to entry smaller. that helps gets more people involved and more people interested in forking off the project.
so if there was a Base hardware that was simple and effective it would help improve the entire project.
Thanks

5 Likes

It is a common affliction with most open source projects - the documentation. We all want to improve the code and the knowledge base not only keeps changing but rarely gets written in the first place. It does, as you say, make entry into the project, STEEP !!

4 Likes

Brian,

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.

[Edit: Here’s the video we made: AgOpenGPS | Grundlagen für den Einstieg - YouTube]

Thank you for starting such a cool project!
image

15 Likes

Great video congratulations Andy,

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.

3 Likes

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.

1 Like

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.

2 Likes

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.

See my update PID for Danfoss proportional valve

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

Hi Brian,

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?

3 Likes

VR… The posibilities…

Is there a github to test DRIVE?

getting close!! i’m really frustrated with it right now lol.

Whats the latest Brian? Still having issues with delay / lag that you said about?

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.

2 Likes

@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 just grabs everything and sends it to the loopback udp. At that point anything can use any pgn for what ever it wishes, including AOG