I was doing some tests and had an accident - the positive lead of my power supply (a LIPO capable of high discharge rates) touched the (2ohm) brake resistor on my odrive. A great deal of current went through the resistor, but the odrive still functions; it boots up, communicates fine, and even controls the motor just fine. However, the same motions that were executed with no problems before this accident are now producing ERROR_BRAKE_CURRENT_OUT_OF_RANGE motor errors (accompanied by a shutdown of that channel). It seems the circuitry related to the brake resistor has been fried. Is additional information required to diagnose the problem? Is it possible to repair this (whether I do it or send it in to odrive) or is the board toast?
Hi Mike,
Make sure that you change the brake resistor.
Since the resistance is fairly low i.e. 2 Ohm, so it is highly likely that brake resistor has burnt out.
Regards,
Thanks for the response. Unfortunately, this does not seem to be the case; I replaced the resistor with another one, and the problem persists (I also independently measured the resistance of the shorted resistor, and it stills seems fine). It seems to me that the short circuit blew whatever circuit pathway(s) exist between the brake resistor ground terminal and the power supply ground.
Would appreciate some input from @madcowswe - is my board fried? Can it be saved?
@Mike, which side of the resistor did you short to DCBus?
If you look at the schematic (last page), a short to DCBus on the -ve side of the resistor could have blown the PCB trace to that side of the connector, potentially. Check the continuity between Brake -ve and GND.
If the short was on the +ve side, then it will have blown up the low-side FETs (Q27,Q28), but it should still work because they aren’t actually used to turn the brake on.
However, if it blew up these FETs then it could also have blown the gate driver U6.
However, the BRAKE_CURRENT_OUT_OF_RANGE error only happens when the braking duty cycle requested exceeds 90% (or is NaN, or negative for some reason - see low_level.cpp)
You may be able to avoid the error (and save some energy) by setting odrv0.config.max_regen_current i.e. send the energy back to the battery instead of into the resistor. This might only be available on development branches i.e. RazorsEdge though.
I’m actually not sure precisely what happened; I previously thought the short happened because the positive lead wire from my battery made contact with the brake resistor housing, but I just probed the resistor housing and it seems to be isolated from both of the terminals (which, now that I think about it, makes sense). So now I’m not really sure what happened, except that I saw some smoke - which I assumed/hoped had just come from the insulation on the brake resistor wires and the DC negative wire - and the brake resistor was very hot. I’ve inspected the board repeatedly and see no signs of physical damage.
I probed with a multimeter and there seems to be very little (immeasurably small for my multimeter) resistance between AUX - (negative) and DCBus ground; so, as far as I can tell, that pathway has not been blown.
All that having been said, I did some more tests and am still seeing consistent failure (brake current out of range error) when doing rapid decelerations. If I limit the deceleration rate (via trap_traj config), it seems I can avoid the error, but this obviously limits the utility and reliability of the board.
As for rerouting the power into the battery - I’m using a lipo battery as my power supply, and as I understand it, they are quite sensitive to overvoltage; is regenerative braking safe in this context?
LiPo are sensitive to overcharge, and it’s better to think of regenerative braking as a current source, rather than a voltage source. What I mean is, when connected to the battery, the bus voltage will not rise very much at all because you are charging the battery, not just the onboard capacitors.
Unless your application is one where you might actually send more (total) energy back to the battery than you pull out of it, (e.g. an electric car going downhill starting with a full battery) then it will be safe, so long as you stick within the charging limit of the battery i.e. if you have a 5Ah battery rated to 2C charge, don’t set max_regen_current higher than 10A or else you might send it current faster than it can sink it.
If the brake resistor got hot, then I’d guess the smoke came from the resistor itself, plus the (unused?) low-side mosfet on the brake drive and/or the gate driver chip for it.
I am seeing similar issues with a large motor though, and never had any smoke. Also someone else posted earlier:
What is your motor.config.requested_current_range set to?
Thanks for the info on lipos/regen braking; sounds like something I should try. I don’t have the latest firmware on the board at the moment, but it’s my understanding that if I set odrv0.config.brake_resistance to 0 and/or physically disconnect the brake resistor, the odrive will redirect the power to vbus.
The issues I’m seeing were completely absent prior to this accident and are occurring consistently now; it seems to me very likely the short was the cause.
motor.config.requested_current_range is set to 60 (default), and current_lim is set to 35.
You’ll need to set brake_resistance to 0 to suppress the error. Physically disconnecting it won’t change anything. And to further protect your battery, you can also set the dc bus overvoltage limit to be whatever the max charging voltage of the battery is.
Also, I fail to see how the brake drive circuitry being fried would cause the error - if it wasn’t working then it would just act like it were disconnected.
More likely, the thing that is fried (or perhaps only slightly damaged) is the current sense amplifier or shunt resistor, since it’s really only a faulty phase current measurement that should cause this error.
Are you sure that both axes are working correctly except for sharp deceleration? Do they both hold position properly all the way through the electrical cycle?
Try setting the requested_current_range to 180A (you need to save config and reboot to apply this change). This may reduce the noise on your current measurements (at the expense of resolution).
Do you know what the motor inductance is? Is it unusually low?
Try also reducing motor.config.current_control_bandwidth - it might be an unstable current controller causing this too.
Thanks for all the advice; after disabling the brake resistor, I was able to increase the accel/decel rates back to pre-accident levels and the odrive seems to be holding up. The bus current seems to peak around 1.0-1.5A during rapid accelerations & decelerations, which is well within spec for the battery. I’m relieved that the board is not a total writeoff.
I didn’t tinker with the requested_current_range or current_control_bandwidth (which have been set to default values all along), but since this issue only popped up after this short circuit accident, I don’t think they are major factors.
I don’t have a meter to test my board right now, but these aren’t normally connected. There is a transistor in the way. I would inspect those MOSFETs for damage.
On the V3.5 schematic (which I understand is identical to V3.6 except for some filter cap values) pin 1 of J23 (Brake -ve) is connected directly to PGND on sheet 4. I’m not exactly sure why it needs a totem-pole driver at all…
Originally it was going to allow a DC brush motor iirc?