amcl subscriber queue

asked 2011-05-19 18:06:23 -0500

Augusto Luis Ballardini

56 ● 3 ● 5 ● 7

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

kwc
7572 ● 29 ● 77 ● 126
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 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 19:10:00 -0500 )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-20 02:29:08 -0500 )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-20 02:56:13 -0500 )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-20 03:10:53 -0500 )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-20 03:26:10 -0500 )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-20 03:30:12 -0500 )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-20 03:37:12 -0500 )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-20 03:58:05 -0500 )edit

Comments

1 Answer

Your answer

Question tools

Stats

Related questions