Getting back rate control for seeding, fertilizer or spraying (old, removed since code was bad) with an application map (new) to control the rates with a prepared map (kml, shapefile, a bitmap? (how to align?))
7 Likes
Second that…
Added complexity… I can spread different rates left and right side of my fertiliser spinner!
Just curious if rate control is being worked on?
I’m new here but was planning to work on sprayer control this winter for the coming season after having saw the rate control feature in previous versions. I recently downloaded the latest version to start getting familiar with it and discovered its been removed. I’m impressed anyways and plan set up guidance at least.
I have been working on variable rate control. I have a list of changes to AgOpenGPS that I do every time there is a new version. https://github.com/SK21/AOG-Rate-Changes
Also here is the arduino code: GitHub - SK21/AOG_RC: AgOpenGPS with rate control.
9 Likes
Hi, SK21. Is this rate control you have going in your Github working at this point? If I get a board printed up is it likely to stay static for a while?
Really would like to get rate control working with section control, happy to help debug.
I have tested it as much as I can. It is below zero here with snow. I will be testing it on the field in about May.
1 Like
Stupid question but I’m still trying to figure out the electronics and haven’t gone into the control. I imagine this doesn’t do PWM valve control on the individual sections based on turning so the inside section doesn’t spray as fast as the outside?
No, its either on or off.
So I’ve built up a board for your rate control, but I have a couple questions:
-
Using a Nano IOT board, just confirming that I need J7, J8 and J9 jumpered as 1-2?
-
Did you have a template for the cutouts on the switch box? I’d happily PR a 3D printed box up to the github if I make one, which would be a bit easier with a template I could just work from.
-
When connecting J3 on the board to the Sec# portion of J1 on the switch, I need to crossover Sec2 and Sec3 because they’re out of order or is that just a printing error?
Do you have a few pics of your wiring/boards?
Hey that’s great. Yes you need to jumper 4 spots J6,J7,J8 and J9 to 1-2 for the Nano33. I don’t have a template for the cutouts. I used an extra switch pcb to mark the holes in the lid. Those two wires need to crossover. I don’t remember why I made it like that. It is labeled correctly.
Here are some pics:
https://github.com/SK21/AOG-Rate-Changes/tree/master/Controlbox
For the original Nano I had to disconnect the LED because it interfered with reading the rate down button. I just burnt it with the soldering iron.
I don’t know about the wifi connect issue with the Nano33. About a month ago I was trying it out and having a lot of disconnects. Then it wouldn’t reconnect. I am running tests on it now and I can’t replicate the problem. It stays connected. I have the router signal at minimum and if you hold your thumb over the nano33 it will disconnect. Remove your thumb and it reconnects right away. Hopefully it keeps working.
Right now the version on github v4 is what will be released. Would you like to add the rate code one last time? Then we can release the existing without it but continue to build for the future and have your rate in v4.1 once you test this spring to make sure it all works as planned.
Ok, I’ll add it to the latest version. A lot of testing will be good. Any suggestions on changes/errors are welcome.
1 Like
Great! When that is done i’ll add back the VR and then see if we can tie it all together as well
1 Like
When I think about rate control or application maps, I am wondering, if it might be better to separate this from AOG. To a new app running besides AOG. This would give flexibility and avoid increasing complexity in AOG. AOG and a Rate Control App (RCA) could comunicate via UDP. What have to be exchanged? Positions of sections to the RCA and rates to AOG. Might be all nonsense, because I haven’t enough knowing to estimate it - I hope to a little bit discussion. Surely it is cheaper to add the rate control code from SK21 to AOG, but maybe this code can also be the starting point of a new app?
I really like the way SK21 has incorporated the single button interface to rate. All the code in the background hides it all to the user and is non intrusive if you don’t use rate. I often think about 2 apps, but once you take everything into account, it never is easier and usually 3x as hard
This could be an area where a well-defined and robust plugin system could be of use. Ultimately variable rate depends on a predefined map that’s essentially a two-dimensional lookup system. A plugin could act on position updates from the main part of AOG, and return data (a simple number in this case) to AOG. Plugins could also add buttons to the GUI and expose their own settings that way.
But yeah that’s complex.
ISOBUS architecture is sort of analogous to the 2nd program idea. The variable rate task controller provides rate information on the bus independent of the other controllers, the mapping, etc. I guess if we’re not careful we’ll end up re-implementing the complexity that is ISOBUS. haha.
1 Like
Hi SK21,
the lastest code for SC/switches is almost done. I hope the problem with the connection loss of Nano33iot is solved, so I’ll get it done by this week. The “normal” nano code was V4 updated yesterday, the rate stuff I didn’t touch. If it should be changed feel free to do so.
So when thinking about VR with multiple independent rates, the communication AOG-RC and back should be changed. Best might be to define new PGN sentences and keep the rage for transfered data wide enough. There were complains about to less range for l/min, see combine forum.
Another thing I can’t say anything about is the Rate control in stand alone mode (spraying with no AOG), which is possible using the switches. There we should also have a concept (using last PWM setting and let user adust by +/- buttons or whatever).
Just my 2ct.
greetings Matthias
1 Like
A plugin system is probably the best way to add new features like rate control or the Open Grade functions or the tree planter functions or what-ever else. It could be a goal to be implemented.
A lot of great ideas. The Nano33 connection problem will have to be tried in the field to know if it is reliable. I looked at your code for the Nano. The comm part is mostly the same. I could write some code so it will communicate with AOG. There are a few differences. I don’t have left and right rate control. I only have 8 relays for now. Maybe a good way to do more is have slave pcbs to handle extra relays. They could communicate with the main rate controller pcb. The slave pcb could be just a copy of the main with different code in the nano.
What kind of data would VR need? For one rate setting across the applicator just the same comm would work. For multiple rate settings it would be a lot more complex.
The stand alone mode could work with a web page from the Nano33 or just with a pressure gauge on the applicator to give you some idea of your rate.
SK21, i’ve made an attempt at plugin/alternate app and come up with socket based in loopback for communication to your own app. It works really well. Do you think this is a better solution overall for rate?
I have the feeling this is the way to go (now that you have probably added all the code) These are 2 completely different exe run at the same time with rateapp listening to the pgn’s from AOG
1 Like