Problem controlling hoverboard motors from USB

Support
1

Hi!

We are working on a robot with oDrive controller and 2 hoverboard motors. In order to configure the motors, we’ve been following the steps explained on the tutorial (https://docs.odriverobotics.com/hoverboard) and everything is working perfectly. The problem comes when creating the next script for controlling both motors:
photo5868678742895865903

We are having trouble with the time that goes from the moment the velocity for one motor is set to the moment it is set for the other motor. It is too high, even if we set them immediately one after the other (times in nanoseconds):

timeBefore: 1571672378333167076
timeMidle: 1571672379033879995
timeAfter: 1571672380123322010
timeAfter-timeBefore: 1790154934

timeBefore: 1571672391617016077
timeMidle: 1571672392223576068
timeAfter: 1571672392571610927
timeAfter-timeBefore: 954594850

timeBefore: 1571672398337743043
timeMidle: 571672398340759992
timeAfter: 1571672398345537900
timeAfter-timeBefore: 7794857

As you can see, there are times that the iteration lasts almost 2s, which is too much time for our project.

Our question is if this is the best way of approaching the control of the two motors or there is a better way.
Thank you so much in advance.
Greetings,
Mario.

2

Hmm. I have never known there to be any delay like this in changing setpoints.
Do you have the same delay using odrivetool? If so, what version of both odruvetool and the firmware are you using?

Do you have USB bus contention issues? e.g. are you sharing the same USB root hub with a bunch of USB 2.0 cameras?

If on Linux, check the output of ‘dmesg -w’ while running your script.

For me, in odrivetool it takes less than 1ms to set both axes:

In [54]: def test(v1, v2):
    ...:     import time
    ...:     t1 = time.time()
    ...:     odrv0.axis0.controller.input_vel=v1
    ...:     t2=time.time()
    ...:     odrv0.axis1.controller.input_vel=v2
    ...:     t3 = time.time()
    ...:     print (t3-t1)
    ...:     return (t1, t2, t3)
    ...: 
    ...: 
    ...: 

In [55]: test(1,1)
0.0007886886596679688
Out[55]: (1571745209.8092928, 1571745209.8097644, 1571745209.8100815)

In [56]:
3

Hi!

For anyone in the same situation, we discovered the problem was originated by the communication with serial port in a ROS callback coded in python, it added too much delay. Once we changed it to c++ with ASCII protocol everything went just perfect: almost no delay. :ok_hand:

Thank you for your help!