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@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@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@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>