Velocity Control - What is the max speed possible?


#1

I have a few doubts before setting odrv0.axis0.controller.config.vel_limit to a higher value.
Per my understanding there are a few limiting factors to the max motor speed like KV and voltage, max speed the encoder can handle, load on the motor of course, controller processing.

My fear is, if I overdo it, I can break the board, hence asking for advice for the current 0.4.7 firmware and 12V with AMT102 encoder and the 5065 270kV Motor.
Or in other words, why is above limit set to 20000 by default? With 8192 CPRs, that is 20*60=1200rpm only, isn’t it?

Also what happens internally if something goes wrong?

For example, the way I would love the speed loop to be implemented is to use the encoder for low rpms, at higher speeds the observer is switched to backEMF (sensorless mode). Thus the encoder and its counter is less likely to lose a step causing all to fail. And when getting close to the limit, the encoder position is resynced.
Is it implemented that way? Are my fears unsubstantiated?

Thanks in advance


#2

It is wise to be cautious in general, since these motors have a lot of power.

That said, it’s unlikely you would break the board. But it’s possible that if you overspeed the encoder, the motor may spin out of control. Should that happen though, we do have an overspeed fault that would trigger if the motor spins more than 120% of vel_lim. That requires of course that vel_lim is set to some value that is possible to reach.

I would suggest to put vel_lim not higher than the minimum of the following:

We actually have a planned feature (not yet implemented) that is similar. Though the idea was to simply generate a fault if they don’t match and the speed is sufficient to trust the sensorless. But selecting the sensorless as the primary source for commutation phase, to stay in control even if they disagree, is a good idea.

It’s actually set to around 147 RPM, I think you may have one zero too many. It’s extremely low on purpose to force the user to consider what max speed makes sense in their application and set it accordingly.


#3

Understood. So let’s see the numbers

  • 0.75 * 12V * 270kv = 2430rpm (shaft) --> 2430 * 8192 / 60 = 331’776 counts/s
  • AMT102 has 7500rpm, which is higher than above, so we are safe here.
  • 35000erpm with 14 pole 5065 motor --> 35000 / 14 = 2500rpm which is also slightly higher than above 2430rpm. Hence safe as well but just.

Motor drives a 80mm diameter wheel, target max speed is 72km/h = 20m/s.
One revolution is 80mm * pi = 0.25m
Hence need 20 / 0.25 = 80 revolutions per second --> 80 * 60 = 4800rpm ----beep----
Cablecam will go only half that speed. Bummer.

I can double the voltage. Then the motor will be twice as fast, encoder is fine with that but the 35’000erpm would be exceeded.

Need a motor with dual shaft, same dimensions, same shaft diameter but twice the kv.
Or a fix for that limitation.

Just to clarify, the cablecam should work very smooth at extremely low speeds, e.g. dolly effects. But should also be capable to follow sports activities that could go into the 100km/h range. It does not necessarily need to be one cablecam that does it all but would be nice.


#4

This is incorrect, you need to divide by the number of pole-pairs, i.e. divide by 7. So it’s 5000 rpm.


#5

So then the 5000rpms would work with 24V? Sweet.

I wonder why there is no limit on number of counts per second. What is the maximum frequency the STM32 counter can handle? 0.7MHz and a solid A/B direction recognition is no problem?


#6

Yes I think so.

We haven’t tested to the speed limit (we don’t have a fast enough encoder). However the input filtering settings on the ODrive by default should allow signals up to 3.5MHz, so about 14 Mcounts/s. If you need more speed than that, we can reconfigure the filters, which allows a theoretical max frequency of 21MHz (84 Mcount/s).


#7

Actually, thinking about it, an absolute encoder would solve all of these things.

  • No need for encoder calibration (except the first time)
  • Nothing happens if an encoder signal is lost once a while
  • No problems transitioning from low-speed encoder observer to high speed backEMF observer and back.

Anyway, I have enough information to continue testing.

My current plan is
Mode 1: Use the running wheel of the cablecam as absolut position indicator: Motor encoder is used for odrive only, cablecam controller sends speed commands.
Mode 2: Cablecam controller is configured to use the odrive’s encoder for absolut position. Cablecam keeps sending trajectory commands. Programming the start/end point means setting the odrive’s min/max allowed position ever going to be sent.