What is the max theoretical precision of a Odrive combined with a hoverboard Motor?
Im thinking about building a direct-drive Telescope. (Two Motors driving two axis of a telescope without any gears between. Just the Motors)
I know, one big problem is the encoder. The accuracy of such a encoder would be at least 20bit.
360° * 60 arcmin * 60 arcsec = 1296000 CPR to get arcsecond accuracy (what I would need for a telescope)
Ideally it would be about ten times as much.
From my knowledge of BLDC motors I would guess that the coils are driven with PWM to set a certain position between two coils. What is the precision of this pwm. This multiplied by number of coils would then result in kind of the maximum resolution I guess.
The Hoverboard Motor is just a example of a motor. But would certainly be very nice if this motor could be used for this purpose!
Stepper motors work like this: the steps/turn times the micro-stepping level (a kind of PWM precision) gives you the positioning precision. Closed loop FOC control doesn’t work like this, the number of coils doesn’t matter. The precision of the pwm also (almost) doesn’t matter, as long as it’s sufficient to maintain a reasonably clean current.
The ODrive can drive down to an error of a few encoder counts on any reasonable motor, as long as there is little external disturbance forces. This is the power of closed loop control. Your limit will be how smooth you can make the mechanics to eliminate non-linear forces like stick-slip.
I think if you got a peek inside the planewave mount you would likely find that they have an absolute encoder being driven by a high tension belt and pulley from the motor so as to increase the effective CPR (which you could do with the ODrive, just set the encoder CPR to the calculated value). For the quick slews there is probably what amounts to a lower res incremental encoder so as to support the range from minute sub arcsecond sidereal tracking and autoguider adjustments through very high speed goto’s. During slews, just keep track of how many times the index gets hit, then decel and swap to absolute. Or just a very fast read rate of the absolute, but I would be impressed if it didn’t miss a full rev at the advertised 50 degree/sec slew.
Edit: Or they may also use a 152mm stainless steel encoder wheel… Still, I think you’d have success gearing up the encoder to achieve a much higher effective CPR. I’d bet a properly tensioned GT3 5MGT 9mm (edit: was going for overkill but overlooked the effect of pitch on minimum pulley size on the encoder side)
GT2 6mm wide or similar with well machined pulleys would get you in the same arena as the planewave. Since the belt is only driving an encoder on a shaft, there’s effectively zero load and you shouldn’t get any stretch of the belt, ever (get a real Gates belt, though).
I also plan to make a mount using the odrive but am currently bogged down with other projects including an observatory (astrophotography is one of my hobbies), so please do keep us posted with your progress!
Edit 2: Are you going to do an alt/az like the planewave or eq? If alt/az I would make affordances for cooling the motor unless you’re running something like a tiny refractor. An eq would suit things better just so you don’t need much holding torque as compared to an impossible to 100% balance alt/az.
EDIT THREEEEEE: BTW this would be an ideal application of the proposed CD Encoder CD Encoder Idea due to its need for very high res and likelihood of seeing very little vibration (pretty much only have to worry about wind pushing things about or a train passing or some dick with loud bass).
Ok, the one with the pulley was the idea to prevent in the first place.
For example: To use the promoted encoder in the odrive-shop with 8192 CPR you would need a 2000:1 reduction to get the accuracy targeted.
And a 2000:1 belt reduction, in my imagination, has at least some flexing!
I assume this would limit the movement speed dramatically. Even if the pulley system drives no real loads.
The CD-Encoder is a interesting concept. But thats a project for itself!
My goal is to have a mechanically sturdy and simple solution. As far as possible off the shelf material.
And less expensive then commercial ones. (The last point would be achieved by far with the encoder listed above) You would need 2 of those encoders, 1 ODrive, 2 Motors. That sounds like 600$
Then the whole assembly.
And of course I would go for a eq-mount.
I think you’re forgetting that the encoder doesn’t necessarily have to be mounted directly to the telescope - it can be mounted on the motor directly and still accurately control position.
For your setup, you could easily do a planetary or ballscrew reduction for the motor, instead of the encoder. Then your telescope precision goes up by the gear ratio, since the motor is allowed to make multiple rotations. In other words, your accuracy is actually:
360 * 60 arcmin * 60 arcsec * N where N is the ratio of motor rotations to telescope rotations
Also, you will likely need gearing for the motor anyway to avoid torque ripple creating too much vibration. I’ve successfully used a VersaPlanetary gearbox here, which you can get in 100:1, or you can probably add a 3rd stage to make it 1000:1. NEMA 23 Case & Gearbox for N5065 Motors
I just found a hackaday project (the winning one this year), which uses a really interesting approach to achieve exactly what I was looking for.
They use standard, low Resolution, Optical encoders, but read the brightness of the sensor-led’s. In this way they achieve millions of steps per revolution.
Surly a really interesting approach!
@Wetmelon:
I agree, it would be easyer to achieve the resolution if I measured the motor and then geared it down to reasonable speed. But there lies the problem i want to eliminate! I want it directly driven because of gears have backlash. Every Gear, Belt, Ballscrew has a tiny bit of backlash. And if your talking about Arc-Second accuracy this matters.
One idea to consider is using a spring to preload your measurement in one direction with a spring as a lower cost alternative to uber-precision components to attempt to tolerance the backlash out of a gearbox or other transmission. It depends on what you’re trying to accomplish.
Dexter’s encoder design has lots of resolution, though I’m not convinced it gets you the arcsecond accuracy and precision you might be hoping for without careful calibration.
I want to see your telescope, post updates on your progress, Cheers!
