Very good. My current Stage hacking for 1.4 is using the name as the basic
ID for a model instance. Combined with dynamic creation of objects, this
will mean no more port numbers in world files (except the base port if
you're in a multi-player-user environment. I expect the client libraries
can do the work of finding the port for your robot's name.
On Sat, 26 Apr 2003, brian gerkey wrote:
> I've just added two new things to Player, that are useful with Stage (on HEAD;
> will merge to patch branch later):
> * The ability to auto-assign ports. With the right command-line flags, you
> can give Player a single base port, and let it find as many other free
> ports as you need. It is an error if the base port is not available.
> Free ports are found by counting up from the base port.
> * The ability to lookup the port that is associated with a given robot's
> name. There is a now an ioctl to Player that does this. It's implemented
> in the C++ client as PlayerClient::LookupPort() and there's a C++ example
> called lookupport.cc.
> Put together, these features allow you to run simulations with lots of robots
> but not worry about which ports are being used, which can be a very good thing,
> especially in multi-user environments. Just let Player auto-assign the ports
> and then use the name service mechansim to find your robots at runtime (you
> would connect to the base port, where you know that Player will be listening).
> A couple of Stage .world-file notes:
> * To try out this feature, use the "base_port" keyword anywhere in your
> .world, outside of any block, e.g.:
> base_port 40000
> Then you can find Player on port 40000 and ask it where to connect to talk
> to other robots.
> * To actually use this feature, you must give your robots names. Stage
> already supports the "name" keyword; check everything.world for examples.
> This solution allows you to find out which robots a given instance of Player is
> serving (for use with Stage), but it doesn't allow you to find multiple
> instances of Player on a network (for use with real robots). The latter is
> more in the realm of the broadcast-based discovery mechanism that Reed has
> proposed. In the end, it would be nice to have the functionality of both, but
> I haven't thought of a nice way to integrate them, and I think that the Stage
> issue is more pressing. I'm open to suggestion on this front.
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> Playerstage-developers mailing list
Richard Vaughan / HRL Laboratories / vaughan@... / +1 310.317.5689