File "/home/ubuntu/FYDP/foosfighter/odrive/core.py", line 241, in find_usb_channels
yield channel_from_usb_device(usb_device, printer)
File "/home/ubuntu/FYDP/foosfighter/odrive/core.py", line 188, in channel_from_usb_device
File "/home/ubuntu/FYDP/foosfighter/odrive/usbbulk_transport.py", line 47, in init
File "/usr/local/lib/python3.5/dist-packages/usb/core.py", line 869, in set_configuration
File "/usr/local/lib/python3.5/dist-packages/usb/core.py", line 102, in wrapper
return f(self, *args, **kwargs)
File "/usr/local/lib/python3.5/dist-packages/usb/core.py", line 148, in managed_set_configuration
File "/usr/local/lib/python3.5/dist-packages/usb/backend/libusb1.py", line 794, in set_configuration
File "/usr/local/lib/python3.5/dist-packages/usb/backend/libusb1.py", line 595, in _check
raise USBError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBError: [Errno None] Other error
This error occurs sometimes after startup or after disconnecting then trying to reconnect to an ODrive over USB. Is there a recommended method of disconnecting from the ODrive so that this doesn’t occur?
I have not seen that error before. Some questions to help us:
- What OS on your PC?
- What code version (git commit or version number)?
- Are you running through a USB hub?
- you say this happens after startup. Does this mean you get the error randomly when the script is mid-running? Or you get this immedietly after running the script, but you mean that the ODrive has been on for a while?
OS is Ubuntu 16.04
The firmware version is recent from master. I downloaded the firmware again within the last week. I’m not sure where to look to check the version number, I haven’t been using git with it
I am using a USB hub. I have 4 ODrives connected.
When I say after startup, I mean that sometimes it occurs the first time that I try to connect to it after applying power to the ODrives once they have completed initialization. Typically power cycling makes the issue go away
Something which may be relevant is that I changed the following lines in usbd_desc.c
#define USBD_VID 0x1209
#define USBD_PID_FS 0x0D32
So that I can identify the ODrives; Do you have an alternative recommendation for how I can identify which ODrive is which
You can check the top of CHANGELOG.md in the Firmware directory.
Changing the VID and PID shouldn’t be causing this kind of problem, though the official way to tell ODrives apart right now is to read the UUID endpoints. Very soon we will also have a serial number on the USB connection.
If you can live with the power-cycling for now, then I suggest we wait a couple of weeks: we have some major changes to how the USB communication is done that is coming up, so maybe we can wait and see if that helps?