I’m experiencing latency issues when using the ODrive Web GUI on my NVIDIA Jetson Orin AGX. On a Windows machine with the exact same settings, everything works seamlessly, and the ODrive setup performs as expected.
However, on my Jetson Orin AGX, the sensor values from the encoder are coming back very slowly, which affects the closed-loop control. This delay introduces vibrations into the motor, making it difficult to operate smoothly.
To troubleshoot, I tested the same setup on another Ubuntu host machine and found that changing the power mode had an impact on the sensor readings from the encoder. On the Jetson, switching to a higher power mode and increasing the CPU frequency improved the encoder readings slightly, but the issue still persists.
Has anyone encountered similar issues with ODrive on Jetson devices? Could this be related to USB communication latency or something else? Any advice or suggestions for further troubleshooting would be greatly appreciated!
In a vacuum, I’m not sure what could be the cause of this. I know we have customers successfully using USB at higher data rates on embedded devices.
A few things to try / let me know:
What’s the output of odrivetool rate-test?
Is this ODrive directly connected to an Orin USB port? Is there a USB hub? Any other USB devices with significant traffic (e.g. camera, etc)
I tested the same setup on another Ubuntu host machine and found that changing the power mode had an impact on the sensor readings from the encoder.
Can you elaborate on this a bit? I’m not sure what you mean by “power mode” – like turning off battery saver on a laptop? Something else?
This delay introduces vibrations into the motor, making it difficult to operate smoothly.
The ODrive control loop shouldn’t be affected by USB issues – do you mean your user code that’s processing encoder data and sending setpoints to the ODrive?
To add to Solomons answer, my first guess based on your screenshot is that it’s CPU saturation such that the GUI can’t update at the nominal rate. This would also impact the responsiveness of the slider and lead to jerky motion when you move the slider. (is that what you mean by “vibration”?)
However, while there might still be optimizations possible from our end, a Jetson should easily have enough CPU power. For comparison, here’s the GUI on a Raspberry Pi 4:
To clarify, I’m not using any USB hubs. By “power mode,” I’m referring to the different operational modes of the Jetson (15W, 30W, 50W, and full power mode). In full power mode, all CPUs are activated.
I’ve discovered that my device is artificially limiting the USB connection, but I haven’t yet pinpointed the cause. I rebuilt a Python script to communicate with the ODrive, focusing specifically on the encoder. After doing this, and connecting the device via USB, I encountered almost no latency. The application’s outputs were plotted in real-time on my screen.
It seems the issue lies in how Ubuntu handles the web GUI. For now, I’m in a good place since I’ll be using Python for my future work anyway.
