ODrive doesn't show up in odrivetool

alan · June 24, 2018, 8:19pm

@Richard_Parsons and @madcowswe
I was able to install the SK3 motor, encoder, and ODrive 3.5 board on my self-driving RC-car. I am running with a 3S battery pack (around 11.1V) and that powers up the board no problem.

Problem found:
What I’ve done on the setup side:

I am running Ubuntu 16.04 on my laptop
I have a 11.1V battery connected to my ODrive 3.5 board with motor connected but no encoder cable connected.
PWR LED lights up on Odrive 3.5 board
USB connected to my Ubuntu 16.04 laptop
Successfully installed odrivetool via pip3 install odrive (for python 3)
Ran odrivetool udev-setup as root (sudo su) with the following result: udev rules configured successfully
I also ran:

echo 'SUBSYSTEM=="usb", ATTR{idVendor}=="1209", ATTR{idProduct}=="0d[0-9][0-9]", MODE="0666"' | sudo tee /etc/udev/rules.d/50-odrive.rules
sudo udevadm control --reload-rules
sudo udevadm trigger # until you reboot you may need to do this everytime you reset the ODrive

lsusb:

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 138a:0091 Validity Sensors, Inc. 
Bus 001 Device 003: ID 0cf3:e301 Atheros Communications, Inc. 
Bus 001 Device 005: ID 1bcf:2b95 Sunplus Innovation Technology Inc. 
Bus 001 Device 002: ID 1209:0d32 InterBiometrics 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

However, when I type odrivetool in my command line, I get the following result [no connection]:

ODrive control utility v0.4.0.post6
Please connect your ODrive.
You can also type help() or quit().

In [1]:

alan · June 24, 2018, 8:39pm

Update:
When I run it in verbose, I get the following:

ODrive control utility v0.4.0.post6
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
Please connect your ODrive.
You can also type help() or quit().
Connecting to device on USB device bus 1 device 6

When I try typing quit(), nothing happens so I am forced to hit Ctrl + C. And I get the following output:

gist.github.com

https://gist.github.com/alan707/dbe3484774517a0b0f8b6eae009bd148

output.sh

In [3]: quit()

^CException ignored in: <module 'threading' from '/usr/lib/python3.5/threading.py'>
Traceback (most recent call last):
  File "/usr/lib/python3.5/threading.py", line 1288, in _shutdown
    t.join()
  File "/usr/lib/python3.5/threading.py", line 1054, in join
    self._wait_for_tstate_lock()
  File "/usr/lib/python3.5/threading.py", line 1070, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):

This file has been truncated. show original

alan · June 24, 2018, 8:44pm

When I run sudo udevadm monitor -u, and I perform the following steps:

Disconnect USB cable connected to ODrive 3.5 board
Connect USB cable connected to ODrive 3.5 board

Output:

sudo udevadm monitor -u
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing

UDEV  [2711.579391] remove   /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.1 (usb)
UDEV  [2711.579755] remove   /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/tty/ttyACM0 (tty)
UDEV  [2711.581706] remove   /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.2 (usb)
UDEV  [2711.581974] remove   /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0 (usb)
UDEV  [2711.584780] remove   /devices/pci0000:00/0000:00:14.0/usb1/1-1 (usb)
UDEV  [2715.043597] add      /devices/pci0000:00/0000:00:14.0/usb1/1-1 (usb)
UDEV  [2715.047429] add      /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0 (usb)
UDEV  [2715.048432] add      /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.1 (usb)
UDEV  [2715.048727] add      /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.2 (usb)
UDEV  [2715.049955] add      /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/tty/ttyACM0 (tty)

madcowswe · June 27, 2018, 4:22am

Hm this means it finds the ODrive and is trying to connect. I don’t know why it fails. Some people have reported that it can take up to 30 seconds to download the JSON from the ODrive (we still don’t know why that happens for some people).
So if waiting at the prompt for 30s doesn’t work, we can try to dig deeper wit the debugger on your machine.

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?