[ros-users] slam_gmapping: extracting pose history
Ivan Dryanovski
ivan.dryanovski at gmail.com
Mon May 17 16:27:28 UTC 2010
Rene & Brian,
I did some testing with our own bag file, and my results confirm what
Brian noticed.
In particular, with the old gsp_->setgenerateMap(false), we have:
- "gsp_->processScan()" takes a small ammount of time
- maps obtained by "GMapping::ScanMatcherMap &smap = best.map" only
model occupied space
- in order to obtain a map with free space, we must iterate over the
tree, which is a linear time operation that grows with the number of
scans (unbound?)
Changing to gsp_->setgenerateMap(true), we have:
- "gsp_->processScan()" takes significantly longer, and is
proportional to the number of particles being used. Presumably that's
because a map is generated for each particle
- maps obtained by "GMapping::ScanMatcherMap &smap = best.map" model
both occupied and free space
- obtaining the map can be done in constant time
Now the map update step is only required for visualization purposes.
My feeling is that for real-time applications, where you are
interested in being able to process as many scans as possible, it
would be better to use gsp_->setgenerateMap(false), and disable
updating the map altogether, so that it doesn't hog up any cpu time.
While this solution would work for us, it seems a little ad-hoc. Is
there any way to obtain the map in constant time without the huge
performance hit obtained by enabling setgenerateMap(true), or are we
hitting an algorithmic limitation of GMapping? Perhaps the tree of
particles can be periodically collapsed, so that its depth does not
grow unbound. I know that DP-SLAM
(http://www.cs.duke.edu/~parr/dpslam/) uses a similar approach. That
would require a significant rewrite of gmapping. But if it is indeed
the case that gmapping can be optimized further for real
time-performance, it might be worth it to put it on the agenda.
Ivan Dryanovski
On Mon, May 17, 2010 at 11:31 AM, Brian Gerkey <gerkey at willowgarage.com> wrote:
> hi Rene,
>
> Thanks for the patch; that approach sounds very promising.
>
> But my casual testing (using logged data via
> gmapping/test/basic_stage_localization.launch) suggests that, with the
> patch applied, slam_gmapping consumes more CPU, rather than less.
>
> As it stands, the common processing profile of slam_gmapping is a
> relatively low nominal load with periodic surges up to 100% of a core
> (presumably when building the occupancy grid).
>
> With the patch applied, slam_gmapping consumes a steady 100% of a
> core. Maybe this is because many unnecessary maps are being built?
>
> A constant-time update step is generally preferred, but not
> necessarily if the constant factor means that a core is always pegged.
>
> brian.
>
>
> On Mon, May 17, 2010 at 3:54 AM, René Wagner <rene.wagner at dfki.de> wrote:
>> Hi all,
>>
>> On Thu, 2010-05-13 at 21:08 -0700, Brian Gerkey wrote:
>>> I've also noticed that the time required to produce the occupancy grid
>>> grows over time. I don't find this too surprising, because presumably
>>> there's more raytracing to be done with each added pose / scan.
>>
>> Online SLAM algorithms try to avoid a situation where this is necessary
>> since a time/space complexity that grows with the distance traveled
>> would be prohibitive.
>>
>> The algorithm behind GMapping [1] only requires the current map, robot
>> pose and weight for each particle. By default, the map does not model
>> free space, but this can be changed through an appropriate
>> configuration.
>>
>> The attached patch instructs GMapping to build the complete map
>> for each particle as part of the regular SLAM process and extracts the
>> map without any additional processing and without any unnecessary
>> copying. This should also avoid the need to patch GMapping to store past
>> laser scans, but I have left that part of the ROS package untouched for
>> now.
>>
>> We used GMapping with a similar configuration at the RoboLudens and
>> RoboCup Rescue competitions in 2006 [2] and it worked well for online
>> operation.
>>
>> Let me know if you have any questions regarding my changes. I'd
>> appreciate it if they could be incorporated into ROS.
>>
>> Cheers,
>>
>> Rene
>>
>> [1]
>> http://www.informatik.uni-freiburg.de/~stachnis/pdf/grisetti06tro.pdf
>> [2] Thanks to Christoph Hertzberg for digging out the code and sending
>> it my way.
>> --
>> ------------------------------------------------------------
>> Dipl.-Inf. René Wagner Junior Researcher
>> DFKI Bremen Enrique-Schmidt-Str. 5
>> Safe and Secure Cognitive Systems D-28359 Bremen
>>
>> Phone: (+49) 421-218-64224 Fax: (+49) 421-218-98-64224
>> Email: Rene.Wagner at dfki.de Web: http://www.dfki.de/sks
>> --- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
>> Firmensitz: Trippstadter Strasse 122, D-67663 Kaiserslautern
>>
>> Geschäftsführung:
>> Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
>> Dr. Walter Olthoff
>> Vorsitzender des Aufsichtsrats:
>> Prof. Dr. h.c. Hans A. Aukes
>> Amtsgericht Kaiserslautern HRB 2313
>> ------------------------------------------------------------
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
More information about the ros-users
mailing list