Force controller from ros to unity delay


I have been trying to tune a yaw rate pid with the force.n as input without much success. I found that there is a 0.5 delay between the force input asked by the ros node and the applied force in the unity platform. Could you check this issue?

Thank you for the help.

Best regards,

Edit: decided to add the controller directly in unity instead of going from ros in the vm to unity and the strange behaviour disappeared. My guess is that there is some communication problem in the force control.


I managed to reproduce what you described and found a delay of 0.2-0.3 seconds (slight varying during each test). Having done some tests on both the Unity and ROS side of the communications, I couldn’t find part of the networking implementation directly contributing to the delay, leading me to presume that the delay lies in the gRPC interfaces and the network communication itself. Additionally, Unity handles network communications asynchronously (the simulation continues to run while a network packet is being received), and if the CPU is reaching capacity this process might be made lower priority, increasing delay. The fact that the behavior disappears when running the controller natively in Unity is to be expected, as the controller is then running synchronously (the simulation waits for the controller before proceeding to the next frame), effectively making the delay zero.

This doesn’t explain why you’re experiencing a larger delay than me though, are you currently running on two separate machines on a local network, or are you running Ubuntu in a virtual machine?

Other than this, I’m not sure if there are any changes I can recommend. The issue you described with tuning a yaw rate PID could be solved by adding an observer to the control loop (if you haven’t already), which with some tuning should be able to handle the amount of delay you’re experiencing.


Thank you for the response.

I am running Ros in a virtual machine with Ubuntu and unity on windows. I managed to fix it by using only 5 Hz in the control node. I guess that Ros was spamming force requests at a higher rate than unity could handle, leading to messages being accumulated in the buffer.

1 Like