From: Nicholas H. <nh...@cs...> - 2004-02-24 04:19:08
|
Hi, Does anyone have any ideas about distributing Player? I mean in the sense that the passthrough driver allows one to run drivers on a workstation rather than a robot. Would it be useful to have multiple Player clients and/or servers using the same Player driver(s) or a selection of drivers scattered over a collection of machines or processes? Does it make sense to do this with Player? There are projects that have done similar things, such as: OROCOS::SmartSoft, OROCOS@KTH, OSCAR, and CARMEN. They don't seem as widely used as Player and require use/knowledge of a distributed computing framework such as CORBA, which may be a bit heavy-weight for some applications. regards, Nicholas |
From: Brian G. <ge...@ro...> - 2004-02-24 18:46:48
|
On Tue, 24 Feb 2004, Nicholas Hannah wrote: > Does anyone have any ideas about distributing Player? I mean in the > sense that the passthrough driver allows one to run drivers on a > workstation rather than a robot. > > Would it be useful to have multiple Player clients and/or servers using > the same Player driver(s) or a selection of drivers scattered over a > collection of machines or processes? Does it make sense to do this with > Player? hi Nicholas, You've brought up an excellent point. Do you have a specific application in mind (e.g., some heavy computation that *needs* to be distributed), or just thinking about how to do this in general? What we have right now is the passthrough driver, which is basically a Player client embedded in a Player server. Although not the most elegant mechanism for this purpose, it does allow you to instantiate drivers anywhere on the network, and wire them up with inputs from any robot (real or simulated). Is there something that the passthrough driver doesn't do for you? > There are projects that have done similar things, such as: > OROCOS::SmartSoft, OROCOS@KTH, OSCAR, and CARMEN. They don't seem as > widely used as Player and require use/knowledge of a distributed > computing framework such as CORBA, which may be a bit heavy-weight for > some applications. I'm not really familiar with the OROCOS packages, but the reason that they use CORBA is to handle the addressing problem. When you've got the compuational bits of your "robot" spread around the network, they need to find and talk to each other in some way. We're currently skirting this problem with Player by requiring the client (whether it be a normal client or a passthrough driver) to know the full host:port:device:index address of the device that it wants to talk to. We've experimented with some automatic discovery/location mechanisms, including Reed Hedges's libservicediscovery and the robot name-lookup that's available when using Stage. To my knowledge, these mechanisms are not yet widely used. CARMEN handles addressing using the publish/subscribe middleware package IPC. This mechanism works great for one robot: each "module" (equivalent to a Player driver) can run anywhere on the network, with messages routed between them by a central server (called "central"). Unfortunately, it works very badly for more than one robot, requiring a great deal of hackery to control a multi-robot system. For example, just to simulate multiple robots, you have to run one simulator per robot and then stitch them together so that each simulator "knows" about the robots in the other simulators. I think that we've done a better job of allowing for control of multi-robot systems, both in simulation and real hardware, but maybe we're not quite there in terms of distributing the computation involved in one "robot". As usual, there's a tradeoff: as we make the rarely-used case easier (i.e., with computation arbitrarily distributed about the network), we'll amost certainly make the often-used case harder (i.e., all computation in one server, on one machine). Comments, anyone? Surely Dylan has some input here... brian. p.s. We'll not be using CORBA; just hearing the word makes me run screaming from the room. |
From: Cameron S. <cam...@cs...> - 2004-02-25 04:04:55
|
On Wed, 2004-02-25 at 05:45, Brian Gerkey wrote: > You've brought up an excellent point. Do you have a specific application > in mind (e.g., some heavy computation that *needs* to be distributed), > or just thinking about how to do this in general? > > What we have right now is the passthrough driver, which is basically a > Player client embedded in a Player server. Although not the most elegant > mechanism for this purpose, it does allow you to instantiate drivers > anywhere on the network, and wire them up with inputs from any robot > (real or simulated). This is kindofa tangent, but I was talking to Nicholas about this yesterday. The primary purpose (correct me when I wrong) of player is to provide a single, simple, shared (networked) interface to the hardware of a robot (or device). For that the current system is perfect, and there's no real reason to distribute it. Distributed robots could have a player server running on each of the distributed parts running part of it, and the controller could just connect to each server. A metaserver could easily be put together (I think) using the passthrough mechanism to present a single player server that interfaced to all subservers. Sorry, this is a subtangent. The main problem for Nicholas is that he wants to have multiple processor intensive algorithms running using the same player data, and those algorithms are currently implemented as player drivers. This means that these algorithms have to be run on the server, unless you use the passthrough mechanism to run another player server off the robot. For mine, that doesn't really make sense. Having the algorithms implemented as player drivers was good in that it made them easily available to all the player users. However, it makes distributed processing more difficult, and in my opinion warps the purpose of the player server. To solve this, I propose another server type (perhaps called "wardrobe") for running algorithms. It would be similar in design to player, except that it would present an interface to algorithms instead of hardware. The algorithmic drivers running on it would connect to one (or many) player servers (or even other wardrobe servers) to collect data instead of getting it directly from the hardware, and would also present a interface to clients similar to the player one. I think such a server could be implemented using mostly player code, and it could be potentially optimised for the new task. Of course, I don't have time to do this now, so I'll not say another word about it unless asked. ;) Cameron. |
From: Richard V. <va...@cs...> - 2004-02-25 05:29:16
|
Cameron et al, Couldn't the algorithm engine be implemented as a driver to the existing Player server? Your algorithm driver would actually be a client to another Player to fetch live data, do some processing, then present the results to downstream clients in a (possibly special) interface. This is very similar to the passthrough model, but without the loop back to the data-originating Player. Not too bad, and no need for a new server with the attendant work. It's a pity because I like the proposed name and I'm always ready to see people stretch the theatrical theme to humorous new lengths. Wardrobe model: client -> Player (algorithm) -> Player (robot) Passthrough model: client -> Player (robot / passthrough ) <-> Player (algorithm) Richard. > To solve this, I propose another server type (perhaps called > "wardrobe") > for running algorithms. It would be similar in design to player, except > that it would present an interface to algorithms instead of hardware. > The algorithmic drivers running on it would connect to one (or many) > player servers (or even other wardrobe servers) to collect data instead > of getting it directly from the hardware, and would also present a > interface to clients similar to the player one. > > I think such a server could be implemented using mostly player code, > and > it could be potentially optimised for the new task. > > Of course, I don't have time to do this now, so I'll not say another > word about it unless asked. ;) > > Cameron. > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Cameron S. <cam...@cs...> - 2004-02-25 07:37:55
|
On Wed, 2004-02-25 at 16:27, Richard Vaughan wrote: > Cameron et al, > > Couldn't the algorithm engine be implemented as a driver to the > existing Player server? Yes! However, there are benefits to using a different server framework. Algorithm drivers are fundamentally different to device drivers and the framework they sit in shouldn't be constrained to be the same. For example, it would make sense to have an extension to the wardrobe server to parallelise tasks over multiple machines. But such an extension to player would add unnecessary complication to the device drivers. I'm sure other optimisations could be made to the wardrobe version of player when hardware-related constraints are dropped. There also may be interface requirements for algorithm drivers not met by player as it doesn't fit the device driver model. Also, and I've not looked at the code, but I don't think player has any prioritising system between devices. It's not really necessary for a whole bunch of io-bound threads, but when one of them is a processor hog it'd be nice to be able to change it's priority (no pun intended). In other words, yes, we don't need no steenkeen' wardrobe. But it might be useful. Cameron. |
From: ahoward <ah...@po...> - 2004-02-25 17:57:42
|
As the author of many "algorithm drivers" in Player, I guess I should speak up here... As others have pointed out, there are pros and cons to putting higher-level algorithms into the Player server. Pros: - You get to use the client/server architecture for free - The client architecture stays the same (all data from one source) - Drivers in the server can access data at higher rates than clients Cons: - CPU-intensive algorithms compete for resources on the robot - No built-in priority mechanism (apart from "nice") - High-latency on some drivers makes the client semantics confusing - Code has to be ported to server-arch-compatible C++ Some of these cons can be ameliorated (e.g., using the passthrough driver to shift computation somewhere else), but others are fundamental. It is also interesting to note that the debate between in-server vs out-of-server drivers reflects the kernel-vs-user space debate in Linux. So, my stunningly bland conclusion from all this is to echo what has already been said: we dont *need* and additional level in the architecture, but it might be *useful*. If I was designing such a system, I would apply the following two tests: 1. In what ways does the "wardrobe" improve the lot of driver writers (what can they do that they could not do before)? 2. In what ways does the wardrobe improve the lot of client writers (what has become easer or works better)? My $0.02, A. On Wed, 25 Feb 2004, Cameron Stone wrote: > On Wed, 2004-02-25 at 16:27, Richard Vaughan wrote: > > Cameron et al, > > > > Couldn't the algorithm engine be implemented as a driver to the > > existing Player server? > > Yes! > > However, there are benefits to using a different server framework. > Algorithm drivers are fundamentally different to device drivers and the > framework they sit in shouldn't be constrained to be the same. > > For example, it would make sense to have an extension to the wardrobe > server to parallelise tasks over multiple machines. But such an > extension to player would add unnecessary complication to the device > drivers. I'm sure other optimisations could be made to the wardrobe > version of player when hardware-related constraints are dropped. There > also may be interface requirements for algorithm drivers not met by > player as it doesn't fit the device driver model. > > Also, and I've not looked at the code, but I don't think player has any > prioritising system between devices. It's not really necessary for a > whole bunch of io-bound threads, but when one of them is a processor hog > it'd be nice to be able to change it's priority (no pun intended). > > In other words, yes, we don't need no steenkeen' wardrobe. But it might > be useful. > > Cameron. > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > Andrew Howard email: ah...@po... Department of Computer Science http: www-robotics.usc.edu/~ahoward University of Southern California phone: 1 (213) 740 6416 Los Angeles, CA, U.S.A. 90089-0781 fax: 1 (213) 821 5696 << Insert pithy saying here >>> |
From: Brian G. <ge...@ro...> - 2004-03-01 22:22:45
|
(sorry for the late reply; i was out sick last week) This discussion had caused me to examine what exactly are the constraints imposed by Player's driver architecture. As I see it, they are: - Code in C++. To me this is a non-issue. It's easy enough to: implement your algorithm in C++, or write C++ bindings for it, or embed an appropriate intrepeter (e.g., Python) that can be called from C++. - Play nice with other drivers on the same machine; i.e., don't hog the processor. This can be managed reasonably well with mechanisms like nice(). Frankly, I don't see the point in implementing our own priority/scheduling system at a higher level. Before we're done, we'll have written our own OS, and done it badly. - Support a particular Player interface. This is where we sometimes box ourselves in, by shoe-horning complex algorithms (e.g., path-planning) into simple existing interfaces (e.g., position). This is convenient, in that we have client-side support for existing interfaces, but we're always throwing away some functionality of the algoriths in the process, as well as changing the semantics of the interface from the client's perspective. There's no reason that we can't create new special-purpose interfaces for such algorithms (as was done for localization). - Suffer the internal buffering latencies introduced by the server. - Work within the client/server model, with read/write/ioctl semantics for data and commands. These last two are real limitations. The latency situation can be improved a great deal, and may soon (I've been thinking about that lately), but the other one is fundamental, though I would argue inconsequential in many (maybe most) cases. I don't have any grand conclusion here, except to say that Player cannot be all things to all people. It's been a success so far because it's easy to use, extend, and maintain. I like new features, but only if they really add some important functionality and don't make complicate usage or maintenance. brian. |