Why are consecutive timestamps in rosbag equal once in a while?

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.

Solution

I solved the problem doing the following:

for ii = 1 : length(odomStructs)
    sec = cast(odomStructs{ii}.Header.Stamp.Sec, 'double');
    nsec = cast(odomStructs{ii}.Header.Stamp.Nsec, 'double');
    odomTime(ii, 1) = sec + nsec*1e-9;
end

In this way, I read the header.stamp, which isn't affected by the same problem.

Don't mind the hypothetical inefficiency of the cycle: I implemented it this way just to make sure I was not taking the wrong element.