I am precalculating the positions to send to motors then use a loop like below to send such commands.
On an Intel Core i5 PC, I noticed that each iteration of the loop (in other words without waiting), was about 5ms.
On raspberry pi however, i’m more the 20~22ms range. i’m using the latest rpi 3 model B+
I use native-stream for usb communication.
In other words
1/0.005 = 200 Hz on PC
1/0.022 = 45 Hz on raspberry pi
apart from porting my code from python to c++, is there anyway that i can increase this frequency on raspberry pi ? (or maybe finding a faster python implementation that python3
t0 = time.monotonic() # gives current absolute time in sec. ex: 28774.414338526
for i in range(0,m):
self.cur_a = distances_a[i]
self.cur_b = distances_b[i]
self.my_odrive.motor0.set_pos_setpoint(int(self.cur_a), 0.0, 0.0)
self.my_odrive.motor1.set_pos_setpoint(int(self.cur_b), 0.0, 0.0)
t1 = time.monotonic()
duration = (t1 - t0)
t0 = t1
time_to_sleep = self.dt - duration
if (time_to_sleep >0):
I use python for its simplicity over performance. therefore, i have never needed performance, thus profiling on python until now. I’m not in front of the PC but i did use the first python profiler that google suggested : cprofile if i remember right.
I could barely make sense of the output but i clearly remember that the following lines were the culprit, which led me to beleive there was basically very little i could do from my code
except sending more “points” with each commands, therefore sending less commands per seconds. However, when i do this, i noticed that the movement was way less fluid (resonate?) and i couldn’t basically use it in production as is. That said, I notice that i understand very little about odrive “gains” and honnestly a clear documentation of such params would help me a lot.
Would copy/pasting the ouput of the profiler help? What can i do to determine if it’s the code execution that is slow or if it’s the OS being slow with USB traffic?