Results get worse compared to commit 116

[schotte]

We started working with the cartographer in the end of october. So we started with the version 116. We worked on that Version till early january. We decided to go onto the newest Version at that point and had no problem running the rosbag again. The only difference was the result. We tried a few weeks to get it to a result as good as befor, but couldnt get it running. We wrote a shell script to auto test some parameters, this got us a better result, but still not as good as befor. As reference we had a mobile mapping system from riegel (similar to this http://www.riegl.com/nc/products/mobile-scanning/produktdetail/product/scanner/53/)
We also integrated the gps fix from the xsens to get better result, this did not made a big difference as the xsens uses a internal filter.

We are using a Sick lms500 and a xsens as imu. They were mounted on a Van and we were driving around near our university. We are working in postprocessing on a VM with xubuntu 14.04. (4cores 16gb ram)

To the Results:
Version 116:

Parameter test results:

(this is with gps as odom, thats why its rotated)

We did read some of the commit msgs, but could not really find out which step made our results getting worse. Maybe someone of you can find the problem.

I m attaching the rosbag, the configuration files, launchfiles and urdf modells. (old and new Version, the other configurations were not changed)
Also I m attaching a program with remaps the imu-data, because we had problems doing it with the ros-internal tools. Also this has the program for the gpsfix to utm conversion node. (this are in the folder cartographer_fue and are build in a normal catkin_ws with catkin_make )
As github just supports 10mb uploads, the files are on google-drive: https://drive.google.com/open?id=0B0ht7RlOmWvLX0UzalhycGdLVjg

If you need some new Information or I missed some needed information feel free to ask.

[wohe]

Since #116 there have been algorithmic changes to local SLAM and the default configuration we provide is for a backpack. One could of course bisect to figure out which commit(s) caused the drop in quality, but I'm not sure this is helpful to you. I would think what you need is tuning for the car use case.

I looked into the data you provided, though without the GPS derived odometry. If you think that part is important: Could you record a bag that has the necessary odometry so that I can simply replay it?

It seems the main issue is tuning. For example, I increased the maximum distance to submaps to consider for loop closure to 30 meters. Also, to avoid slipping in one case in the lower right of the map, I increased reliance on the constant velocity model a bit by raising the translation_weight. The 5 cm default resolution is quite high for a car so I changed it to 15 cm.

SPARSE_POSE_GRAPH.constraint_builder.max_constraint_distance = 30.
TRAJECTORY_BUILDER_2D.submaps.resolution = 0.15
TRAJECTORY_BUILDER_2D.ceres_scan_matcher.translation_weight = 3e1

This produces a map very similar to the one you show for #116. I hope this helps you as a starting point. If you have further questions, just let me know.

[schotte]

Thank you for the quick response. It really looks better now :)
I tryed to record the data, so you dont need to run the nodes, but I failed. I m getting a time syncronisation warning from the Cartographer, while replaying.

[ WARN] [1485363867.747249771, 1485362329.488265818]: W0125 18:04:27.000000 20856 tf_bridge.cc:51] Lookup would require extrapolation into the past. Requested time 1482230642.311152900 but the earliest data is at time 1485362329.634929960, when looking up transform from frame [imu_link] to frame [base_link]

The cartographer is not calculating any results because of this.