ODrive doesn't show up in odrivetool

tedc · June 30, 2018, 10:08pm

I have this same issue running ubuntu 16.04 on Raspberry Pi 3. And i’ve waited more than 30sec…
The odrivetool said it was installed and configured successfully, and i’ve updated the udev rules for the USB port. Using dmesg | grep usb it shows the drive is connected and gives the serial number of the connected drive.
I’ve tried specifying the path using the --path option, and also tried the specifying the serial number of the drive using the -s option.
Running “sudo odrivetool -v --verbose” i get:

ODrive control utility v0.4.0.post7
Waiting for ODrive…
USB discover loop
ConfigurationValue 1
InterfaceNumber 0,0
EndpointAddress 130
InterfaceNumber 1,0
EndpointAddress 1
EndpointAddress 129
InterfaceNumber 2,0
EndpointAddress 3
EndpointAddress 131
Kernel Driver was not attached
EndpointAddress for writing 3
EndpointAddress for reading 131
Connecting to device on USB device bus 1 device 7
Please connect your ODrive.
You can also type help() or quite()

What Kernel driver is required for running this odrivetool?
Are there any additional debugging checks we can do to find out why that Kernel driver is not getting installed correctly?
Thanks, Ted

tedc · June 30, 2018, 10:19pm

Also i’ve noticed that the ODrive connects to /ttyACM0 instead of /ttyUSB0 as listed in the documentation. Looking at the post from @alan his is also connecting to this /ttyACM0. Not sure if that matters or not.

Maybe its defaulting to the wrong driver?

Thanks, Ted

madcowswe · July 1, 2018, 5:52am

Ok, I have a Rpi 3 here to test on, so I can try to debug on that if I also get this issue. I’ll let you guys know how it goes.

tedc · July 1, 2018, 3:00pm

In case it helps @madcowswe, these guys have an Ubuntu image for Raspberry Pi 3 that already includes ROS installed ready to be flashed onto your SD Card:
https://downloads.ubiquityrobotics.com/pi.html
Thanks, Ted

alexisdal · July 3, 2018, 12:22pm

i did check and i did use a raspberry pi 3 model B+ during my tests.
So for me, odrive board on raspi 3 model B+ does work, but you have to wait 7sec, which is the expected behavior, until the cache mechanism is implemented.

alexisdal · July 3, 2018, 12:26pm

however, and that’s where it becomes interesting, I install a debian Buster (kernel 4.16) on that very win7 corporate machine that requires 30s to show my odrive board to see what happens with linux and i have exactly the behavior shown here ;
odrive does appear in lsusb, but niether with a simple test.py script nor a sudo odrivetool it appears. See output below.
I only manage to get the odrive to appear in odrivetool once (i left the PC unattended for a minute or so), but never managed to reproduce it.

user@debian:~/Desktop/odrive_test$ time sudo python3 test.py 
^CTraceback (most recent call last):
  File "test.py", line 4, in <module>
    odrv0 = odrive.find_any()
  File "/usr/local/lib/python3.6/dist-packages/fibre/discovery.py", line 125, in find_any
    done_signal.wait(timeout=timeout)
  File "/usr/local/lib/python3.6/dist-packages/fibre/utils.py", line 84, in wait
    if not self._evt.wait(timeout=timeout):
  File "/usr/lib/python3.6/threading.py", line 551, in wait
    signaled = self._cond.wait(timeout)
  File "/usr/lib/python3.6/threading.py", line 295, in wait
    waiter.acquire()
KeyboardInterrupt

real	0m40,393s
user	0m0,176s
sys	0m0,038s
user@debian:~/Desktop/odrive_test$ time sudo odrivetool --verbose
ODrive control utility v0.4.1
Waiting for ODrive...
USB discover loop
ConfigurationValue 1
	InterfaceNumber 0,0
		EndpointAddress 130
	InterfaceNumber 1,0
		EndpointAddress 1
		EndpointAddress 129
	InterfaceNumber 2,0
		EndpointAddress 3
		EndpointAddress 131

Kernel Driver was not attached
EndpointAddress for writing 3
EndpointAddress for reading 131
Connecting to device on USB device bus 2 device 3
Please connect your ODrive.
You can also type help() or quit().

In [1]: quit()

no response - probably incompatible

real	1m10,969s
user	0m0,797s
sys	0m0,129s
user@debian:~/Desktop/odrive_test$ uname -a
Linux debian 4.16.0-2-amd64 #1 SMP Debian 4.16.16-2 (2018-06-22) x86_64 GNU/Linux

zhangzq71 · July 4, 2018, 6:20am

Alan,

Have you solved that problem? I have exactly the same problem you have, but my ODrive3.4 board ever work perfectly before my last pulling the source and compile. I don’t remember which version of the firmware that runs correctly, I rolled back to many of previous version but none of them can work until that source code only can be compiled on KEIL, that maybe the version almost one year ago.

alan · July 4, 2018, 2:31pm

Hey, still have same issue.

zhangzq71 · July 5, 2018, 5:13am

I rolled back to version f42747e it works well using explore_odrive.py.

zhangzq71 · July 5, 2018, 6:33am

it seems the last version that can work with odrivetool is 8fc3a43.

tedc · July 6, 2018, 1:35pm

I’ve found that odrivetool connects to odrive once in a while (maybe 1 out of 10 times I start it) and I can write commands and get data back. To connect I leave the odrive connected/powered and repeatedly start/quit odrivetool. But when it does connect, it is still in the USB discovery loop, and odrivetool will continually (about 1 second intervals) give the status that its still in this USB discovery mode (even though its already connected).

So the issue doesn’t seem to be that the driver isn’t there, but maybe some type of timing related error during that initial connection phase/sequence.

Hopefully that helps diagnose what’s going on here.

Thanks, Ted

Neil_FV · July 9, 2018, 7:27am

I’ve seen similar to tedc, I can sometimes get a Channel Broken Exception with oDriveTool and yet still make commands to the motor speed which are implemented but fail when I request state feedback, hanging oDriveTool for a while before churning out errors.

shreeyak · July 13, 2018, 8:39am

I’m having the exact same issue! I’m using v0.4.1.

This is dmesg:

[ 1759.575857] usb 1-2: USB disconnect, device number 18
[ 1764.824631] usb 1-2: new full-speed USB device number 19 using xhci_hcd
[ 1764.966665] usb 1-2: New USB device found, idVendor=1209, idProduct=0d32
[ 1764.966670] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1764.966675] usb 1-2: Product: ODrive 3.4 CDC Interface
[ 1764.966678] usb 1-2: Manufacturer: ODrive Robotics
[ 1764.966682] usb 1-2: SerialNumber: 306539843235
[ 1764.967456] cdc_acm 1-2:1.0: ttyACM0: USB ACM device

And lsusb:

$ lsusb
Bus 002 Device 004: ID 0451:8140 Texas Instruments, Inc. 
Bus 002 Device 003: ID 0451:8140 Texas Instruments, Inc. 
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 1b1c:1b2d Corsair 
Bus 001 Device 003: ID 046d:c332 Logitech, Inc. 
Bus 001 Device 004: ID 0451:8142 Texas Instruments, Inc. TUSB8041 4-Port Hub
Bus 001 Device 002: ID 0451:8142 Texas Instruments, Inc. TUSB8041 4-Port Hub
Bus 001 Device 019: ID 1209:0d32 InterBiometrics 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

And this is output of odrivetool, it just gets stuck forever and doesn’t proceed.

$ odrivetool --verbose
ODrive control utility v0.4.1
Waiting for ODrive...
USB discover loop
ConfigurationValue 1
	InterfaceNumber 0,0
		EndpointAddress 130
	InterfaceNumber 1,0
		EndpointAddress 1
		EndpointAddress 129
	InterfaceNumber 2,0
		EndpointAddress 3
		EndpointAddress 131

Please connect your ODrive.
You can also type help() or quit().

Kernel Driver was not attached
EndpointAddress for writing 3
EndpointAddress for reading 131
Connecting to device on USB device bus 1 device 19
In [1]:

This is what I get from PYUSB_DEBUG=debug odrivetool:

2018-07-13 14:16:50,278 DEBUG:usb.backend.libusb1:_LibUSB.bulk_read(<usb.backend.libusb1._DeviceHandle object at 0x7f3564159fd0>, 131, 2, array('B', [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]), 999)
2018-07-13 14:16:51,278 DEBUG:usb.backend.libusb1:_LibUSB.bulk_read(<usb.backend.libusb1._DeviceHandle object at 0x7f3564159fd0>, 131, 2, array('B', [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]), 999)
2018-07-13 14:16:52,278 DEBUG:usb.backend.libusb1:_LibUSB.bulk_read(<usb.backend.libusb1._DeviceHandle object at 0x7f3564159fd0>, 131, 2, array('B', [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]), 999)
2018-07-13 14:16:53,278 DEBUG:usb.backend.libusb1:_LibUSB.bulk_read(<usb.backend.libusb1._DeviceHandle object at 0x7f3564159fd0>, 131, 2, array('B', [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]), 999)
2018-07-13 14:16:54,278 DEBUG:usb.backend.libusb1:_LibUSB.bulk_read(<usb.backend.libusb1._DeviceHandle object at 0x7f3564159fd0>, 131, 2, array('B', [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]), 999)
2018-07-13 14:16:55,277 DEBUG:usb.backend.libusb1:_LibUSB.bulk_read(<usb.backend.libusb1._DeviceHandle object at 0x7f3564159fd0>, 131, 2, array('B', [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]), 999)
2018-07-13 14:16:56,277 DEBUG:usb.backend.libusb1:_LibUSB.bulk_read(<usb.backend.libusb1._DeviceHandle object at 0x7f3564159fd0>, 131, 2, array('B', [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]), 999)
2018-07-13 14:16:57,277 DEBUG:usb.backend.libusb1:_LibUSB.bulk_read(<usb.backend.libusb1._DeviceHandle object at 0x7f3564159fd0>, 131, 2, array('B', [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]), 999)
2018-07-13 14:16:58,277 DEBUG:us

Lots of zeros in my terminal…

shreeyak · July 14, 2018, 4:47am

I added this as an issue on github.
I noticed that the odrivetool was resetting the USB and going into ACM mode?

$ dmesg
...
[17804.495789] usb 1-2: USB disconnect, device number 10
[17808.625756] usb 1-2: new full-speed USB device number 11 using xhci_hcd
[17808.767326] usb 1-2: New USB device found, idVendor=1209, idProduct=0d32
[17808.767327] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[17808.767328] usb 1-2: Product: ODrive 3.4 CDC Interface
[17808.767329] usb 1-2: Manufacturer: ODrive Robotics
[17808.767330] usb 1-2: SerialNumber: 306539843235
[17808.768061] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[17815.454033] usb 1-2: reset full-speed USB device number 11 using xhci_hcd
[17815.594962] cdc_acm 1-2:1.0: ttyACM0: USB ACM device

tedc · July 15, 2018, 2:50am

Hi @shreeyak, in case it helps you or others that have this problem, here is a temporary work-around for Ubuntu 16.04 that eventually connects (after ~2 to ~20 tries, typically ~4 tries) through python:

import odrive
from random import randint
# Find the ODrive that is connected to USB port
i = 1
drvD = None
while drvD == None:
    try:
        dly = randint(70,100) / 10.0
        print("Connecting to ODrive, timeout " + str(dly) +", try " +str(i))
        drvD = odrive.find_any(timeout=dly)
    except TimeoutError:
        i += 1
drvD.axis0.requested_state = AXIS_STATE_IDLE
...

I’ve been able to continue on with other tests with ODrive using above method until this issue is correctly fixed.

Note that before the above code will connect, you must first verify that the serial number of your ODrive is returned with this command:

(lsusb -d 1209:0d32 -v; lsusb -d 0483:df11 -v) | grep iSerial

Hope that helps,
Ted

mvelado · July 16, 2018, 8:05pm

I can’t find that firmware. Any chance you could drop a link?

mvelado · July 17, 2018, 5:39am

GOOD NEWS. I have something that fixes the issue. I am running a 3.5 24V ODrive, and I realized that if you flash the firmware back to 0.3.6 (I know that theres no 3.5 file so I just used the 3.4 24V hex file) the ODrive will connect. I don’t know what really changed from there to 0.4.0 that causes it to not work well but I think @madcowswe will be able to figure it out eventually.

madcowswe · July 17, 2018, 5:47am

Thanks, I’m sure that will help, at least gives a finite span of the kinds of bugs that could be the issue.

zhangzq71 · July 18, 2018, 5:32am

Hi, I just reset the firmware version to 8fc3a43 and build it again.

metanoic · July 23, 2018, 5:17am

Those of you having issues, can you try disabling the CDC device that ODrive exposes, please? It’s the one labeled “ODrive 3.5 CDC Interface”, or if not named on Windows it’s exposed as a “USB Serial Device (COMx)” under the Ports (COM & LPT) in Device Manager.

I’ve been tracking down this issue on my machine for a couple hours now and want to confirm it’s the same issue ya’ll are experiencing. If it is, then disabling that device/driver should allow you to connect via odrivetool using the existing code from the devel branch.