-
Notifications
You must be signed in to change notification settings - Fork 147
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
Performance issues with bridging gpu_lidar data #368
Comments
@azeey Do you have any insight into this issue? |
Without delving too deeply, I noticed that the launch file is creating one bridge node for all cliff sensors and one node for ir sensors. To improve performance, I recommend creating a node for each topic/sensor. |
@azeey I created separate nodes for each topic and sensor like this:
Still seeing the same performance though. I also tested using the point cloud data instead of laserscans but it performed the same. |
From further investigation it seems that anything that subscribes to the |
Yes, I believe so. So you might just be running into a compute limitation with your system. Are you using an NVIDIA GPU and is it configured properly? |
I am using a GTX 1650 and it is barely reaching 30% usage. My CPU is also only reaching around 40% utilisation. Also as a separate question: is there a reason why |
There seems to be some sort of overhead in the For example, if I replace the Subscribe line here with:
I would expect it to cap at 30 hz, since it was publishing at over 30hz uncapped before. But instead, I am seeing closer to 20 hz on the ros topic. The update rate on the sensor hasn't actually changed from 62hz. |
I think we are having the same problem see gz-sensors #332. I believe gpulidar, ir, and camera are all rendering sensors. |
Environment
Binary: 0.244.9
Description
The Create 3 sim uses a number of
gpu_lidar
sensors to simulate the IR intensity sensors as well as cliff detection sensors. The sensor data is bridged to ROS 2 withros_gz_bridge
and used by nodes. Performance of the simulation is reduced significantly as soon as the bridges for these sensors are added, and the topic frequency in ros2 is well below the desiredupdate_rate
specified in the urdf.update_rate
of the sensor.ros2 topic hz
reports that topics are published at around 60% of the update rate. Additionally, the RTF in Gazebo drops significantly when theparameter_bridge
nodes for the lidars are running.Steps to reproduce
ros2 launch irobot_create_ignition_bringup create_ignition.launch.py
ros2 topic hz /_internal/cliff_front_left/scan
ros2 topic hz /_internal/ir_intensity_front_center_left/scan
For me the cliff sensors publish at around 47hz and the ir sensors at around 35hz. They both have update rates set to 62hz.
RTF also jumps between 40-60%.
With the bridges disabled I now have a steady RTF of around 90%.
update_rate
by commenting out line 58 in common_properties.urdf.xacro. Launch the sim again.With this configuration, my RTF sits at a very consistent 31-33% without much fluctuation. Additionally, both cliff and IR sensors report around 160hz on their respective ros2 topics.
To achieve the desired 62hz, I have to set the update rate of the sensors to around 100hz. Clearly my machine is capable of publishing 160hz, so I am not sure what is causing this loss of ~1/3 the desired frequency. Additionally, why does the ros_gz_bridge cause such significantly reduced Gazebo RTF performance?
The text was updated successfully, but these errors were encountered: