-
Notifications
You must be signed in to change notification settings - Fork 368
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Evaluate ROS - Unity Communication Performance #55
Comments
This is a very interesting evaluation. To maximize performance, we should stay out of any Unity Event function, except Awake or Start for an initial trigger of a thread-based system that runs in parallel. We designed the Unity Message Handling Framework to be able to do that. The MessageReceiver is directly triggered by a Subscriber and can further process the message without waiting for any Unity event function to be called. In all our I have not found any clear information about when or how often calculation time is given to parallel running threads in Unity. It depends on the event & multi-treading architecture and multi-core capabilities of Unity and .NET. Other than Unity, the only things that slow down the communication on the non-ROS machine are:
I suggest the following evalutations:
Please do keep us updated with the tests. If you can share any performance test scripts or Unity projects with us, please do! |
Thanks for the feedback, I'll get back when I have more data! |
I have now done some more evaluation with your suggestions in mind. It seems the delays were due to the face that my Provider called its UpdateMessage() method during the FixedUpdate callback. I did some hack to make the Publisher call the UpdateMessage() method instead, and after that I got very fast response times, about 0.6 ms. I got the same result when I did a pure C# implementation, and when I made new Publishers and Subscribers that did not use the Event system at all. The files I used to do the evaluation are in my fork if anyone is interested: https://github.com/hassanbot/ros-sharp/tree/performance-evaluation I feel satisfied now, and I think I can make a better solution without hacking already present files. You can close this issue if you don't have anything to add. Thanks for the input before, it really helped me pinpoint the problem :) |
These are very interesting news! It is good to know that neither the event system nor Unity have a huge impact on the performance when setting up the publishers and subscribers correctly. Thank you for sharing these evaluation results! |
I have a question!
I'm implementing an application where I want Unity to listen for ROS messages on a topic and, as soon as one is received, publish another message on a separate topic. It's important that the response from Unity is as fast as possible, preferably below 5 ms.
I have devised the following setup:
while(true)
loop. The loop publishes a message and then waits for anAutoResetEvent
block to be released.MessageReceiver
.I'm using ROS on a separate Ubuntu machine to send messages, and then using Wireshark to measure timings. Some observations I've made:
But my question is: What is it that decides when a Subscriber handles a message, and when a Publisher dispatches it? Does it somehow depend on the Fixed Timestep?
Thanks for a great product!
The text was updated successfully, but these errors were encountered: