Hello Odrivers!
I want to use a servo motor to drive a High Torque Vinyl Record Turntable.
This will be belt driven and I will be using it to cut records on a DIY record lathe I’m building.
Motor Requirements: There needs to be no cogging (hope this is the right term) and silence and rotational accuracy at slow speeds (no wow or flutter).
Just wondering if this application is appropriate for the Odrive board and it’s target servo motors…?
Thanks!
Hey dewoof,
Anti-cogging is a feature that I’d like to incorporate into ODrive, but isn’t there yet. Currently, the hobby grade motors that the community has been testing with tend to have high cogging torques. However, non-cogging industrial style servos are available and should work with ODrive provided it’s within the power limits.
Do you have any numerical specs that ODrive would have to be capable of achieving for this task?
How about these:
I would like to have about 10 Kg/cm of torque.
The gearing will be around 10:1.
The TT’s lowest speed will be 16 rpm so the servo motors lowest speed would be about 160 rpm.
The TT’s highest speed will be 78 rpm so the servo motors highest speed would be about 780 rpm.
The weight of the spinning mass will be about 12 Kg.
Speed accuracy/stability should be .01%
Does that help or are you looking for something else?
Hi @dewoof, Welcome to the ODrive communitty!
I think the ODrive would be well suited for your application. Presently I can’t quote any velocity tracking performance, but I think you would do the community a huge favor to pioneer this area. And you certainly would have our support in this.
Here are some ideas on how to obtain good velocity stability performance, in the order of easiest to implement to more difficult:
I assume the torque you quote is at the turntable, and not the motor? If so then you are golden. If you need this torque on the motor, I would consider more reduction.
Cheers!
Here are some back-of-the-envelope calculations that might help:
I once did a test on the Turnigy Aerodrive SK3 - 4250-410kv motor, and it needed 3A of current to overcome the cogging torque and start spinning. So assuming the cogging torque then is 3A worth of torque, and we know that 50A worth of torque is 1Nm on this motor, we can approximate the cogging as a sinusoid with amplitude 3/50 Nm. At the turntable, this is 3/5Nm due to the 10:1 gearing.
At 50rpm at the turntable, 500rpm at the motor, this looks like this, where the factor 7 is from the fact that the motor has 7 pole pairs.
Assuming 0.4m diameter 12kg turntable, we get 0.24 kg m^2 moment of inertia (calculation).
We take the ripple torque, divide by the moment of inertia, and get angular acceleration, and hence integrate to get angular veloceity: WA link. This gives a ripple magnitude of about 7 mrad/s, which as a ratio of the original speed is 0.1% error (calculation).
So here we see that just from the weight of the turntable alone we can get 0.1% tracking error. The closed loop velocity control can only serve to improve on this!
Thanks madcow,
looks promising!
I’m definitely talking about torque at the turntable, not the motor.
If I double the mass to 24kg, define 0.3m as the diameter I’m most interested in, and plug these values into your moment of inertia equation:
24kg * (0.3m)^2 / 2 = 1.08 kg m^2.
I get a quadrupling of the moment of inertia.
Not being able to follow the rest of your math forces me to ask the question:
Does this cut the speed/tracking error by 1/4 bringing it down to .025% ?
Is so, that would be getting pretty close to what I want/need.
Using a high resolution encoder is certainly a possibility too.
Would the 600PPR encoders you include with the kit be high enough?
You need to be careful, the moment of inertia equation for a disc has the radius squared, not the diameter. So you actually get 24kg * (0.15m)^2 / 2 = 0.27 kg m^2.
But otherwise, yes the velocity ripple magnitude should be linearly inversely proportional to the moment inertia, as you suggested.
So I went and read the datasheet for an equivalent encoder (the ones from china don’t have a datasheet at all…), and the phase noise is actually 1/2 of the resolution, so basically 1/4800 of a turn. As a rough approximation we can say that we have 2400/(4*7) = 86 counts to average over a quarter electrical cycle to get the speed estimate for the peak of the velocity vs the baseline.
Mathematically, we have a noise magnitude of 1/4800 of a turn, and we average over 86 counts, we get a final averaged phase error of sqrt((1/4800)^2/86) = 0.00002246516 turn.
However we need to identify the frequency error from a phase drift at an excitation of 60 hz (500rpm * 7pole pairs) = 380 rad/s. From integrating sinusoids, we make the argument that a 1 turn/s error at 60Hz will at it’s peak drift by 1/380 turns. So our detection needs to compare to 1/380 turn. We take the ratio of 0.00002246516 turn to 1/380 turn and get 0.00002246516 * 380 = 0.0085367608 = 0.85%.
In other words, the mass of the turntable already silences the velocity error so much that this (600PPR) encoder is not able to detect it, and hence it can’t improve much further.
If you use an 2000PPR encoder instead, you get just about 0.1% error: WA link.
All of the above should be taken with a grain of salt, since the quarter-electrical-rotation average is not what actually happens, but instead a 1st-order PLL is used.
Follow up questions to help me figure out which way to go:
Thanks for all this!
Sure no problem.
It’s worth noting that it makes sense to go for only one or the other of the above: i.e. either active or passive cogging torque reduction: they don’t reinforce each other, they just work independently. For instance, if the passive reduction already makes it smooth enough that the encoder can’t pick it up, the encoder can’t help any further.
Of course you can still get a high resolution encoder and both 14 and 28 pole motors, and experiment to see what works.
Also, I should say, while cogging torque identification and open-loop (feed forward) cancellation is not on the high priority for me to implement, it shouldn’t actually be too complicated.
A simple implementation could consist of rotating the rotor very slowly around, with feedback control, and sampling the state of the integrator output: i.e. the steady state current required to hold the rotor in place. Do this going both forward and back, and average the result, to cancel friction. Store the result in a table in the firmware: as current (i.e. torque) required to be applied as a function of rotor angle.
When running the motor: Interpolate the table, and apply this current as a feed forward term.
I’m happy to support you if you want to implement this.
That makes sense, thanks.
What about a fluid coupling on the motor to gear assembly (like automatic transmissions in cars),
Would that be an effective way to average the cogging out of the system?
Actually, you could put a flywheel on the motor, then couple the motor to the turntable via a spring. This should make for a 2’nd order filter, which should very significantly reduce the effect of the cogging.
This has the downside of reducing the control authority of the speed of the turntable, so the bearings on the turntable have to be very good, and the load very even.
Even just a flywheel on the motor could be a good idea: the moment of inertia on the motor side is 10^2 = 100 times more effective of filtering than the flywheel moment of inertia, due the the gear ratio.
Spring?
I’m not seeing how that works - do you mean a spring coupling in between the motor and the gear?
So like Motor - flywheel - springy coupling - turntable.
But I think you can just flywheel the motor enough and you should be good, not worry about the spring.
A flywheel on the motor would be very doable - excellent idea.
I think I will head in that direction to start with but will also put a hi-res encoder on there for speed data and to see how well it works to mitigate cogging on it’s own…