ros bag file size

[Chenweng1]

Hi, Can anyone please tell me will the ros bag file size and the number of points vary from one mode to another (512x10, 512x20, 1024x10,1024x20, 2048x10)? I see the ros bag size and number of ros message vary largely if I record the (lidar_packets) and the (/os1_cloud_node/points). Which topic should I consider ?

Thanks weng

[zuzi-m]

It depends on what you want to do. Do you want to use the raw data as it comes from the sensor, or do you just want to use the resulting point cloud?

If you save the lidar_packets, you will have to reconstruct them into the point cloud yourself - each message in lidar_packets contains raw data of one lidar packet (described in software user guide, section 3.4) which holds 16 columns of 64 points and some headers (frame_id, timestamp, etc). And the number of packets you need to read to construct one frame of point cloud depends also on the mode because they have different number of columns (512, 1024 or 2048).

The os1_cloud_node/points topic contains messages holding the point cloud frames reconstructed from the lidar_packets topic. Based on the mode, each point cloud will have 512x64, 1024x64 or 2048x64 points, each point with all its data (xyz, range, intensity, noise, reflectivity...) and a header for the entire point cloud (timestamp, frame id...).

The size of the data per second of recording in both cases depends on the mode because the first number says how many columns there are in each point cloud, and the second number says how many times per second you get the entire point cloud data (10 or 20). So for each mode the number of points per second is number_of_columns * 64 * refresh_rate. (e.g. for 512x10 it is 327680 points per second and for 1024x20 it is 1310720 points per second which is four times more).

While amount of data in both topics for each mode depends on the number of points per second, the difference is that the lidar_packets do not contain XYZ positions of the points and are packed more efficiently in the memory, but include some more overhead because each message requires some headers and each column has headers too. On the other hand, the point cloud topic has less overhead in headers, but much more data because of XYZ positions of each point stored and the data types of the values. I can't compute the difference exactly, but I would say if you need to save space, use the lidar_packets because they should be smaller. But if you don't have to save memory, choose the topic that is more suitable for what you want to do with it.

[Chenweng1]

Hi @zuzi-m ,

Thank you very much for your valuable response.My goal is to get the las file from the point cloud with all the information including (x,y,z, range, intensity and noise).I am using the pcl_ros library to get the pcd file directly from the bag file. Later, using the cloud compare to get the .las files from the pcd files.I don't know my pcd files only contains the (x,y,z and the intensity information). there is no timestamp(t), noise and range information in the pcd file attribute. Can you please guide me on how I can retrieve the noise, range and timestamp information from my rosbag containing (/os1_cloud_node/points) topic ?

Thank you very much for your valuable time.

Best

Weng

[zuzi-m]

@Chenweng1 looks like you have exactly the same problem as in #94 - have a look at my last answer. You have to use a correct point type for your point cloud.

[JJuhyeon-Kim]

It depends on what you want to do. Do you want to use the raw data as it comes from the sensor, or do you just want to use the resulting point cloud?

If you save the lidar_packets, you will have to reconstruct them into the point cloud yourself - each message in lidar_packets contains raw data of one lidar packet (described in software user guide, section 3.4) which holds 16 columns of 64 points and some headers (frame_id, timestamp, etc). And the number of packets you need to read to construct one frame of point cloud depends also on the mode because they have different number of columns (512, 1024 or 2048).

The os1_cloud_node/points topic contains messages holding the point cloud frames reconstructed from the lidar_packets topic. Based on the mode, each point cloud will have 512x64, 1024x64 or 2048x64 points, each point with all its data (xyz, range, intensity, noise, reflectivity...) and a header for the entire point cloud (timestamp, frame id...).

The size of the data per second of recording in both cases depends on the mode because the first number says how many columns there are in each point cloud, and the second number says how many times per second you get the entire point cloud data (10 or 20). So for each mode the number of points per second is number_of_columns * 64 * refresh_rate. (e.g. for 512x10 it is 327680 points per second and for 1024x20 it is 1310720 points per second which is four times more).

While amount of data in both topics for each mode depends on the number of points per second, the difference is that the lidar_packets do not contain XYZ positions of the points and are packed more efficiently in the memory, but include some more overhead because each message requires some headers and each column has headers too. On the other hand, the point cloud topic has less overhead in headers, but much more data because of XYZ positions of each point stored and the data types of the values. I can't compute the difference exactly, but I would say if you need to save space, use the lidar_packets because they should be smaller. But if you don't have to save memory, choose the topic that is more suitable for what you want to do with it.

Hi @zuzi-m , thank you for your information. Your explanation really helped me understand the concept of 'lidar_packets' and 'os_cloud_node/points' topics. BTW, I'm struggling with acquiring Ouster data. I acquired bag file with 'lidar_packets' topic, but what I need is XYZ positions of each point. Is there any way I can convert the data from 'lidar_packets' to 'os_cloud_node/points'?

Thank you for your kind explanation.

[kairenw]

Hi, let's keep all conversation on this topic at the relevant issue at https://github.com/ouster-lidar/ouster_example/issues/367