Inconsistent Timestamp Values between Simulation Data and Real-World Data
When collecting data through the collector
ROS Node, ROS Messages recorded in a simulation environment exhibit different timestamp characteristics than ROS Messages recorded with the robot in the real world. The discrepancy only applies to messages that contain a header
field which subsequently contains a stamp
field for a timestamp. A timestamp in a message header is a genpy.Time
object, holding the time passed since the unix epoch in a secs
and nsecs
field. Currently, all messages that are being collected and persisted can have 4 different configurations of timestamps:
- Message-Header timestamp with secs and nsecs representing time passed since unix epoch
- Message-Header timestamp with both secs and nsecs set to 0
- Message-Header timestamp with secs and nsecs representing time passed since begin of the simulation
- No Message-Header (In this case, the timestamp of when the mssage was written into the rosbag is used in later processing)
These conditions apply to all message types (camera messages[/nr/camera/, /zed] and action messages[/joy, /nr/engine/input, /vesc/ackermann..]). These timestamps become important when ROS Bag files are being read and converted by the RosBagReader
class in the neuroracer-ai package. The RosBagReader tries to match camera and action messages in order to logically correlate them so they can be extracted together as training datapoints. It does so by comparing timestamps. If a message does not have a message header with a timestamp, it used the timestamp recorded by the ROS Bag writing process. Whe nthe matching was implemented, it was assumed that message header timestamps are always positive (secs and nsecs > 0), of expected structure (time passed since unix epoch, as per genpy.Time documentation) and accurate. While it is unclear why we have messages of case 2, with a message header timestamp of secs == 0 and nsecs == 0, we know that case 3 only happens when recording data within a simulation. While we can fix case 2 for now by instead just using the less accurate rosbag timestamp, we ideally want all messages to be stamped as accurately as possible. Especially when images from multiple camera topics are extracted together, accurate message header timestamps are of great importance. The following actions are suggested to combat the issue:
-
Deploy a Fix for Case 2 in the RosBagReader Class (done) -
Investigate why Case 2 is happening in the first place and fix to it records the time passed since unix epoch properly -
Investigate if we can get proper time since unix epoch timestamps in simulator data or find alternative