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?
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:
75% * bus voltage * motor kv in RPM, converted to counts/s
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.
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.
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?
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).
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.
I’m aware that this is an old topic, but I’m wondering if the 35,000 ERPM limit still stands or has that issue been resolved? (Read that thread as well, but flew right over my head…) If so, what is the maximum ERPM that the Odrive can handle?
Basically, I’m considering the Odrive to run in velocity control a 50V 20A 14,000 RPM (280 KV) 3-pole sensorless motor that would nominally run on 42,000 ERPM. I have been using the VESC before with three phase shunts and three dedicated AD8418 amplifiers, I see that the Odrive is using only two shunts, without dedicated amplifiers, so I’m assuming it has higher error on current measurement? I also saw a mention in the other thread that 42,000 ERPM was cutting close to the stop-band of the current controller bandwidth? I struggled finding any updates on it, so that’s why I’m wondering what is the real maximum speed.
On ODrive v3, it still stands. Yes, the two shunts is a bit of a problem, and because of it we can only hit about ~ 75% of the theoretical max speed. So ~10,500 rpm in your case (31.5k eRPM)
The current controller bandwidth defaults to 1k rad/s, with a max of about 4k.
ODrive v4 has 3 shunts and will (pending firmware support) not have these issues.