ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

how to use ethzasl_icp_mapping with velodyne?

asked 2013-08-28 23:53:42 -0600

aswin gravatar image

updated 2013-08-29 04:15:00 -0600

Hi all, I am using a .pcap file to playback velodyne HDL 64E_2 data using the velodyne ros package. I would like to obtain some odometry data using the velodyne and the ethzasl_icp_mapping package seems to be a good start. I am able to register pointclouds using a kinect, but with the velodyne I have no output on /point_map. My launch file is as below. I am not using any filters or icp config file and just want to try out the package with default parameters. Is there anything wrong here?

  <node pkg="velodyne_driver" type="velodyne_node" name="velodyne_driver">
    <param name="model" value="64E_S2"/>
    <param name="pcap" value="/home/hope/Downloads/velodynepcap/S227_target.pcap"/>
    <param name="read_once" value="false"/>
    <param name="read_fast" value="false"/>
    <param name="repeat_delay" value="10000.0"/>
    <param name="rpm" value="200.0"/>
    <param name="frame_id" value="velodyne"/>

<node pkg="velodyne_pointcloud" type="cloud_node" name="cloud_node">
    <param name="calibration" value="$(find velodyne_pointcloud)/params/64e_utexas.yaml"/>
    <param name="min_range" value="3.0"/>
    <param name="max_range" value="130.0"/>

<node name="mapper" type="mapper" pkg="ethzasl_icp_mapper" output="screen" >
    <remap from="cloud_in" to="/velodyne/velodyne_points" />
    <param name="subscribe_scan" value="false"/>
    <param name="subscribe_cloud" value="true"/>
    <param name="odom_frame" value="/velodyne" />
    <param name="map_frame" value="/map" />
    <param name="useConstMotionModel" value="false" />
    <param name="localizing" value="true" />
    <param name="mapping" value="true" />
    <param name="minOverlap" value="0.8" />
    <param name="maxOverlapToMerge" value="0.9" />
    <param name="tfRefreshPeriod" value="0.01" />
    <param name="vtkFinalMapName" value="finalMap.vtk" />
    <param name="useROSLogger" value="true" />
    <param name="minReadingPointCount" value="1000" />
    <param name="minMapPointCount" value="10000" />
    <param name="inputQueueSize" value="1" /> 

If there are any other techniques that can do laser odometry, kindly suggest

edit retag flag offensive close merge delete

3 Answers

Sort by ยป oldest newest most voted

answered 2013-08-29 05:42:23 -0600

joq gravatar image

updated 2013-08-29 05:45:09 -0600

I have not tried that combination. Several questions and comments:

  • Are you using a recent version of the driver? It has fixes for the 64E S2. Are you running Hydro or Groovy?

  • You should verify the speed of your device. I've seen examples at 300 RPM, but not 200 RPM, I don't think that is an option. Velodyne provides a procedure for configuring the speed, consult the manual if you need or want to change it.

  • Using nodelets rather than nodes would probably reduce your CPU overhead noticeably.

  • You should use the correct angles calibration for your device, params/64e_utexas.yaml is for an older model than your S2. The script will convert the db.xml provided by Velodyne with your device into the YAML format used by the velodyne_pointcloud package.

  • The cloud node publishes data in the "/velodyne" frame to the /velodyne_points topic, not /velodyne/velodyne_points. Use rostopic list or rosgraph to verify what is actually being published. Also, rostopic hz will tell how often messages are actually sent.

  • The driver does not publish a transform from "/velodyne" to "/odom". How could it know that? You do need to provide one yourself.

  • Since your device is moving, something needs to transform "/velodyne" points into the "/odom" frame. Normally that would be done via the transform node instead of the cloud node. It transforms each packet as it's received, to minimise "smearing" of data as the device revolves. Unfortunately, that presumes you have a separate odometry source, publishing that transform for the conversion.

I am not sure what to recommend for the circular odometry dependency: the driver needs odometry for transforming data into a fixed "/odom" frame, but that's what you are trying to generate. If the vehicle is moving slowly enough and the device is rotating quickly enough, you may be able to get away with assuming the point cloud generated for each rotation is "instantaneous".

I am open to suggestions for how to change the driver to better support your use case. Perhaps we could write a different transform node and nodelet that would better suit your requirements. It is not clear to me how that would work, however.

I would expect other rotating LIDARs to exhibit similar problems. I would appreciate suggestions from people with experience doing similar things with those devices. Heading changes tend to cause more trouble than forward motion.

edit flag offensive delete link more


Hi, first of all, thanks a lot for the work on the driver. I do have issues running some pcap files (e.g., but thats off topic. Yes, I normally run it at 900 rpm and it looks fine. I get errors on "unable to open calibration file", the 64e_utexas is the only working one i have. I am using the hydro package in ubuntu 13.04.

aswin gravatar image aswin  ( 2013-08-29 06:16:35 -0600 )edit

Thanks for the suggestion on the rostopic. Thats probably what is wrong. Will try it out. I think the driver as is, serves its purpose; and no feature enhancement is required.

aswin gravatar image aswin  ( 2013-08-29 06:19:42 -0600 )edit

I hope you're right. I am interested in knowing the results of your work.

joq gravatar image joq  ( 2013-08-29 06:29:16 -0600 )edit

The latest Hydro version 1.1.1 provides a `params/64e_s2.1-sztaki.yaml` configuration file. That S2.1 is more similar to your S2 than our old 64E from 2007. I would try that, instead.

joq gravatar image joq  ( 2013-08-29 06:30:11 -0600 )edit

The manual says your model supports spin rates from 300 to 1200 RPM. That higher, 20Hz, speed should help minimize rotational "smearing" for your application.

joq gravatar image joq  ( 2013-08-29 06:36:51 -0600 )edit

Will post any updates here. Regarding the calibration file, I cannot load 64e_s2.1-sztaki.yaml. I will verify if I doing it correct 2moro.

aswin gravatar image aswin  ( 2013-08-29 06:41:09 -0600 )edit

The problem was with the wrong ros topic as you suggested. It should just be /velodyne_points. Thank you.

aswin gravatar image aswin  ( 2013-08-29 15:39:09 -0600 )edit

answered 2013-08-29 06:54:33 -0600

Francois gravatar image

We didn't try yet the node ethzasl_icp_mapper with a Velodyne 64 (and never used pcap format) but we have some appropriate configuration files for the Velodyne 32. You can have a look at the folder ./launch/artor for some examples or directly on GitHub.

Some of the results can be seen here:

Once you confirm that your topic names are correctly links, I'm foreseeing some other challenges at the registration level:

  • The default configuration of the node might have some problem due to the concentric circle generated by the 64 beams. I really suggest you to start with the config files in ./launch/artor

  • The point cloud that you will give to the topic "cloud_in" should optimally be from an assembled point cloud of 360 degrees. If you want to do it well, you would need an estimate of the platform motion. For a quick implementation, you can assume that the platform is static during one Velodyne revolution.

  • The bandwidth use by that sensor is very large. Don't expect real-time capability at the beginning so you should replay your data at a slow rate to see what is going on.

I hope that will put you on the good track!

edit flag offensive delete link more


Very cool! Was your work done using the ROS Velodyne driver?

joq gravatar image joq  ( 2013-08-29 07:07:18 -0600 )edit

I used the same parameters and filters used for artor, but with a 64E_2 laser. The program ran, but I did not see any associations or map built. This could be due to vehicle speed or my overlap parameters. Here is my data log with a "no sensor noise or normals found" warning.

aswin gravatar image aswin  ( 2013-08-29 15:41:42 -0600 )edit

@aswin: the link you provide doesn't seem to work. @ joq: I'm only supporting the platform for the 3D mapping but I think they use their custom version of the driver that is floating around the lab since some years. I will direct them to your node so they can have a look.

Francois gravatar image Francois  ( 2013-08-30 07:32:27 -0600 )edit

It works: Unfortunately this page adds a (/p) to the link. So plz remove it if this is the case.

aswin gravatar image aswin  ( 2013-08-30 21:55:09 -0600 )edit

Thanks to all for your support. I can get odometry with artor configuration with no problem. Due to the speed of the velodyne (1200rpm) and speed of the vehicle(10kmph), the map is lost, Nevertheless I was able to get fairly good odometry information. This was tested on a quadcore i7. I guess for higher speeds, a more powerful pc is required.

aswin gravatar image aswin  ( 2013-09-01 17:08:40 -0600 )edit

I am using groovy and velodyne 32E for ethzasl_icp_mapper, but it keep on showing this error ERROR: cannot launch node of type [point_cloud_converter/point_cloud_converter]: point_cloud_converter artor file in launch folder i.e. artor_mapper.launch mentions this <remap from="cloud_in" to="/velodyne/assembled_cloud2"/> which really doesn't exist.

maverick01 gravatar image maverick01  ( 2013-10-18 01:53:56 -0600 )edit

Yes, the launch file that you are using is specific for a platform that we have in our lab and not intended to be used out-of-the-box. I suggest you to copy the launch file and adapt what your need.

Francois gravatar image Francois  ( 2013-10-18 02:15:47 -0600 )edit

[follow up] In its current configuration, Artor produces PointCloud msgs and not PointCloud2, which explains the extra node point_cloud_converter. You will also need to remap cloud_in to your own topic.

Francois gravatar image Francois  ( 2013-10-18 02:17:12 -0600 )edit

answered 2013-08-29 00:35:45 -0600

arp gravatar image

Hi, I have used ethzasl_icp_mapping with tilting laser-scanner. But I have not worked with velodyne. Do the velodyne nodes you are launching provide a tf from the "/sensor_frame" to "/odom" frame?

In your case "/odom" frame and "/sensor_frame" are both velodyne.

The node ethzasl_icp_mapping requires the transform "/sensor_frame" to "/odom" frame.

It basically requires some initial guesses for odometry. The package provides uses this guesses and provides corrected odometry using ICP as far as I know.

edit flag offensive delete link more


Hi, I do not have any odometry. I also tried giving a zero tf from /velodyne to /odom, but dint help. The openni example in the stack works without any odometry or tf though

aswin gravatar image aswin  ( 2013-08-29 03:10:38 -0600 )edit

Hey, is odometry input (wheel, GPS, IMU) really necessary for node ethzasl_icp_mapping to work? I tried the node with velodyne 32E pcap file without any odometry input. But it couldn't output direction or move forward for more than 5m. After which it stopped at a point and kept adding points at the same place.

maverick01 gravatar image maverick01  ( 2013-11-19 18:09:01 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2013-08-28 23:53:42 -0600

Seen: 1,924 times

Last updated: Aug 29 '13