High current noise

[geez]

I’m experiencing rather high current noise on my setup, which increases with speed (as I would expect). However, the noise is substantial, even at moderate speeds.

Setup:

• T-Motor 8012 (100 KV)
• AS5048A absolute encoder
• 40V power supply

An example:

Here, peak-peak measured current is around 8A already at ~140 rad/s (~1193 rpm). This seems excessive. Am I correct here or is that expected?

I can quite consistently reach speeds up to 180-200 rad/s, but any higher I usually get a combination of the following errors:

• MOTOR_ERROR_CURRENT_SENSE_SATURATION
• MOTOR_ERROR_UNKNOWN_TORQUE
• MOTOR_ERROR_UNKNOWN_CURRENT_MEASUREMENT
• CONTROLLER_ERROR_INVALID_ESTIMATE
• ERROR_BRAKE_CURRENT_OUT_OF_RANGE
• MOTOR_ERROR_CURRENT_LIMIT_VIOLATION

I have tried the following:

• Decrease and increase current controller bandwidth (250 up to 5000)
• Setting high REQUESTED_CURRENT, in which case I got poorer current control performance, no increase in speed, and eventually:
  • MOTOR_ERROR_CURRENT_LIMIT_VIOLATION and
  • MOTOR_ERROR_UNKNOWN_TORQUE

Considering the given speed limits in the docs:

1. motor RPM limit: What is meant here?
2. encoder RPM limit: Using absolute AS5048A. No limit, in datasheet at least.
3. motor KV * 0.7 * Supply voltage: 100 * 0.7 * 40 = 2800 RPM =~ 293 rad/s.
4. 35000 eRPM / # of motor pole pairs: 35000/21 = 1667 RPM =~ 174 rad/s <— Critical limit
5. (840M counts/minute) / encoder cpr: 840e6 / 16384 = 51270 RPM

I’m aware of these topics:

Velocity Control - What is the max speed possible?

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 defau…

ERROR BRAKE CURRENT OUT OF RANGE error at high speeds

I get the motor error ERROR_BRAKE_CURRENT_OUT_OF_RANGE when pushing a BLDC to high speeds. What are the conditions that trigger this error? Is it something that can be adjusted? Thanks.

and I suspect I am somehow dealing with that eRPM limit. Is there anything I can do here? Is the observed behaviour expected, even at lower speeds?

[Wetmelon]

@geez

motor RPM limit: What is meant here?

Mechanical limit before the bearings explode.

I don’t know why you’re doing all your math in rad/sec, that’s quite confusing lol. Are you talking about electrical radians / sec, or mechanical? All of the values we use (e.g. input_vel and vel_estimate) are in terms of turns/sec, or rev/sec, not radians.

600Hz * 21 pp = 12,600_{rpm} = 210_{rev/sec}

What you’re seeing is the current controller going somewhat unstable. In my experience, the AS5048A isn’t great at high speed. It’s a bit noisy, and some other nonlinearities hurt its performance quite a bit. Maybe you can try reducing or increasing the encoder.config.bandwidth to help?

[geez]

Há, yeah, sorry about that… I’m a roboticist by nature and I do everything in rad/s where possible These are mechanical rad/s, of the motor rotor. For clarity:

turns2deg	= 360 # One turn in deg
deg2rad		= math.pi/180 # Degree to rad
turns2rad	= turns2deg*deg2rad # Turns to rad

Thanks for the suggestion on encoder bandwidth; I haven’t tried that yet. Given that the iq-setpoint is very stable, I assume the commutation is getting messed up because the position isn’t quite right?

[Wetmelon]

@geez

because the position isn’t quite right?

That’s the usual cause. In general, the voltage vector lagging or leading the optimal value will eventually cause it to go unstable. Phase lag due to high speeds, encoder noise, or (usually) fast acceleration becomes a problem.

[geez]

Thanks again for the input. Yeah, that does make sense. I’ve now tried different values for both encoder.config.bandwidth and motor.config.current_control_bandwidth; decreasing both (to 500) and increasing both (to 3000) in every possible permutation. Although increasing the encoder’s bandwidth does seem to slightly reduce the noise at lower speeds, the instability remains. I don’t suspect there is anything I can do, electrically, to remedy this?

I see the AS5047P mentions high speed capability on its datasheet; do you reckon I’d have a better result with that?

[geez]

@Wetmelon would you have any experience with the AS5047P?

[Wetmelon]

Yep, should work fine… but the AS5047/AS5048 definitely seem to have more noise, and have a lower top speed, than the CUI AMT incremental encoders. I haven’t dug into the reason why yet. It could be propagation delay?