how to use ethzasl_icp_mapping with velodyne?

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

aswin
528 ●32 ●44 ●51

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

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>

<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>

<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" /> 
</node>

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

edit retag flag offensive close merge delete

add a comment

3 Answers

Sort by » oldest newest most voted

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

joq
25443 ●181 ●256 ●408

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

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 gencalibration.py 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

Comments

Hi, first of all, thanks a lot for the work on the driver. I do have issues running some pcap files (e.g. http://robots.engin.umich.edu/SoftwareData/Ford), 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 ( 2013-08-29 06:16:35 -0500 )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 ( 2013-08-29 06:19:42 -0500 )edit

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

joq ( 2013-08-29 06:29:16 -0500 )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 ( 2013-08-29 06:30:11 -0500 )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 ( 2013-08-29 06:36:51 -0500 )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 ( 2013-08-29 06:41:09 -0500 )edit

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

aswin ( 2013-08-29 15:39:09 -0500 )edit

add a comment

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

Francois
101 ●2 ●2

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

Comments

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

joq ( 2013-08-29 07:07:18 -0500 )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. https://dl.dropboxusercontent.com/u/8948006/icp-log.txt

aswin ( 2013-08-29 15:41:42 -0500 )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 ( 2013-08-30 07:32:27 -0500 )edit

It works: https://dl.dropboxusercontent.com/u/8948006/icp-log.txt. Unfortunately this page adds a (/p) to the link. So plz remove it if this is the case.

aswin ( 2013-08-30 21:55:09 -0500 )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 ( 2013-09-01 17:08:40 -0500 )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 ( 2013-10-18 01:53:56 -0500 )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 ( 2013-10-18 02:15:47 -0500 )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 ( 2013-10-18 02:17:12 -0500 )edit

see more comments

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

arp

172 ●6 ●9 ●15

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

Comments

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 ( 2013-08-29 03:10:38 -0500 )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 ( 2013-11-19 18:09:01 -0500 )edit

add a comment

how to use ethzasl_icp_mapping with velodyne?

3 Answers

Comments

Comments

Comments

Question Tools

Stats

Related questions

how to use ethzasl_icp_mapping with velodyne? edit

3 Answers

Comments

Comments

Comments

Question Tools

Stats

Related questions

how to use ethzasl_icp_mapping with velodyne?