Have you considered orbitrol drift? It seems not to me looking at py code.
Not yet. This is something I will work on next. I want to go outside and have a test run first.
I want to try out the ideas mentioned in this thread (e.g. zero point tracking using IMU, endpoint detection by resistance/amp measurement…).
Orbitol drift can be considerable and rather unpredictable. An encoder will need to be referenced to something pretty regularly to be reliable. On my old 716 this would need to be several times a minute as it drifts, especially when cold.
Good to know that. I will see if this is the case with the system I want to test on too. In that case, centering by IMU several times a minute might be challenging because of noise and the shaking cabin.
It is this HTK22 optical rotary encoder from Phidgets, which I am using: Optical Rotary Encoder HKT22 - 3531_0 at Phidgets
The datasheet doesn’t state directly if it is absolute or incremental. But from my understanding, I am pretty sure it’s incremental because of the price, connector and protocol. May I ask why you are interested in this?
Yes, I too didn’t find out whether it is absolute or incremental (I guess you made a home test already). If it was an absolute encoder, this method will be easily solved.
HKT22 is clearly an incremental encoder and anyway Phidget Motor Control cant handle an absolute encoder.
Like a WAS perhaps on the kingpin… Then you would know the exact steering angle all the time
To me, a steer wheel (or motor) encoder coupled with a purely hydraulic steer is just adding massive vagueness to a fairly feedback critical system for little benefit. Orbitals are not consistent. The point of the WAS less thing to me was the total lack of a sensor, and more so the benefits of angular velocity over steer angle.
Yup the Deere in the centre keeps going round and round, new random spot all the time.
One of the things lacking is a solid angular velocity. I think with the new use of the bno085 in uart-rvc at 100 hz may overcome that deficiency.
As the orbital drift seems to be a really big issue, I will get a Honeywell RTY090LVEAX WAS to have a good reference value. This can then also be used to capture quantitative data on how well the encoder solution is working.
It will be drifting and it won’t be consistent. Beyond that I can’t see the encoder being overly useful.
I agree. This neatly bypasses all the side draft, slip and WAS zeroing issues.
@BrianTee_Admin Could we copyright strike Farmtek.fr? Farmtek developed a WASless compatible version of AOG including automatic calibration.
AOG is licensed under GNU GPL which states: Any modifications to or software including GPL-licensed code must also be made available under the GPL along with build & install instructions.
The goal of the copyright strike would not be to bring down this company, but to force it to upstream the code to AOG so we can enjoy it as well.
I have not a working-install system of AOG yet, but isn’ t possible to use an absolute encoder with multiturn possibilities and remember the location? I think that will use continuous power supply to the sensor in order to keep track of the position of the steering wheel (low power with sleep mode). I will check soon a solution for this.
That would theoretically work if your steering wheel is always in the same position when the wheels are forward (like a car). I know the farm equipment that I run the wheels and the steering wheel relative position change continually.
Thank you for this info. I do not have that knowledge.
There’s always some hydraulic slippage