From: Geoffrey B. <gb...@ki...> - 2007-06-22 11:05:17
|
If you want to make changes to the map interface that you would like everyone to benefit from, now is the time to do it. The 2.1 release is coming up soon, and if the change is made before then, it will go in that release. Otherwise, it will have to wait a year or more for the 2.2 release before it goes in an official distribution and not just the unstable CVS version. Geoff Fabian Aichele wrote: > Hello! > > On Fr, 2007-06-22 at 08:51 +1200, Toby Collett wrote: >> Currently the maps can be dynamic, but there is no way to inform the >> clients that there have been changes, perhaps all we need is to be >> able to push update reports (not the updated data itself). For big >> maps that would allow client to intelligently age data in areas they >> are not currently active in and only actually re request it when they >> approach the areas that have had updates. >> > For my own needs an occupancy grid map with 70 meter side length with > cell size 10x10 cm is/should be manageable even with a non-optimized > update protocol, i. e. re-transmitting the whole map (if using a > greyscale bitmap). > > >> All that would be needed for this would be a new data message with >> type=DATA, subtype=PLAYER_MAP_DATA_UPDATE_REPORT >> and a message body with the update region >> start (x,y) and size (width, height) > > So the map driver would publish that data message after finishing the update procedure itself, and e. g. the wavefront planner would "consume" it > and request the updated map. That was my first idea as well. > > I will start extending the map driver first, after adapting the SLAM algorithm I intend to use so it is able to communicate with the "rest" of Player > (it was written for the CARMEN framework). > > Regards, > Fabian Aichele -- Robotics research group, University of Auckland http://www.ece.auckland.ac.nz/~gbig005/ |