Experiences with ODrive and 5kW motor - brake resistor overheating

Ok, so obviously ODrive is not meant for such high powered motors but I thought I’d give it a go. I have 2 very-high power motors to test with it. Rotomax 50cc (5kW) and Rotomax 150cc (10kW).

With the 50cc I have glued an 8mm magnet to the bottom of the shaft for use with an AS5047P, which I have connected via SPI. It works extremely well even though the alignment is terrible both in terms of concentricity of the magnet and mounting of the PCB. No need to recalibrate on boot.

It works very well in position mode, has a lot of torque.
Interestingly I couldn’t get the thing to calibrate when I had the motor soldered directly to the board. I got ERROR_PHASE_RESISTANCE_OUT_OF_RANGE until I put a length of cable between the ODrive and the motor.
The motor is only 21 milliOhm phase-phase according to its specs, so maybe a bit too low for the ODrive.

I’m powering from a Farnell AP60-50 60V 50A power supply, but I note that even when driving 80A through the motor, it pulls less than 2A from the 50V PSU, because the winding resistance is so low and the motor is not moving quickly, so no back EMF.

However, I get some “interesting” faults at high speeds.
In velocity mode, if I try to drive the motor more than 600,000 counts/sec (2200 rpm) then the motor disables, and odrivetool will hang when I try to send the next command (e.g read faults). I assume this is a USB issue. odrivetool comes back when I power cycle the drive.
At this point I notice that the brake resistor is burning hot. I smelled it rather than felt it.

If I lower the voltage to 15V, then I get the same behaviour but I don’t get the USB dropout. The error, apparently is ERROR_BRAKE_CURRENT_OUT_OF_RANGE.

2200rpm would equate to just under 12V back-EMF from this motor, so it should be able to go a lot faster. The AS5047P should be well within its limits too, as it is rated to 28k rpm. However, I know that the AS5047p has about 20us delay at least in sampling, even in incremental mode. Combined with the latency in SPI transmission, it may be that the motor cannot commutate properly at high speed. I can’t explain the brake resistor stuff though. Maybe if the commutation is off, then so is the PSU current calculation i.e. the odrive thinks its going negative when its not.

I will try sensorless mode next. It would be interesting to be able to automatically switch over to sensorless mode at high speeds for velocity and commutation, while still using the AS5047P for position feedback and low-speed commutation.
I guess it should be possible to automatically determine flux linkage and pole pairs too if using an encoder with known resolution.

Awesome! I always wondered how that would work.

Did you try tweaking the max calibration currents? The process is described here https://docs.odriverobotics.com/troubleshooting#common-motor-errors

We’ve seen this brake resistor issue before. We’re not exactly sure what causes it but my guess is that once the motor gets to the speed it needs to be, you can see some really wild swings in acceleration and deceleration about the setpoint. The brake resistor gets fed-forward the braking current to avoid dumping the load into the DC bus, which means the brake resistor ends up sucking a significant portion of the DC current going to the motor. I think a 2 or 4 pole moving average filter would help a lot here.

At 12V and 90% max duty cycle you have 10.8V available. If you want to dump 80A through the resistor, you need a braking resistance of 0.135 ohms. If you’re using the 0.5ohm resistor, you’ll want to put 4 of them in parallel to hit this resistance and still have enough heat dissipation. If you’re using the 2ohm resistor right now, you’re limited to about 5A of braking current, which could very well be hitting the limit.

The whole brake handling logic is on my list of things to improve in the future… but if you’re using RazorsEdge, you can increase odrv.config.max_regen_current to some non-zero value if you only want the brake resistor to kick on after the braking current exceeds some limit.