I’m upgrading my system to multiple Odrives and migrating from hoverboard motors to Chinese nema34 motors and gearboxes. While testing these new motors with the Odrivetool I’m finding that sometimes the tool becomes un-responsive after entering velocity commands for about a minute at a time.
Do any of you know what could be causing this hiccup?
Are you using UART or USB?
I’ve been using USB. I haven’t updated for a while because I haven’t encountered the issue, but then I found it again after trying to read the vbus_voltage.
I then quit the odrivetool to try and see what the problem was, and after restarting odrivetool I see the “usb device init failed”.
I then restarted my odrives and everything works as normal.
edit: It seems now like any command, to any of my three odrives might cause this to happen at any time. I’m running the latest 5.1 devel branch which I installed through flashing with STlink because I can’t make the DFU install work.
I tried a bunch of things to get reliable communication again, the ones that I think worked were
- installing a new version of odrivetool
- switching from devel branch to master and a fresh flash of the firmware with STlink, (the dfu tool still doesn’t work, at least for me). It also seems like the most recent devel branch doesn’t work with the most recent odrivetool, but the communication issues that I originally switched to devel to resolve got merged into master so it doesn’t stop my work.
But apparently it hasn’t worked!
I have a reproduceable error while setting up a hoverboard motor, where everything works until I try to check odrv0.axis0.motor, at which point the odrivetool freezes until I get the error:
"In [3]: odrv0.axis0.motor
Out[3]: ---------------------------------------------------------------------------
ChannelBrokenException Traceback (most recent call last)
~\anaconda3\lib\site-packages\IPython\core\formatters.py in call(self, obj)
700 type_pprinters=self.type_printers,
701 deferred_pprinters=self.deferred_printers)
→ 702 printer.pretty(obj)
703 printer.flush()
704 return stream.getvalue()
~\anaconda3\lib\site-packages\IPython\lib\pretty.py in pretty(self, obj)
392 if cls is not object
393 and callable(cls.dict.get(‘repr’)):
→ 394 return _repr_pprint(obj, self, cycle)
395
396 return _default_pprint(obj, self, cycle)
~\anaconda3\lib\site-packages\IPython\lib\pretty.py in repr_pprint(obj, p, cycle)
698 “”“A pprint that just redirects to the normal repr function.”""
699 # Find newlines and replace them with p.break()
→ 700 output = repr(obj)
701 lines = output.splitlines()
702 with p.group():
~\anaconda3\lib\site-packages\fibre\remote_object.py in repr(self)
231
232 def repr(self):
→ 233 return self.str()
234
235 def getattribute(self, name):
~\anaconda3\lib\site-packages\fibre\remote_object.py in str(self)
228
229 def str(self):
→ 230 return self._dump("", depth=2)
231
232 def repr(self):
~\anaconda3\lib\site-packages\fibre\remote_object.py in _dump(self, indent, depth)
223 val_str = indent + key + (": " if depth == 1 else “:\n”) + val._dump(indent + " ", depth - 1)
224 else:
→ 225 val_str = indent + val._dump()
226 lines.append(val_str)
227 return “\n”.join(lines)
~\anaconda3\lib\site-packages\fibre\remote_object.py in _dump(self)
84 elif self._name == “error”:
85 # special case: errors should be displayed in hex (TODO: generalize)
—> 86 val_str = “0x{:04X}”.format(self.get_value())
87 else:
88 val_str = str(self.get_value())
~\anaconda3\lib\site-packages\fibre\remote_object.py in get_value(self)
70
71 def get_value(self):
—> 72 buffer = self._parent.channel.remote_endpoint_operation(self._id, None, True, self._codec.get_length())
73 return self._codec.deserialize(buffer)
74
~\anaconda3\lib\site-packages\fibre\protocol.py in remote_endpoint_operation(self, endpoint_id, input, expect_ack, output_length)
312 return self._responses.pop(seq_no)
313 # TODO: record channel statistics
→ 314 raise ChannelBrokenException() # Too many resend attempts
315 finally:
316 self._expected_acks.pop(seq_no)
ChannelBrokenException:"
I think maybe it’s an issue with USB drivers, since it seems like the error arises when I try to get feedback from the odrive, but the odrivetool is also really slow, just tabbing through commands takes a long time.
Nope, checking “odrv0.axis0.motor” works before running the motor calibration, and only throws the errors after running the calibration.
Are you using a USB hub? Usually these problems happen due to the hub. I’ve seen all sorts of bizarre USB behaviours on ODrive (like the terminal itself slowing down and each character taking a second or two to type) just because it was plugged into some garbage hub.
I have, but in the process of debugging I took the Odrives off the hub. Not the issue.
edit 1: I’m able to work around not being able to read the motor values after running motor calibration by instead saving the configuration, then rebooting the Odrive. At that point I can get through configuration and issue the commands as normal but with almost the same significant communication delay I had at the start.
edit 2: per this post I tried deleting my drivers because I could have screwed them up messing around with Zadig. Everything seems like it’s working but once I start entering torque commands the system lags and then stops working, exactly like it has been.
Everything seems like it’s working but once I start entering torque commands the system lags and then stops working, exactly like it has been.
Oh, you probably just have noise problems then. Grab a couple ferrite rings from the shop and make sure you’re using a high quality, short, USB cable. Pretty common issue.
1 Like
That was it! after a day of testing with the ferrite I’ve stopped encountering the issue.
I think this would be a good thing to put in either the troubleshooting or hoverboard setup sections, because it seems like anyone with sufficiently big motors is likely to encounter this.