The Player Project

Hello all,

I was wondering if anyone is using the MultiClient in the C++ 
libraries.  It's pretty much the last major chunk from the old api that 
I haven't gotten around to moving over.  If people are using it, I'm 
more than happy to port it over.  If not though, I may end up removing 
it from the headers.  The way I understand things, it looks like we 
could almost do the same thing w/ the following code (roughly).

list<PlayerClient*> multi_client;

PlayerClient pc1("localhost");
PlayerClient pc2("anotherhost");

multi_client.push_back(&pc1);
multi_client.push_back(&pc2);

std::for_each(multi_client.begin(),
                multi_client.end(),
                std::mem_fun(&PlayerClient::Read));

Any input is welcome.

Best regards,

-bk

On Oct 22, 2005, at 6:19 PM, Michael C. Menefee wrote:

> This may be more appropriate for the design list, but I thought I'd  
> try
> here first.  I have a few projects I'm looking to implement player/ 
> stage
> on, but I'm wondering about how to use the motor interface exactly.
> None of my platforms have odometry or any other type of feedback on
> their drive motor outputs.  I simply specify a "power level" (0-255,
> Devantech MD22 motor controller) or a PWM pulse width (AVR PWM
> generator).  Now, I suppose I _could_ just use the thetaspeed value to
> store this information, but that seems incorrect to me since there are
> actual physical units associated with it.  If I performed some kind of
> measurement on the motor (tricky at best, since a few of these are
> underwater thrusters), calibrated this rotational velocity value to a
> power level, etc., I still have no way of ensuring the motor is  
> actually
> turning at that speed. (i.e. as the batteries start to wear, motors  
> will
> turn more slowly for given power levels, etc.)
>
> So, my question is then what is the appropriate way to handle a
> situation like this?  I would say just implement another interface  
> type
> ("dumbmotor" or something), but I am by no means experienced with this
> framework, so I thought I'd ask here first.

While you're right that it's kind of ugly to put your power level  
byte into the 'thetaspeed' field, that's what I would suggest to  
start: Support the motor interface, interpret commanded thetaspeed as  
"power" and report "power" as thetaspeed.

Of course you're breaking the semantics of the interface by doing  
this (e.g., other drivers or clients that use the motor interface  
"properly" won't work with your driver), but think about it as an  
exploratory step.  The set of interfaces and the messages that they  
specify evolve over time as new devices become available and as  
developers want to access different functionality.  There are many  
examples of people (myself included) shoe-horning devices into  
existing interfaces in non-obvious ways until an informed decision  
can be made to either modify the interface or create a new one.

     brian.

On Nov 1, 2005, at 1:44 PM, Geoffrey Biggs wrote:

> After running into some problems with using the pioneer arm via the  
> p2os driver, I found that the p2os driver has been changed (back?)  
> to overwrite older commands when a new one comes in.
>
> http://cvs.sourceforge.net/viewcvs.py/playerstage/code/player/ 
> server/drivers/mixed/p2os/p2os.cc?r1=1.46&r2=1.47
>
> Unfortunately, this causes problems with the actarray component of  
> the driver. A new command for the actarray may be moving a  
> different joint to a previous, as yet unhandled command, meaning  
> that the previous command no longer happens.

Sorry, that's my fault.  As you've guessed, I wanted to stop queueing  
on the position2d interface; I didn't consider how other interfaces  
would be affected.

> Obviously it should overwrite commands for other interfaces such as  
> position, but at the same time it shouldn't for the actarray. We  
> need to come up with a solution to this sort of problem occuring in  
> mixed drivers. Toby has mentioned maybe putting overwriting into  
> the message itself. A config file option would be another  
> possibility, but I have a feeling that'd require far too much re- 
> engineering of the driver class at this late stage before the final  
> version of player-2.

How about this: The MessageQueue could maintain a list/table of  
device addresses and overwrite settings.  When a message comes in,  
the queue checks the address to decide whether the new message should  
replace any old one.  We could add a flag to control this behavior to  
Driver::AddInterface; this call would modify MessageQueue's list/ 
table appropriately.

Would that do it?

It can still happen that a rogue client or driver can send messages  
fast enough to fill up the queue, of course.

     brian.