asked 2011-05-19 18:06:23 -0500Augusto Luis Ballardini
I am currently working with the AMCL node and I noticed a spring effect when the robot moves at high speed, I mean that there is a kind of delay in the transformation provided by AMCL node. I initially assumed that my PC was not fast enough, then I tried with a core-i7 but the situation has not improved as hoped. So I took some time to analyze the code and I want to ask you something about it:
at lines 345 + 346 of the amcl_node (http://www.ros.org/doc/api/amcl/html/amcl__node_8cpp_source.html @ line 345 + 346) there are the definitions of the laser subscribers and filters, both with a "queue_size" of 100 messages. In this case, if the laser node publishing frequency is 25hz, this queue will contain a long "history" (4 secs) and if the PC is not fast enough to process every single beam in this queue, this could be the reason of the "spring effect".
I tried to change the value of the queue, I set it to 1 because I think AMCL should take the last laser scan to compute the new pose (not a pose in the past, even if the published transform is future dated).
With this change the spring effect is no longer present, but I would like to understand why the authors of the code put a queue lenght like that, maybe there's something that I have not yet considered.
Thank you! Augusto
answered 2011-06-12 20:37:47 -0500Brian Gerkey
I put the queue length of 100 in there, not for any particularly good reason, but because it was the sort of default that I was using everywhere at the time. I agree that is could be lowered, but I don't think that it should be causing the behavior that you're seeing.
amcl is clocked by incoming laser data: it only does work on receipt of a new scan. When a scan is received, the robot's travel distance is checked, and if it's large enough (compared to
~update_min_a), then a filter update is performed; otherwise the scan is discarded. Under normal circumstances, the great majority of laser scans are simply discarded, with minimal computational cost, and the incoming message queue doesn't fill up.
If your robot is moving very fast and/or you have set the
~update_min_* parameters very low, then I suppose that
amcl could get busy, processing more than the usual number of laser scans. In that situation, and if laser scans are also coming in a high rate, then I could see how the incoming message queue might fill up. But I'd be a little surprised.
amcl node consuming 100% of the CPU?
Can you provide a bag with representative data that I can use to reproduce the problem?
Asked: 2011-05-19 18:06:23 -0500
Seen: 167 times
Last updated: Jun 12 '11