AOG without wheel angle sensor

But the orbitrol always leaks some oil so you always need constant zero correction, or you need a reaction orbitrol?

My Hürlimann has reaction orbitrol /steering. And when driving on a slope or with implement at one side, the steering wheel “slips” about 1 cm pr 100 m drive, because I have to hold the steering wheel to same side all the time.

Gear for the rotary encoder

@doppelgrau Not sure if it’s already made: Maybe it’s a good idea to have an option for a higher PoE voltage up to 60V. Current injection to the stepper will be much faster allowing more dynamic drive.

I’d thought about it using 802.3XX compatible PoE,(48V), but decided to design it for passive PoE and only up to 24V.
Reason: Way simpler (internal) power supply, no trouble with the PoE circuits (and space) and PoE-Switch in the cab not so easy, since the power supplies usually require 50V.

20201010_181303_resized 20201010_183013_resized

2 Likes

This is a great thread it has explained a lot.

Running Trimble Ez systems mostly, I finally understand why they go for “a little walk” sometimes after turning a corner fast or just randomly in the middle of a field. Also why they are limited on approach angle and take such a long distance to stabilize.

I do agree for the ease of installation would be nice not to have the WAS, a system that can be quickly popped in and out of multiple units would be handy.

But I am starting to see the benefits of WAS functionality.

2 Likes

Fully agree - knowing the wheel angle in absolute values is the best option. unfortunately applying the sensor is the biggest hurdle for those guys I know working the AOG, so my idea of emulating the sensor by tracking the steering wheel angle.
Status of today: Tracking the steering wheel works well (my encoder even has an oversized precision), but I’ve to investigate on a better center sensor. The repeat accuracy of my proximity switch is too poor. Right now I got a cheap Hall element sensor. Will try the lateral shaft bipolar option.

I expect your sensor has too much deadband, meaning it will trigger at different steering angles depending on which side you approach the sensor. You could maybe test the two degrees at which it triggers and use those values instead of 0 for resetting your encoder tracking.

was my idea as well. finally you have four angles, because these sensors have a hysteresis. Ok, still something, you can deal with in software. but at least with my one, the switching point differs from time to time, and that’s nothing you can compensate…

Interesting idea to use speed sensors on each track on a two track machine. From the two speeds it should be possible to deduce steered angle (virtual analogue of wheel Angle or turning rate) directly (ignoring track slip) . On our CATs steering wheel angle is not proportional to turning rate.

For tracked vehicles, for example, BNO55 could be used. You would have to write a program that would reset to zero when PWM = 0 (the vehicle is driving straight) while turning the whole vehicle (PWM <> 0), we would have an angle and a turning speed.

Same idea for the swather. I think the steering wheel angle is proportional to the turning rate, but this ratio could be different at different speeds. An interesting problem.

finally you only need to know that there is a sufficient speed. Then, when there is no angular accelaration, the machine goes 0°. But it will be not so easy to detect… The angle should be proportional or at least “predictable” but there is certain drift over time.

This is exactly the reason I started a topic in February, which originated this topic by you. After some months of “hibernation”, I have completed the soldering of PCB V2, made some tests and found that the AOG PCB solution has for me two disadvantages compared to CEREA. 1: the need for the WAS and associated tedious installation. 2: When manually moving the driving wheel, it needs a tremendous arms force to move the wheel. To avoid it, I am thinking to put a switch between Cytron and Phidgets motor, so to cut the continuity between them when manually moving the wheel. Seems not efficient…
So for those who come from CEREA, who already have the Phidgets Motor Controller 1065_1B, with its associated optical rotary encoder HKT22, not complaining of the accuracy of the wheels position, it may be a possibility to continue using the Phidgets controller and optical encoder. The Phidgets controller is connected via USB to a USB hub. Is it so difficult to make the modification on AOG to allow the use of this hardware setup?. For me it is, as I am null on programming.

For clarification, I was answering your above post.

@ESCBB from the hardware point of view you are able to do the Cerea solution with the AgOpenGPS PCB: there is an input for a motor turn sensor where you can connect the HKT22 sensor (mind, that the supply is 5V). Furthermore, when using a IBT-2 motor driver, you don’t have additional forces, because that driver has an extra “disable” input, so that the DC motor can turn freely. So from the HW point of view, all is there.
But: The software concept is different, but I never digged into the details there. That’s a bigger discussion still ongoing that I don’t want to repeat. Maybe one day a clever software guy comes up with a solution, maybe with two RTK antennas… Let’s see…

Thanks for your answer. About the IBT-2, I have just ordered to test it, but I dont see how to manage the “disable option” so to avoid the extra force. Could you help on this?.

About the need for WAS like ER10031, while AOG is being now under a hardware redesign process to reach perfection (per the discussions on Telegram forum), the part of the system to get wheels position reading seems forgotten. I say this because the use of ER10031 or similar, which are not ruggedized, nor designed specifically for the use that AOG is doing (mud, dust, water etc).
For the users with electrical motor (not valves), a solution with HKT22 together with the Phidgets controller 1065_1B, solves the problem, and is an affordable cost solution.
I hope one day the software gurus see the path already walked by Cerea.

Regarding the cut off possibility:
In steer.png file found in the support folder, you see Led_pin or Aux hydraulic relay, that is the one you use for your relay to cut power to motor driver. Works both for cytron and IBT_2 just different pin from PCB

1 Like

Thanks Larsvest, I see now the steer.png file, but not what I must change. What I understand is that these two “Led_pin Aux hydraulic relay” allows to feed a relay, but not see how are interfacing with Cytron and what needs to be changes from what I have now. Perhaps is very obvious and I am still sleep.