Re: [Playerstage-developers] Robots, Position and PIDs

[Geoffrey B. <g....@au...>]

It's worth noting that querying a device's capabilities to see what it 
can do before you try and make it do it is a very common technique when 
interacting with highly variable computer hardware, especially 
multimedia hardware such as video cards and sound cards. Both the 
DirectX and the OpenGL systems provide methods for checking what video 
cards are available on the system and then what capabilities they have 
so that the most suitable drawing method can be used. I think it makes 
sense to provide a similar capability when dealing with robot hardware, 
as this is also variable. That way, rather than just knowing you have a 
laser scanner to play with (for example), you would know whether it 
supports certain features and so be able to choose the best algorithm 
for dealing with its data. Obviously there is going to be some 
fundamental functionality that would be necessary to even qualify as a 
device meeting a certain interface (eg, a laser device returns range 
data in some form).

While the variability in robot hardware is nowhere near as wide as it is 
in video cards, I think it would be wise to provide this functionality 
for what variability there is and in case the variability increases in 
the future (which it is likely to do). If it is done right, such a query 
should only be necessary when the program starts.

Geoff

-- 
Robotics research group, University of Auckland
http://www.ece.auckland.ac.nz/~gbig005/

Matthew Johnson wrote:
> All,
> 
> Would it not make more sense to make the interfaces different if they
> are not always supported?  The idea of querying to find out what an
> interface can do seems backwards to me.  I expect an interface to be
> able to do what is described in the interface definition.  If this is
> not the case, would I need to ask ALL interfaces if they can do what I
> plan to ask them do before using them? If not, why make a special case
> for the position interface.
> 
> Matt   
> 
> -----Original Message-----
> From: pla...@li...
> [mailto:pla...@li...] On Behalf Of
> Toby Collett
> Sent: Sunday, May 15, 2005 2:30 PM
> To: pla...@li...
> Subject: Re: [Playerstage-developers] Robots, Position and PIDs
> 
> Toby Collett wrote:
> 
> 
>>>>Perhaps we need a capabilities request? so we can actively find out
> 
> what
> 
>>>>an interface supports rather than simply detecting failure after the
>>>>event...
>>>>     
>>>>
>>>
>>>That's an idea, could be a standard configuration request that takes
>>>the message subtype and returns ACK or NACK.
>>>
>>>   
>>>
>>
>>Yeah, basically what I was thinking.
>>
>> 
>>
> 
> Actually Ive been thinking some more, We should send an array of message
> types/subtypes that are supported when we send the subscription
> acknowledgement. This would be far simpler, clients that want to ignore
> it can, client libs can parse it and store it in the proxy so a simply
> GetCaps(TYPE,SUBTYPE) call could be used as a lookup...
> 
> Toby
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> _______________________________________________
> Playerstage-developers mailing list
> Pla...@li...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Playerstage-developers mailing list
> Pla...@li...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers