RobotecAI
Mid 360
In order to get closer to the real MID360 radar, motion distortion is taken into account. Is it possible to increase the update frequency to 1000 Hz and collect 200 points 1 ms, so that 20,000 points can also be collected in 100 milliseconds?
Can I modify it std::map<std::string, std::pair<std::string, std::size_t>> LidarPatternLoader::presetNameToLoadInfo = { {"Alpha Prime", {"VelodyneVLS128.mat3x4f", 1}}, {"Puck", {"VelodyneVLP16.mat3x4f", 1}}, {"Ultra Puck", {"VelodyneVLP32C.mat3x4f", 1}}, {"OS1 64", {"OusterOS1_64.mat3x4f", 1}}, {"Pandar64", {"HesaiPandarQT64.mat3x4f", 1}}, {"Pandar40P", {"HesaiPandar40P.mat3x4f", 1}}, {"Livox Avia", {"LivoxAvia.mat3x4f", 40}}, {"Livox Horizon", {"LivoxHorizon.mat3x4f", 40}}, {"Livox Mid40", {"LivoxMid40.mat3x4f", 40}}, {"Livox Mid70", {"LivoxMid70.mat3x4f", 40}}, {"Livox Mid360", {"LivoxMid360.mat3x4f", 40}}, {"Livox Tele15", {"LivoxTele15.mat3x4f", 40}}, };
Here {"Livox Mid360", {"LivoxMid360.mat3x4f", 40}}, when the radar update frequency is changed to 1000hz, I want to scan 200 points every 1ms. Can I modify it to 4000 to reach 1ms 200 points?| @Roboterbastler
I tried to change the refresh rate and sampling, and the factor changed directly from 92% to 50% This is my computer configuration [18:34:19][ 13 us][info]: RGL Version 0.20.0 branch=develop commitSHA1=d1ff3b6cf618518d60a4cc6acb9231e3aa9e9e28 [18:34:20][ 73881 us][info]: Running on GPU: NVIDIA GeForce RTX 3060 Laptop GPU [18:34:20][ 15 us][info]: Built against OptiX SDK version: 7.2.0 [18:34:20][ 1 us][info]: Built against OptiX ABI version: 41 [18:34:20][ 0 us][info]: Built against CUDA Toolkit version: 11.7 [18:34:20][ 4 us][info]: Installed CUDA runtime version: 11.7 [18:34:20][ 0 us][info]: Installed CUDA driver version: 12.7 [18:34:20][ 4396 us][info]: Installed NVidia kernel driver version: 565.77
The following picture is 10hz {"Livox Mid360", {"LivoxMid360.mat3x4f", 40}} 94%
The following picture is 1000hz {"Livox Mid360", {"LivoxMid360.mat3x4f", 4000}}
The performance is almost half of what it was before. Is this reasonable?
@Roboterbastler @zakmat @ruffsl @adamdbrw
@huqin-RM
In order to get closer to the real MID360 radar, motion distortion is taken into account. Is it possible to increase the update frequency to 1000 Hz and collect 200 points 1 ms, so that 20,000 points can also be collected in 100 milliseconds?
You are right, this is the most straightforward approach to simulate motion distortion. However, keep in mind that in order for this method to work, the physics calculations must be performed at least as often as the LiDAR updates (in this case, 1000 Hz). If physics updates fall behind, the sensor will generate data at the same simulation states.
The performance is almost half of what it was before. Is this reasonable?
Yes, this is expected. Each time the sensor is triggered, RGL must rebuild the scene on the GPU, perform raycasting, and process the resulting point cloud. By increasing the sensor update rate 100 times, the RGL pipeline also need to be executed 100 times more frequently, which significantly increases the overall workload.
In order to get closer to the real MID360 radar, motion distortion is taken into account. Is it possible to increase the update frequency to 1000 Hz and collect 200 points 1 ms, so that 20,000 points can also be collected in 100 milliseconds?
You are right, this is the most straightforward approach to simulate motion distortion. However, keep in mind that in order for this method to work, the physics calculations must be performed at least as often as the LiDAR updates (in this case, 1000 Hz). If physics updates fall behind, the sensor will generate data at the same simulation states.
The performance is almost half of what it was before. Is this reasonable?
Yes, this is expected. Each time the sensor is triggered, RGL must rebuild the scene on the GPU, perform raycasting, and process the resulting point cloud. By increasing the sensor update rate 100 times, the RGL pipeline also need to be executed 100 times more frequently, which significantly increases the overall workload.
If two radars with the same frequency and model are executed, they will be reconstructed by RGL on GPU and ray tracing will be performed separately. If so, can it be realized that when the frequency and model are the same, all radar rays are gathered together, and only RGL is performed once to reconstruct the GPU scene and perform ray tracing? Will it improve the simulation rate when multiple radars of the same model are working?
Thank you for your question. In the current implementation, if two or more sensor are triggered on the same simulation state, the scene is rebuilt once. We use cache mechanism to skip unnecessary computation if possible. Ray tracing is performed independently for each sensor and requires significantly less computation time than building a scene. Combining ray tracing for all sensors into a single process is not expected to yield a substantial performance improvement.
Thank you for your question. In the current implementation, if two or more sensor are triggered on the same simulation state, the scene is rebuilt once. We use cache mechanism to skip unnecessary computation if possible. Ray tracing is performed independently for each sensor and requires significantly less computation time than building a scene. Combining ray tracing for all sensors into a single process is not expected to yield a substantial performance improvement.
Thank you for your reply.I can run a radar factor up to 70% at 1000hz. But when there are two radars, it drops to 54%. Where does this performance loss come from? I tried to have only one radar at 1000hz, but the number of samples doubled each time, and the result was still about 70%. It seems that it has little to do with the number of single radar samples, but with the number of radars.
It appears that the performance drop when using two or more LiDARs may be due to how sensor triggers are currently implemented. Each LiDAR calls its RayTrace method at PreUpdate stage, and this method performs two main operations:
- The update of rays and the request for raytracing (link)
- Raytracing is performed asynchronously, so it does not block the Gazebo thread.
- Fetching and publishing results (link)
- This part blocks the Gazebo thread because it waits until the point cloud is fully computed.
When running a simulation with two LiDARs, the sequence of the operations is as follows: first LiDAR raytrace -> Gazebo waits for the results -> Gazebo fetches the point cloud -> second LiDAR raytrace -> Gazebo waits for the results -> Gazebo fetches the point cloud.
To optimize performance, you can try to separate raytacing and results fetching and call them at two different stages: PreUpdate and Update. This approach allows both LiDARs to perform raytracing simultaneously, which should reduce the overall wait time for the results.
It appears that the performance drop when using two or more LiDARs may be due to how sensor triggers are currently implemented. Each LiDAR calls its RayTrace method at PreUpdate stage, and this method performs two main operations:
The update of rays and the request for raytracing (link)
- Raytracing is performed asynchronously, so it does not block the Gazebo thread.
Fetching and publishing results (link)
- This part blocks the Gazebo thread because it waits until the point cloud is fully computed.
When running a simulation with two LiDARs, the sequence of the operations is as follows: first LiDAR raytrace -> Gazebo waits for the results -> Gazebo fetches the point cloud -> second LiDAR raytrace -> Gazebo waits for the results -> Gazebo fetches the point cloud.
To optimize performance, you can try to separate raytacing and results fetching and call them at two different stages: PreUpdate and Update. This approach allows both LiDARs to perform raytracing simultaneously, which should reduce the overall wait time for the results.
Thank you very much. I'll give it a try.