Reputation: 402
I have a Velodyne VLP-16 "Puck" lidar that I am trying to use with Google Cartographer in ROS. I've set "npackets" in the velodyne driver to 1, to get the message frequency we see in Google's sample bag files, but the messages seem to be published sporadically (see the attached RQT image).
What could be the limiting factor here?
I've tried this with direct ethernet connections between my VLP-16 and the computer, and with computers running Ubuntu with an Intel Core I5-7600 processor and a Core I5-8365U processor.
Are these processors just not fast enough, or is there some other bottleneck causing these pauses in messages?
As a result, the Cartographer validator complains that one message begins before the previous message ends:
cartographer_rosbag_validate -bag_filename 2021-08-10-17-10-09.bag
W0810 17:19:57.937173 4886 rosbag_validate_main.cc:166] Sensor with frame_id "velodyne" measurements overlap in time. Previous range message, ending at time stamp 637642374093122761, must finish before current range message, which ranges from 637642374093120291 to 637642374093133354
W0810 17:19:57.940515 4886 rosbag_validate_main.cc:166] Sensor with frame_id "velodyne" measurements overlap in time. Previous range message, ending at time stamp 637642374093783810, must finish before current range message, which ranges from 637642374093783614 to 637642374093796654
W0810 17:19:57.940832 4886 rosbag_validate_main.cc:166] Sensor with frame_id "velodyne" measurements overlap in time. Previous range message, ending at time stamp 637642374093929761, must finish before current range message, which ranges from 637642374093929736 to 637642374093942776
W0810 17:19:59.675483 4886 rosbag_validate_main.cc:203] Sensor with frame_id "velodyne" range measurements have longest overlap of 0.0012975 s
I0810 17:19:59.675602 4886 rosbag_validate_main.cc:399] Time delta histogram for consecutive messages on topic "points2" (frame_id: "velodyne"):
Count: 8126 Min: 8.821e-06 Max: 0.0126982 Mean: 0.00132742
[0.000009, 0.001278) # Count: 295 (3.63032%) Total: 295
(3.63032%)
[0.001278, 0.002547) ################### Count: 7828 (96.3328%) Total: 8123 (99.9631%)
[0.002547, 0.003816) Count: 2 (0.0246124%) Total: 8125 (99.9877%)
[0.003816, 0.005085) Count: 0 (0%) Total: 8125 (99.9877%)
[0.005085, 0.006353) Count: 0 (0%) Total: 8125 (99.9877%)
[0.006353, 0.007622) Count: 0 (0%) Total: 8125 (99.9877%)
[0.007622, 0.008891) Count: 0 (0%) Total: 8125 (99.9877%)
[0.008891, 0.010160) Count: 0 (0%) Total: 8125 (99.9877%)
[0.010160, 0.011429) Count: 0 (0%) Total: 8125 (99.9877%)
[0.011429, 0.012698] Count: 1 (0.0123062%) Total: 8126 (100%)
Upvotes: 1
Views: 690
Reputation: 4843
Trying to record pointcloud data can be pretty intensive since it gets pretty dense. As well, the way rosbag record
works is it will occasionally open and write chunks of data to the disk. This, in turn, can create a problem if chunks aren't being written to the disk as quick as they're coming in.
I had the same problem recording 3 VLP-16s at once on an I7-6700. In the end I was able to get it working by editing both the buffsize
and chunksize
; where chunksize
is the actual size it uses when writing to files. My final command was rosbag record --lz4 --chunksize=16000 --buffsize=640000 -O <output_file> <topic_names>
. Note: I also ended up using lz4 compression since it was the quickest option.
This is all assuming the issue you're having is specific to rosbag
and it doesn't show up when listening to the topic right off the velodyne node. If the latter is also an issue, and since the VLP-16s use broadcast messages, it could be a network interface setup problem.
Upvotes: 2