Add Velodyne HDL-64E Support

[erichahn]

TL;DR; Is there a template anywhere to easily switch between 2d, 3d, using imu, using multiple lidar sensors, and which types of messages to send at cartographer.

I currently have access to an hdl-64e velodyne. Looking through the config files it seems like changing the backpack_2d.lua file to use a point_cloud, and to remap from points2 to my topic /velodyne_points would allow mapping.

What I'm having trouble wrapping my head around is how to create my own urdf to allow all my robot joints and links to comply with the map frame, and exactly what changes need to be made to launch files, lua files, or other config files. I've been able to almost get thing working, however the map does not generate properly, and the lidar points do not load very quickly.

I do not believe I'm hardware limited. Have a very capable machine but believe I've not setup everything properly so far.

[Entropy512]

For any Velodyne, you're going to want to start with a 3D configuration.

As far as the URDF - it's a bit of a learning curve, but the most important things are: Choose a fixed reference point on your robot. This is the tracking_link in the configuration files - and ideally this is whatever frame your odometry source publishes a transform to. General ROS convention seems to be to call this base_link.

Then your URDF should, at a minimum, contain transforms from that reference point (base_link) to your IMU's frame and the Velodyne's frame.

Unfortunately I can't yet make my configurations public, but as an example, I have a robot that has Ackermann steering and is driven by the steer wheel.

base_link is the center point between the rear wheels of the robot. My urdf does have a drivewheel_link that listens to joint states published by my odometry node but this is only for visualization - Cartographer does not need this. I have fixed transforms between base_link and my laser's optical center, and once we get our mounting plate for our Velodynes and IMU built, I'll have fixed transforms between base_link and each VLP-16 and our IMU. (In my case, I'll likely have transforms from a reference point on our mounting plate to each of those, and then a transform from base_link to that reference point).

If you are using odometry as an input, you want published_frame and odom_frame to match. Cartographer will publish a transform between map_frame and odom_frame/published_frame. If you are not using odometry and instead are having Cartographer provide it - I think backpack_3d has the proper conventions here, I forget what they are.

Also - an IMU is required for 3D.

[erichahn]

I was hoping to stick with 2D for now as I do not currently have the IMU being published, however, because the 64 detects many(most) points on the ground and sometimes off adjacent buildings, trees, etc. I'm hearing that 3D may be the only way to properly generate maps.

Thank you for the clarification of the URDF. I currently have that set properly, and am also using the base_link convention.

I was able to get 2D running, without an IMU, however it had a very difficult time generating the map I believe because tracking was not working properly. Again, roads(outside), vs indoors with nice walls.

[wohe]

• revo_lds is a 2D example without an IMU, especially important in this case is use_online_correlative_scan_matching
• If you do not use an IMU, we assume +z of your tracking frame to always approximately point upwards.
• You can use min_z and max_z to filter our points on the ground.
• If you need more help, please provide a bag file and your configuration.

[Entropy512]

@erichahn Based on @wohe 's comment, I guess it depends on your actual vehicle platform.

Most outdoor vehicle applications can't be assumed to always be on a flat surface, and even if they are, usually have enough suspension dynamics that the "tracking frame always pointing up" assumption isn't valid. (I believe that while technically an IMU is not required, that particular assumption fails in enough cases that you really want an IMU if using a 3D sensor).

I've had great results with 2D, however: 1) I'm in an indoor application on a flat floor 2) I have so far only used laser scanners that scan in a level disc, such as SICK LMS100 and Pepperl+Fuchs R2000 - for example, the VLP-16 3D unit does not have any beams at 0 degrees elevation. 3) My vehicle has no suspension, so the scanner stays fairly level.

We're working on mounting 3D sensors to the same vehicle, but as I mentioned - we're assuming from the get-go that we really want the IMU. (Part of it is because I want to be able to continue proper navigation when the vehicle goes up a ramp.)

[SirVer]

seems like all questions in here are answered, so closing this issue.

@Entropy512 Andrew, thank you for the excellent community work in here. This is much appreciated!