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.

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)

Toby

On 6/22/07, Kevin Barry <barryk@gmail.com> wrote:
Player maps don't /need/ to be static. Just most of the existing ones are. There is a sonar based map generating tool posted here: http://sourceforge.net/tracker/index.php?func=detail&aid=1565758&group_id=42445&atid=433166
and I've made a modified version to use the ladar however I've not played with it at all lately. I believe one of my friends got wavefront working with a generated/updating map, however sometimes it would crash player. (Not sure if this was the ladar based mapping driver or wavefront or what)

Also 2-5 seconds sounds HUGE. What kind of system will this run on? If you have to transfer the whole map (i think cmap is transfer only a portion of it?) then I can see why you'd not want to do it every update, but 2-5 seconds is plenty of time for VFH to get stuck somewhere.


On 6/21/07, Fabian Aichele < faichele@hilarenhaus.hilaritas.de> wrote:
Hello!

The algorithm implementation I intend to use comes with its own map format and visualization tool, basically including everything needed for "stand-alone" operation.

The mapcspace driver is, as far as I understand its operation, not exactly what I require, since it seems to rely on another map driver as input, which again implies a "static" map.

My idea would be to convert the algorithm's map format to a bitmap in regular time intervals (2-5 seconds?) and extend the map driver to reread map data on the fly (for example, "and"-ing the existing bitmap and the new one generated from the SLAM algorithm output), and the planner driver would have to be extended to "poll" the map driver for new data at around the same time interval.

Well, there's where I'd be a bit lost, since I will have to figure out how to add a new message type to a Player driver.

Regards,
Fabian Aichele

-----Ursprüngliche Nachricht-----
Von: playerstage-developers-bounces@lists.sourceforge.net [mailto:playerstage-developers-bounces@lists.sourceforge.net ] Im Auftrag von Pablo Rivera
Gesendet: Donnerstag, 21. Juni 2007 21:33
An: playerstage-developers@lists.sourceforge.net
Betreff: Re: [Playerstage-developers] Implementing "localize" and "map"interfaces

Fabian,
For reasons specific to the project I am working on, we are using our own
map and planner (which can be updated during run-time,) instead of the
Player map interface.. But it would be nice if Player maps could
be changed after init. What about the "mapcspace" driver?
-Pablo Rivera

--------------------------------------

From: Fabian Aichele <faichele@hi...> - 2007-06-21 12:57
Hello!

About three weeks ago I already asked about Simultaneous Location and
Mapping-related material within PlayerStage, and meanwhile took a look
at the pmap utility set as hinted in the replies to my question, along
with the other implementations of SLAM algorithms that I found in other
robotic projects (mainly for CARMEN).

Based on the requirements of my task I have decided to port an existing
implementation of a particle filter based algorithm
(http://www.openslam.org/gmapping.html) to work with Player/Stage.
The tasks at hand are:
- Autonomously explore and map the workspace.
- Navigate to given positions based on the map obtained from
exploration.

The second subtask is (I think) much easier, since it can be realized
with what is already available in Player/Stage (the amcl, nd or vfh, and
wavefront drivers).
The first task, however, requires apart from a SLAM algorithm, an active
exploration heuristic which determines the "course of action" for
exploration based on the results of the SLAM algorithm. The SLAM
algorithm mentioned above is the only one for which I could find a
matching heuristic.

Now my questions regarding the best practice for implementation:
- Would you recommend to create a Player driver which exposes "localize"
and "map" interfaces, or do all the high-level work in a client
application which only communicates via position2d and laser proxies
with Player?
- As far as I could determine from the "map" driver source, maps are
static, i. e. the map file is read once at initialization of the driver,
without a possibility to update map data on the fly. How difficult would
it be to extend the existing map driver to offer a way of manipulating
map data during runtime?

Regards,
Fabian Aichele

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Playerstage-developers mailing list
Playerstage-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/playerstage-developers



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Playerstage-developers mailing list
Playerstage-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/playerstage-developers


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Playerstage-developers mailing list
Playerstage-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/playerstage-developers




--
This email is intended for the addressee only and may contain privileged and/or confidential information