amcl subscriber queue

amcl

asked 2011-05-19 13:06:23 -0600

Augusto Luis Ballardini

430 ●11 ●16 ●22 http://www.ira.disco.u...

updated 2011-06-17 12:31:12 -0600

kwc
12244 ●54 ●90 ●132 http://kwc.org/

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

edit retag flag offensive close merge delete

Comments

Did you spend time changing any of the parameters to the AMCL node before changing the size of the subscriber queue? You can find their descriptions here: http://www.ros.org/wiki/amcl#Parameters .

Eric Perko ( 2011-05-19 14:10:00 -0600 )edit

Hi Eric. I spent hours with those parameters after analyzing the algorithm on the book by Thrun, Burgard and Fox (Prob. Robotics), unfortunately without success. What I wonder is why there should be a message queue to be analyzed, this filter doesn't need every laserscan, but just the last one.

Augusto Luis Ballardini ( 2011-05-19 21:29:08 -0600 )edit

If you want to use more than one laser, you need a queue larger than 1 to be sure that you process both lasers. If the situation didn't improve for you even on an I7, I don't think it's an issue with the message queue. We are running it on a Core 2 with 1.7GHz without a problem.

Lorenz ( 2011-05-19 21:56:13 -0600 )edit

Same here. I've got a laser coming in at 75Hz on an i7 and it easily keeps up. One thing you may want to check (and I'd be interested in your results) would be to decrease the "update_min_d" parameter. At higher speeds, you may want to run AMCL more frequently to keep those buffers "clear".

Eric Perko ( 2011-05-19 22:10:53 -0600 )edit

Hi Lorenz and Eric. I would like to ask you at what speed your robotsmoves. I did my first test with ROS/Amcl on a Pioneer3dx robot without problems, but now I'm using a little car for an autonomous driving project and if i move faster than 5 m/sec I have problems.

Augusto Luis Ballardini ( 2011-05-19 22:26:10 -0600 )edit

I usually run with AMCL up to about 2.2m/sec. Can you reproduce the problem in a simulator like Stage or Gazebo if the simulated robot is moving at ~5m/sec with the simulated laser?

Eric Perko ( 2011-05-19 22:30:12 -0600 )edit

Lorenz, since AMCL processes one laserscan at time, and there is no certainty that messages arrive alternated (laser1 lasers2 laser1 ...) a laserscan queue larger than 1 could help to avoid unusual behaviors, but a queue of 100 I think it's extremely long.

Augusto Luis Ballardini ( 2011-05-19 22:37:12 -0600 )edit

@Eric: I never tried to use stage or gazebo until now, maybe it is good time to do it :-) I tried a wide set of values for the update_min_d parameter, now it is set to the default 0.2m

Augusto Luis Ballardini ( 2011-05-19 22:58:05 -0600 )edit

add a comment

answered 2011-06-12 15:37:47 -0600

Brian Gerkey
2916 ●22 ●23 ●34

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?

edit flag offensive delete link

add a comment

amcl subscriber queue

Comments

1 Answer

Question Tools

Stats

Related questions

amcl subscriber queue edit

Comments

1 Answer

Question Tools

Stats

Related questions

amcl subscriber queue