Kind of a different question but would it be possible to use AOG to control a side-shifting implement, such as a row cultivator(30"rows) or weed burner? I’m sure RTK is accurate enough, but not so sure as to the best way to adapt the code to control a hydraulic shift cylinder, as it does’t “steer” the implement with a WAS. Thought flow was to run a seperate receiver/antenna on the seeder while seeding to record the actual row path, mitigating any drift or trailing errors, then use the recorded path to control a side-shift cultivator to follow the rows precisely. Any thoughts & input?
By the way impressive work by all in making this what it is, and a milestone in opensource ag.
Maybe this would work: WAS set at 2.5 V = center(can also be used to manually control sideshift) PCB and normal hydraulic steering setup to control sideshift, an AOG computer, the GPS antenna on the machine. Now AOG will order sideshift every time Setpoint is different from Actual (look in steer chart). I believe this demands seeding with GPS antenna ON the seeder, else the sidehill drift will influence the position of rows.
That’s what I was thinking, just wasn’t sure if it would work the same because the code is for steering not shifting. Guess I was thinking as the Actual nears/reaches the Setpoint, wouldn’t it return the steering to straight ahead(not accounting for software drift compensation here), therefore canceling the shift just preformed? Already ordering the goodies for the PCB build, guess we’ll see how it goes.
I also interested in hydraulic row cultivator control.
For now I have a couple one with Claas camera, but it is far from perfect.
I think implement should be controlled from the same instance of AOG.
On cultivator we need (I prefer esp32 setup) for path follow:
-esp32 for implement shifting
–in AOG_Autosteer_ESP32 we need a little modifications on PWM part
-md13s for hydraulic valves
-ADS1115 for potentiometer readings
-zed-f9p for coordinates
-second zed-f9p/BNO for roll (I do not think we need heading, maybe wrong, depends of antenna allignment)
On seeder we need for path record (not sure, maybe tractor’s path enough):
-esp32
-zed-f9p for coordinates
-second zed-f9p/BNO for roll (I do not think we need heading, maybe wrong, depends of antenna allignment)
The hardest part (for myself), from AOG we need:
-receive and record real seeder path from separate esp32 (not sure it is needed)
-receive coordinates from cultivator, calculate distance from guidance line and send back.
So minimum needed modification to AOG code is to add separate udp port to receive coordinates from cultivator, calculate distance from guidance line and send back to some another (that autosteer) udp port.
However maybe AOG alone is precise enough for row cultivator(20"rows) and we do not need all of this?
Just for info, I am organic farmer, so no herbicides at all, only row cultivators.
My idea was to use mount the antenna on the seeder frame during planting to record the exact tool path regardless of any drift or trailing errors, then use that saved path for the cultivator control with the antenna again mounted on the toolbar of the implement.
As for tractor control I was just going to run a separate guidance unit for tractor steering, but really isn’t a big focus as it’s an easy solve.
Organic farmer here also, I’m hoping to try my idea out this spring and post the results.
What you mean separate guidance unit - arduino or AgOpenGps unit?
Arduino is not a problem - there are little change on steering logic.
For me AOG is the problem, I am talking about path planner, for me there are many questions about this part.
How AOG can record full path?
How AOG can guide on recorded path?
Is it can be done using single curve line?
What to do with turns?
P.S.: It could be great if Brian write something about this idea.
I guess it would take 2 completely independent systems as the heading of the tractor and its position is of no use to an implement many meters back. I think commercial systems that try that fail. You would have to send the critical info either to another computer on the machine, or, an antenna on tractor and one on the tool and bring all that data into the one computer on the tractor.
This is when interapp takes over getting the info from AOG but yet still fully in communication with all PGN’s and status. I realize most of you haven’t heard of interapp, but if you look at UDP settings, you can see the button to turn it on. Its for a secondary app that uses AOG’s data etc and yet be a completely independent exe.
I firmly believe we have the tech/knowledge/desire to do this. It literally is just another autosteer system with its own position following the same path the tractor does be it abline or abcurve or even a recorded path.
Maybe i sound too optimistic but in engineering it’s called “We solved that problem already”
For a following tractor, tool, or etc, what information would need to be saved and streamed to that secondary tool? Probably want to start a list:
ABref points, ABCurrent, any offsets that may have reset AB, speed, drift, tool width, tool offset, right side, or left side.
Set which tool does all the navigation, then set the slave tool to just follow the leader.
Well really you would just need the line to follow and an on- off. Offset etc would be unique for the tool. Since there is a GPS on the tool, you already have most of what you need
I watched a corn grinding video. The combine was running over here, the truck running over there to be filled. The camera was loading based on the size of the pile in the truck. Now what I thought the truck would need was an accurate current speed from the combine. But a current fix would work just as well. The truck just stays x,y distance away from the combine. Other tools or separate vehicles could do the same. Just set x,y. All else is relative to that x,y. Is that correct?
Besides the AB line the AB curve would also be nice… maybe its the best to send the actual line to follow. This could be an AB line with number XX, an AB curve etc. including offsets.
Another point is the heading. This could be done by fix to fix calculation of the implement gps, but maybe its more accurate to use the heading information from tractor. We need the heading for the decision to move the implement left or right (what actually IS left/right).
So in my opinion we need to send these informations: actual line to follow, heading, on/off.
Yes curve the same way. As far as heading coming in i don’t think that is required at all. The unit would only have to look at distance from the line. “Steering” is only a single vector, meaning it isn’t x and y like a tractor which has a heading and position. The hitch sets the heading and only can move left or right. IT actually is a very simple system with the second order derivative mostly removed. The only term would be derivative and proportional of position, not position and heading.
At last in my head, i could be totally wrong, but mathematically the implement is displayed this way on the screen. There isn’t really an “implement” only an algorithm using a following technique - just like the real thing.
Maybe I am wrong with this…
When the implement only knows its distance to the line and it obviously also knows wich direction (n, w, s, e) the line is, then it has to move there, but to do this it also needs to know wich direction for example the hydaulic cylinder needs to move (“left or right”). So in my opinion the implement needs to know the heading as it knows then which direction to move.
So in my head the tractor moves to the north, the implement follows the line S → N. Now it has the position where it actually is and the position (line) where it should be and calculates the distance/“error”. The mounted hydraulic cylinder could move the implement to the left and right. But the implement doesn’t “know” if left=west/east and right=east/west as this changes every time we take a turn at the end of the field. To get this to know it needs the heading.
Maybe I just wrote a lot of nonsense, but please correct me if I’m wrong
And hopefully my englisch isn’t too bad…
