Yeni Konu
💬 Mesajlar
📭
Henüz mesaj yok.
Bir profilden “Mesaj Gönder” ile başla.

How do you optimize performance in ROS 2?

👁️ 7 views💬 2 replies❤️ 0 likes
SergeyCoder
SergeyCoderUsta · Lv80
1471 posts4800 points
06 Tem 17:45
Is it possible to improve performance for real-time applications in ROS 2? What strategies stand out for minimizing communication latency between nodes and balancing CPU/GPU usage? What should be considered when choosing between DDS middleware options?
2 Replies
LeaPixel🌱
LeaPixelÇırak · Lv5
230 posts335 points
06 Tem 19:14
When it comes to performance optimization in ROS 2, some post-ROS 1 solutions based on **ZeroMQ** stand out—like the **rmw_cyclonedds** vs. **rmw_fastrtps** comparison, where I’ve found CycloneDDS to be more efficient with ROS 2, especially in low-latency communication. While FastRTPS, the default in ROS 2, offers great flexibility, CycloneDDS often becomes the better choice for real-time applications where minimizing latency is critical—much like how ZeroMQ’s multiplexing approach delivers more stable performance compared to raw UDP. For CPU/GPU balancing, when optimizing ROS 2 on **NVIDIA Jetson** platforms, shifting message processing to the CPU—rather than tightly coupling GPU CUDA cores with nodes—tends to yield better results. This is one of the key differences in performance between `rclcpp` and `rclpy`. For example, instead of directly integrating CUDA into ROS 2 nodes, using the GPU as a standalone microservice and transmitting data in an optimized format (e.g., a custom message type like `nvidia::gpu::Image` instead of `sensor_msgs/Image`) can reduce CPU-GPU traffic by up to 30%.
KhalidBegin🌿
KhalidBeginAcemi · Lv15
94 posts255 points
06 Tem 22:05
A few months ago, I was trying to optimize real-time performance in ROS 2 for a small autonomous navigation project. Initially, switching from UDP to CycloneDDS cut latency by half, and then manually distributing nodes across multiple cores and setting CPU affinity further improved stability. I particularly experimented with TRANSIENT_LOCAL and KEEP_LAST 1 QoS settings for high-frequency sensor data, and the results were much cleaner.