Hi,
I was wondering wether AOG could manage the Phidgets Motor Controller ref. 1065_1B. This Motor Controller takes care also to process the data from the Optical Rotary Encoder ref. HKT22(3531_0) which works as a WAS.
The main reasons are that we have them already, and that by using this hardware configuration, avoid to send a cable to the wheels area and also solves the mechanical adaptation of any other angle sensor.
With the current PCB V2, I dont see a way to connect them, perhaps the new software version V4 with the associated PCB will allow to “recycle” this hardware ??.
About sections control, we are already served with Arduino Uno and a pair of 8 relays modules.
Thanks!!
You need a WAS on steer linkage. The encoder will not be accurate due to leakage in orbitrol.
1 Like
Thanks for your reply. With a different Ag autosteer program (Cerea) and with the hardware above, it seems really accurate, so we dont see the need to introduce a different “WAS” other than the current optical encoder installed on the phidgets motor.This is why I was wondering for this possibility to be used on the coming AOG V4.
Yes, you could write the code and make it work. I reckon you will need to use a LS7366R chip between the encoder & arduino as arduino will struggle to keep accurate count with interrupts. Take the output of the LS7366R do a bit of math and input the result as the steer angle input.
Will look forward to how you get on so share your results.
Many of us use a steering motor with a drive wheel, not with a continuously attached wheel running on gears. In this case the encoder at the motor loses steering angle knowledge every time the tractor is driven manually. I wonder how long it would take for the software to find the actual steering angle or even a rough estimate of it. Who wants additional steering wobble just to avoid WAS? The optical rotary encoder is more expensive than a good WAS. Installation time is probably not extremely critical for us who prefer a low cost approach instead of a factory built auto-steer system.
I would still like to know more on the Cerea approach, any videos showing how quickly it finds the actual steering angle and what is the actual algorithm. How does it work at a very low speed etc.
AgOpenGPS is often used with a hydraulic steering valve. One would need a WAS in that case or at least the encoder at the electric motor would be useless in this case. The WAS approach works for both. On this and on many other topics my preference would be to let the software experts spend their valuable time on feature enhancements or similar rather than spending their time to implement one thing multiple times.
2 Likes
Any news here? Did someone give the idea a try?
Ok, I got AOG working in general with a WAS, but the solution is neither very robust nor convenient to install. And I think the need of a WAS discourages people from using AOG. So I’m thinking about the following:
- Phigets motor + HKT22 as mentioned by ESCBB, coupled by gear (already installed)
- Either Apm’s idea with the LS73355R or something like an 8-pin PIC µC with some lines of assembler (this may emulate an ADS1015, so that the original Arduino code keeps working)
The resolution/quality will be at least the same or even better than of any WAS (300 pulses per turn of the Phigets w/o any ADC noise).
I’ve two different init procedures in my mind:
1st option: Before starting farming turn the wheels to 0°, engage the gear and activate autosteering
2nd option: Before starting farming turn the wheels to the left limit and then to the right limit and activate autosteering
All ideas welcome!
Aren’t there IMU sensors that can tell AoG the tractor’s rate of turn?
I know my EZ-Steer system works without any encoder whatsoever on the steering angle or the steering wheel. I assume it’s using an inertial sensor to measure the yaw rate and then it just applies a certain amount of left or right to try to get the heading it thinks it wants. Would be interesting if AOG could do something similar. But I don’t think the neat stanley steering or pure pursuit strategies would work with this. Would pretty much be simply some kind of heading error loop.
rate of turn = velocity x (WAS - WAS0) x something
so this may theoretically work for higher speeds and if you can calculate the speed, but mind that IMOs have a noteworthable drift as well. Would require a totally new steering algorithm and even with that, I’m not sure, if this would be stable enough.
@torriem: That’s my idea: I want to avoid steeing sensors by an encoder of the control motor. I’m sure, EZ-Steer has a rotary encoder for its own motor inside. Like Cerea.
Problem: I don’t want to rewrite the autosteer algorithm 
I’m pretty sure there’s no encoder in the ez-steer. I just don’t see what use it would be since the motor isn’t fixed to the wheel all the time. In fact it can even slip and it still works. Given the settings, I think it just has a rough idea of how many degrees per turn the motor can create, and uses that to get it closer (a certain speed for a certain length of time). Ultimately the vehicle heading error drives the system. Like I said, AOG currently does not use heading error, but rather pure pursuit or stanley which require information about the steering angle. You’d have to modify AOG to add a purely heading-error strategy. I don’t think you can estimate steering angle good enough to make the pure pursuit or stanley algorithms work, even with an encoder on the motor. And if it slips or can come away from the wheel like the ez steer does, all bets are off.