USB Serial Communication Stops

Support
1

In my application, I need to know when the motor is decelerating so I can issue another position command to keep the motor moving without stopping. Im sending “r odrv0.axis0.encoder.vel_estimate” and look for when the returned value is decreasing. After sending a few dozen of this command the odrive hangs, the current goes from 55ma idle to 43ms, and the comm port is removed from the os (using raspberry pi)

I have tried sending the command every 10ms, 100ms, and 1 second and no change on how and when it dies. Rarely instead of the current going to 43ma, it raps up to over 1.7 amps, although the usb serial port is still dead.

Any ideas?

UPDATE: Just a few minutes after I posted this, the uart stops responding to anything, yet the odrivetool works fine. Wheres The Fun? I reflashed the firmware and now its back alive.

UPADTE2: After reading this post, I decided to comment out the code in ascii_protocol.cpp that I was not using. Serial performance went from lasting less than a minute to running (currently) 5 minutes. I’ll take that as a fix but it would be great if a ‘real’ fix was found. Obviously its memory releated…

2

Same issue with you. In my case, I used version 3.4 odrive and I’ve commented out all the commands in ascii_protocol.cpp except “v”. However, it doesn’t work well and still died casually. Maybe version 3.5 doesn’t have this problem, anyone know?

3

I am using version 3.6 with USB serial, and communicating from my PC using c++ code.
It works well while write, but after few reads, stop working and I am able to read only 2 bytes and those are 0x0a, 0x0a.
Does this relate to your problem, or your issue resolved?
And how you were communicating?

Saurabh

4

Can you make a trace with wireshark of the communication?

On windows:

  1. Download and install wireshark,
  2. download USBPcap,
  3. move USBPcapCMD.exe to C:\Program Files\Wireshark\extcap
  4. fireup wireshark and capture your usb data
  5. filter out irrelevant usb devices like your mouse
1 Like
5

I resolved this issue by using tcflush before sending some command.