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.
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.
@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
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.
I knew it was there, just hard to search for the right words
This word combi in search got me there! relay led_pin
Click on Fendt and you see a sketch with motor, relay and motordriver.
I see now, many thanks.
From the steer.png image, I see 2 “Led Pin…”, one in clear blue from the “Dir” in PCB, and the other one in dark blue from the “PWM2” in PCB.
The sketch you refer, is edited asking: on PWM2 (Pin 9 on Arduino)?.
I wonder which of them.
I understand this activates an Arduino relay board optoisolated, as recommended on the next post from the Fendt.
A lot of things to test for the next weekend.
That is to be found in autosteerschematic.pdf (also in support). Follow line from arduino D9 - it goes to PWM2 on pcb (can also be found on pictures of pcbV2 but not easily. It passes R14 on the way
Reason to 2 different options is IBT_2 and Cytron motordriver, they get different pin setup of arduino (which today is done in AGOpen program) before version 4.1 , pinnr. setup was done directly in the ino program/setup of autosteer.ino : And that is why today the ino name is Autosteer_USB_4.3.10
But as GoRoNb posted above you don´t need relay with IBT_2 @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…
@ESCBB There is a nice TI paper. Fig. 5 shows the current flow: left: motor driven actively, middle: what the IBT-2 is doing during idle (you still charge the battery when turning the steering wheel fast enough), right: what the Cytron is doing (motor short = highest breaking force). If you simply put in a switch to to motor lines, the breaking forces are minimized. That’s the best option apart from disengaging the motor mechanically.
Regarding the original question. Given we have gps speed and an IMU that outputs angular velocity, it should be possible to have a stab at wheel angle calculation shouldn’t it?
I’m presently attempting to port the standard arduino code to an ESP32 , so I’ll try to have a stab at something on that if I manage it.
It will have the added advantage of becoming much more sensitive with speed, which could be useful.
