-
Notifications
You must be signed in to change notification settings - Fork 655
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
fix(-): non uniformity of concatenated pointcloud publishing speed #9126
base: main
Are you sure you want to change the base?
fix(-): non uniformity of concatenated pointcloud publishing speed #9126
Conversation
Thank you for contributing to the Autoware project! 🚧 If your pull request is in progress, switch it to draft mode. Please ensure:
|
Node: /perception/object_recognition/detection/object_association_merger_araya_AERO_16_YE5_6871_436549973956238849 |
Here, the waiting time for each topic is set. |
It is possible that the data in velodyne_packets does not contain any contents, so I will investigate including that point. |
Please put the ticket/bag link to the PR description, so that other internal member can also track the issue. |
Top lidar and other lidars are not same. |
Cases where point clouds exist in rosbag and have been converted, but have not been integrated.
|
The left velodyne packets had no delay, but the Top velodyne packets had an interval of 200 ms.
On the other hand, the node interpreting velodyne packets(velodyne_decoder_ros_wrapper.cpp) often takes about 200 ms, which may be the reason for the lack of integration.
Case: Left Velodyne Packets
|
The way I got the above display was to output the topic header |
I also have this problem in my environment, even I replayed the ROS bag slowly. |
It seems that decoder is slow, I will also ask the component team for ideas. |
Sorry for butting in.
|
I'm one of the Nebula maintainers, I'll quickly take a look at the bag to see if it's packet loss or an issue with Nebula! |
I ran the bag (just top LiDAR packets) locally and
Which version of Nebula are you currently using @emuemuJP? |
@mojomex which is part of nebula/v0.01 on April 3rd. It is the nebula used in XX1:beta/v0.45.0 |
@Owen-Liuyuxuan |
Thank you everyone! |
@mojomex Node info
Then, after waiting for a while after launch, the following error message appeared.
|
@emuemuJP Hi, it looks like a network error to me. Could you confirm your IP settings? There is a config file for each sensor in nebula_ros/config/lidar/velodyne, please compare the settings there with your network setup, Wireshark etc. |
Ah, are you trying to run off a rosbag? |
@mojomex |
Thank you for the confirmation! We've only updated the Nebula documentation to cover this a few days ago, so it's understandable that people haven't seen it yet. If there's any further trouble, the new documentation provides some useful info 🙂 |
@Owen-Liuyuxuan |
@mojomex |
@Owen-Liuyuxuan With the new Nebula, I was not able to reproduce the result: comment from above.
|
CPU/(network) usage is around 50%. cpu_usage.webm |
@emuemuJP Hm, this indeed looks like a performance issue then. When using tools like To be honest, Velodyne is not high on our priority list and the code is known to be quite........, so I cannot spend a lot of time on it unless the above factors are confirmed. |
@mojomex Thank you for your kind reply! |
My laptop was balanced mode. I changed mode from balanced to performance. |
packet timestamps are here.
Processing log is following. Packet |
Interesting, the queue size (I assume that's Nebula's mt_queue?) is way larger than expected... |
@mojomex Originally, It had only one packet loss but while processing there were three packets lost. |
I made the same change and checked it. |
Description
The number of point clouds to be publish is suddenly reduced, which has negative effects such as unstable ROI shape.
pointpainting_roi_cluster_fusion_objects_before.webm
Related links
Parent Issue:
How was this PR tested?
Notes for reviewers
None.
Interface changes
None.
Effects on system behavior
None.