Hi all,
I’m looking into using an ODrive S1 controller to drive a BLDC for a telescope mount which requires high resolution. To achieve this, I plan on using a optical encoder with a resolution of approximately 0.2 arcseconds as the load encoder. The load side is connected to the BLDC via a 160:1 reducer, meaning in order to match the resolution of the load encoder, the commutation encoder would need to be 16 bit or higher.
Does the commutation encoder need to have equivalent or higher resolution (after reduction) as the load encoder in order to make use of the load encoder’s high resolution? I imagine if the resolution for the commutation encoder is too low, then the ODrive will not be able to reliably position the BLDC within the precision of the load encoder.
Thank you!
Edit for clarity: I shouldn’t need this level of resolution for positional control (resolution to several arcseconds is fine there), but I do need smooth motion at very low load velocities (i.e. 15 arcseconds / s)
Hey there,
Super cool application!
Generally no need for commutation and load encoders to match resolution. It’s true that if the commutation encoder is extremely low precision (e.g. hall sensors), you get some torque ripple and inaccuracy in commutation – but you get diminishing returns quite fast; I don’t think that there would be a measurable difference between a 512 CPR and a 4096 CPR encoder in terms of torque ripple, outside of large transient response, which here would only happen if the telescope falls over 
The main reason you would want a high-resolution commutation encoder is if you plan to run your velocity loop off the commutation encoder, as opposed to the load encoder – that may be a good idea here if your reducer has a lot of backlash. That being said, I think you could probably just use the (14-bit) AMT21 at first and give that a shot.
Thanks for the quick and detailed response, Solomon! My reducer should have very little backlash as it is a harmonic drive, so based on what you said I suspect I will be able to run the velocity loop off the load encoder. Accordingly, I will try a “lower resolution” (12 or 14 bit) encoder first.
My motors are using larger 14mm shafts, so unfortunately I won’t be able to use the AMT21. I’m looking into encoder options at the moment, and right now I’m thinking about either the AMT24 (nearly identical RS485 protocol to AMT21, seemingly only differing in commands for zeroing and resetting) or a side-mounted magnetic encoder (either AEAT-9922 or MA732) with a ring magnet. I’ll need to do some digging to see how well side-mounting is supported with the ODrive firmware, though.
Thanks again!
Totally makes sense!
AMT24 is identical to the AMT21, yes, however the AMT21 we sell has a custom firmware to allow for higher performance at speed – the stock AMT21/AMT24 firmware has big issues that cause it to lose resolution fast at higher speeds.
You can use the OA1 off-axis with the devel firmware branch, however I’d maybe recommend checking out the RLS Orbis (with the SPI slave option) instead – shouldn’t be an issue with a 14mm shaft. Only consideration is that SPI encoders are a bit more sensitive to EMI, so you may have to use a shielded cable and/or route the SPI lines away from the motor phases.