1

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? enter image description here

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%)
Ardiya
  • 677
  • 6
  • 19
Michael Kossin
  • 342
  • 3
  • 14
  • What's the `rosbag record` command you're using to record the pointcloud topic? – BTables Aug 11 '21 at 17:00
  • @BTables it is just rosbag record points2. I've also tried using a buffer (rosbag record points2 -b 0). – Michael Kossin Aug 11 '21 at 18:38
  • do you happen to know the bandwidth usage of `points2`? What does `rostopic bw /points2` give? I'm pretty sure this is a throughput issue with rosbag record; I've run into almost this exact problem with the VLP-16s – BTables Aug 11 '21 at 18:47
  • @BTables The output of rostopic bw /points2 is as follows: ``` average: 1.66MB/s mean: 0.00MB min: 0.00MB max: 0.01MB window: 100 average: 1.68MB/s mean: 0.00MB min: 0.00MB max: 0.01MB window: 100 average: 1.69MB/s mean: 0.00MB min: 0.00MB max: 0.01MB window: 100 ``` – Michael Kossin Aug 11 '21 at 19:31

1 Answers1

2

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.

BTables
  • 4,413
  • 2
  • 11
  • 30