ODrive Browning Out Suspection

1

Hi,

I am currently having an issue with my S1 that I suspect is a “browning out” problem. During use, sometimes connectors get jostled the wrong way which causes power to not be fully delivered via USB-C from my Raspberry Pi. This causes the ODrive to repeat the previously sent command until I kill the system with an E-Stop. The message I get in the middle of the control loop has arbitration ID 0x04, instead of 0x09, and when I try reading the message the same way I do in closed loop mode, get_encoder_estimates reads (-2.86e-42,0) for motor position and velocity (note the first number is usually just any very small number). It seems as if the motor loses itself and spins indefinitely unless I cut power myself. Upon rebooting, I check for a heartbeat and do not get one until I reset the connection between my Raspberry Pi and ODrive, the power cycling always seems to do the trick.

I try to send a message over the CAN bus, but since the connection has been effectively severed during that moment, the message is not received.

I guess my questions is twofold: am I correct this is some browning out error? If so, I was wondering if there was some functionality I might be able to implement where if this were to occur, the motor should shut down. On top of better securing my connectors, I was wondering if there could be a better absolute failsafe option.

Thanks so much,
Dom

2

“fully delivered via USB-C from my Raspberry Pi”

Do you mean that the rPi is browning out? Or that the S1 is being powered over USB from the Pi, and the connection is being knocked?

am I correct this is some browning out error?

I don’t think so, if the S1 is connected via DC+ power as well, then it’ll draw from that, doesn’t need USB.

On top of better securing my connectors, I was wondering if there could be a better absolute failsafe option.

You can always enable the watchdog, we recommend that.

All that being said, this generally shouldn’t happen. The expected behavior is that when the CAN connection is restored, the ODrive continues sending heartbeats/other periodic messages typically. Maybe you have autobaud set, and the ODrive is dropping back into scanning mode due to the bus-off detection?

Some questions:

  1. What CAN adapter are you using for the Pi?
  2. Does this still happen when the S1 is unplugged over USB-C and only powered from DC+?
  3. Can you send a few pictures of your wiring?
3

Hi,

  1. This is the CAN Hat I am using: https://www.waveshare.com/2-ch-can-hat.htm

  2. Maybe I set this up wrong, but the ODrive does not display anything from the LED unless I have the Raspberry Pi plugged into it as well. I do not see a cyan LED color when the power is being delivered to the ODrive unless the USBC is plugged into the ODrive at the same time. I power the S1s with 2 6s LiPo batteries. Any idea why this might be happening?

  3. I attached a drawing of the wiring because it is quite a messy setup currently so pictures do little to help. Let me know if you require more pictures and I will try to take some informative ones. The rPi is directly connected to wall power. We have the drives powered by the battery and the rPi isolated from that.

For various predetermined reasons the system i am using runs realtime on a Pi, and the code is quite heavy, so the loop rate is variable. I have setup the ODrive to not send cyclic messages, but instead explicitly send/receive when prompted. Also, I am running on firmware 0.6.9.post0. Watchdog is not enabled (I think because I don’t have cyclic messages on?), and autobaud should not be enabled because I am on an older firmware.

IMG_4172
IMG_41721920×2560 217 KB

4

Maybe I set this up wrong, but the ODrive does not display anything from the LED unless I have the Raspberry Pi plugged into it as well. I do not see a cyan LED color when the power is being delivered to the ODrive unless the USBC is plugged into the ODrive at the same time. I power the S1s with 2 6s LiPo batteries. Any idea why this might be happening?

Yeah this is super abnormal. Do you think you might be shorting the 5V rail somehow? Does it still do this when you disconnect everything (except the power) from the S1?

5

I’m unsure how I could be shorting that rail, unless hitting the EStop during use caused some kind of issue? The relay I have set up is meant to sink a lot more current than we could ever pull. Just checked, and this does happen even when everything is disconnected except for battery power.

Also should note I have 2 identical setups as part of the same system that only share battery power. The rPis, CAN connections, and all other parts are isolated from one another. The lack of LED power happens for both systems. I don’t recall ever plugging these into the Pis without the USB isolators, so I don’t think I caused a ground loop at some point.

6

I’m unsure how I could be shorting that rail, unless hitting the EStop during use caused some kind of issue? The relay I have set up is meant to sink a lot more current than we could ever pull. Just checked, and this does happen even when everything is disconnected except for battery power.

What was your original order number? I’d like to swap out your S1 and see if the problem persists.

Also should note I have 2 identical setups as part of the same system that only share battery power. The rPis, CAN connections, and all other parts are isolated from one another. The lack of LED power happens for both systems. I don’t recall ever plugging these into the Pis without the USB isolators, so I don’t think I caused a ground loop at some point.

That’s very strange. I think some pictures of the wiring would be very helpful. What encoder/others do you have plugged into the S1?

If you disconnect everything from the S1 except for power (e.g. unplug USB, CAN, encoders, etc), does it still not turn on? Or does the green LED turn on but the RGB one doesn’t? Etc.

7

The order number was 11166

I have nothing else plugged into the S1, I use the onboard encoder and no other accessories. I attached some pictures of the setup, its a bit tough to follow but the green and white cables are the CAN wires, and then the power gets delivered through the relay from DC+ and DC- that is gated by the relay and EStop button. The other CAN connection is for intermittent messages the Pis send to each other.

EDIT: the ethernet from the Pi is to my PC so I can SSH in, and the other USB is a connection to an external microcontroller board. The ODrive is connected to the USB isolator.

I tried about everything. If I connect the batteries and run my code, when I ask the S1 for a heartbeat, nothing is returned and my code errors out. No LEDs come on at all when there isn’t any power from the Pi as far as I can tell.

Here are some pics:

motors
motors1920×2560 466 KB

IMG_4186
IMG_41861920×2560 353 KB

IMG_4185
IMG_41851920×2560 348 KB

IMG_4190
IMG_41901920×1440 206 KB

IMG_4188
IMG_41881920×1440 222 KB

8

Interesting. So the only way this can happen is if you nuked the 5V logic rail somehow, but the 12V gate drive rail was still OK.

Here’s something that would be super super useful:

  • Remove the S1 from the motor, disconnect CAN and USB
  • Connect DC+/DC- directly to a bench power supply via the screw terminals (so we don’t have to worry about any soldering issues with your connectors).
  • Give it about 24V from the bench supply at some nominal safe current limit - maybe 0.1-0.5A.
  • Check what the reported current output is from the bench supply. Should be something like 0.01-0.05A.
  • Measure the following test points (on the back of the board). All measurements can be done relative to DC-
  • T7, T8, T9, T10, T30, T31, T12, T13, T1

Diagram below w/ test points marked to make it easier:

2025-08-06_08-58
2025-08-06_08-581708×1467 366 KB

Careful when measuring the test points, they’re pretty small and you don’t want your multimeter probe to slip. Once you’ve done that, please let me know the voltage at each!

I have two concerns with what I’ve seen from your pictures:

  1. You have a piece of plastic for mounting that’s sitting directly on top of the 5V regulator, marked with an arrow. This definitely makes me suspect mechanical damage.
    image
    image808×601 69 KB
  2. As far as I can tell, you don’t have any precharge or soft-start circuit. This means that whenever your contactor closes (connects), you’re slamming the S1s with your full bus voltage. That causes a massive inrush current, and can spike the input voltage really high (I’ve seen to 80-90V from a 48V supply with uncontrolled inrush), and cause damage. I would strongly recommend adding a second relay/contactor in parallel with the main bus one, with a ~1-2ohm resistor across it – this way when powering on the system, you can close the precharge contactor for a second or two before closing the main contactor, so that the bus voltage at the S1s can safely ramp up with managed inrush current.
9

Got it. I’ll follow up in this thread when I test all of those components! Thanks for your help so far!

10

Tested! Here are the results. The lack of 5V makes me think that the regulator is damaged.

image

I appreciate the advice about implementing a soft start circuit. I will look into adding one in to avoid this issue in the future with other drives. I am not sure if it was mechanical damage that caused this or something else, but better safe than sorry!

For future reference, what exactly are these T pins? Just so I know what I’m testing for in the future! :slight_smile:

EDIT: Also, reported current is 0.031A

EDIT2: Assuming the worst case, what wattage resistor should I be looking at for the soft start? Most datasheets report continuous, unsure of what peaks they can handle.

11

Hi,

Replacing the drivers helped, and the watchdog is functional. Thanks for that!

However, I am having trouble currently with this error I am getting more and more frequently. Every so often, I will receive a message with arbitration ID 0x04. I am unusre what this means given that the docs state this is a Host → ODrive command. During my main control loop, I only send/recv commands with 0x09 as an ID. Any ideas as to what could be causing this message to be received on my RPi?

12

Hmm, that’s very interesting, I agree that’s a host->ODrive command. Can you post the full arbitration ID (including node ID) as well as the specific data in the message as well? My best guess is that there’s some logic issue decoding the messages in your appliaction code.

13

Oh sorry I never responded here!

T7: 12V output from DC+ → 12V step-down
T8: Filtered 12V supply for system power
T9: Filtered 12V supply for gate drive power (for the inverter)
T10: 5V rail for internal power
T30: 5V rail for external power
T31: 3.3V rail for external power
T12: 3.3V rail for internal power
T13: 3.3V analog rail
T1: ~1.8V rail for microcontroller power.

So it definitely looks like there’s something blown with the 12V->5V step-down, which is why the S1 only works with the external USB supply (which also feeds 5V)

EDIT2: Assuming the worst case, what wattage resistor should I be looking at for the soft start? Most datasheets report continuous, unsure of what peaks they can handle.

It really depends. You can calculate the total energy of the precharge pulse, and compare to the resistor’s short term overload rating. For instance, a 10-ohm resistor from a 48V supply into a single S1 (328uF capacitance) will result in a voltage curve across the resistor of V e^(-t / RC) == 48 e^(-t / 10 * 328e-6), and thus a power curve (given P = V^2 / R) of (48 e^(-t / 10 * 328e-6))^2 / 10. If you integrate this, you get about 0.377 joules, across about 10ms:

2025-09-05-091903_1250x509_scrot
2025-09-05-091903_1250x509_scrot1250×509 25.2 KB

And then an average pulse power curve (y axis is watts, x axis is integration time) of this:

2025-09-05-092351_1634x521_scrot
2025-09-05-092351_1634x521_scrot1634×521 28.7 KB

So that’s about 175W average across 1ms, 75W average across 5ms, and about 50W average across 10ms.

Looking at the single pulse rating in the datasheet for the Vishay CRCW-HP series (which is a pulse rated resistor), we can mark these points (175W @ 1ms, 75W @ 5ms, 50W @ 10ms), and see that it’s all within the curve for the CRCW2512-HP

2025-09-05-092627_2712x941_scrot
2025-09-05-092627_2712x941_scrot1920×666 186 KB

So even a small (pulse rated!) resistor like the CRCW251210R0FKEGHP will work just fine here. And I think you’d be totally fine also with something like a wirewound resistor, even though it’s not specifically pulse rated.

14

This is the full message I get (just printing everything out) when I forcibly recreate the error by disconnecting the drive. Unfortunately the issue happens seemingly at random during actual use but I get the same error message when disconnecting the CAN wire or cutting off power while the control loop is running.

Timestamp: 1727751602.893796 ID: 0004 S E DLC: 8 00 08 00 00 00 00 00 00 Channel: can0

Timestamp: 1727751602.894330 ID: 0004 S E DLC: 8 00 20 00 00 00 00 00 00 Channel: can0

During actual use, with the new drives that are only battery powered, I am able to put the drive into idle if this issue is read (watchdog does not trip and is set to 0.03s), so perhaps it is a blip in communication?

Let me know if there’s something else I should print out.

No problem at all. Thanks so much for this info about the testing pins and the resistor, super useful to know and I’ll put a soft start in soon!

15

This is the full message I get (just printing everything out) when I forcibly recreate the error by disconnecting the drive. Unfortunately the issue happens seemingly at random during actual use but I get the same error message when disconnecting the CAN wire or cutting off power while the control loop is running.

Timestamp: 1727751602.893796 ID: 0004 S E DLC: 8 00 08 00 00 00 00 00 00 Channel: can0

Timestamp: 1727751602.894330 ID: 0004 S E DLC: 8 00 20 00 00 00 00 00 00 Channel: can0

During actual use, with the new drives that are only battery powered, I am able to put the drive into idle if this issue is read (watchdog does not trip and is set to 0.03s), so perhaps it is a blip in communication?

This definitely doesn’t seem correct, that generally looks like garbage. So this only happens when the ODrive loses power or you pull CAN? Is it consistently the 0004 ID? I’ll have our software guy look at this and see if he has any ideas.

16

These are SocketCAN error frames that are generated by the Linux kernel, as indicated by the E flag. They do not correspond to any messages on the bus.

The message ID “0004” (CAN_ERR_CRTL) means there are “controller problems” which are detailed in data[1].
The first payload then decodes to CAN_ERR_CRTL_TX_WARNING.
The second payload decodes to CAN_ERR_CRTL_TX_PASSIVE.
See kernel defines here:

I would say such errors are expected when there are electrical issues on the bus, which I guess could happen depending on how the ODrive goes down.