Is an encoder on reduction supported

(newbie question)
Can I put a reduction like 1:10 on a motor, then put an encoder after the reduction, then use SimpleFOC to control the position of the encoder?

By the way, any reasonable combination lightweight BLDC + reduction gear ~1:10, which is backdrivable?

Hi @scriptmonkey , welcome to SimpleFOC.

We recommend connecting the encoder directly to the motor shaft. Trying to sense the motor position from a “secondary” axis will be more complicated. One problem is backlash, which will introduce imprecision into your readings.
Another problem is that you will effectively reduce the accuracy by 10 - you’ll be reading 10 motor revolutions with one sensor revolution. So in particular I think this would make the use of cheap sensors quite impossible, but even an expensive 14bit sensor would become a 10-11bit sensor, with corresponding decrease in performance.

I don’t know of any… it would be cool if someone had some pointers on this. The quasi-direct-drive motors I have seen are not cheap. Things like this:

or this:

http://www.gyems.cn/product.html

Cool stuff, but not cheap.

I would like to know the actuator (servo) position. I guess that I could use two encoders, but as the precision which I would need is only about 8 bits, a single encoder after the reducer would be more compact. Is it in principle possible with SimpleFOC? Would not it rather need high precision angular data for a reliable control? How would it react to an additional source of noise between a motor and an encoder?

There are some attempts at printing backdrivable cycloidal drivers, for example Simple Cycloidal Robot Knee - YouTube .

3D printing cycloids is hard. I’ve tried, as have many others in this forum.

If you’re not familiar with the “Skyentific” YouTube Channel, I recommend it. Lots of good stuff on robot actuators there.

I would use two encoders for your use case - a cheap one on the final output, because as you say you don’t need that great accuracy there. Something like an AS5600 will probably be enough. And a better one on the motor shaft.

The encoder pretty much can’t be accurate enough - the more accurate, the better your results will be. Accuracy here is not just the number of bits, but also to do with signal to noise (i.e. effectively usable bits), speed/latency (bandwidth) and linearity. So getting a good quality sensor definitely will improve your results. This will be noticeable in things like:

  • power consumption in closed loop mode
  • smoothness of rotation when rotating slowly
  • maximum speed attainable
  • number of pole-pairs you can handle

That said, depending on the motor and performance needed, a 12 bit sensor, or even 10 bit sensor can get you good results when properly mounted on the motor shaft.

Currently no. But it would be fairly easy to write a subclass of Sensor which does this for you.

See comments above.

On a theoretical level, not well, as described above.

But in practice you can just try it out… If it works well enough for you, then that’s good, right? And if not, you can always come back to the idea of using 2 encoders.