LiDAR and Camera ros msg count

asked 2021-01-28 02:01:12 -0500

Ajay gravatar image

updated 2021-01-28 02:20:50 -0500

Hello everyone, I am bit confused about understanding the ros messages count. I have recorded bag file with Camera and LiDAR sensor. Camera operated @25 HZ and LiDAR operated at 10 HZ. But when i checked the ros bag info, it shows like below:

rosbag record /cam/image_raw /points_raw

Camera: /cam/image_raw: 147 msgs/ sensor_msgs/Image (25hz)

LiDAR /points_raw: 187 msgs/ sensor_mgs/PointCloud2 (10hz)

But, though camera operating higher frequency than LiDAR, how it records fewer msgs than LiDAR.

Sorry, If i missed something here, any answer appreciated.

Regards, Ajay

edit retag flag offensive close merge delete



How long is the bag file, and are there any gaps in the data? rqt_bag (wiki) is a good tool that may help your investigation.

tryan gravatar image tryan  ( 2021-01-28 08:28:51 -0500 )edit

@tryan, Thank you so much, it's very useful tool.

Ajay gravatar image Ajay  ( 2021-01-28 19:17:39 -0500 )edit

@tryan, Currently am reading data from multiple topics in rosbag file using a C++ callback function. Where each callback function carries topic msg information, msg->data, msg->header and so on. But i am trying to get rosbag time along with the topic msg data. Like as it in python (for topic, msg, t in bag), How can i read bagtime in C++. ?

Ajay gravatar image Ajay  ( 2021-01-31 06:24:58 -0500 )edit

Did you resolve your first question? This should maybe be posted as a separate one, but here's a brief response:

I'm a little confused about what you're trying to accomplish. The time you get from the bag file corresponds to when the recorder node actually wrote the message to file (receipt time), which is different than the timestamp you might see in a message header (publish time). You can obtain receipt time directly from the bag file, but it's not something you would get from a published message via callback.

To do something like the Python loop in C++, you would create a rosbag::View on a bag (as in the rosbag API examples) and iterate through the messages. You can access the receipt time of a message with the rosbag::MessageInstance::getTime() funciton

tryan gravatar image tryan  ( 2021-01-31 14:55:40 -0500 )edit

@tryan, Thank you, sorry for posting new issue over here. Regarding the first question, I figured out the reason that Camera Node has an issue with while streaming data.

Regarding the second question: I wanted to synchronize the data on multiple topics based on the Bag time stamp. To verify the synchronized frames from different topics, I am looking for bagtime stamp.

Ajay gravatar image Ajay  ( 2021-01-31 18:37:16 -0500 )edit

If you're trying to synchronize data, you should work with the publish times (timestamp in the message headers) rather than the receipt times (t in Python above, or rosbag::MessageInstance::getTime()). There's an example of how to synchronize multiple topics with a message_filters::TimeSynchronizer in the rosbag cookbook.

tryan gravatar image tryan  ( 2021-01-31 19:40:18 -0500 )edit

@tryan, Excellent this is really helpful. By the way, Do you have any idea about how does ROS handle topic synchronization by default? Because currently, am reading two topics data with different NODES (10HZ, 30HZ). I have not used any TimeSynchronizer, Just am picking a frame from the NODE (30HZ) whenever there is message arrives in NODE (10HZ).

So I wonder, Which frame got picked on what basis.

Ajay gravatar image Ajay  ( 2021-01-31 19:53:50 -0500 )edit

ROS doesn't synchronize topics by default. Certain sensors may publish multiple synchronized topics, but that's up to the sensor manufacturer/driver developer to figure out. Also, ROS doesn't enforce timing on its own. A node may put an arbitrary timestamp on a message and publish it at a different arbitrary time if that's how it's coded. Nodes that are set to run at a particular frequency often just operate _near_ that frequency--you can check by looking at the timestamps in the message headers. Unless you want to do a deep investigation of the sensor node, though, it's usually alright to assume that the timestamp in the message header is when the data occurred. Still, without a TimeSynchronizer or similar, there's nothing forcing the messages you get from two different topics to contain data close in time. Depending on accuracy requirements for your application ...(more)

tryan gravatar image tryan  ( 2021-01-31 20:51:30 -0500 )edit