I don’t know if it is a big problem or not because I am not so deep in programming.
As I understood correctly the aim is to count the rotations of the steer shaft or the motor shaft and calculate with this the wheel angle as there is a certain wheel angle per pulse.
How I see it AOG outputs the set wheel angle as an absolute value.
So the steer wheel turns till this value is reached.
If you now count the rotations and would like to set a wheel angle of for example +2° you know it has to turn for example 50 pulses.
If the new set angle is 0° what will you do than? Does 0° means 0 pulses?
In reallity you would need -50 pulses in counter direction.
You know how many pulses it takes from end stop left to end stop right (lets say 2400 pulses).
You know where 0° is (in my example 1100 pulses from left) and have “pulses per degree” (e.g. 28 pulses/degree).
So calibration aside (where you need to make some adjustments from time to time) you simply keep track of the pulses and know the current (virtual) steering angle.
So if you are 1234 pulses from left end stop, the steering angle is (1234-1100)/28=134/28=4,78°. And if you compare that to the value AOG sends, you know if you need to turn the wheel (and in which direction) or not.
The timing gears on an engine used to have two marks that must line up. My thoughts, two sensors, one with a lot of pulses, one with just one in the zero position. When AOG starts rotate the wheel right and left a quarter turn, if it does not find zero, ask the operator to zero the wheels and test again. Just a thought.
@KentStuff: sorry, what kind of timing gear are you talking about? I found totally different translations… @doppelgrau: Why do you perfer a stepper motor? It’s current driven, needs dedicated drivers and is painful in terms of EMC, if the wiring is not perfect.
very simple to control speed/position (need 10° to the left, just turn 1400 steps clockwise (and enough libraries that take care of acceleration/deceleration).
easy to source in NEMA17 (compact size = more room for the knees)
dedicated driver (e.g. BD63524AEFV) do not cost much more than a VNH7070AS or something similar to control a normal DC motor
Current driven: using one IO Pin you can change VREF between three values (high, low, high impedance) => higher torque when needed, (way) lower holding torque (and heat) if no rotation needed. (Nearly 2A on high, 0,5A on low => 1/16 power and heat in holding currently planed.) Also disabling the driver/setting all FETs to high impedance is possible while not running. So I do not see a large downside there, maybe even a positive point, not the problem with large startup currents.
Power consumption low enough, that passive PoE should be possible. So only one wire (or two with a (foot-)switch) needed => a setup where the motor is removed during street driving possible.
EMC might be a problem, but I hope the PCB is designed well in that point, and the cables to the motor are only a few cm (PCB/driver sits on the back of the motor).
Last but not least: was inspired by the S42B, so a stepper was not a far away option.
Currently on two (way simpler) boards before ordering them, then it will get interesting, if my assumptions will work out.
Dual ring encoder like in a printer is what I had in mind. Like the picture below but small spaces. Outer ring is counting degrees, inner ring marks zero.
Rethinking this, the only way you can make sure the wheels turned is to measure the wheels. Turning this by hand could really confuse the ticks, it could be ticking right while the computer thinks it is ticking left. It would take multiple, offset, ticks to verify it was ticking the correct direction.
Determining the direction is easy when you use 2 sensors, then you have a cycle shift. But the biggest problem will be the constant need to set 0, probably only the patent with an inductive sensor on the stick will work here. In my tractors I have solenoid valves, but out of curiosity I marked the point on the steering wheel with a tape and tried to steer myself on the line by hand. It depends a bit on the conditions, but after 50m the shift was already about 1 hour.
@doppelgrau: I really love your high-tech ideas! Maybe you should have a look at Trinamic (now part of Maxim), too. They have very good stepper drivers being able to detect loss of steps (they call it “StallGuard”), but you’ll like more what they call “SensOStep”. You’ll be able to integrate this into your PCBA. IC comes from AMS e. g.: AS5048. But still not conviced about stepper in general @KentStuff: my encoder already has A and B signals like shown in Wikipedia. But the zero pulse has to come from either the wheels (simple approximation switch), a pair of wheel speed sensors, the angular acceleration divided by speed or the GNSS. Wide playground open for us…
@GoRoNb: I had thought about the Trimatic, but they cost way more if you want to get 2A, and since I have the “magnetic encoder” I already have means to detect lost steps. And I want the magnetic encoder, so manual steering is still possible.
But yes, using a stepper is an experiment, I hope a successful experiment, but an experiment.
I look forward to your results with a stepper motor. I think such a motor is very suitable for our application because it can be controlled very precisely. Completely new possibilities could arise. For example, one could be that we do not longer have to play around with the minPWM values, since the motor itself recognizes when it is turning.
A stepper motor has some other parameters you’ll need:
Acceleration speed (to slow is bad for AOG,to fast means the motor stalls)
Maximum speed (torque is reduced at higher speed => too high, stalling again)
Not yet sure, if I want to try some “atomatic setup” for these or just misuse some of the existing parameters (maxPWM /10 = max rotation per second, proportial gain = acceleration or something like that).
Guess start with misuse of existing parameters, one point less on the todo list, but automatic setup would be also a nice idea (increase these parameters, until steps are lost, then subtract a good safety margin and save them).
Made a short real-world test this evening: Working fine, so both, a WAS and an incremental encoder work and it can be switched between them!
(of course, only one option is needed in real life…)
Both is possible. Fendt seems to be very stable, so most likely it will run without assuming that you do u-turns regularly. But you may add a sensor; its active low signal will set to zero again on real walk-through events (middle of 1>0 - 0>1 edges).
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.
@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.
