Menu
▾
▴
Re: [Playerstage-developers] Patch for ability to push config/geometry
|
From: Toby C. <tco...@di...> - 2004-10-01 05:19:26
|
Hi, I considered the geometry style device interface, however while this has some benefits it also has some drawbacks, namely you need to define twice (or three times) as many interfaces, eg laser laser_geom and laser_config, which adds a lot of complexity, not to mention supporting this many interfaces... The other drawback of geometry push through a data type interface, partiularly in a PUSH_ALL mode is that config and geometry updates will generally be at a much lower frequency to data updates, although this isnt nesasarily a big problem... Maybe the alternative I mentioned of a variable content data packet is the best bet, add 2 bit flags for wether the packet contains geometry or config info and stick them on the end if it does...this would have the advantage of being fairly transparent to devices that dont wnat to support it (just ignore the bit fields)... but really it is fairly similar to my original implementation... anyhow, just some more ideas, Toby ahoward wrote: >Hi Toby, Brian: > >I havent looked at Toby's patch, but here are a few thoughts based on my >incomplete understanding... > >The request/reply mechanism, while generally useful for doing device >initialization, is hopeless for in-the-loop control (too slow, no PUSH >mechanism). Your patch effectively addresses both problems by allowing >each interace to support more than one kind of packet. This is something >that we have been talking about for some time, but never implemented. > >With our recent changes to support multiple interfaces on each driver, we >can now achieve the same effect using a separate interface: e.g., we could >define a "geometry" interface which spits out data whenever the geometry >of a device changes. If you dont care about the geometry, you dont >subscribe to this interface. Dead easy to implement on the driver side; >no changes on the client side. I suspect that this is what we should aim >for in the next release. > >Coming back to the question of multiple packet types for each interface, I >see both pros and cons in this. Pro is that you can keep data logically >grouped in a single interface, con is the increased conceptial and >programmatic complexity. Right now, I'm feel this would not be a good >idea, but I could be persuaded. > > A. > > >On Fri, 1 Oct 2004, Toby Collett wrote: > > > >>Hi Brian, >>Just to clarify a little, the client doesnt actually recieve unsolicited >>response messages, I created two new messages types (for geometry and >>config) which are passed as seperate messages rather than as response >>messages, this makes it very easy for the client to just ignore these >>messages if they are not wanted (which I have set up the c and c++ >>client libraries to do). So the patch as it stands will only break >>custom client libraries and these will be able to be fixed in about 3 >>lines of code...the only issue then is a slight increase in network traffic. >> >>I havent done this but in addition you could also add extra option for >>the acess mode (binary ored for config/geom PUSH/PULL) and only push if >>these are set, this would solve the network traffic issue. >> >>Feel free to take or leave which ever parts of the patch you like or >>dont, if there is a better way to do this that you want me to look into >>let me know, there is the option of having multiple types of data >>packet(which could include geometry and config when needed), this would >>probably require less server change but more client change so ...... >>Toby >> >>Brian Gerkey wrote: >> >> >> >>>On Wed, 29 Sep 2004, Toby Collett wrote: >>> >>> >>> >>>>Attached is a fairly major patch to the player server (gzipped as I >>>>wasnt sure about the attachment size limit) which allows for drivers >>>>to push geometry and config changes to clients. This is useful when >>>>a) you have a device whos geometry changes at runtime (ie the lower >>>>sonar bank on the b21r) >>>>b) you have two client subscribed to one device and one changes the >>>>config, the changes can then be pushed to the other client (think >>>>sick LMS resolution change) >>>>c) im sure there are some other options, ... a device that changes >>>>config automatically for power conditions... ? >>>> >>>> >>>hi Toby, >>> >>>Thanks for the patch. It's something that we've talked about for a long >>>time, and would definitely be useful. Although, regarding your example >>>(b), each laser data packet actually has enough metadata (resolutions, >>>aperture) that it's self-contained; the client doesn't need to be >>>separately informed about a configuration change. >>> >>>As you say, this is a major patch, since it changes the message protocol >>>(i.e., a client may now receive unsolicited config responses). As such, >>>it'll take me a while to look over your patch and decide how best to >>>incorporate this functionality. >>> >>> brian. >>> >>> >>> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >>Use IT products in your business? Tell us what you think of them. Give us >>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more >>http://productguide.itmanagersjournal.com/guidepromo.tmpl >>_______________________________________________ >>Playerstage-developers mailing list >>Pla...@li... >>https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> >> >> > >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 >>> > > > > > > > > > > > > > > > >------------------------------------------------------- >This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >Use IT products in your business? Tell us what you think of them. Give us >Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more >http://productguide.itmanagersjournal.com/guidepromo.tmpl >_______________________________________________ >Playerstage-developers mailing list >Pla...@li... >https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > |