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?
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?
Hi,
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?
Thanks
---------------------------------------------------------------------------
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)
79
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)
388
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 )
950
~\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)
534
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 )))
618
KeyboardInterrupt:
Hope this helps.
Thanks
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.
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.
