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.
CodePudding user response:
I think what you are reading in odomTime
is not the time stamp of the message in the topic /odom
, when you use MessageList
the MessageList table contains one row for each message in the bag ( in your case a raw for /odom
and a raw for /cmd_vel
that's whey you are getting the time stamp twice.
please refer to this tutorial for more info
CodePudding user response:
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.