USB Comm Trouble: 56V V3.6

Support
1

(As a “new user” apparently I’m not allowed to have more than two links in a post. You’ll have to trust me about the references to where I found things. Very frustrating that the support area has silly limits on new users, even paying customers for hardware.)

I’m having a lot of trouble getting USB communications to be stable with this thing. Consistently, 10 seconds after seeing “Connected to ODrive 207438A5304E as odrv0” I get “Oh no odrv0 disappeared”.

I followed the instructions, as far as software setup is concerned, at for Win 10 using Anaconda. I used zadig to get the driver set correctly. At that point, there was still something missing because there were no DLLs for libusb. I used the advice here https://stackoverflow.com/questions/54162872/pyusb-with-windows-libusb1-and-libusb-win32-backends-not-working to track down the DLLs and get them on the path.

I get several warnings when I start up odrivetool from within Anacoda’s command line:

(base) C:\Users\Random User>odrivetool
ODrive control utility v0.4.12
C:\ProgramData\Anaconda3\lib\site-packages\fibre\shell.py:104: RuntimeWarning: coroutine ‘InteractiveShell.run_code’ was
never awaited
console.runcode(‘import sys’)
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
C:\ProgramData\Anaconda3\lib\site-packages\fibre\shell.py:105: RuntimeWarning: coroutine ‘InteractiveShell.run_code’ was
never awaited
console.runcode(‘superexcepthook = sys.excepthook’)
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
C:\ProgramData\Anaconda3\lib\site-packages\fibre\shell.py:106: RuntimeWarning: coroutine ‘InteractiveShell.run_code’ was
never awaited
console.runcode(‘def newexcepthook(ex_class,ex,trace):\n’
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
C:\ProgramData\Anaconda3\lib\site-packages\fibre\shell.py:109: RuntimeWarning: coroutine ‘InteractiveShell.run_code’ was
never awaited
console.runcode(‘sys.excepthook=newexcepthook’)
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
Please connect your ODrive.
You can also type help() or quit().

Connected to ODrive 207438A5304E as odrv0

I attempted to use “odrivetool dfu” to make sure the firmware was up to date. A surprising thing was that it reported “0.4.12-dev” was on the board with “0.4.12” available. After trying to update using that, it then told me that the firmware on the board didn’t support DFU and to update via STLINK.

I went to to find the firmware for update, downloaded ODriveFirmware_v3.6-56V.elf and ran the openocd command line listed here . What’s up with this whole startup process? Why did the original firmware report 0.4.12 and the “released” 0.4.12 firmware reports 3.6? How do I get odrivetool to communicate for more than 10 seconds?

2

Also, for what it’s worth, “disappeared” happens when running from a battery at ~56V as well as from a Sorensen DCS80-37 at ~24V.

3

I had the exact same issues. The fix for me was doing the following 3 things:

  1. Use an USB isolator. I have this one: https://hifimediy.com/product/usb-isolator/
  2. Braid the motor cables.
  3. Add a toroid to the motor cables. I have this one: https://www.digikey.com/product-detail/en/kemet/ESD-R-47S/399-ESD-R-47S-ND/10524456

Since doing this I have experienced 0 issues with the USB connection.

1 Like
4

Thanks for the suggestions. Those would make more sense if it could be switching noise coupled from either my power supply or the motor drive. A this point, I don’t have any of that. I’m just trying to get communication going first. It isn’t even stable then.

5

I had the same issue. Odrive would drop connection even without it being in closed loop control yet. USB isolator helped with that issue. It might have been a ground loop issue but I never verified that.

But I still had to braid the motor cables and add toroids because communication would often drop during closed loop control.

1 Like
6

Definitely not hardware. Definitely software, on the PC side.

Same PC, spun up an Ubuntu 20.04.1 instance in Vmware. Using the default startup instructions. After assigning the Odrive USB device to the vmware player, odrivetool running inside of ubuntu finds the odrive (eventually, seems like it takes longer.)

Communications are stable: I can change the voltage on the bench supply and read it back via odrv0.vbus_voltage and see the change correctly.

Works fine (motor not turning yet) with the Sorensen bench supply, which I know has some switch mode noise swimming around on the DC side.

7

Hmm… check in Zadig - ODrive Interface 2 should be libusb, and ODrive Interface 0 should be usbser

I’ll look into the link restrictions.

8

I don’t know about VMWare, but I use VBox a lot, and I have given up on using it for anything but the most trivial of USB tasks.
USB mass storage devices get horrendous data corruption, USB (2.0) cameras just don’t work…

Is there any way you could run Linux natively? e.g. with a raspberry pi or similar and connect from your PC over SSH?

9

Virtual Box doesn’t want to play with random USB devices like Odrive. It took one pass of setting that up before I learned my lesson. Hence, VMWare. Worked great.

Too many configurations here to try to always run natively. We depend on Win OS for too many other CAD tools.

10

I’ll look into the second (0th) interface. I believe that libusb was the way I had it set up. In VMWare, I’m only sending “2” to the VM and it works fine.