This is my first reply, I am also struggling with this issue. I was hoping to manipulate raw data in Python easily that I recorded to .bag files.
For my setup, I am using python 2.7.17 (because of ROS dependencies), I import "rosbag" and "rospy", and am able to load my prerecorded .bag file easily using the command
myBag = rosbag.Bag('Filename.bag'). I can get it to list what topics are in the bag, and then I pick the LIDAR topic using
myBag.read_messages('topics=[/os1_node/lidar_packets']) I can get the timestamp and the msg output for a single packet - I can also iterate thru all the packets in the ROS bag file. All seems ok.
So, if I select the LIDAR topic, and then use a for loop to iterate thru the file, for each message (msg) and timestamp (t), the msg is 12609 bytes in length, coming in 8 bit chunks.
Everyone in the forums says "refer to the manual" but, and on page 20 of V1.13.0 of the OS1 Software User Guide it says that each LIDAR data packet should be 12608 bytes. What is up with the extra byte. I was worried I did the math wrong:
[Timestamp (2 words = 8 bytes) + Measurement ID (0.5 words = 2 bytes)+ Frame ID (0.5 words = 2 bytes) + Encoder Count (1 word = 4 bytes) + 64 Data Blocks (3 words*64 = 768 bytes) + Azimuth Status (1 word = 4 bytes)] * 16 azimuth positions = 12608 bytes
Looks like the math is ok, still all my "msg"s from my .bag files are 12609 bytes. If I look at the data stream from "msg" carefully, I have an extra "0" byte at the end of very message (right after my 0xFFFF "the azimuth is good" 32-bit word). I am throwing the "0" byte at the end of every message away, so, that gets us to 12608 bytes, just like the manual.
Q1) What is that extra "0" byte at the end of every ROS .bag message? OK to discard it?
Well, I guess it is time to pull the message out and make it relevant using pg 20-21 of the manual. This leads me to my next issue:
Q2) Why aren't there public functions to pull relevant data out of the ROS .bag object? It looks like we only can get a timestamp and a message from the bag? Is there a ROS .bag message parser routine for Python already written or some function that I missed?
So, I started to write one, and right off the bat, I can't get the timestamp to match with the myBag time object. Not even close. I suspect the issue is I don't know how the timestamp word is formed.
Q3) If you take the first 8 bytes from the message to get your timestamp, how are these ordered to form the uint64 for the timestamp of that azimuth block? I know it won't match exactly, since I have 16 azimuth blocks, and they will all have a slightly different timestamps, but I can't get it right to even get close. I did however, manage to pull the measurement ID, the frame ID, and the encoder count A-OK, and the values seem correct as I watch the bag get parsed.
So, if anyone can point me to a ROS / Ouster Python library so I can get access to the data (range, reflectivity, etc) in the bag message easily without having to bit shift on my own, I would be grateful. I suspect it would answer (or bypass) all three of my q's above.