0
$\begingroup$

Rosanswers logo

I'm using ROS Noetic on Ubuntu 20.04 (kernel version 5.15.0-53-generic) on a MSI GF66 and I have encountered a strange problem when analyzing a recorded rosbag.

I have to publish at 10 Hz by means of a Simulink model some messages to the /cmd_vel topic of a Turtlebot that moves in Gazebo and records the /odom and /cmd_vel topics. When analyzing the recorded bag, I notice something strange: every once in a while, two consecutive timestamps are exactly equal, even though the value of the two corresponding messages of the topic are not equal (it holds both for /odom and /cmd_vel).

I use the following script in Matlab to extract the information from the bag:

bagSelect = rosbag('BagPubSimulink.bag');

odomBag = select(bagSelect, 'Time', [bagSelect.StartTime bagSelect.EndTime], 'Topic', '/odom');

odomStructs = readMessages(odomBag, 'DataFormat','struct');

odomTime = odomBag.MessageList.Time;

Then, I cycle on odomStructs to extract the messages I need, let's say odomX.

Taking two instants k and k + 1 when the problem occurs:

odomTime(k : k + 1) = {149.674000000000; 149.674000000000}

odomX(k : k + 1) = {-0.790906331505904; -0.787962666465643}`

I've noticed that this problem happens more frequently in the recorded bag when the considered topic has a high publishing frequency, e.g. if I record the /clock topic, this problem of consecutive timestamps being equal is magnified and can last for more than two consecutive timestamps.

Can you please help me with this problem?

In order to install ROS, I've followed the instructions at https://emanual.robotis.com/docs/en/platform/turtlebot3/quick-start/ up to paragraph 1.1.5.

I've actually had to add some lines of code from the video linked in the same page, because they are not written there.

I'm sorry if something is not clear and whether I've not used the correct wording, but I'm new to both Ubuntu and ROS and I have a lot to learn.

Please, tell me if I have to provide some more details to work out a solution.

Edit

The problem is not due to the fact that the duplicated timestamps belong to two messages of the two topics I've recorded. In fact, this is MessageList of the variable bagSelect:

Time                Topic        MessageType            FileOffset

99.3160000000000    '/cmd_vel'  'geometry_msgs/Twist'   402403
99.3170000000000    '/odom'     'nav_msgs/Odometry'     402497
99.3270000000000    '/odom'     'nav_msgs/Odometry'     403261
99.3690000000000    '/odom'     'nav_msgs/Odometry'     404025
99.4150000000000    '/cmd_vel'  'geometry_msgs/Twist'   404789
99.4170000000000    '/odom'     'nav_msgs/Odometry'     404883
99.4610000000000    '/odom'     'nav_msgs/Odometry'     405647
99.4610000000000    '/odom'     'nav_msgs/Odometry'     406411
99.5050000000000    '/odom'     'nav_msgs/Odometry'     407175
99.5160000000000    '/cmd_vel'  'geometry_msgs/Twist'   407939
99.5270000000000    '/odom'     'nav_msgs/Odometry'     408033
99.5730000000000    '/odom'     'nav_msgs/Odometry'     408797
99.6160000000000    '/cmd_vel'  'geometry_msgs/Twist'   409561
99.6170000000000    '/odom'     'nav_msgs/Odometry'     409655
99.6650000000000    '/odom'     'nav_msgs/Odometry'     410419
99.6650000000000    '/odom'     'nav_msgs/Odometry'     411183
99.7120000000000    '/odom'     'nav_msgs/Odometry'     411947
99.7150000000000    '/cmd_vel'  'geometry_msgs/Twist'   412711

Interestingly, /odom is the only topic of this bag that suffers from this timestamps duplication problem. Thus, it seems that the problem doesn't affect topics that are published by myself.

As a matter of fact, I've tried recording the /clock topic only with the Turtlebot staying still in the Gazebo world, and inside the MessageList I get bunch of equal timestamps, referring to different time instants, meaning that the messages of /clock topic are correctly different the one from the other.


Originally posted by Heisenasd on ROS Answers with karma: 13 on 2022-12-03

Post score: 1

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

A particular rosbag message can have two timestamps: one is the time-of-arrival at the node which is recording the rosbag, and the other is the header.stamp inside the message. It is not unexpected for the first to have duplicate arrival times -- it simply means that some networking delay caused two messages to be delivered to the rosbag process in the same memory buffer.


Originally posted by Mike Scheutzow with karma: 4903 on 2022-12-07

This answer was ACCEPTED on the original site

Post score: 1


Original comments

Comment by Heisenasd on 2022-12-07:
Thanks a lot for your answer! Do you think I can work out a solution to this problem? Also, I'm afraid there can be something wrong with the installation procedure I followed. Can it be the case in your opinion?. I'm saying this, because I installed ROS on three different machines in three different months (I've experienced some hardware problems, which were non-ROS related) and the only one where I didn't experience this issue was the first one, which was the least powerful one! Therefore. I suspect I may have forgotten something during, but my lack of experience with both Ubuntu and ROS doesn't really help me. At the end, this isn't such an insurmountable problem, but still it is, and I'd like to solve it. Thank you in advance for your considerations.

Comment by Mike Scheutzow on 2022-12-07:
You appear to be using the wrong timestamp. If your processing cares about exact timing of a msg, you should be using the header.stamp that was inserted by the node that published the message. This one is not affected by network latency.

Comment by Heisenasd on 2022-12-08:
I've managed to solve my problem! Thank you a lot!

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.