From: Fabian A. <fai...@hi...> - 2007-06-21 20:25:16
|
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=FCngliche Nachricht----- Von: pla...@li... = [mailto:pla...@li...] Im Auftrag = von Pablo Rivera Gesendet: Donnerstag, 21. Juni 2007 21:33 An: pla...@li... 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=20 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 Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
From: Toby C. <tco...@pl...> - 2007-06-21 20:37:03
|
Adding a new message to player is not overly difficult, however I suspect a fair few people will have their own ideas about how dynamic map updates should work. Player can push the updates out to clients, but we need to think carefully about how to do this (particularly for grid based maps, where you only want to push the updated parts...) I would recommend implementing it as a player driver and updating the interface, this is functionality that should be useful to a number of people. The best thing would be to post your proposed changes here once you have thought them through and get the feedback of the rest of the community= . Toby On 6/22/07, Fabian Aichele <fai...@hi...> wrote: > > Hello! > > The algorithm implementation I intend to use comes with its own map forma= t > and visualization tool, basically including everything needed for > "stand-alone" operation. > > The mapcspace driver is, as far as I understand its operation, not exactl= y > what I require, since it seems to rely on another map driver as input, wh= ich > 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 n= ew > one generated from the SLAM algorithm output), and the planner driver wou= ld > have to be extended to "poll" the map driver for new data at around the s= ame > time interval. > > Well, there's where I'd be a bit lost, since I will have to figure out ho= w > to add a new message type to a Player driver. > > Regards, > Fabian Aichele > > -----Urspr=FCngliche Nachricht----- > Von: pla...@li... [mailto: > pla...@li...] Im Auftrag von Pabl= o > Rivera > Gesendet: Donnerstag, 21. Juni 2007 21:33 > An: pla...@li... > 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 > Pla...@li... > 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 > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > --=20 This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Kevin B. <ba...@gm...> - 2007-06-21 20:38:43
|
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=3Ddetail&aid=3D1565758&group_= id=3D42445&atid=3D433166 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. (No= t 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 <fai...@hi...> wrote: > > Hello! > > The algorithm implementation I intend to use comes with its own map forma= t > and visualization tool, basically including everything needed for > "stand-alone" operation. > > The mapcspace driver is, as far as I understand its operation, not exactl= y > what I require, since it seems to rely on another map driver as input, wh= ich > 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 n= ew > one generated from the SLAM algorithm output), and the planner driver wou= ld > have to be extended to "poll" the map driver for new data at around the s= ame > time interval. > > Well, there's where I'd be a bit lost, since I will have to figure out ho= w > to add a new message type to a Player driver. > > Regards, > Fabian Aichele > > -----Urspr=FCngliche Nachricht----- > Von: pla...@li... [mailto: > pla...@li...] Im Auftrag von Pabl= o > Rivera > Gesendet: Donnerstag, 21. Juni 2007 21:33 > An: pla...@li... > 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 > Pla...@li... > 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 > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: Toby C. <tco...@pl...> - 2007-06-21 20:51:58
|
Currently the maps can be dynamic, but there is no way to inform the client= s 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=3DDATA, subtype=3DPLAYER_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 <ba...@gm...> 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=3Ddetail&aid=3D1565758&grou= p_id=3D42445&atid=3D433166 > 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 yo= u > have to transfer the whole map (i think cmap is transfer only a portion o= f > 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 <fai...@hi...> wrote: > > > > Hello! > > > > The algorithm implementation I intend to use comes with its own map > > format and visualization tool, basically including everything needed fo= r > > "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 rere= ad > > 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 w= ould > > 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=FCngliche Nachricht----- > > Von: pla...@li... [mailto: > > pla...@li...] Im Auftrag von > > Pablo Rivera > > Gesendet: Donnerstag, 21. Juni 2007 21:33 > > An: pla...@li... > > 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, an= d > > wavefront drivers). > > The first task, however, requires apart from a SLAM algorithm, an activ= e > > > > 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 woul= d > > 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 > > Pla...@li... > > 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 > > Pla...@li... > > 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 > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > --=20 This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Fabian A. <fai...@hi...> - 2007-06-21 21:37:41
|
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 |
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/ |
From: Brian G. <br...@ge...> - 2007-06-22 18:31:01
|
On Jun 21, 2007, at 1:51 PM, 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. > > 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) A similar mechanism is already available. The driver can publish a PLAYER_MAP_DATA_INFO message, which contains the current (and possibly changed) map metadata (in a player_map_info_t). Subscribed parties (clients or drivers) can compare this metadata to their cached copies and decide whether to issue a PLAYER_MAP_REQ_GET_DATA request to get the new map. In the long run, it would be nicer to expose which part of the map has changed since last publication. But that can get tricky, since the "map diff" should be computed on a per-subscriber basis. brian. |
From: Fabian A. <fai...@hi...> - 2007-06-21 21:28:22
|
Hello! On Do, 2007-06-21 at 16:38 -0400, Kevin Barry 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=3Ddetail&aid=3D1565758&grou= p_id=3D42445&atid=3D433166 > 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)=20 >=20 I actually ran into that particular mapping driver. However, I have to prefer implementations which fit the sensor equipment that is available (SICK S300 laser range finder) due to time constraints; I still have about 3 months before my diploma thesis is due. > 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.=20 My initial idea was to use the wavefront planner with the updated map, and the nd local planner instead of vfh. The timing interval was only an initial estimate based on the assumption that a planner would be able to operate on an incrementally created map with relatively short distances between waypoints, where the laser range finder would cover the area "ahead" sufficiently for short-term planning. Also, I do not intend to operate the robot at speeds higher than 1 m/s. =20 > On 6/21/07, Fabian Aichele <fai...@hi...> wrote: > Hello! > =20 > The algorithm implementation I intend to use comes with its > own map format and visualization tool, basically including > everything needed for "stand-alone" operation. > =20 > 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.=20 > =20 > 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.=20 > =20 > 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. > =20 > Regards, > Fabian Aichele > =20 > -----Urspr=C3=BCngliche Nachricht----- > Von: pla...@li... > [mailto:pla...@li...] > Im Auftrag von Pablo Rivera > Gesendet: Donnerstag, 21. Juni 2007 21:33 > An: pla...@li... > Betreff: Re: [Playerstage-developers] Implementing "localize" > and "map"interfaces=20 > =20 > 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=20 > be changed after init. What about the "mapcspace" driver? > -Pablo Rivera > =20 > -------------------------------------- > =20 > From: Fabian Aichele <faichele@hi...> - 2007-06-21 12:57 > Hello! > =20 > 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). > =20 > Based on the requirements of my task I have decided to port an > existing > implementation of a particle filter based algorithm=20 > (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=20 > exploration. > =20 > 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=20 > 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. > =20 > 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=20 > 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,=20 > 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? > =20 > Regards, > Fabian Aichele > =20 > -----------------------------------------------------------------= --------=20 > 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 > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-develope= rs > =20 > =20 > =20 > -----------------------------------------------------------------= --------=20 > 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 > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-develope= rs >=20 > ------------------------------------------------------------------------- > 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 ma= iling list Pla...@li... https://lists.sourc= eforge.net/lists/listinfo/playerstage-developers |
From: Brian G. <br...@ge...> - 2007-06-22 18:25:22
|
On Jun 21, 2007, at 2:25 PM, Fabian Aichele wrote: > > My initial idea was to use the wavefront planner with the updated map, > and the nd local planner instead of vfh. One thing to look out for is that internal cspace construction in the wavefront driver is naive and slow, probably too slow to be used on a constantly changing map. I would recommend poking into the wavefront driver to improve this code (it's possible to dilate obstacles much more efficiently). You may also have to add support for handling a dynamic map, because the wavefront driver probably just gets the map once during Setup. This is not hard; add a clause to Wavefront::ProcessMessage() to handle a MAP_DATA message. Then when your mapping driver publishes a new map, the planner will copy it in, re-dilate the obstacles, and proceed from there as normal. brian. |
From: <mic...@gm...> - 2007-06-22 09:34:29
|
Hi developers, I have a problem publishing data from my custom Stage-model to Player. My model simulates wireless connections and has to publish the link information so that player clients can access it. It works fine with intergers but I get problems publishing the IP, MAC and ESSID which are all char arrays. First I set the corresponding entries inside Publish in p_wifi.cc. This looks like: void InterfaceWifi::Publish( void ) { stg_wifi_data_t* sdata = (stg_wifi_data_t*)mod->data; assert(sdata); stg_wifi_config_t* cfg = (stg_wifi_config_t*)mod->cfg; assert(cfg); player_wifi_data_t pdata; memset( &pdata, 0, sizeof(pdata) ); // Translate the Stage-formatted sdata into the Player-formatted pdata int link_count = sdata->neighbours->len; pdata.links_count = link_count; for(int i=0; i<link_count; i++) { stg_wifi_sample_t sam_temp = g_array_index(sdata->neighbours, stg_wifi_sample_t, i); snprintf((char *)pdata.links[i].mac, 32, "%s", sam_temp.mac); snprintf((char *)pdata.links[i].ip, 32, "%s", sam_temp.ip); strncpy((char*)pdata.links[i].essid, sam_temp.essid, 32); printf("\nIP:\t%s",pdata.links[i].ip); printf("\nESSID:\t%s",pdata.links[i].essid); printf("\nMAC:\t%s",pdata.links[i].mac); // just some testing constants pdata.links[i].mode =4; pdata.links[i].encrypt=5; pdata.links[i].freq =2400; pdata.links[i].qual =1; pdata.links[i].level=2; pdata.links[i].noise=3; } ... } The printf commands print the correct strings so I guess its all correct. In the next step I try to make the data available for player clients. I handle the data inside playerc_wifi_putmsg in dev_wifi.c. void playerc_wifi_putmsg(playerc_wifi_t *device, player_msghdr_t *header, player_wifi_data_t *data, size_t len) { int i; if((header->type == PLAYER_MSGTYPE_DATA)) { device->link_count = data->links_count; // I inserted a new field for the own faked IP. This works fine! strncpy(self->ip, data->ip,32); for (i = 0; i < device->link_count; i++) { memcpy(device->links[i].mac, data->links[i].mac, sizeof(data->links[i].mac)); strncpy(device->links[i].ip, "192.168.0.2", sizeof(device>links[i].ip)); strncpy(device->links[i].essid, data->links[i].essid, sizeof(device->links[i].essid)); //differ in signedness because of char and uint8_t device->links[i].mode = data->links[i].mode; device->links[i].encrypt = data->links[i].encrypt; device->links[i].freq = data->links[i].freq; device->links[i].qual = data->links[i].qual; device->links[i].level = data->links[i].level; device->links[i].noise = data->links[i].noise; } } return; } As you can see I tried to give a constant IP adress to check if I can access it later in my wifiproxy. This works. It also works with the integers like freq,mode,encrypt etc. But with the char arrays it's mysterious. Regardless of whatever I try: strncpy, strcpy, memcpy, snprintf...! The data->links[i].mac,ip,essid seem to be empty. Is it possible that they got lost somewhere? I checked some existing implementations for example rfid but I don't find any solution. I hope you guys can help me on this one. Thanks a lot Michael ------------------------------------- Albert Ludwigs Universität Freiburg Germany |
From: Geoffrey B. <gb...@ki...> - 2007-06-22 11:01:05
|
You have to set the mac_count, ip_count and essid_count members of the data structure to the length of their respective strings. These values are used by XDR to figure out how much data is actually in your message and so how much to pack/unpack for transmission over the network to clients. If they're zero, then the XDR system will assume that the mac, ip and essid members are empty and not copy anything. Geoff Michael Sebastian Schröder wrote: > Hi developers, > > I have a problem publishing data from my custom Stage-model to Player. > My model simulates wireless connections and has to publish the link > information so that player clients can access it. It works fine with > intergers but I get problems publishing the IP, MAC and ESSID which are > all char arrays. > > First I set the corresponding entries inside Publish in p_wifi.cc. This > looks like: > void InterfaceWifi::Publish( void ) > { > stg_wifi_data_t* sdata = (stg_wifi_data_t*)mod->data; > assert(sdata); > > stg_wifi_config_t* cfg = (stg_wifi_config_t*)mod->cfg; > assert(cfg); > > player_wifi_data_t pdata; > memset( &pdata, 0, sizeof(pdata) ); > // Translate the Stage-formatted sdata into the Player-formatted pdata > > int link_count = sdata->neighbours->len; > pdata.links_count = link_count; > > for(int i=0; i<link_count; i++) > { > stg_wifi_sample_t sam_temp = g_array_index(sdata->neighbours, > stg_wifi_sample_t, i); > > snprintf((char *)pdata.links[i].mac, 32, "%s", sam_temp.mac); > snprintf((char *)pdata.links[i].ip, 32, "%s", sam_temp.ip); > strncpy((char*)pdata.links[i].essid, sam_temp.essid, 32); > > printf("\nIP:\t%s",pdata.links[i].ip); > printf("\nESSID:\t%s",pdata.links[i].essid); > printf("\nMAC:\t%s",pdata.links[i].mac); > > // just some testing constants > pdata.links[i].mode =4; > pdata.links[i].encrypt=5; > pdata.links[i].freq =2400; > pdata.links[i].qual =1; > pdata.links[i].level=2; > pdata.links[i].noise=3; > } > ... > } > > The printf commands print the correct strings so I guess its all > correct. In the next step I try to make the data available for player > clients. I handle the data inside playerc_wifi_putmsg in dev_wifi.c. > > void playerc_wifi_putmsg(playerc_wifi_t *device, player_msghdr_t *header, > player_wifi_data_t *data, size_t len) > { > int i; > > if((header->type == PLAYER_MSGTYPE_DATA)) > { > device->link_count = data->links_count; > // I inserted a new field for the own faked IP. This works fine! > strncpy(self->ip, data->ip,32); > > for (i = 0; i < device->link_count; i++) > { > memcpy(device->links[i].mac, data->links[i].mac, > sizeof(data->links[i].mac)); > strncpy(device->links[i].ip, "192.168.0.2", > sizeof(device>links[i].ip)); > strncpy(device->links[i].essid, data->links[i].essid, > sizeof(device->links[i].essid)); //differ in signedness because of > char and uint8_t > > device->links[i].mode = data->links[i].mode; > device->links[i].encrypt = data->links[i].encrypt; > device->links[i].freq = data->links[i].freq; > device->links[i].qual = data->links[i].qual; > device->links[i].level = data->links[i].level; > device->links[i].noise = data->links[i].noise; > } > } > return; > } > > As you can see I tried to give a constant IP adress to check if I can > access it later in my wifiproxy. This works. It also works with the > integers like freq,mode,encrypt etc. But with the char arrays it's > mysterious. Regardless of whatever I try: strncpy, strcpy, memcpy, > snprintf...! The data->links[i].mac,ip,essid seem to be empty. Is it > possible that they got lost somewhere? > > I checked some existing implementations for example rfid but I don't > find any solution. I hope you guys can help me on this one. > > Thanks a lot > > Michael > > ------------------------------------- > Albert Ludwigs Universität Freiburg > Germany > > ------------------------------------------------------------------------- > 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 > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > -- Robotics research group, University of Auckland http://www.ece.auckland.ac.nz/~gbig005/ |
From: Jamuraa <ja...@ba...> - 2007-06-22 14:19:09
|
On 6/22/07, Michael Sebastian Schr=F6der <mic...@gm...> wrote: > Hi developers, > > I have a problem publishing data from my custom Stage-model to Player. > My model simulates wireless connections and has to publish the link > information so that player clients can access it. It works fine with > intergers but I get problems publishing the IP, MAC and ESSID which are > all char arrays. > > First I set the corresponding entries inside Publish in p_wifi.cc. This > looks like: [snip code for wifi stage model] This reminds me - if people are interested, I have a stage wifi model (and associated interface code) that detects other wifi models within range and reports their IP and MAC and ESSID as set in the world file. I always assumed that it was somewhat useless because the player wifi interface doesn't seem to be built to work that way - it's meant to find Access Points or other networks I think? I would be willing to clean up the addition and submit it if it is deemed useful. It uses non-line-of-sight but also has some propagation difference for solids and non-solids in the stage world (wifi is hindered in the model by solids). --=20 Michael Janssen --- Jamuraa --- ja...@ba... --- ja...@de... |
From: Brian G. <br...@ge...> - 2007-06-22 15:52:32
|
On Jun 22, 2007, at 7:19 AM, Jamuraa wrote: > This reminds me - if people are interested, I have a stage wifi model > (and associated interface code) that detects other wifi models within > range and reports their IP and MAC and ESSID as set in the world file. > I always assumed that it was somewhat useless because the player > wifi interface doesn't seem to be built to work that way - it's meant > to find Access Points or other networks I think? The wifi interface should support what you're doing, as it returns a set of link structures, where each link has IP, MAC, ESSID, and associated metrics (quality, noise, etc.). There's no constraint that these links go to APs; they could go to other clients when operating in ad hoc mode. On the other hand, we can definitely modify the wifi interface to accommodate more realistic and/or interesting kinds of data. Any suggestions? > I would be willing > to clean up the addition and submit it if it is deemed useful. > It uses non-line-of-sight but also has some propagation difference for > solids and non-solids in the stage world (wifi is hindered in the > model by solids). That would be very useful, indeed. If you post it to the patch tracker, I'll integrate. brian. |