Getting feedback of a rotary position

[Watth]

Hey EEVfolks,
Considering a hobby-level toy-grade design of a robotic arm, actuated by a stepper motor (or even a plain DC motor); how would you implement cheap position sensing of a rotary position (no more than a range of 180°)?
This would also allow knowing the arm's position after a shut-down and allow somewhat precise movement with a non-stepper motor.
Do you think a single turn a potentiometer be enough? Would a multiturn pot (with multiplying gears) be worth it?
Thanks for reading!

[langwadt]

AS5600 or similar

[TimFox]

It depends on the angular resolution you need.
Precision wire-wound pots have finite resolution due to wire size, and a "servo" quality pot should specify that resolution.
Good 10-turn pots from Bourns:  https://www.bourns.com/docs/product-datasheets/3500.pdf?sfvrsn=8cb7c7ec_4
The more-expensive 3501 series in that data sheet "smooshes out" the resolution with a conductive plastic coating over the wires.
Note that for the standard 3500 series, the resolution improves at higher resistance, due to smaller-diameter wire.
An example of a good (yet expensive) single-turn (continuous rotation) pot from Bourns:  https://www.bourns.com/docs/product-datasheets/6534.pdf?sfvrsn=52a823c2_5

[MarkT]

AS5600 or similar

Yes, second that.  You just need a diametrically magnetized disc magnet (many magnet shops have these now) and the encoder chip.  Probably are some pre-built modules available using these.

[RJSV]

   I've seen encoders that are low resolution digital where there's a wheel, moderate sized like 5 cm diameter.
   The optical code wheel has a checker board like appearance and (likely) 3 separate IR sensors very close to what a straight binary pattern counting with 3 bits.
   I believe it was an 8 level code, but a type that only has one change at a time, as the position sensing can't get easily confused.  As you know, a 3-bit binary code can have two or even all three bits change at once.
   If that optical wheel is used, you might expect to sense rotary position to within about 45 degrees.  If there is a bit of gear-down might get better resolution, as something like an arm doesn't move 360°.
   Potentiometers can be a bit 'scratchy' as they move, so you would have to use L.P. filter etc.

[TimFox]

For absolute encoders, you want a "monostrophic" code, of which the most popular is "Gray code", so that only one bit changes at each increment.

[Infraviolet]

So long as you're confident in the ability of any supervising microcontroller to keep up and catch every rising and falling edge (so as not to loose position to drift over time) you'd probably do well with an incremental quadrature encoder. Often you can do this by mounting magnets on a motor's backshaft (if it has a backshaft from the motor before the main shaft goes in to a reduction gearbox) which move past a hall sensor to give rising and falling edges as the backshaft turns (the gearbo meeans hundreds of backshaft turns, typically, per turn of the main output shaft).

Quadrature ensures that the microcontroller readings the encoder pulses knows at all times which direction the encoder is turning in, so always adds or subtracts each count as appropriate.

Multiplying gears to drive a rotary encoder from the main shaft can work, I've 3d printed them soemtimes, but any backlash in these gears gives an inaccuracy in the measured position versus the true position, and some deadband when the main shaft changes direction. I did it with a stack of 6 to 1 planetary units, driven from the carrier (usually the output shaft when in reduction mode) so as to make the sun spin 6 times faster. I stacked up two of these (36 fold speed increase), then had the final sun hold a ring of 10 magnets (5 pointed up, 5 pointed down, alternating per place) which spun past hall effect sensors. If you do this you must make sure the gearsae fairly loose and very low friction, because any friction on the final sun gear gets multiplied up in to a motion resisting torque of (in my case) 36 times that at the shaft you are controlling.

One can buy for about £7 a style of incremental quadrature encoder with hundreds of pulses per rotation (this style of thing, lots of sellers, and not limited to ones on amazon: https://www.amazon.co.uk/Incremental-Encoder-E6B2-CWZ6C-Diameter-General-Purpose/dp/B08CCBMW96/ note that the test description for that encoder is odd, some nonsense about linear bearings, but follow the part name and you'll find similar form factor items of the same functionality) which uses optical sensors insie to track rotating glass wheels with darkened markings on them. It may be a bit bulky, it is the size of a small motor already, but it would be no bulkier than 3d printing your own gear train to multiply up before feeding to a several-pulses-per-turn magnetic encoder, and wouldn't have the backlash assocated with multiplying gears.

I've heard good things about absolute encoding with AS5600 style chips, these style of things can be addressed over I2C/SPI/UART and give you an absolute reading, so you won't have position dirft if you missed counting a rise/fall. Some have both a digital protocol interface and a quadrature output for incremental tracking.

[BeBuLamar]

Using an incremental encoder like the quadrature encoder would require a homing procedure every time you recycle power as the machine doesn't know the position. I think for non precision and less than 180 degree a potentiometer is sufficient and much simpler. I have worked on larger printing presses with hundreds of ink keys that need to be positioned and they all used potentiometers. With absolute encoder it should be at least 8 bit to be good.

[Terry Bites]

www.amazon.fr/s?k=CJMCU-103&__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=17T6W75PII7A2&sprefix=cjmcu-103%2Caps%2C77&ref=nb_sb_noss