I’m getting ERROR_CURRENT_LIMIT_VIOLATION at power levels well below what I would expect. With the default motor.config.current_lim value of 10A, I can only spin to 4 revs/sec before getting the error. Bumping current_lim to 20A gets me to 7 revs/s. This is well below the 60 revs/sec I’d like to get to. I don’t know what an appropriate current_lim value is, but at this rate, needing>100 Amps seems too high.
I have a 56V version 3.6 running a 2 kW rated eBike motor (like this). Hall sensors are filtered with 47 nF caps, and the motor wires are wrapped twice through a ferrite ring.
Changing the current_control_bandwidth from 100 to 50 doesn’t seem to do anything. I don’t think it’s a controller gain thing anyway since the highest sustainable speed is the same whether I sneak up on it or jump straight there from 0.
I suspect the motor is fine. I’ve run it with a different controller, and the phase resistance/inductance look ok at .06, .00008 respectively. Is there a problem, or do I just need to toughen up and set my current_lim to 120A?
Can you plot
Id_measured? This will give us an idea of what’s going on.
You can also plot the
vel_estimate, as that will determine how much current is commanded.
I ran the motor for 5 seconds at each of the speeds shown and recorded as many data points as I could. You can see it kick off with the error at 6 revs/sec. That vel_estimate is nasty looking… encoder problems?
And here’s just the time series for the same data (clipping off the end cases where the controller was in error)
First off, thanks so much for gathering and plotting coherent data! Makes life much easier
Yeah. Since Id_measured goes up with each velocity, that means your current controller is losing track of the motor and the current vectors are misaligned. Setting the current lim won’t really help. That usually indicates some sort of encoder problem. Could be noise, but with the ferrite ring and the 47nF caps you should be fine
What do you have for
motor.config.current_control_bandwidth? Both should be probably in the ~ 100 ballpark
Thanks, both those values =100.
I tested things in sensorless mode today (plots below) to eliminate badness from the encoder. Check out the noise in sensorless_estimator.vel_estimate on the bottom row. Even icky-er. My sensorless target vel=200 rad/sec with accel=20 rad/s/s. Why it only went up to 10 revs/sec (60 rad/sec) is unclear to me.
Sensorless operation is ok for my needs, but things still seem way off. Shouldn’t Id_measured be close to zero for a well tuned system?
The phase wires for the motor and the hall sensor wires run through an umbilical that is about a meter long. Do you think stripping that off and twisting the phase wires would help things? (I didn’t do real well in physics II, so this is a little like black magic to me…)
FYI the input units are in rev/sec not rad/sec, someone else just had this question. You’re off by 2*Pi
It could be that your motor has very trapezoidal bEMF instead of sinusoidal?
Hmm, maybe. You can also try the ferrite rings from the shop (or similar items) Ferrite Ring ESD-R-28C-1 — ODrive
Is this perhaps an extremely coggy motor? Does it want to snap to certain positions as you move it by hand?
Cogging acts like a torque offset as a function of rotation, and so can cause a lot of error in torque control (and in velocity control, especially if the system has low inertia, like a motor moving without a load.)
It can be calibrated out - you could try the (still very experimental) anticogging feature of ODrive.
I’m using the ferrite ring from the store, but I’ve got a connector on there I want to replace. I’ll keep poking.
Per the documents at the link below, the units are radians. Revs has been the standard everywhere else, so I was surprised to see radians here. Are those old docs that need updating?
" The sensorless speed ramping parameters are in
accel (in [radians/s] and [radians/s^2]) control the speed that the ramp tries to reach and how quickly it gets there."
Thanks. I’ll give it a shot.