Avoid using outdated laser scans

[corot]

I have quite bad experiences while using this for mapping, and I found that one of the reasons is because of outdated scans. So I tried reducing the queue for laser scans to one, so unprocessed scans don't accumulate and we always use the latest available.

I added an extra check on how old latest scan is: scan_tolerance parameter. A negative value disables it.

I don't understand deeply how gmapping works, so feel free to discard this pull request if it's misguided or useless.

[mikeferguson]

Could you elaborate on what you mean by "bad experiences"? Obviously, if the scan gets old enough, TF won't have data to transform it, which should just throw a ROS_ERROR message, but not really cause problems.

I would suggest not changing the size of the queue mid-release-cycle, as it could have unintended side effects. It should be possible to add a new parameter for the queue size instead.

[corot]

Big jumps in robot pose due to "wrong" scan matching. I quote the wrong because it's wrong from the omniscient RViz point of view but not for the algorithm. I tried tweaking parameters to make gmapping relay more on odometry instead of accepting any matching, but failed.

In more detail: I use a turtlebot, so the "laser" is very narrow. So when it faces featureless areas like walls, it gets easily confused. That's specially true in simulation, where the environment is normally very featureless, or in test environments without typical furniture (as in this video http://www.youtube.com/watch?v=unLtvC2sBN4&feature=youtu.be). I wonder if the algorithm would need an ad-hoc rule to avoid corrections (specially big jumps) when matching a featureless scan... as it does when the scan is fully nan or inf.

On old scans:

I think there's no such a control by now, as current implementation uses Transformer::transformPose, who doesn't control timings (not 100% sure on this, sorry). At least I have never seen the WARN "Failed to compute odom pose, skipping scan", but I have verified that after a map update, the 5 stocked scans get processed, with the oldest one being a second old.

Ok with the extra parameter; or we can just start a new branch (indigo-devel).