adding driver and pointcloud support for the VLP16

[PatrickHussey]

Modifications to support the VLP16 including pointcloud processing.

I have the a PCAP file if there is no hardware available to test. I have tested with the units we have inhouse. Also added azimuth correction for inter block/firing dsr#.

Added launch file and calibration for the VLP16 as well.

[jack-oquin]

That looks great! Thanks for the contribution.

We need a PCAP file to use for a unit test case. Preferably no more than 20MB or 30MB. It'll be uploaded to download.ros.org for the build farm to use.

[PatrickHussey]

No problem, big fans of Velodyne here. We just got 4 VLP-16. I'll upload the PCAP soon.

I also have a driver for the HDL-32E position stream if that's of interest. No good to me now; the VLP-16 doesn't have inertial sensors (looks like I'm back to the Segway BSA or a 3DM-GX3-45 inertial reference for 3D mapping). One note is that the inertial sensors on the Velodyne systems don't appear to be temperature compensated so not really a big loss, plus the GPS is only available in RMC which is no good for covariance or 3D fix. Although GPS is somewhat useful for precise time synchronization using a NTPD driver.

[jack-oquin]

I also have a driver for the HDL-32E position stream if that's of interest.

There have been many requests for that. Does it run as a separate node subscribing to a different UDP port?

[PatrickHussey]

Yes it is a completely separate node running in Python with a separate UDP connection, I'll include it in the velodyne driver and create a new pull request when I have a chance.

I have a PCAP file ready, where should I upload it? I also updated the test directories to include the VLP16 tests, do you want me to add those to the pull request? They are all correct except for the MD5 checksum of the file on download.ros.org, which I won't have until the file gets uploaded.

Also I noticed in the PCAP files on download.ros.org do not have messages directed to ports other than 2368 filtered out which should cause the RawData::unpack function to fail, but instead because the headers are not specifically checked in the 32E/64 HDL unpack function it causes this strange blind spot behavior when playing back PCAP files, because those packets are skipped but not decremented from the number of packets per rotation. At any rate the PCAP file I made filters by port and the RawData::unpack_vlp16 has an assertion check for the header (0xEEFF), and no blind spots in the PCAP playback.

[jack-oquin]

Yes it is a completely separate node running in Python with a separate UDP connection, I'll include it in the velodyne driver and create a new pull request when I have a chance.

How about adding a new package to the repo, called velodyne_position, or something similar? It's only useful for certain models.

Alternatively, if it's easier to add as a new node to velodyne_driver (because of common code or something), that's OK with me. The main benefit of a separate package is that it does not add additional dependencies for those not using the new node.

I have a PCAP file ready, where should I upload it? I also updated the test directories to include the VLP16 tests, do you want me to add those to the pull request? They are all correct except for the MD5 checksum of the file on download.ros.org, which I won't have until the file gets uploaded.

It needs to go in http://download.ros.org/data/velodyne/, with a name like vlp16.pcap.

[jack-oquin]

You can send the PCAP directly to @tfoote, or send it to me and I'll pass it to him. It might be possible to send as an e-mail attachment. How large is the file?

Let's not add the test until the upload finishes. Otherwise, the build farm's continuous integration will start reporting failures.

The MD5 sum should only depend on the file's contents, not its location.

[PatrickHussey]

got it I'll send you a link to dropbox, its 9MB so email will probably just kick it back

[PatrickHussey]

Here is a link to the pcap file

https://www.dropbox.com/s/rljaapjn9rzx0id/vlp16.pcap?dl=0

[tfoote]

The file is now available at: http://download.ros.org/data/velodyne/vlp16.pcap

[jack-oquin]

Thanks, Tully.

[PatrickHussey]

I committed the updates to include the tests for VLP16, update launch header and modified the CMakeLists.txt for velodyne_driver and velodyne_pointcloud to include the tests and download the test data.

When I get some time I'll create a new package for the position data parsing and time synchronization with GPS via NTPD. We actually use GPS and GPS denied RTC time synchronization with our embedded system so I might just release it as supported for our platforms when we release the stack for the new Segway system architecture we developed.

[jack-oquin]

Sounds good. There is already an issue (#24) requesting it.

[PatrickHussey]

Ran all the tests relating to the VLP16 support, should be good to go.

[jack-oquin]

Works for me. The only test problems are due to #45, and have nothing to do with this PR.

Thanks for the excellent work. Whom should we credit in the change history?

[PatrickHussey]

Patrick Hussey, haven’t gotten around to a personal github account yet.

PATRICK HUSSEY
Principal Engineer

STANLEY INNOVATION, INC
9 Henry Clay Drive
Merrimack, NH 03054
Direct: 603.689.9724
Fax: 603.882.8818
http://www.stanleyinnovation.com/

[jack-oquin]

No problem, Patrick. Thanks for your contribution.

[PatrickHussey]

Happy to help, I think the VLP16 is a game changer. Our platforms push 8m/s+ so the Velodyne systems are perfect for us. We plan to really push support of the sensor going forward. I am very impressed with the sensor, and Velodyne LiDAR products in general.

Glad I could contribute!