From: Reed H. <re...@ze...> - 2003-07-14 18:46:19
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, July 7, 2003, at 01:52 PM, brian gerkey wrote: > That sounds like a great idea. As for your questions, like Andrew > said, > you can get pretty much all that info by walking through the global > 'deviceTable', which is a linked list of all available devices (i.e., > instaniated drivers). Check devicetable.h for methods and such for > accessing that list. I tried this but the table doesn't seem to be filled in until after my device is created (ie, after the Init function which creates the new device). I wonder if I need to add a new virtual method to CDevice that is called after all the devices are ready, but before the main thread of execution starts? (Where would I call this? What would I call it? Setup and Init are taken :) The main thing I need I guess is to grab the port off the server device (PLAYER_PLAYER_CODE). "global_playerport" always seems to be 6665 as well. thanks reed > Feel free to augment the accessor methods if you need > to. > > Note that, because Player can control multiple robots (e.g., when used > with Stage), each entry in that list has its own robot name and port. > When you're using real hardware, they'll all be the same. > > As for the hostname, we're currently not storing that anywhere, but we > could. > In the meantime, you can just call gethostname(2). > > brian. > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/ > 01 > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iD8DBQE/EvlNFK83gN8ItOQRAsL7AJ4tMduwHcnvkTjhW6TqCRq113K8QgCeKMSs VaYThdBG9Xtaa9F8iPGsCj0= =Jq0J -----END PGP SIGNATURE----- |
From: Reed H. <re...@ze...> - 2003-07-15 22:51:55
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Can you do all this in your driver's Setup()? At that point, the > deviceTable > is filled, and you can happily walk through it. The problem with that is that Setup is only called when a client subscribes, and there is no client interface to this device. However.... > Btw, if you specify > "alwayson 1" as an option to the device in the config file, it will be > subscribed when the server starts (but after the deviceTable is > filled); you > can do this for any device. This should fix that problem though. Can I manually set that in my driver, rather than putting it in the config file each time? (OK, I'll RTF[M|S].... :) > > Btw, how will the name server work? Here is how libservicediscovery works, for anyone who is interested. I have uploaded a tarball with the library source code and some info here: http://interreality.org/software/servicediscovery Libservicediscovery (LSD) sends and responds to queries. Typically these are broadcast via UDP to the local network, but you can also set specific hosts and ports to open TCP connections to, and set some options to relay between the two transport mechanisms. A query is four regular expressions: title, description, types and url. In the Player device I call the title "name" (the robot name), and I call types "tags". To advertise a service you add its four strings to an instance of the ServiceDirectory class. You also call methods on ServiceDirectory to make queries and to service incoming queries. If any incoming query matches a service you have added, a response is sent. The way you would use it with Player is to add a "service_adv" it to your config file (with driver "lsd") or to the Stage world file. You can set the name, description and tags of the service, and you can override the URL as well. Also, any other devices on the robot will be added to the "tags" (types) list like this: "device:laser(sicklms200)". Then if your client is looking for all robots with a laser, it does: LSD::ServiceDirectory sd; sd.query("device:laser(.*)", "", "", "", callback) Or if it is looking for a robot named "Robbie", it could do: LSD::ServiceDirectory sd; sd.query("", "Robbie", "", "", callback); Then, in some loop or callback somewhere, it does: sd.handleIncoming(); Above, 'callback' is an instance of a subclass of ServiceAdvertisementListener. It contains a virtual method notifyNewService which is passsed an id (integer returned from query), and a Service struct containing the title, description, types and url of the service that was found. I also wrote a simple "service_responder" program which just runs programs when it recieves responses to associated queries. I use this to just run a set of clients for every robot that comes online. My summer research project is to evaluate some interfaces for working with lots of robots (10-20 to start with, maybe more as time goes on), so a) It's quite tedious to run (3 to 5) X (10 to 20) clients by hand and even by script b) I need to run clients on more than one workstation c) I will be making sure that the system holds up under at least that many clients, maybe more. It's a VERY lightweight protocol, and messages are only sent for queries, replies, and new services, so there really isn't danger of flooding your network at all unless you put a query in a busyloop or something foolish like that :) reed -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iD8DBQE/FIU3FK83gN8ItOQRAk7BAJ0SyT2FdYYZmLcpoQT4P0Ls6nRLjgCcDLuX WMLklAzbxPwWtG6cCNL/U30= =/s4n -----END PGP SIGNATURE----- |
From: Reed H. <re...@ze...> - 2003-07-15 23:17:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, July 15, 2003, at 05:28 PM, brian gerkey wrote: > On Mon, 14 Jul 2003, Reed Hedges wrote: >> I wonder if I need to add a new virtual method to CDevice that is >> called after all the devices are ready, but before the main thread of >> execution starts? ... > Btw, if you specify > "alwayson 1" as an option to the device in the config file, it will be > subscribed when the server starts OK, I have two changes to CDevice and to main.cc: 1. I made an "alwayson" member of CDevice (public). This is normally false, unless you set "alwayson" in the config file (like before), or the device sets it in its constructor. Then, after the devices are created, instead of just checking the config file, parse_config_file checks this flag and subscribes if it's true. Unfortunately, while useful, this will happen for Stage, since it doesn't use the config file, and it looks like only the preceding devices in the config file will be in the table. So I also did what I suggested before: 2. I added a last-minute setup hook in the form of a virtual method to CDevice called "Prepare". main() calls each method's "Prepare" method on all devices right before going into the main loop. Please let me know what you think before I commit it. (Ill also test it more fully with stage, etc, tomorrow) reed -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iD8DBQE/FItUFK83gN8ItOQRAip1AJ4sFnROMZ8feU0LKjvPZ+53LbYutwCgjU0s EJaa8RMCTBhABYebhT6Eo78= =Y4P6 -----END PGP SIGNATURE----- |
From: brian g. <bg...@us...> - 2003-07-16 19:35:15
|
On Tue, 15 Jul 2003, Reed Hedges wrote: > OK, I have two changes to CDevice and to main.cc: > > 1. I made an "alwayson" member of CDevice (public). This is normally > false, unless you set "alwayson" in the config file (like before), or > the device sets it in its constructor. Then, after the devices are > created, instead of just checking the config file, parse_config_file > checks this flag and subscribes if it's true. > > Unfortunately, while useful, this will happen for Stage, since it > doesn't use the config file, and it looks like only the preceding > devices in the config file will be in the table. So I also did what I > suggested before: > > 2. I added a last-minute setup hook in the form of a virtual method to > CDevice called "Prepare". main() calls each method's "Prepare" method > on all devices right before going into the main loop. hi Reed, Frankly, I'd rather not extend the CDevice API further, unless we really need to. However, looking at what you want to do, I don't see another option. So go ahead with those changes, but don't document them (I'm sure that you were just about to), because I don't want other drivers using them. That way we can take them back out later. The changes you're making won't be necessary once Stage supports the new separate config file model, right? Because then you can put "alwayson" in Player's config file. So these changes can be temporary, basically so that you get your experiments done in the near term. Also, I'm thinking that once your name service has been tried out a bit as a driver, we can just roll it into the server core, since it really provides fundamental server functionality. At that point, it will be available all the time and we don't have to worry about config files, "alwayson", etc. Sound good? brian. |
From: Reed H. <re...@ze...> - 2003-07-16 20:06:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > The changes you're making won't be necessary once Stage supports the > new > separate config file model, right? Because then you can put > "alwayson" in > Player's config file. OK, if you want to do that it's fine with me. > Also, I'm thinking that once your name service has been tried out a > bit as a > driver, we can just roll it into the server core Well, I was considering doing that originally, but I think it works well as a device: you can selectively enable/disable it on robots just like any other device, and you could have drivers for other service advertisement systems if you wanted (e.g. Rendezvous/MDNS, SSDP, etc.); It's modular (maybe in the future you can dynamically load/unload driver code or something); The autoconf macros are helpful for searching for libservicediscovery. reed -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iD8DBQE/Fa+MFK83gN8ItOQRApUGAKCKw4qfZjFkw+rznSdCYkA1ePtQnACghgeE 47C1LlAdQlr/KiN48LAvhKU= =wHpr -----END PGP SIGNATURE----- |
From: brian g. <bg...@us...> - 2003-07-15 21:29:59
|
On Mon, 14 Jul 2003, Reed Hedges wrote: > I tried this but the table doesn't seem to be filled in until after my > device is created (ie, after the Init function which creates the new > device). > > I wonder if I need to add a new virtual method to CDevice that is > called after all the devices are ready, but before the main thread of > execution starts? (Where would I call this? What would I call it? > Setup and Init are taken :) > > The main thing I need I guess is to grab the port off the server device > (PLAYER_PLAYER_CODE). "global_playerport" always seems to be 6665 as > well. > hi Reed, Can you do all this in your driver's Setup()? At that point, the deviceTable is filled, and you can happily walk through it. Btw, if you specify "alwayson 1" as an option to the device in the config file, it will be subscribed when the server starts (but after the deviceTable is filled); you can do this for any device. Btw, how will the name server work? brian. |