Instead of data exported from their viewer software, it's a pcap captured with Wireshark or a another network capture tool that uses the standard pcap format.
Initially I was trying to extract the lidar packets with libpcap and python, using pcapy or similar, and went through a lot of trouble getting the pcap library to build in the cygwin environment. Python and libpcap were able to load the data from the pcap, but rendered the binary into a long string with escape codes like '\xff'.
I then discovered that Wireshark has a function called 'follow udp stream'- right-click on the data part of a packet in Wireshark and then export as 'raw'. The exported data doesn't preserve division between packets any longer, but since each is of a consistent length (1206 bytes) it's easy to parse.
Python does work well for loading binary data from file:
import array
f = open('data.raw') # the data exported from wireshark in the raw format
bin = array.array('B') # setup an array of typecode unsigned byte
bin.fromfile(f, 1206) # each packet has 1206 bytes of data
The contents of bin now have 1206 bytes of data that looks like this:
>>> bin
array('B', [255, 221, 33, 39, 5, 9, 67, 178, 8, 116, 160, 13, 126, 222, 13, 63, 217, 8, 162, 204, ...
The 'B' element doesn't prevent indexing into the real data with bin[0] and getting 255 and so on.
The first two bytes indicate whether the data is from the upper or lower array, and the 33 39 is interpreted to mean that the reading was taken when the sensor head was rotated to (39*255+33)/100 or 99.78 degrees.
For 32 times after those first two bytes there are pairs of distance bytes followed by single intensity bytes, and then it starts over for a total of 12 times... and there are 6 more bytes with information that is unnecessary now. See here for what I currently have for parsing the raw file, later I will get into add the per laser calibration data.
5 comments:
Hi. I wonder how different it is when processing a pcap file from a Velodyne HDL-32E. I tried to apply it to the sample data that came with the Velodyne CD by running your code:
"python pcap_to_csv.py Road.pcap 0 Road.csv"
but returns the following:
"4
Traceback (most recent call last):
File "pcap_to_csv.py", line 117, in
rotCor.append( float(eval(row[1])) )
IndexError: list index out of range"
What could be happening here?
Hi Eric,
Did you get your problem solved? I also need the same data in csv format. If you have any solution, please do share with me.
Thanks
Is there a manual for the 32E that defines the packet structure? That is what I used for this. It's likely the packet structure changed to be half as long (I think there are half as many lidars and therefore half as much data) so the hardcoded sizes in the python script would overrun the indices and give you the 'list index out of range' error.
If you can locate a manual and also get me a sample 32E data file I could take a look.
The webpage of http://www.ros.org/wiki/velodyne_common says the 32E will be supported by ROS eventually, it might be worth looking in there to see if they've updated the code but not the webpage.
Actually in looking at the code it is failing with parsing the calibration file that should be associated with the scanner- for me it was called db.csv- do you have something like that?
The link for the sample data is broken
Post a Comment