Dears, first of all, what an incredible library, congrats to everyone involved and thank you so much for making this happen!!
I am just about starting my first project, ESC should arrive tomorrow. I will run a 2700kv motor which is geared down to the output with a belt by 20:116. I would like to measure the ouput shaft with a nagnetic SPI sensor rather than the motor directly, and put it to velocity control, can this be done by the library? Target max output shaft speed is around 50 rad/s.
Thanks for any comment!
What driver/ESC are you planning to use? A 2700kv motor will likely have low phase resistance and need a fairly high current driver/esc.
You’ll need a sensor on motor side (to do FOC alignment/closed loop), why do you also want a sensor on output shaft? I can understand it for angle control but it is less clear for velocity control where output speed can be calculated from gear ratio.
Or were you hoping not to have a sensor on motor?
I will get the B-G431B-ESC and I have some AS5048A Encoders here.
So, I hoped to get rid on the sensor on the motor, and have the one on the output only. There are some practical reasons, in my current design it is much easier to integrate on the output shaft. But also, on the Motor I will have something in the range of 300 rad/s, I think I was reading here this is too much for the mentioned sensor.
Any suggestion if this motor/sensor/target speed combination is going to work?
300 rad/s = ~50 revs per s = ~3000rpm . As long as you are sampling roughly an order of magnitude faster the sensor should be ok with sensor attached to motor. You won’t be able to use any closed loop control with sensor attached after gear. Closed loop requires exact knowledge of where stator windings are w.r.t. rotor poles and this will be lost (or very hard to determine) through a gear.
@Marc_O is our high speed specialist . He had to do quite a bit to get to 9000rpm so will better know the challenges.
The datasheet of the AS5048A doesn’t list any maximum speed. I think this sensor will do just fine with 300 rad/s.
In theory it is possible to attach the sensor to a geared output. For closed loop control It’s very important that the sensor is connected rigidly with a very low amount of play and backlash. This might be difficult with belt reduction.
Thanks everybody, I am excited to give both options a try!
I really wouldn’t attach the sensor responsible for the electrical alignment of the motor via a belt. Even a small amount of slip will cause the motor alignment to be wrong, with loss of torque as a result (at best - at worst, big currents and burnt motors as the PID tries to adjust to incorrect sensor values).
But a good solution can be to do both - one sensor on the motor, for alignment, and one on the output, which is used to drive the velocity control. Depending on your application’s needs you might get away with a less accurate, cheaper sensor on the output side, as the velocity control loop doesn’t have to run as fast, and you can do filtering to get smoother values.
Agree with @runger. The mechanical impedance will introduce uncontrollable oscillations and even a tiny error will get amplifiied until resonance and you will rip the setup apart. At best you lose the setup. At worst you get hurt. You can use the geared sensor only as a target and not as a motor control feedback mechanism. you also need to program the entire physics of the system. I have worked with the P version and the error is not a joke. this sensor is very fast but at 14 bits rather noisy.
@Owen_Williams, you are quite right.
@Chris, you have to put an encoder or hall sensors (in my case, in a previous topic) before the gear for the motion control (SimpleFOC here), in fact on the motor shaft. Then if you have to get more accuracy, of course you can put another encoder after the gearbox, belt ratio in your case, to know where you are with much more accuracy if this one got higher resolution.
After keep in mind that i.e. if you have a ratio gearbox of 1: 50 with 4 pole pairs and 3 halls so, you will get a velocity / 50, but a resolution higher at the end of gearbox in exemple, 24 (pulses per turn motor without gearbox) x 50 = 1200 counts/revolution.
Of couse, it is the same way with an encoder with more resolution per turn.
Anyway, to perform this at high velocity, the encoder processing has to be fast (sensor, and also optimise the code) because this one slow down the processing of the FOC, with the interrupt routine and to avoid an instability behavior thereafter.