From: Jaime V. M. <jai...@en...> - 2005-03-03 06:56:46
|
Hi I was under the impression the "key" and "index" which define "provides" and "requires" tuples, as in: key:port:interface:index (string:integer:string:integer) were somehow redundant. I mean position:0, position:1 etc will uniquely identify the interfaces a driver supports, and didn't see the need to specify odometry, compass, gyro, as in the doc example: driver ( name "p2os" provides ["odometry::position:0" "compass::position:1" "gyro::position:2" "bumper:0" "sonar:0"] ) Yet running the wavefront example provided by Brian, if I remove "odometry" in the example below, when I later run "planernav", it just doesn't. Put back "odometry" and it works. Despite of position devices being unique by the indices. I pressume playernav has been compiled expecting that "key", but something escapes me: Am I wrong to pressume that simply using different indices for the interfaces will uniquely identify the devices it represents, and I should not need to give them keys? Ta Jaime > ---------------------------------------------------------------------------------------------------- > # load the Stage plugin simulation driver > driver > ( > name "stage" > provides ["simulation:0"] > plugin "libstage" > > # load the named file into the simulator > worldfile "simple.world" > ) > > driver > ( > name "stage" > provides ["odometry::position:1"] > model "robot" > ) > driver > ( > name "stage" > provides ["laser:0"] > model "robot" > ) > > # Load the map for localization and planning from the same image file, > # and specify the correct resolution (a 500x500 pixel map at 15m x 15m > # is 0.03 m / pixel resolution). > driver > ( > name "mapfile" > provides ["map:0"] > filename "bitmaps/cave.png" > resolution 0.03 > negate 1 > ) > > # If instead you wanted to localize and plan at a different resolution, > # say 0.1 m / pixel, then you'd comment out the above driver block and > # uncomment the following two blocks: > > #driver > #( > # name "mapfile" > # provides ["map:1"] > # filename "bitmaps/cave.png" > # resolution 0.03 > # negate 1 > #) > #driver > #( > # name "mapscale" > # # read in map:1, the original map > # requires ["map:1"] > # # output the scaled map on map:0, where other drivers (and playernav) > # # will read it > # provides ["map:0"] > # resolution 0.1 > #) > > driver > ( > name "amcl" > provides ["localize:0"] > requires ["odometry::position:1" "laser:0" "laser::map:0"] > # Say that I want the particle filter to update whenever the robot moves > # at least 0.1 meters and/or rotates by at least 5 degrees. > update_thresh [0.1 5] > ) > driver > ( > name "vfh" > provides ["position:0"] > requires ["position:1" "laser:0"] > safety_dist 0.1 > distance_epsilon 0.3 > angle_epsilon 5 > ) > driver > ( > name "wavefront" > provides ["planner:0"] > requires ["position:0" "localize:0" "map:0"] > safety_dist 0.15 > distance_epsilon 0.5 > angle_epsilon 10 > ) -- Dr Jaime Valls Miro Centre for Autonomous Systems (Room 2/6/31) UTS, Faculty of Engineering PO BOX 123, Broadway NSW 2007 p: +61 2 9514 2967 f: +61 2 9514 2655 jaime.vallsmiro[AT]eng.uts.edu.au -- UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views the University of Technology, Sydney. Before opening any attachments, please check them for viruses and defects. |
From: Brian G. <ge...@ro...> - 2005-03-03 19:37:39
|
On Thu, 3 Mar 2005, Jaime Valls Miro wrote: > I was under the impression the "key" and "index" which define "provides" and "requires" tuples, as in: > key:port:interface:index (string:integer:string:integer) > were somehow redundant. I mean position:0, position:1 etc will uniquely identify the interfaces a driver > supports, and didn't see the need to specify odometry, compass, gyro, as in the doc example: > > driver > ( > name "p2os" > provides ["odometry::position:0" > "compass::position:1" > "gyro::position:2" > "bumper:0" > "sonar:0"] > ) The purpose of the key is to allow a driver that supports multiple interfaces of the same type to map those interfaces onto different devices. For example, instead of the example above, you could do this: driver ( name "p2os" provides ["odometry::position:14" "compass::position:0" "gyro::position:25"] ) That is, provide the robot's odometry as position:14, the compass as position:0, and the gyro as position:25. The same goes for devices that are required by a driver. For example, the amcl driver can take as input different kinds of 'position' devices and it treats them each differently; e.g., a different action model would be used for odometry data vs. IMU data. Likewise, the amcl driver can take as input different kinds of 'map' devices; e.g., a laser-based map vs. a wifi signal-strength map. (Ignore for the moment that the features I've just mentioned aren't currently implemented in amcl). Consider: driver ( name "amcl" provides ["localize:0"] requires ["odometry::position:1" "laser:0" "laser::map:0"] ) That is, take input from position:1 and treat it as odometry, and take input from map:0 and treat is a laser map. No key necessary for laser:0, because amcl only supports one laser interface. > Yet running the wavefront example provided by Brian, if I remove "odometry" in the example below, when I > later run "planernav", it just doesn't. Put back "odometry" and it works. Despite of position devices > being unique by the indices. I pressume playernav has been compiled expecting that "key", but something > escapes me: Am I wrong to pressume that simply using different indices for the interfaces will uniquely > identify the devices it represents, and I should not need to give them keys? The key is used *only* by the driver to which it is supplied, not by consumers of that driver (e.g., clients, other drivers). A player device is fully addressed as: host:port:interface:index Note that the key is not included in this address. playernav isn't doing anything key-specific; the problem is that amcl didn't know what to do with an anonymous 'position' device. The "odometry" key is needed to tell amcl how to interpret the data. brian. -- Brian P. Gerkey ge...@ai... Stanford AI Lab http://ai.stanford.edu/~gerkey |
From: Richard v. <va...@cs...> - 2005-03-03 19:48:29
|
Brian - this info is important an non-obvious: how about pasting this mail into the FAQ? Richard On 3-Mar-05, at 11:37 AM, Brian Gerkey wrote: > On Thu, 3 Mar 2005, Jaime Valls Miro wrote: > >> I was under the impression the "key" and "index" which define >> "provides" and "requires" tuples, as in: >> key:port:interface:index (string:integer:string:integer) >> were somehow redundant. I mean position:0, position:1 etc will >> uniquely identify the interfaces a driver >> supports, and didn't see the need to specify odometry, compass, gyro, >> as in the doc example: >> >> driver >> ( >> name "p2os" >> provides ["odometry::position:0" >> "compass::position:1" >> "gyro::position:2" >> "bumper:0" >> "sonar:0"] >> ) > > The purpose of the key is to allow a driver that supports multiple > interfaces of the same type to map those interfaces onto different > devices. For example, instead of the example above, you could do this: > > driver > ( > name "p2os" > provides ["odometry::position:14" > "compass::position:0" > "gyro::position:25"] > ) > > That is, provide the robot's odometry as position:14, the compass as > position:0, and the gyro as position:25. > > The same goes for devices that are required by a driver. For example, > the amcl driver can take as input different kinds of 'position' devices > and it treats them each differently; e.g., a different action model > would > be used for odometry data vs. IMU data. Likewise, the amcl driver can > take as input different kinds of 'map' devices; e.g., a laser-based map > vs. a wifi signal-strength map. (Ignore for the moment that the > features > I've just mentioned aren't currently implemented in amcl). > > Consider: > > driver > ( > name "amcl" > provides ["localize:0"] > requires ["odometry::position:1" "laser:0" "laser::map:0"] > ) > > That is, take input from position:1 and treat it as odometry, and take > input from map:0 and treat is a laser map. No key necessary for > laser:0, > because amcl only supports one laser interface. > >> Yet running the wavefront example provided by Brian, if I remove >> "odometry" in the example below, when I >> later run "planernav", it just doesn't. Put back "odometry" and it >> works. Despite of position devices >> being unique by the indices. I pressume playernav has been compiled >> expecting that "key", but something >> escapes me: Am I wrong to pressume that simply using different >> indices for the interfaces will uniquely >> identify the devices it represents, and I should not need to give >> them keys? > > The key is used *only* by the driver to which it is supplied, not by > consumers of that driver (e.g., clients, other drivers). A player > device > is fully addressed as: > host:port:interface:index > Note that the key is not included in this address. > > playernav isn't doing anything key-specific; the problem is that > amcl didn't know what to do with an anonymous 'position' device. > The "odometry" key is needed to tell amcl how to interpret the data. > > brian. > > -- > Brian P. Gerkey ge...@ai... > Stanford AI Lab http://ai.stanford.edu/~gerkey > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > -- Richard Vaughan School of Computing Science / Simon Fraser University |
From: Brian G. <ge...@ai...> - 2005-03-07 18:41:24
|
Richard vaughan wrote: > Brian - this info is important an non-obvious: how about pasting this > mail into the FAQ? Done: http://playerstage.sourceforge.net/faq.html#cfgkey At some point, this info should migrate into the main documentation... brian. -- Brian P. Gerkey ge...@ai... Stanford AI Lab http://ai.stanford.edu/~gerkey |
From: Jaime V. M. <jai...@en...> - 2005-03-03 23:16:45
|
Thanks Brian, very informative. I agree with Richard, it is non-trivial, and useful to the community. I guess for simple .cfg's you don't even think about it, simply paste or modify an existing example. But then you get carried away :-) and that's when you need a more throrough understanding of the syntax. Thanks again, Jaime Brian Gerkey wrote: > On Thu, 3 Mar 2005, Jaime Valls Miro wrote: > > > I was under the impression the "key" and "index" which define "provides" and "requires" tuples, as in: > > key:port:interface:index (string:integer:string:integer) > > were somehow redundant. I mean position:0, position:1 etc will uniquely identify the interfaces a driver > > supports, and didn't see the need to specify odometry, compass, gyro, as in the doc example: > > > > driver > > ( > > name "p2os" > > provides ["odometry::position:0" > > "compass::position:1" > > "gyro::position:2" > > "bumper:0" > > "sonar:0"] > > ) > > The purpose of the key is to allow a driver that supports multiple > interfaces of the same type to map those interfaces onto different > devices. For example, instead of the example above, you could do this: > > driver > ( > name "p2os" > provides ["odometry::position:14" > "compass::position:0" > "gyro::position:25"] > ) > > That is, provide the robot's odometry as position:14, the compass as > position:0, and the gyro as position:25. > > The same goes for devices that are required by a driver. For example, > the amcl driver can take as input different kinds of 'position' devices > and it treats them each differently; e.g., a different action model would > be used for odometry data vs. IMU data. Likewise, the amcl driver can > take as input different kinds of 'map' devices; e.g., a laser-based map > vs. a wifi signal-strength map. (Ignore for the moment that the features > I've just mentioned aren't currently implemented in amcl). > > Consider: > > driver > ( > name "amcl" > provides ["localize:0"] > requires ["odometry::position:1" "laser:0" "laser::map:0"] > ) > > That is, take input from position:1 and treat it as odometry, and take > input from map:0 and treat is a laser map. No key necessary for laser:0, > because amcl only supports one laser interface. > > > Yet running the wavefront example provided by Brian, if I remove "odometry" in the example below, when I > > later run "planernav", it just doesn't. Put back "odometry" and it works. Despite of position devices > > being unique by the indices. I pressume playernav has been compiled expecting that "key", but something > > escapes me: Am I wrong to pressume that simply using different indices for the interfaces will uniquely > > identify the devices it represents, and I should not need to give them keys? > > The key is used *only* by the driver to which it is supplied, not by > consumers of that driver (e.g., clients, other drivers). A player device > is fully addressed as: > host:port:interface:index > Note that the key is not included in this address. > > playernav isn't doing anything key-specific; the problem is that > amcl didn't know what to do with an anonymous 'position' device. > The "odometry" key is needed to tell amcl how to interpret the data. > > brian. > > -- > Brian P. Gerkey ge...@ai... > Stanford AI Lab http://ai.stanford.edu/~gerkey > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users -- UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views the University of Technology, Sydney. Before opening any attachments, please check them for viruses and defects. |