Revision history [back]

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.

Fundamentally, 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_d and ~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.

Is the amcl node consuming 100% of the CPU?

Can you provide a bag with representative data that I can use to reproduce the problem?