Odrive unresponsive after entering closed loop control

I have successfully calibrated my motor and encoder to use an index pulse through the odrivetool, but when i enter closed loop control the odrive stops responding to commands, If i change the control mode before i enter the state it changes its behaviour but if i try and change a set point for example the odrive doesn’t react or respond with any errors.

Here is my config:

I am using the AMT102 encoder and this is My Motor.

Thanks for your help.

Hmm, so if you use hex(odrv0.axis0.error) do you get anything? What about odrv0.axis0.current_state?

1 Like

If i use hex(odrv0.axis0.error) before I put it into closed loop mode it returns 0x0 . If i use it after i get no response.

If use odrv0.axis0.current_state before i put it into closed loop mode it returns 1. If i use it after i got no response.

Can you show us a screenshot of what it looks like when you don’t get a response?


Thanks for your help.

This is what it looks like when it freezes.

It doesn’t allow me to input anything.

I just tried again and for some reason I was able to move the motor a couple of times before it became unresponsive again! Very strange, i didn’t change any of the physical setup or any settings.

As you can see i was able to move the motor back and forth 5 times before it became unresponsive again.

FYI When the drive becomes unresponsive it still holds its position if i try and move the motor by hand.

Thanks again!

When it’s in the frozen state, can you do ctrl+c and then post a screenshot of the entire stacktrace?

KeyboardInterrupt                         Traceback (most recent call last)
~\Anaconda3\lib\site-packages\fibre\shell.py in <module>()
----> 1 odrv0.axis0.controller.pos_setpoint = 10000

~\Anaconda3\lib\site-packages\fibre\remote_object.py in __setattr__(self, name, value)
    250         if isinstance(attr, RemoteProperty):
    251             if attr._can_write:
--> 252                 attr.set_value(value)
    253             else:
    254                 raise Exception("Cannot write to property {}".format(name))

~\Anaconda3\lib\site-packages\fibre\remote_object.py in set_value(self, value)
     76         buffer = self._codec.serialize(value)
     77         # TODO: Currenly we wait for an ack here. Settle on the default guarantee.
---> 78         self._parent.__channel__.remote_endpoint_operation(self._id, buffer, True, 0)
     80     def _dump(self):

~\Anaconda3\lib\site-packages\fibre\protocol.py in remote_endpoint_operation(self, endpoint_id, input, expect_ack, output_length)
    295                     self._my_lock.acquire()
    296                     try:
--> 297                         self._output.process_packet(packet)
    298                     except ChannelDamagedException:
    299                         attempt += 1

~\Anaconda3\lib\site-packages\fibre\usbbulk_transport.py in process_packet(self, usbBuffer)
     96   def process_packet(self, usbBuffer):
     97     try:
---> 98       ret = self.epw.write(usbBuffer, 0)
     99       if self._was_damaged:
    100         self._logger.debug("Recovered from USB halt/stall condition")

~\Anaconda3\lib\site-packages\usb\core.py in write(self, data, timeout)
    385         For details, see the Device.write() method.
    386         """
--> 387         return self.device.write(self, data, timeout)
    389     def read(self, size_or_buffer, timeout = None):

~\Anaconda3\lib\site-packages\usb\core.py in write(self, endpoint, data, timeout)
    946                 intf.bInterfaceNumber,
    947                 _interop.as_array(data),
--> 948                 self.__get_timeout(timeout)
    949             )

~\Anaconda3\lib\site-packages\usb\backend\libusb0.py in bulk_write(self, dev_handle, ep, intf, data, timeout)
    531                             ep,
    532                             intf,
--> 533                             data, timeout)
    535     @methodtrace(_logger)

~\Anaconda3\lib\site-packages\usb\backend\libusb0.py in __write(self, fn, dev_handle, ep, intf, data, timeout)
    614                         cast(address, c_char_p),
    615                         length,
--> 616                         timeout
    617                     )))


Hope this helps.


Hm are you at all able to try connecting from a different PC?

Hi! I’m having the same issue in both V0.4.7 and V0.4.5 of odrivetool and firmware.

I’m running an ODrive v3.3 on Windows 10.
I’ve also tried on a different PC with Windows 7 with the same results.

This is repeatable for me in both cases, and only happens once closed loop mode has been entered.

What happens if you set the startup_closed_loop_control flag to true before enabling the axis rather than setting the requested_state separately? Do you still get the unresponsive behavior?

Yep same result unfortunately

Sorry for the delay in answering: do you still have this problem?

I have the same problem when I use longer cables for the motor

I’m also having this problem. I’m using the setting <axis>.config.startup_closed_loop_control = True for the race sim I’m developing. After settings this to True and rebooting, the Odrive isn’t available anymore in odrivetool.

I can use serial commands to control the position of the motors, but after a while this also becomes unresponsive. And because the odrive isn’t available in odrivetool, I can’t see any errors.

Please solve this problem.

I have the same issue with the 3.6 56V version. I have updated the firmware & all drivers. Unfortunately this leaves me dead in the water, is this just a defective unit or a known issue?

I had the same issue as described in the first post. My problem ended up being solved by putting a ferrite on the usb cable. The usb cable didn’t touch the motor wires but was inside a metal enclosure with them.

Hope this helps.

1 Like

I’ve exactly the same trouble !!! Any suggestion ?!!! I try on two different PC W10 & Ubuntu and a Mac

Best regards

Hi @Jean-Robert_Humbert, can you describe (or better, take a picture of) your setup? ODrive’s USB communication can be somewhat sensitive to grounding and other noise issues. Braiding your motor cables, using ferrite beads on the 3 wires together, properly grounding (or isolating, depending) your motor casing, etc can all have an effect on the USB performance.

Have someone tried to add a couple of TVS diodes between TP1/TP3 and TP2/TP3 pads?
A noise reduction should be pretty reliable for the usb connection at reasonable bounds, but high voltage spikes can ruin it all.