I think that you make a good point, I guess it comes down to deciding what is core functionality of a driver. Many position drivers will not really have a meaningful maximum speed, so should we have a specific request for it which drivers that dont support NACK, or do we have it as a property with its weak definition that is slightly more error prone...

I guess the pragmatic middleground is: change all the really obvious driver specific data to properties (like the RMP stuff in position2d), and as new pieces of info arise (like max speed) consider on an individual basis. If an interface has been around for a long time like position2d then chances are anything that is not in it by now is not core to the interface (so is a candidate for properties).

Another parallel approach to deciding if its a property or a core request is to look at the abstraction the interface provides and whether the request fits in that abstraction, using the approach max_speed does seem to be part of the position2d metadata, but we need to be consistent and make it max speeds with x, y and theta, and also add it to position1d and 3d.

Maybe we should write a set of ground rules about properties, i.e.
It's not a property if:
 - Its data or a command
 - It is more than a single value
 - if its core to the abstraction the interface provides

It is a property if:
 - It is specific to an individual driver
 - It doesnt fit the abstraction of the interface (this also possibly implies that a second interface should be provided, for example PID tuning is not the responsibility of the position 2d interface, it should be in a controlLoop interface or something...)




On 5/24/07, Richard vaughan <vaughan@cs.sfu.ca> wrote:
** I have moved this thread to ps-developers**

The main trouble with the property bag model is that it avoids imposing any useful abstraction. Here's a complete and consistent interface:

class Proxy 
{
int SetProperty( string id, int val );
int SetProperty( string id, double val );
int SetProperty( string id, string val );

int GetProperty( string id, int& val );
int GetProperty( string id, double& val );
int GetProperty( string id, string& val );
};

This can do *everything* the Player proxies can do. But it says nothing about robots, and the compiler cannot help you.  Debugging code on a console-free robot because you typed "MAX_SPED" by mistake is exactly the kind of problem that hard-coded interface specs are designed to avoid. How do you know if your property-based code is portable? By looking at every string in every file and checking the manual to see that it "must be supported" by drivers? 

I'll repeat myself and suggest that properties should be restricted to driver-specific state. Anything generic should be part of the interface spec. Portable code should use no properties at all, and getting/setting properties should be visibly different to using regular Player interfaces. 

By the way, the simulation interface has long supported property bags for tweaking simulation models in a very general way, so I absolutely think it's useful in the right place. But it should be used very sparingly!

If we were going to go down this route, we could have saved a whole lot of time by using $(generic key-value middleware)  and just specified a set of robot-ish keys. 

That's a total of 4 cents worth, so I'll hush up now.

Richard/


On 22-May-07, at 7:51 PM, Toby Collett wrote:

This is something that is up for discussion, my personal opionion is that properties are fine for common functionality.

Here is a summary of the discussion Geoff and I had about this (I dont recall if it was in his original post). 

A list of preferred property names should be declared in the interface documentation. Properties such as max speed would be candidates for this. This means that *if* a driver supports a maximum speed property this would be called max_speed (or whatever it is defined as in the interface as the preferred name).

The benefit of this is that properties encapsulate the setting and getting both from the client end and from the config file and we do not need to create as many methods in our proxies as getting properties is generic.

The disadvantage is that the property names are not enforced by the compiler, so developers can name there properties slightly differently causing issues (hopefully documentation of these will mitigate this). The other disadvantage is accessing properties in the client proxy is slightly more tedious (PositionProxy->GetProperty("MAX_SPEED") as opposed to PositionProxy->GetMaxSpeed(). But we dont have to maintain as large a set of members in the proxies.

What is the wider opinion on this?

Toby


On 5/23/07, Richard vaughan < vaughan@cs.sfu.ca> wrote:

On 22-May-07, at 6:11 PM, Geoffrey Biggs wrote:

> Yep, definitely, that's a prime candidate for a property.

Isn't MAX_SPEED a near-universal property of a position device? Most
position devices should be able to supply that when queried.

I thought properties should be driver-specific, such as
"VFH_NEARNESS_THRESHOLD"  ( I made that one up).

The fact that you suggest a dedicated proxy function gives the game
away. Robot-portable code should almost never use properties. Or do I
misunderstand?

Richard/

> Geoff
>
> Brian Gerkey wrote:
>> On May 16, 2007, at 6:21 AM, Marcelo Salazar wrote:
>>
>>> Could be interesting to add a function to set the MAX_SPEED in the
>>> PlayerCc::Position2dProxy, for example:
>>>
>>> SetMaxSpeed (double amaxXSpeed, double amaxYawSpeed);
>>>
>>> Is it possible request to be included in the next version?
>>
>> This sounds like something that should go into Geoff's new property
>> bag framework, right?
>>
>>      brian.
>
>
> --
> Robotics research group, University of Auckland
> http://www.ece.auckland.ac.nz/~gbig005/
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Playerstage-users mailing list
> Playerstage-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/playerstage-users


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Playerstage-users mailing list
Playerstage-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/playerstage-users



--
This email is intended for the addressee only and may contain privileged and/or confidential information
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Playerstage-users mailing list


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Playerstage-developers mailing list
Playerstage-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/playerstage-developers




--
This email is intended for the addressee only and may contain privileged and/or confidential information