What sort of a real world approach do you have? I hope not a hydraulic orbitrol for steering a tractor. You would need continuous zero point tracking. Implementing that might be useful also when a WAS was present.
Even with a mechanic steering you would need to take into account that the steering angle might not be the same for both directions.
You’re right, that’s the key question. Right now, it supports only the use of an inductive proximitivity sensor at the steering rod setting the center position every time it passes by. So there is still a part “outside” the cabin, but no mechanics any more.
It’s a first approach. One further option is extracting the zero position from the GNSS or angular accelaration of BNO055 while moving. Other option: connecting to CAN and use the already build-in WAS.
Good idea with an inductive sensor. It might work. You would also have to take into account the hysteresis of the sensor, count the encoder pulses at the time of switching on the inductive sensor and divide it in half, then the exact point 0 would be.
Interessting topic to get it work without WAS.
I think the agular acceleration would work if you go a straight line where you have a steady heading but if you go a curve I am not sure how it should work there.
Maybe it is possible to get a steer angle from the speed you get back on the ideal line.
Right. You only need the center signal from time to time, so both GNSS (speed+heading) or a combination of GNSS(speed) and BNO055 (heading) should work. But it needs a lot of math, so not the best option inside an Arduino. Should be easier to calculate it inside AOG, but that’s not my competence…
Ok I think my idea would require a complete new steering algorithm.
Take the devation to the line and devide it in very small pieces.
Calculate the approach speed in very small time steps and than adjust the steering. The angle would not matter.
If it goes too fast to the line turn less if it goes too slow turn more.
Cerea people probably like it because they have no experience about the steering performance of AOG with WAS or OEM systems that pretty much always use a WAS.
Don’t get me wrong, I like it when people have new/different ideas but one must be careful with the arguments to drive the idea.
I’d see a “no WAS” approach mainly useful for vehicles that do not have real steered wheels and then cannot have a simple WAS. Unfortunately these vehicles cannot use a zero wheel angle detector, I guess not always a steering wheel. Some of the other approaches proposed above could work.
I agree. People who previously used JD or Trimble systems without a steering sensor are surprised that the AG wheels do not oscillate but make almost imperceptible small corrections, the AG does not need a 20m headland to “catch the line” as in systems without WAS. Ag also has no problem with driving at slow and high speeds, systems without WAS get lost at both low and higher speeds, problems above 8km already begin, and you also get lost in curves. Also, if it is possible to install WAS, it is worth getting tired of doing it. But it’s nice that @GoRoNb is working on an alternative solution because it can be used, for example, in tracked vehicles, etc.
If you have a normal tractor you are absolutely right.
The time to mount a WAS is well invested and you get a proper steering.
For sure it takes some time till it is mounted but I guess we all like play around and built something on our own.
Maybe we shoud think about some self adjusting stuff.
Would be helpful if wheel angle 0° or the output PWMs could be adjusted by the system itself doing some teach drives.
That would make the system easier on a different way.
@bricbric: it would be like pushing a trailor backwards. Nevertheless, I like the idea in general. Imagine, there is one antenna at engine hood and one at the end of a sowing machine. Maybe it’s limited to sowing, but even for that, it may save more money that it costs, when overlapping is eliminated. But that’s beyont my skills to implement this…
@F380: The Fendt I know is drifting really low, so centering during a u-turn should be sufficient anyway. But there is a big drift, when pushing the steering wheel into the limits. Apart from that, I’m thinking of a different idea: I can store the rotation steps from one steering limit to the other one permanently in the EEPROM. If I go into one of the limits during each u-turn, I may not need any centering any more. Will try…
I’m exited on your feedback how it works.
I guess it could work very well.
It means that you know it is for example 50 pulses from 0° to the limit.
At 50 you stop counting even if you turn the steering wheel more because it is drifting, thats the idea?
When the steering wheel is turned back you go through the 0° point and your inductive sensor tells that.
Something like that could be useful for a two track tractor. Having a rotation sensor on both tracks and at the moment both have the same speed it is set to 0°.
I currently plan to try something similar. (Stepper motor and on the shaft a magnet and on the PCB on the back of the stepper a sensor that tracks the position of the stepper. That PCB should contain everything, be attached at the end of the stepper and have only one (ethernet) cable. Data over UDP, power over passive PoE.)
Initial (stored in flash): slowly rotate once from left to right and back to get full “travel”.
Each start: let the operator turn the wheels once from one side to the other, if same travel reported good to go (and know our zero which is in the middle ± steer zero adjust)
While driving: minimal adjustments according to the deviation from guidance line
At sharp turns (set aog to allow slightly tighter turns than possible) use the endstop for recalibration.