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
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?
