Oh no odrv0 disappeared

Hello,
I got this message “Oh no odrv0 disappeared” and the Odrive stop working once the I send the the AXIS_STATE_FULL_CALIBRATION_SEQUENCE command or any other movements commands then the Odrive will reconnected again once the motor stops ?
Same results with versions 3.6 &3.5 with macOS and windows
And if send AXIS_STATE_CLOSED_LOOP_CONTROL , i can stop the motor only by sending stop command from the Arduino connected to the Odrive using UART
Any advice?
Note: The Odrive will works fine if i fully control it from the Arduino

Hello Ozzo.nebras,
Can you check if there is any kind of USB error in the system log when ODrive disappears?

1 Like

Can you also try a different power supply and a different USB cable?
How are your motor phases wired? Is there some possibility of a ground loop? Can you try with a known working motor/encoder pair?

1 Like

I am using MacBook pro with USB-C to USB-A adapter, when figure out the problem i tried another adapter and the problem still there, both of the adapters convert one USB-C to three USB-A


Today I tried a new adapter which has only one input and one output and it solve the problem

I’m having this problem as well.

I’ve been using the board with a particular motor and encoder on a ThinkPad running Linux with out issue. On my iMac, it rarely connects, and when it does, it disappears a few seconds later.

The device enumerates on the USB bus just fine. I’ve tried ports on both internal hubs. I’m running the board on a lab power supply at 14.8V (per motor spec). Running odrivetool --verbose doesn’t provide any useful info. I ran pip --upgrade --no-cache-dir earlier today to ensure I’m on the latest.

Board: V3.6, 24volt, 0.4.11 driver
iMac 27", mid-2010
macOS High Sierra 10.13.6
USB cable that shipped with the Odrive, no obvious sources of interference nearby

Any help appreciated.


syslog info:

USB connect event:

default 18:27:31.637489 -0800 icdd #ICDebug - 23:{ICWiredBrowser.m} (USB Device first match)
default 18:27:31.638309 -0800 icdd #ICDebug - 388:{ICWiredBrowser.m} (3 USB Descriptions Managed)
default 18:27:33.722562 -0800 icdd #ICDebug - 37:{ICWiredBrowser.m} (USB Interface first match)
default 18:27:33.723489 -0800 icdd #ICDebug - 388:{ICWiredBrowser.m} (4 USB Descriptions Managed)
default 18:27:33.723587 -0800 icdd #ICDebug - 37:{ICWiredBrowser.m} (USB Interface first match)
default 18:27:33.724870 -0800 icdd #ICDebug - 388:{ICWiredBrowser.m} (5 USB Descriptions Managed)
default 18:27:33.725606 -0800 icdd #ICDebug - 388:{ICWiredBrowser.m} (6 USB Descriptions Managed)
default 18:27:34.777953 -0800 icdd #ICDebug - 51:{ICWiredBrowser.m} (USB terminate)
default 18:27:34.778043 -0800 icdd #ICDebug - 344:{ICWiredBrowser.m} (–> USB Terminate)
default 18:27:34.778602 -0800 icdd #ICDebug - 371:{ICWiredBrowser.m} (2 USB Descriptions Managed)
default 18:27:34.778658 -0800 icdd #ICDebug - 373:{ICWiredBrowser.m} (<-- USB Terminate)
default 18:27:36.778905 -0800 icdd #ICDebug - 23:{ICWiredBrowser.m} (USB Device first match)
default 18:27:36.780012 -0800 icdd #ICDebug - 388:{ICWiredBrowser.m} (3 USB Descriptions Managed)
default 18:27:36.780627 -0800 kernel 144257.794961 ODrive 3.6 CDC Interface@fa140000: IOUSBHostDevice::getDescriptorGated: compliance violation: USB 2.0 9.3.5: device returned more than wLength data
default 18:27:36.782248 -0800 kernel 144257.796586 ODrive 3.6 CDC Interface@fa140000: IOUSBHostDevice::getDescriptorGated: compliance violation: USB 2.0 9.3.5: device returned more than wLength data
default 18:27:36.787403 -0800 kernel 144257.801731 ODrive 3.6 CDC Interface@fa140000: IOUSBHostDevice::getDescriptorGated: compliance violation: USB 2.0 9.3.5: device returned more than wLength data
default 18:27:36.792034 -0800 kernel 144257.806360 AppleUSBHostCompositeDevice@(null): AppleUSBHostCompositeDevice::ConfigureDevice: unable to set a configuration (0xe00002ed)

Bump.

(Seems forum software wants a complete sentence before it will post…)

Hi @autox

If you only have this issue outside of the IDLE state, then it’s typically a noise problem. If it also happens in the IDLE state, it’s going to be more difficult to chase down.

Can you check what version of the board firmware you’re running? Once connected to the board, use odrv0 and look at the fw_version_xxx values to determine the firmware version

Hey, thanks for picking this up.

FW 0.4.11, as above. Same cable run as the other machine on my desk that it works on (Ubuntu). It’s currently not connecting to the Mac at all, so I can only assume it’s in the idle state, since that’s what I observed on the Ubuntu machine. It has only ever connected on the Mac for a short period - not enough to actually use it.

I see, so it works on the Ubuntu machine but doesn’t work at all on the Mac?

Unfortunately what Oskar said in his email is true - none of us have Macs, so this could be hard to debug. I assume you’ve read through the documentation on docs.odriverobotics.com?

It’s possible some of the USB handling code between Ubuntu and Mac is similar - do they both have lsusb for instance? Or you can try this PYUSB_DEBUG=debug odrivetool, though I’m not sure how that works :thinking:

I was wondering if you could tell me the name of the brand you used. I am also planning on getting one of these but I want to make sure I get the same brand as you that way the ODrive works for me as well

Any USB-C to USB-A with this should solve the problem :USB Isolator — ODrive