Oh ok. Yes you could get the heading from fix to fix from implement GPS. But with dual GPS on the tractor it is more stable at low speed or detecting going Reverse.
I think this has run to two separate situations. One with a tractor dragging an implement that needs fine tuned right and left, the other as a separate vehicle to follow at a given, “off my wing tip” kind of function. Seems both would be useful. The “off my wing tip” function could easily be sent an offset recorded path speed and all. Edit: With a time stamp.
Edit2: This video is a simple side shift walk behind that seems to be more of the weed burner option.
Sorry, guys, but I still do not understand why implement need heading.
As I understand heading is just an angle.
I think distance from line(path, curve or AB) is all implement need, it can be positive and negative for left and right.
Also for this precision thing we need roll of implement, not sure if tractor’s roll can be used.
I found that AOG has feature of path recording and following - robot icon.
So main work done, I think.
You can drive the same line in two directions.
Driving the line “up” and the implement is right of the line, we need to shift to the left.
Driving “down” and the implement is right of the line, we need to shift to the right.
Little bit hard to explain.
Ohh, I understand, direction.
But direction is already calculated on the tractor.
Or we talking about situation when implement controlled by separate AOG instance?
Anyway are fix to fix heading not enough for direction?
Yes will be enough. But if we have dual heading in the main aog instance and can send precise heading from dual GPS in two bytes, it would be a shame to not use it 
Otherwise an implement instance could also calculate fix to fix heading.
Well the ab line has a direction, and then the GPS on the implement if moving has a direction. If the GPS heading is opposite to ab line heading, left is right, right is left. Its the same for autosteer, works the same way.
Thing is, the heading of the tractor will always be “wrong” with respect to the implement, especially on AB curve and sidehills
I have seen a SBG system with dual reciever/antenna, one for tractor and the other for implement.
It could follow AB line and had steering discs(with WAS on) on the implement. Both implement and tractor had their own steering controller.
Steering discs were activated by a hydraulic cylinder.
Transferred to AOG you could record seeded path, and then let implement follow that line.
One AOG for tractor and another AOG for implement.
1 Like
So, as I understand, using separate AOG it already done?
Just some tune arduino’s steering part.
Do it needs to recenter implement on turns?
For now I do not understand how to detect turns on arduino(esp32), maybe using uturn byte, but does uturn work with path recording?
And can I pause path recording on turns?
Since udp communication done via broadcast, does there no conflicts in data sources/destinations in single network?
Is it enough to change AOG’s and module’s port?
Can I run second instance of AOG on the same tablet?
Or there can be problem with work directory?
Do the existing implement steering products follow a recorded path? I would assume not.
Those who have implement steering, why not use it every time, also steer the seeder. In that case every run would be the same, the tractor and the implement (seeder and cultivator etc.) would follow the same A-B lines (I bet these applications always use straight A-B lines although contour lines might not make a difference but could be ignored if they introduce any additional complexity).
The outcome would be straight rows to be cultivated with straight lines instead of any wobbling recorded lines.
Perhaps these guys need the system running on headlands too, there contour lines probably. Still it would be two independent AOG systems, one driving the tractor and the second steering the implement. At most a common on/off switch?
2 Likes
There would be some basic row communication required - but mainly when to autosteer, when not to, and what line to follow - essentially exactly what AOG already does.
1 Like
Seeders, like I have, are to big (12m width) for steering and attached by a drawbar.
Since 12m seeders are attached by a drawbar and cultivators are mounted on a hitch (with steering mechanism), not sure does steering on headland is possible.
But if seeder and cultivator have the same mounting type, I think there are no problem, just follow path.
1 Like
So this is missing part of AOG?
There are no PGN with data when to autosteer, when not to.
This is needed at the end of the row to stop steering and recenter.
I think this can be done using MachineControlData’s PGN - Hydraulic Lift and when Hydraulic Lift rised stop steering and make recenter.
Or just use work switch on the cultivator to detect when it is rised.
Implement guidance , you’re completely in a new land. Everything you need, you need to add.
Hi Brian, are you any further on with Implement Guidance ?
Also do you think AOG would steer an implement with a steering axle ( no auto steer on the tractor ,just auto steer on the implement only)
I don’t see why not - except the implement is pulled as opposed to free running like a tractor. But really i think all you need is to correct the distance from line since you really can’t “steer” if you know what i mean, you can only guide it back to the line.
But maybe not, it would be a very interesting project. Some of these things you just have to try. Pure Pursuit comes up with a steering angle to get to the line, and really that is all you are doing on an implement.
I would be bold and say - it would work in Stanley mode which is designed to put the steer axle over the line - and that is exactly what an implement is.
3 Likes
Hello! Joel from Finland here, new on the forum.
I would like to experiment with row cultivating in grains (organic farming), row pitch of 25cm. I was investigating camera guided systems and then found out about aog. I have read on the forum for 2 weeks and fell that i have gathered enough knowlege to dear to make a post. 
So my idea is to guide a sideshifted implement with aog. I would record the paths when I seed the field with the gps antenna on the seeder and then have an autosteer box and gps receiver on the row cultivator. The autosteer would only be for side shifting the implement not steer the tractor, for now at least.
I’m not sure how to make the side shifting work since it would not steer like a steering axle that returns to it’s center position once it’s on the right line, it would need to shift until it’s on the line and keep that offset. I found out that in the machine control PGN there is an offset value sent from aog to be used for an external guidance light bar. Maybe this could be used to side shift an implement also if the pwm calculations would be handled in the arduino using the guidance bar offset value.
Does anyone have any input on this setup?
You only have to use this distance from line to move the cylinder until it reach 0. It will need some PID to work properly.
We have something similar in the OpenGrade blade control ino. The software only send the distance from target and the ino makes the calculations.
But this need the distance from line, not the target angle. It was in v4 but I’m not sure it’s in v5.
I steered a planter by swinging the drawbar on the tractor. I would think your side shift cultivator should react even quicker and should work better. I just used 50/50 voltage divider resistors to send a “centered” was signal so that as soon as AOG is happy it stops adjusting the side shift.