The Player Project

Radu,

I think this is a good idea.  I think this low level control should not
be lumped into the interface with the higher level stuff, particularly
when it is clear that not all robots will support all the capabilities.
I think it would be good to start a thread of discussion on ALL the
player interfaces and how to clean them up or improve them.

Matt

-----Original Message-----
From: playerstage-developers-admin@...
[mailto:playerstage-developers-admin@...] On Behalf Of
Radu Bogdan Rusu
Sent: Thursday, May 12, 2005 6:08 AM
To: playerstage-developers@...
Subject: [Playerstage-developers] Robots, Position and PIDs


Hellos,

Some time ago, Fred Labrosse and after that, a few weeks ago, Matthew
Johnson enquired the possibility of being able to turn their robots on
spot
by simply specifying the heading.

>From my understanding, only the following drivers have PIDs
implemented:
reb, kephera, clodbuster and obot (which according to obot.cc has a bad
low-level PID motor controller implemented). Reed Hedges stated that
he's
already working on implementing it for the p2os.

For all the other supported robots that do not have a low-level
controller
(PID-like) already implemented, wouldn't it be nice for us to support it
via
the player drivers? I'm also thinking Stage here. 

Is anyone else working on this? I was prepared to implement an abstract
controller and then build P, PD, PI, PID and others on top of them for
Javaclient, but I think it would save everyone some effort if we do it
at
the driver level.

Am I smoking crack or is this a good idea? :)

Cheers,
Radu.
--
| Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
| Javaclient for P/S/G      | http://java-player.sf.net
| Robotics Research Group   , Technical University of Cluj-Napoca[.ro]


-------------------------------------------------------
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
Playerstage-developers@...
https://lists.sourceforge.net/lists/listinfo/playerstage-developers

Radu Bogdan Rusu wrote:

>For all the other supported robots that do not have a low-level controller
>(PID-like) already implemented, wouldn't it be nice for us to support it via
>the player drivers? I'm also thinking Stage here. 
>
>Is anyone else working on this? I was prepared to implement an abstract
>controller and then build P, PD, PI, PID and others on top of them for
>Javaclient, but I think it would save everyone some effort if we do it at
>the driver level.
>
I already have a fairly full featured driver that does this for our 
Marvin robot, which could easily be extended.  The source is all online 
at:  http://www.iris.ethz.ch/research/marvin/files/.  It may give you 
some ideas. 

Basically, I break the robot down into motors and low-level I/O.  This 
is the place where the PID belongs.  Then, on top of that I have the 
Marvin driver which just uses two motors.  It should be able to support 
pretty much any differential drive robot that is made up of 2 motors. 

The low level control is based on our irisController class, which I 
haven't put the source online for yet.  This is mainly because I haven't 
gone through and optimized this code.  Using this framework, I've 
written control for 2 different low level I/O platforms we have here, 
and it can easily be extended to others.

Let me know if you're interested in add/collaborating on this.

Cheers,

bk

Radu Bogdan Rusu wrote:
> Hellos,
> 
> Some time ago, Fred Labrosse and after that, a few weeks ago, Matthew
> Johnson enquired the possibility of being able to turn their robots on spot
> by simply specifying the heading.
> 
> Is anyone else working on this? I was prepared to implement an abstract
> controller and then build P, PD, PI, PID and others on top of them for
> Javaclient, but I think it would save everyone some effort if we do it at
> the driver level.

We've been discussing this recently.

I think it can be an optional component of the position driver.  Not all robots 
offer position control natively, and we probably shouldn't force driver writers 
to implement that.

We're still trying to decide what the interface should be.   The REB driver has 
a configuration request to switch control modes, and then uses "xspeed" for 
translation distance, "yawspeed" for heading, etc.  However, this has some 
limitations: you have to wait until the request has been processed, it overloads 
the "speed" fields in a confusing way, and there is no way to use velocity 
control for translation and heading control for heading.  What I did tentatively 
for myself  is to extend the command structure to have "xpos" , "ypos" and "yaw" 
fields, and have different modes signified by the mode field:  mode=0 is 
velocity control, mode=1 is absolute position control, mode=2 is relative 
(delta) position control.

Look in the mailing list archives for details, or I can send a patch to anyone 
who is interested. (My Stage patch is on sourceforge).

This is not pretty at all in the implementation (I implemented it in Stage and 
also in the p2os driver to just send HEAD, MOVE, DHEAD commands, but haven't had 
a chance to test it).

There has been some discussion about redesigning the position interface bit, 
along with some general architectural changes to Player.  One change that Brian 
is about to move into CVS HEAD I think is to have multiple command types, so we 
can seperate the position and velocity control commands into seperate 
sructs/packets.

I'd like to decouple position and heading control as well but we haven't 
discussed that at all really.

I would also like to expand the SPEED config request to have maximum/minimum 
speeds, speeds to use for position control, and acceleration/deceleration values.

Reed

On 12-May-05, at 4:07 AM, Radu Bogdan Rusu wrote:

>
> Hellos,
>
> Some time ago, Fred Labrosse and after that, a few weeks ago, Matthew
> Johnson enquired the possibility of being able to turn their robots on 
> spot
> by simply specifying the heading.
>
>> From my understanding, only the following drivers have PIDs 
>> implemented:
> reb, kephera, clodbuster and obot (which according to obot.cc has a bad
> low-level PID motor controller implemented). Reed Hedges stated that 
> he's
> already working on implementing it for the p2os.
>
> For all the other supported robots that do not have a low-level 
> controller
> (PID-like) already implemented, wouldn't it be nice for us to support 
> it via
> the player drivers? I'm also thinking Stage here.

Stage does this already. Put the position device into 
position-control-mode, and away you go.

> Am I smoking crack or is this a good idea? :)

It's a good idea. Crack should be employed for debugging only.

Richard.

On Thu, May 12, 2005 at 09:47:44AM -0700, Richard vaughan wrote:
> 
> On 12-May-05, at 4:07 AM, Radu Bogdan Rusu wrote:
> 
> >
> >Hellos,
> >
> >Some time ago, Fred Labrosse and after that, a few weeks ago, Matthew
> >Johnson enquired the possibility of being able to turn their robots on 
> >spot
> >by simply specifying the heading.
> >
> >>From my understanding, only the following drivers have PIDs 
> >>implemented:
> >reb, kephera, clodbuster and obot (which according to obot.cc has a bad
> >low-level PID motor controller implemented). Reed Hedges stated that 
> >he's
> >already working on implementing it for the p2os.
> >
> >For all the other supported robots that do not have a low-level 
> >controller
> >(PID-like) already implemented, wouldn't it be nice for us to support 
> >it via
> >the player drivers? I'm also thinking Stage here.
> 
> Stage does this already. Put the position device into 
> position-control-mode, and away you go.

On my current CVSed Stage it didn't :( (April 22). Player was giving me
"warn: stg_position doesn't support config id 5 (player_interfaces.cc
PositionConfig)" when issuing a "Configuration request: Change control
mode." with mode=1.

I just updated, but now Player won't start libstage :) Ohh, the horror :)
PLAYERPATH: /usr/local/lib
trying to load /usr/local/lib/libstage...success
invoking player_driver_init()...failed
error   : failed to resolve player_driver_init: /usr/lib/libltdl.so.3:
undefined symbol: player_driver_init

error   : failed to load plugin: libstage

I need some ideas on this one. My brain just died.

> >Am I smoking crack or is this a good idea? :)
> 
> It's a good idea. Crack should be employed for debugging only.

Haha :) Have to remember that one! ;)

> Richard.
> 
> 

Yours sincerely,
Radu Bogdan Rusu
--
| Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
| Javaclient for P/S/G      | http://java-player.sf.net
| Robotics Research Group   , Technical University of Cluj-Napoca[.ro]

Radu Bogdan Rusu wrote:

> I just updated, but now Player won't start libstage :) Ohh, the horror :)
> PLAYERPATH: /usr/local/lib
> trying to load /usr/local/lib/libstage...success
> invoking player_driver_init()...failed
> error   : failed to resolve player_driver_init: /usr/lib/libltdl.so.3:
> undefined symbol: player_driver_init
> 
> error   : failed to load plugin: libstage

Stage has been broken into two libs; there's still a libstage, but it's 
now the player-independent lib.  Your .cfg file should instead reference 
the player-specific lib:
   plugin "libstageplugin"
It will in turn load libstage.

This also tripped me up, and is likely to get other users, too.  Maybe 
libstage should get a new name, so that people won't accidentally load 
it, when they mean libstageplugin.  Hmm, but that won't help if there's 
already a libstage installed; they'll just be using the old version of 
stage.  Can't think of a nice fix for this.

	brian.

-- 
Brian P. Gerkey                    gerkey@...
Stanford AI Lab                    http://ai.stanford.edu/~gerkey

On May 12, 2005, at 2:37 PM, Radu Bogdan Rusu wrote:

> On Thu, May 12, 2005 at 09:47:44AM -0700, Richard vaughan wrote:
>>
>> On 12-May-05, at 4:07 AM, Radu Bogdan Rusu wrote:
>>
>>>
>>> Hellos,
>>>
>>> Some time ago, Fred Labrosse and after that, a few weeks ago, Matthew
>>> Johnson enquired the possibility of being able to turn their robots 
>>> on
>>> spot
>>> by simply specifying the heading.
>>>
>>>> From my understanding, only the following drivers have PIDs
>>>> implemented:
>>> reb, kephera, clodbuster and obot (which according to obot.cc has a 
>>> bad
>>> low-level PID motor controller implemented). Reed Hedges stated that
>>> he's
>>> already working on implementing it for the p2os.
>>>
>>> For all the other supported robots that do not have a low-level
>>> controller
>>> (PID-like) already implemented, wouldn't it be nice for us to support
>>> it via
>>> the player drivers? I'm also thinking Stage here.
>>
>> Stage does this already. Put the position device into
>> position-control-mode, and away you go.
>
> On my current CVSed Stage it didn't :( (April 22). Player was giving me
> "warn: stg_position doesn't support config id 5 (player_interfaces.cc
> PositionConfig)" when issuing a "Configuration request: Change control
> mode." with mode=1.
>
> I just updated, but now Player won't start libstage :) Ohh, the horror 
> :)
> PLAYERPATH: /usr/local/lib
> trying to load /usr/local/lib/libstage...success
> invoking player_driver_init()...failed
> error   : failed to resolve player_driver_init: /usr/lib/libltdl.so.3:
> undefined symbol: player_driver_init
>
> error   : failed to load plugin: libstage

> I need some ideas on this one. My brain just died.

the name of the plugin changed from libstage to libstageplugin. Update 
your .cfg files. Sorry about your brain.

Richard.

--
Richard Vaughan
School of Computing Science / Simon Fraser University

Okay, fixed. Thanks for that one Brian, must have missed it.

Richard, Is this the configuration request type you were refering to? :
#define PLAYER_POSITION_POSITION_MODE_REQ ((uint8_t)5)

Latest player/stage still gives:
warn: stg_position doesn't support config id 5 (player_interfaces.cc
PositionConfig)

PS. It's the same with PLAYER_POSITION_VELOCITY_MODE_REQ.

Cheers,
Radu.

On Thu, May 12, 2005 at 03:59:18PM -0700, Brian Gerkey wrote:
> Radu Bogdan Rusu wrote:
> 
> >I just updated, but now Player won't start libstage :) Ohh, the horror :)
> >PLAYERPATH: /usr/local/lib
> >trying to load /usr/local/lib/libstage...success
> >invoking player_driver_init()...failed
> >error   : failed to resolve player_driver_init: /usr/lib/libltdl.so.3:
> >undefined symbol: player_driver_init
> >
> >error   : failed to load plugin: libstage
> 
> Stage has been broken into two libs; there's still a libstage, but it's 
> now the player-independent lib.  Your .cfg file should instead reference 
> the player-specific lib:
>   plugin "libstageplugin"
> It will in turn load libstage.
> 
> This also tripped me up, and is likely to get other users, too.  Maybe 
> libstage should get a new name, so that people won't accidentally load 
> it, when they mean libstageplugin.  Hmm, but that won't help if there's 
> already a libstage installed; they'll just be using the old version of 
> stage.  Can't think of a nice fix for this.
> 
> 	brian.
> 
> -- 
> Brian P. Gerkey                    gerkey@...
> Stanford AI Lab                    http://ai.stanford.edu/~gerkey
> 

Yours sincerely,
Radu Bogdan Rusu
--
| Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
| Javaclient for P/S/G      | http://java-player.sf.net
| Robotics Research Group   , Technical University of Cluj-Napoca[.ro]

Brian Gerkey wrote:
> This also tripped me up, and is likely to get other users, too.  Maybe 
> libstage should get a new name, so that people won't accidentally load 
> it, when they mean libstageplugin.  Hmm, but that won't help if there's 
> already a libstage installed; they'll just be using the old version of 
> stage.  Can't think of a nice fix for this.

Just make sure it's in the change log (and summary News if Stage has that).

We could also make the error messages a bit more helpful. "failed to resolve 
player_driver_init" can be translated into: "/usr/local/lib/libstage.so is not a 
valid Player plugin module (failed to resolve player_driver_init function.)", 
which is useful both for plugin developers and users.

It looks like all the example configs in Stage have been updated to 
libstageplugin too.

Reed


Index: server/main.cc
===================================================================
RCS file: /cvsroot/playerstage/code/player/server/main.cc,v
retrieving revision 1.130
diff -r1.130 main.cc
923,925c1009,1012
<       puts("failed");
<       PLAYER_ERROR1("failed to resolve player_driver_init: %s\n",
<                   lt_dlerror() );
---
 >       if(!quiet_startup) // continuation of previous unquiet message.
 >         puts("failed");
 >       PLAYER_ERROR2("%s does is not a valid Player plugin (failed to resolve 
player_driver_init function; %s)\n",
 >                   fullpath, lt_dlerror() );
932c1019,1020
<       puts("failed");
---
 >       if(!quiet_startup) // continuation of previous unquiet message.
 >         puts("failed");

Hi,
Just to mention this again, the soon to be merged (what is the current
timeframe?) message-overhaul branch of player supports a subtype in the
message header, this allows for a single 'interface' to support multiple
data and command  structures in a similar manner to how we previously
supported multiple request/response structures.
This could allow more flexibility in the interfaces (ie seperate
structures for position and velocity control etc) as well as the
potential for driver specific structures.
Perhaps we need a capabilities request? so we can actively find out what
an interface supports rather than simply detecting failure after the
event...

Toby Collett

Reed Hedges wrote:

> Radu Bogdan Rusu wrote:
>
>> Hellos,
>>
>> Some time ago, Fred Labrosse and after that, a few weeks ago, Matthew
>> Johnson enquired the possibility of being able to turn their robots
>> on spot
>> by simply specifying the heading.
>>
>> Is anyone else working on this? I was prepared to implement an abstract
>> controller and then build P, PD, PI, PID and others on top of them for
>> Javaclient, but I think it would save everyone some effort if we do
>> it at
>> the driver level.
>
>
> We've been discussing this recently.
>
> I think it can be an optional component of the position driver.  Not
> all robots offer position control natively, and we probably shouldn't
> force driver writers to implement that.
>
> We're still trying to decide what the interface should be.   The REB
> driver has a configuration request to switch control modes, and then
> uses "xspeed" for translation distance, "yawspeed" for heading, etc. 
> However, this has some limitations: you have to wait until the request
> has been processed, it overloads the "speed" fields in a confusing
> way, and there is no way to use velocity control for translation and
> heading control for heading.  What I did tentatively for myself  is to
> extend the command structure to have "xpos" , "ypos" and "yaw" fields,
> and have different modes signified by the mode field:  mode=0 is
> velocity control, mode=1 is absolute position control, mode=2 is
> relative (delta) position control.
>
> Look in the mailing list archives for details, or I can send a patch
> to anyone who is interested. (My Stage patch is on sourceforge).
>
> This is not pretty at all in the implementation (I implemented it in
> Stage and also in the p2os driver to just send HEAD, MOVE, DHEAD
> commands, but haven't had a chance to test it).
>
> There has been some discussion about redesigning the position
> interface bit, along with some general architectural changes to
> Player.  One change that Brian is about to move into CVS HEAD I think
> is to have multiple command types, so we can seperate the position and
> velocity control commands into seperate sructs/packets.
>
> I'd like to decouple position and heading control as well but we
> haven't discussed that at all really.
>
> I would also like to expand the SPEED config request to have
> maximum/minimum speeds, speeds to use for position control, and
> acceleration/deceleration values.
>
> Reed
>
>
>
>
>
> -------------------------------------------------------
> 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
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>

Toby Collett wrote:
> Hi,
> Just to mention this again, the soon to be merged (what is the current
> timeframe?) message-overhaul branch of player supports a subtype in the
> message header, this allows for a single 'interface' to support multiple
> data and command  structures in a similar manner to how we previously
> supported multiple request/response structures.
> This could allow more flexibility in the interfaces (ie seperate
> structures for position and velocity control etc) as well as the
> potential for driver specific structures.

Yeah, I'm waiting on that before further development in this area...


> 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.

>> 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.

Toby

On Fri, May 13, 2005 at 05:57:24PM -0400, Reed Hedges wrote:
> Toby Collett wrote:
> >Hi,
> >Just to mention this again, the soon to be merged (what is the current
> >timeframe?) message-overhaul branch of player supports a subtype in the
> >message header, this allows for a single 'interface' to support multiple
> >data and command  structures in a similar manner to how we previously
> >supported multiple request/response structures.
> >This could allow more flexibility in the interfaces (ie seperate
> >structures for position and velocity control etc) as well as the
> >potential for driver specific structures.
> 
> Yeah, I'm waiting on that before further development in this area...

Reed, have your patches been merged into the tree code? 

Yours sincerely,
Radu Bogdan Rusu
--
| Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
| Javaclient for P/S/G      | http://java-player.sf.net
| Robotics Research Group   , Technical University of Cluj-Napoca[.ro]

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...

Sounds like a good idea to me.  Interestingly, this feature was 
requested about 2.5 years ago:

http://sourceforge.net/tracker/index.php?func=detail&aid=660523&group_id=42445&atid=433167
	
	brian.

-- 
Brian P. Gerkey                    gerkey@...
Stanford AI Lab                    http://ai.stanford.edu/~gerkey

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

Radu Bogdan Rusu wrote:
> On Fri, May 13, 2005 at 05:57:24PM -0400, Reed Hedges wrote:
> 
>>Toby Collett wrote:

>>>Just to mention this again, the soon to be merged (what is the current
>>>timeframe?) message-overhaul branch of player supports a subtype in the
>>>message header, this allows for a single 'interface' to support multiple
>>>data and command  structures in a similar manner to how we previously
>>>supported multiple request/response structures.

>>Yeah, I'm waiting on that before further development in this area...
> 
> 
> Reed, have your patches been merged into the tree code? 

No, not yet, and they probably won't be as they are.

I'll rewrite them after some of these big changes are done.  The interfaces will 
be completetly different, I presume, and it might be better to make drastic 
changes to the Position2D interface and leave Position a bit closer to the old 
interface for easier transition?

Also my stage implementation of the absolute/relative position controls was 
somewhat flawed, I'll be posting a new patch for that to the SF tracker.

But let me know if you want them anyway.

Reed

On Mon, May 16, 2005 at 08:27:52AM -0400, Reed Hedges wrote:
> Radu Bogdan Rusu wrote:
> >On Fri, May 13, 2005 at 05:57:24PM -0400, Reed Hedges wrote:
> >
> >>Toby Collett wrote:
> 
> >>>Just to mention this again, the soon to be merged (what is the current
> >>>timeframe?) message-overhaul branch of player supports a subtype in the
> >>>message header, this allows for a single 'interface' to support multiple
> >>>data and command  structures in a similar manner to how we previously
> >>>supported multiple request/response structures.
> 
> >>Yeah, I'm waiting on that before further development in this area...
> >
> >
> >Reed, have your patches been merged into the tree code? 
> 
> No, not yet, and they probably won't be as they are.
> 
> I'll rewrite them after some of these big changes are done.  The interfaces 
> will be completetly different, I presume, and it might be better to make 
> drastic changes to the Position2D interface and leave Position a bit closer 
> to the old interface for easier transition?
> 
> Also my stage implementation of the absolute/relative position controls was 
> somewhat flawed, I'll be posting a new patch for that to the SF tracker.
> 
> But let me know if you want them anyway.

Sure thing. I'm trying to implement a couple of robust controllers with a
colleague of mine, and the setHeading stuff is exactly what we need. It
sucks using a P(ID) for heading at the higher level, especially since this
can be done at the lower level.

Do you patches include both p2os and Stage modifications? I'm still having
trouble using PLAYER_POSITION_{POSITION,VELOCITY}_MODE_REQ in Stage :(

As Brian said, we can still work and improve the 1.6.4, while the big
architectural changes go to the new version (1.7 ?).

> Reed

Cheers,
Radu.
--
| Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
| Javaclient for P/S/G      | http://java-player.sf.net
| Robotics Research Group   , Technical University of Cluj-Napoca[.ro]

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: playerstage-developers-admin@...
[mailto:playerstage-developers-admin@...] On Behalf Of
Toby Collett
Sent: Sunday, May 15, 2005 2:30 PM
To: playerstage-developers@...
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
Playerstage-developers@...
https://lists.sourceforge.net/lists/listinfo/playerstage-developers

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: playerstage-developers-admin@...
> [mailto:playerstage-developers-admin@...] On Behalf Of
> Toby Collett
> Sent: Sunday, May 15, 2005 2:30 PM
> To: playerstage-developers@...
> 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
> Playerstage-developers@...
> 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
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers

Radu Bogdan Rusu wrote:

>>But let me know if you want them anyway.
> 
> 
> Sure thing. I'm trying to implement a couple of robust controllers with a
> colleague of mine, and the setHeading stuff is exactly what we need. It
> sucks using a P(ID) for heading at the higher level, especially since this
> can be done at the lower level.
> 
> Do you patches include both p2os and Stage modifications? I'm still having
> trouble using PLAYER_POSITION_{POSITION,VELOCITY}_MODE_REQ in Stage :(

Just Stage implementation, but the P2OS driver change should be almost trivial: 
just send a HEAD command for absolute heading, DHEAD for relative heading, and 
MOVE for relative translation.  Of course, absolute translation is tricky with a 
non-omnidirectional robot, but the Stage code includes a method for doing it 
(turn to face the goal, drive to the goal, then perform any absolute heading 
control you need). My Stage patch sort of messes that up (absolute position 
control) though I think and I haven't tested it yet since I don't need it yet.

I have no idea how robust my Stage controllers are, just trying different 
combinations to test I have worked out whatever bugs there were.  The heading 
control is just a proportion, speed-limited. It doesn't check for overshoot, it 
assumes it's running frequently enough to catch the goal heading within 1 or 2 
degrees accuracy.   Do you have a more rigorous testing procedure I can try?

Anyway, my changes to Stage will be posted soon on sourceforge (and distributed 
with the new ActivMedia simulator based on stage).


Reed

The player protocol already allows a device to not support some aspects
of an interface (ie velocity or position control for the position
interface), it simply sends a nack to any request it doesnt support.
Adding capabilities checking simply allows an application to check ahead
of time which can be more convienient.

If every variaton in capabilities led to a new interface then we would
effectively have one interface for every message or request that could
be sent to a device, however the other extreme is to simply have a robot
interface that supports every message and query it to see if it supports
laser_geom, sonar_data etc which is also obviously flawed.

Given the two extremes, the pragmatic approach is to group major
categories into interfaces with minor variations in supported
capabilities allowing for the sanity of developers. This is the approach
that player takes at the moment. If we wished to make this more formal
we could specify in the documentation which messages for a given
interface are 'required' to be supported, such as range readings for
laser devices.

There is certainly good arguments toward seperating position control,
velocity control and odometry readings into three seperate interfaces
but given the generally linked nature of the three from a driver point
of view it makes sense to have them linked. I'll reserve my judgement on
that one.

Toby Collett

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: playerstage-developers-admin@...
>[mailto:playerstage-developers-admin@...] On Behalf Of
>Toby Collett
>Sent: Sunday, May 15, 2005 2:30 PM
>To: playerstage-developers@...
>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
>Playerstage-developers@...
>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
>Playerstage-developers@...
>https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>
>  
>

Has there been any thought toward getting feedback from requests?  For
example, I tell a robot to move to some position and then I get informed
when it has reached its destination or has failed to reach its
destination.  Using the information obtained from the "read" part of
Player, some of this functionality could be achieved, but I wonder if it
would be beneficial to include this feedback explicitly without having
to add state monitors.

Matt

The playerstage server in CVS now has the ability to send many types of
data message, these need to be defined in the interface and also
provided in the driver but the ability to do so it definately there.

Exactly what messages are defined is really up to what people feel they
need and are prepared to implement.

Toby Collett

Matthew Johnson wrote:

>Has there been any thought toward getting feedback from requests?  For
>example, I tell a robot to move to some position and then I get informed
>when it has reached its destination or has failed to reach its
>destination.  Using the information obtained from the "read" part of
>Player, some of this functionality could be achieved, but I wonder if it
>would be beneficial to include this feedback explicitly without having
>to add state monitors.
>
>Matt
>
>
>
>
>-------------------------------------------------------
>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
>Playerstage-developers@...
>https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>
>  
>

Hello Brad,

...and sorry for replying so late. I've been busy with some final
university projects, and also had a lot of work to do on our ZeeRO robot,
which proudly reached its v1.0 stable (hardware-wise :).

After I started the discussion here, I went ahead and developed some basic
controller classes for Javaclient (they are up on the CVS head at SF).
Basically we support an abstract controller, and then upon that, I built
some simple ones such as P,PI,PD and PID.

Of course, this is not the desired solution (at least not for everyone),
since Javacline is just *one* of the many existing clients for P/S/G. So, to
make a long story short, I'd be happy to start collaborating with you or
anyone else to implement the controllers at the player level.

Right now, it might be safe to hold until 1.7 is over and the XDR is
implemented, since Javaclient will suffer some changes too. Of course, we
can discuss and put some ideas on paper until then. :)

Cheers,
Radu.

On Thu, May 12, 2005 at 03:35:08PM +0200, Brad Kratochvil wrote:
> Radu Bogdan Rusu wrote:
> 
> >For all the other supported robots that do not have a low-level controller
> >(PID-like) already implemented, wouldn't it be nice for us to support it 
> >via
> >the player drivers? I'm also thinking Stage here. 
> >
> >Is anyone else working on this? I was prepared to implement an abstract
> >controller and then build P, PD, PI, PID and others on top of them for
> >Javaclient, but I think it would save everyone some effort if we do it at
> >the driver level.
> >
> I already have a fairly full featured driver that does this for our 
> Marvin robot, which could easily be extended.  The source is all online 
> at:  http://www.iris.ethz.ch/research/marvin/files/.  It may give you 
> some ideas. 
> 
> Basically, I break the robot down into motors and low-level I/O.  This 
> is the place where the PID belongs.  Then, on top of that I have the 
> Marvin driver which just uses two motors.  It should be able to support 
> pretty much any differential drive robot that is made up of 2 motors. 
> 
> The low level control is based on our irisController class, which I 
> haven't put the source online for yet.  This is mainly because I haven't 
> gone through and optimized this code.  Using this framework, I've 
> written control for 2 different low level I/O platforms we have here, 
> and it can easily be extended to others.
> 
> Let me know if you're interested in add/collaborating on this.
> 
> Cheers,
> 
> bk
> 

Yours sincerely,
Radu Bogdan Rusu
--
| Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
| PhD student/teaching assistant
| Robotics Research Group, Technical University of Cluj-Napoca[.ro]

Radu Bogdan Rusu wrote:

>Of course, this is not the desired solution (at least not for everyone),
>since Javacline is just *one* of the many existing clients for P/S/G. So, to
>make a long story short, I'd be happy to start collaborating with you or
>anyone else to implement the controllers at the player level.
>
>Right now, it might be safe to hold until 1.7 is over and the XDR is
>implemented, since Javaclient will suffer some changes too. Of course, we
>can discuss and put some ideas on paper until then. :)
>
>  
>
It may be nice to build a fairly generic differential drive robot 
driver.  Then people could write the low level motor interface for their 
particular hardware, but not have to worry about the higher level stuff 
for most robots.  Would something like this be helpful to your project?  
If so, I've already got the basis for this done in our Marvin driver.  
What we'd need to do is figure out how best to generalize this, and what 
others would need.

I'm working w/ some of the other devs on an interface overhaul.  Is 
there anything that people would like to see changed/added/removed in 
the position interface (or any interfaces for that matter).

Best regards,

Brad