I will certainely have plenty of questions, so if your are keen at anwsering, here is some background information :
I am using this node an a differential robot you can see here (the hokuyo providing the scans is a the front on the first left picture.
http://team-ard.com/images/stories/crotocombo.jpgIt evolves on such kind of tables with fixed walls often in view:
http://team-ard.com/images/stories/coupe2010.jpg
The classical odometry does well at the condition of separating the propulsive whell from the "encoder wheel". It is not the case in our design, so the odometry information are good at :
_ low speed/low acc
_ better at the beginning
_ no good when bumping into an obstacle (and this happens oftenly).
So my team and I are very interessed in such kind of "no floor link" odometry, that's why we are trying the canonical_scan_matcher. But behind this, there are industrial applications of this that would love to have a working combination of dead reackoning + laser odometry.
What I misses in the documentation is the tuning capabilities of the node, knowing that a quite good odometry is provided (I think there are by default configured for no odometry returns). In comparing the 2 systems, I see both system sometimes right sometimes wrong. So there must be something to tune to have a proper merge of the 2 localisation systems.
Another point : it seems that the system is (by far) better when the environnment is static (which is normal). Is it something to tune to be robust to this ?