I'm running ros2 foxy on ubuntu x64.

I've tried to find more information in other questions. While finding some hints in that direction in

• https://answers.ros.org/question/318536/understanding-rosbag-timestamps/
• https://answers.ros.org/question/71647/bag-file-camera1394-timestamps-out-of-order/

but no answer that fully covered this question.

To illustrate my question, I've created this node in rclcpp:

#include <chrono>
#include <functional>
#include <memory>
#include <string>
#include "example.hpp"

EX::EX() : Node("EX")
{
  pub_temp = this->create_publisher<sensor_msgs::msg::Temperature> ("myTemp", 1);
}

int main(int argc, char *argv[])
{
  rclcpp::init(argc, argv);
  auto node = std::make_shared<EX>();

  rclcpp::Rate loop_rate(20);

  sensor_msgs::msg::Temperature myTemp;
  rclcpp::Clock clk;

  while (rclcpp::ok())
  {
    rclcpp::Time now = clk.now();
    myTemp.temperature = now.seconds();
    myTemp.header.stamp = now;

    node->pub_temp->publish(myTemp);

    loop_rate.sleep();
    rclcpp::spin_some(node);
  }

  rclcpp::shutdown();
  return 0;
}

The only aim is to publish current time in a message, while reusing already defined sensor_msg.

Having this node running, I record a rosbag by means of

ros2 bag record -a -o test

Then, I convert the rosbag into a csv by means of https://github.com/fishros/ros2bag_convert, which seems to be just a python interface to ros2bag.

In resulting csv, I see both, temperature (used as container for float time in seconds) and header.stamp are equal and monotonic increasing. But the rosbag timestamps are not monotonic increasing (removed other columns to improve readability)

time,temperature
2023/04/14 23:25:01.713269932,1681507501.712159
2023/04/14 23:25:01.763184384,1681507501.7621498
2023/04/14 23:25:01.813263977,1681507501.8121464
2023/04/14 23:25:01.863493836,1681507501.8623857
2023/04/14 23:25:01.913219134,1681507501.9123156
2023/04/14 23:25:01.963290093,1681507501.9621348
2023/04/14 23:25:02.12836290,1681507502.0120738 <-- wrong order
2023/04/14 23:25:02.63265628,1681507502.0622058 <-- wrong order
2023/04/14 23:25:02.109310622,1681507502.1082995
2023/04/14 23:25:02.163232019,1681507502.162216
2023/04/14 23:25:02.212783868,1681507502.2116454
2023/04/14 23:25:02.263243347,1681507502.262219
2023/04/14 23:25:02.309256681,1681507502.3084276
2023/04/14 23:25:02.363401993,1681507502.3622973
2023/04/14 23:25:02.413387354,1681507502.4122632
2023/04/14 23:25:02.463181642,1681507502.4621735
2023/04/14 23:25:02.513352901,1681507502.5121999
2023/04/14 23:25:02.563386845,1681507502.562251
2023/04/14 23:25:02.613217409,1681507502.6121466
2023/04/14 23:25:02.663480320,1681507502.6622477
2023/04/14 23:25:02.713262122,1681507502.7121816
2023/04/14 23:25:02.763399794,1681507502.7621949
2023/04/14 23:25:02.813229584,1681507502.8121612
2023/04/14 23:25:02.863225064,1681507502.8621368
2023/04/14 23:25:02.913630391,1681507502.912515
2023/04/14 23:25:02.963167168,1681507502.9621494 
2023/04/14 23:25:03.13150167,1681507503.0121276 <-- wrong order
2023/04/14 23:25:03.63157445,1681507503.062264  <-- wrong order
2023/04/14 23:25:03.113222072,1681507503.11224
2023/04/14 23:25:03.163350163,1681507503.1622245
2023/04/14 23:25:03.213454869,1681507503.2121778
2023/04/14 23:25:03.263233942,1681507503.262333
2023/04/14 23:25:03.313329800,1681507503.3122218
2023/04/14 23:25:03.363291941,1681507503.3622735
2023/04/14 23:25:03.413252180,1681507503.4121559
2023/04/14 23:25:03.463149939,1681507503.4621599
2023/04/14 23:25:03.513308239,1681507503.5122519
2023/04/14 23:25:03.563362947,1681507503.5622513
2023/04/14 23:25:03.613719179,1681507503.6121912
2023/04/14 23:25:03.663333300,1681507503.6622345
2023/04/14 23:25:03.713221713,1681507503.7121353
2023/04/14 23:25:03.763469970,1681507503.7622874
2023/04/14 23:25:03.813340610,1681507503.8122153
2023/04/14 23:25:03.863140192,1681507503.862155
2023/04/14 23:25:03.913280269,1681507503.9122233
2023/04/14 23:25:03.963255939,1681507503.9621973
2023/04/14 23:25:04.13163006,1681507504.0122058 <-- wrong order
2023/04/14 23:25:04.63282752,1681507504.0622451 <-- wrong order
2023/04/14 23:25:04.113324193,1681507504.1122315
2023/04/14 23:25:04.163296747,1681507504.1622348

I've already tried to use --qos-profile-overrides-path in ros2 bag record to ensure a

  history: keep_last
  depth: 1

but this didn't change anything.

My questions are:

• What does the timestamp in ros2 bag mean?
  
• Why is it not monotonic increasing but having jumps at a constant rate of 1 s
• I planned to use the timestamp to postprocess data based on their time (e.g. plotting). Should I add a header in each message instead of using timestamps of ros2bag?

Please notice that the publisher has a queue size of 1.

If you want to build a good system, it's vital to understand the characteristics of the connections your ros nodes are using.