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.