DC_BUS_OVER_VOLTAGE error triggers

[eliasoa]

Hello!
I am using two ODrive S1s with 16384 CPR ABSOLUTE RS485 ENCODER WITH CABLE FOR ODRIVE PRO OR S1 and DUAL SHAFT MOTOR - D6374 150KV. I supply them with a 24V 4.5A 100W power supply.

The plan is to use them in a cable-driven parallel robot, something like this: RopeBot - Prototype 2: A cable-driven robot with 3 degrees of freedom (youtube.com)

I currently have two of them mounted as shown:

I control the position of the wooden block by reading each motor’s encoder position and using it to calculate the direction to “pull”. To ensure tension in the cable, I use Torque mode and let the torque request sent to each motor vary by ± some number to get enough difference in torque to move the wooden piece.

This works perfectly fine when the velocity limit is set to <= 4 turns/sec. This is a bit slow, so I want it to move faster, but the moment I turn it higher, DC_BUS_OVER_VOLTAGE errors trigger, either in one of the ODrives or both.

{
“fw_version”: “0.6.9”,
“commit_hash”: 2499272527,
“product”: “5.2.0”,
“active_errors”: 134217728,
“active_errors_str”: “BRAKE_RESISTOR_DISARMED”,
“disarm_reason”: 256,
“disarm_reason_str”: “DC_BUS_OVER_VOLTAGE”,
“procedure_result”: 3,
“procedure_result_str”: “DISARMED”,
“last_drv_fault”: 0,
“internal_issues”: 0
}

When logging the v_bus voltage, the voltage spikes when the setpoint change occurs, and regardless of how much margin I configure the motors with, they always trigger the error. I have tested with a bench power supply which I cap at 15V, and configured the trip level to 24. It still triggers.

I also tried to increase the brake resistor to 2.05 ohms in steps, as suggested in the documentation, but this did not help either.

Is there something I am missing here, or is it just not possible to get more speed out of the motors in torque control?

I am grateful for any and all input

[solomondg]

Hi! Hmm… there’s a chance you’re being affected by an issue we had. Can you try updating the firmware to the devel channel, and then back to normal?

odrivetool dfu --channel devel

then

odrivetool dfu

To explain, here may have been an issue with the factory configuration on a few units - updating to devel and then downgrading back to the mainline firmware channel will fix it, if that was the case

[eliasoa]

Thanks for the reply!
I have tried to update and “downdate” both ODrives, but this did not solve the problem.

Using a velocity limit of 4 turns/s everything works fine

When I turn the velocity limit up to 5 turns/s the wooden block oscillates back and forth, see picture:

before one or both ODrives throws an error:
{
“fw_version”: “0.6.9”,
“commit_hash”: 2499272527,
“product”: “5.2.0”,
“active_errors”: 134217728,
“active_errors_str”: “BRAKE_RESISTOR_DISARMED”,
“disarm_reason”: 256,
“disarm_reason_str”: “DC_BUS_OVER_VOLTAGE”,
“procedure_result”: 3,
“procedure_result_str”: “DISARMED”,
“last_drv_fault”: 0,
“internal_issues”: 0
}
I also used the inspector to monitor the vbus_voltage on both ODrives:

and compared to velocity limit = 4:

it’s clear to see that when it crashes, the vbus voltage is really close to the limit set in the config. The power supply delivers 24 V.

[solnor]

Hi,
I have the exact same problem with my S1 driver. I run them in torque mode and the control system seems to request too much voltage and then it trips the DC_BUS_OVER_VOLTAGE error on the driver. When I set the DC bus overvoltage trip level in the GUI to a higher voltage, the control system also just requests more voltage and trips the error anyways.
What is the fix for this? Is there a saturation limit I can set somewhere? Can this error be disabled entirely?

Out of curiosity: What is the purpose of this error?

Thanks!

[tentpole]

Hi - I am seeing a similar issue as the original poster here. @solomondg - was this issue fixed by any chance?

Any other debug steps?

[solomondg]

Hi! This is likely caused by improper brake resistor connection, or higher resistance in the brake resistors than expected – try enabling DC bus voltage feedback on the brake resistor, and let me know if the issue persists.

[tentpole]

Thanks for the quick response - I’m just testing the setup in browser based GUI - I clicked the “use brake resistor” checkbox and entered in the measured resistance at the wires (2.1ohms). Is there somewhere else I need to enable the DC bus voltage feedback or is checking that box sufficient? I’m using the S1 version with soldered on screw terminals so I don’t think the connection is the issue.

[tentpole]

It does seem to hit the “was_saturated” latch immediately upon entering torque mode & the measured current is NaN

[solomondg]

NaN measured current is normal, the S1 doesn’t have that functionality at the moment. The was_saturated thing is interesting. Could you show me a picture of the top side of your board, as well as the hw_version_revision property in the GUI?

[tentpole]

Pictures attached, thank you.

[solomondg]

Strange – @Samuel what’s your thoughts here?

@tentpole What bus voltage are you using, and what’s your current_soft_max?

Can you show how the wires are soldered/connected to the brake resistor?

[tentpole]

Using a 24V, 350W meanwell supply. Current soft max is 50amp,

[solomondg]

Soldering looks fine. One thing to note is that at 24V a ~2 ohm resistor will only sink 12A at 100% duty cycle, so chances are when you’re hitting higher currents your brake resistor is saturating. I’d recommend trying dropping the current_soft_max to ~10A, and get a lower value brake resistor (maybe 0.5 ohm to sink 48A at 24V).

[tentpole]

Hi @solomondg - I got a new shunt resistor hooked up that’s 1/2 ohm and set the current_soft_max to 10a but I’m still seeing the same behavior where the v_bus_voltage will spike and trigger the error.

How quickly should the shunt be kicking in? Is it possible it’s just not responding fast enough or something? (I don’t know how these things work).

[tentpole]

Ok figured it out, definitely user error. In case anyone else is google searching this in the future. I didn’t realize you had to set manually set enable_dc_bus_voltage_feedback to true & the ramp voltage values after you went through the initial gui configuration, I assumed setting the brake resistor value and checking the box during configuration was enough. I updated these values and now it works as expected

[solomondg]

Glad to hear you got it figured out! Yes, we should definitely have support in the GUI for automatically setting the feedback voltage ramp.