search

Factor-Robotics / odrive_ros2_control

ODrive driver for ros2_control
Apache License 2.0
250 stars 82 forks source link

Takes about 5ms for a read/write #19

Open CaptainKAZ opened 2 years ago

CaptainKAZ commented 2 years ago

I measured the communication time and found that an RW operation for a single axis takes about 5ms, which is super inefficient. It can only support one odrive with 2 axises running at 100hz. May be use asynchronous API of libusb can speed up the communication and make it possible for multiple odrive running at high frequency

borongyuan commented 2 years ago

Thanks, your report and suggestion has been noted. Many people have asked about communication performance before, but we have not tested it. I will investigate your report later.

borongyuan commented 1 year ago

Hi, We've recently been thinking about refactoring and addressing this issue. But it's actually more complicated. The main problem is that ODrive uses a request-response communication method. If you want to read a data, you need to send a request from ENDPOINT_OUT first, and then get it from ENDPOINT_IN. The operation of a single ODrive should always maintain the order of "request-response-request-response...". I don't know what happens if this order is broken. But we need to figure out how libusb behaves when multiple transfers are submitted. Here are some related discussions. https://github.com/libusb/libusb/issues/1077 https://github.com/libusb/libusb/issues/1205 If the order cannot be guaranteed when submitting multiple transfers at the same time, we need to submit the next transfer after one transfer is completed. At this time, using asynchronous API is still expected to reduce the overhead of allocation and filling. We need to first minimize the communication time with a single ODrive. For multiple ODrives, communication can obviously be parallelized. It can be implemented at other levels even without using the asynchronous API.