There is not a global message debug that I know of, but if you use the passthrough driver to access the bumper interface and then run player with -d 2 I think you get a message to the console with every message...
alternatively you could subscribe with another client, such as player print and see the frequency it is getting data.

Toby

On 04/03/2008, Elod Kironsky <elod.kironsky@avg.com> wrote:
Brian Gerkey wrote:
>
> On Mar 3, 2008, at 2:48 PM, Elod Kironsky wrote:
>
>> Well, I'm printing every message from the server to the console (read
>> header, read length number of bytes and print it). If I use shorter
>> intervals, I get some bumper data messages but mostly only SYNCH
>> messages. So that is why I suspect, that the data messages are simply
>> timed out somewhere on the queue. I have my client written in Smalltalk,
>> so I cannot examine the playerc_bumper_t structure, I use my own
>> decoding methods that work with a bunch of bytes :-)
>
> Ah.  Well, there's no timeout in the queues on the server side.  Once
> a message is put onto a client's outgoing queue, it will either be
> delivered to the client, or it will be overwritten by a subsequent
> message with the same signature (replacement rule depending).
>
> In PULL mode with replacement, if you poll at a rate less than the
> rate at which the underlying driver publishes the data, then you
> should get a new data message (followed by a SYNCH) every cycle.  Of
> course, if you read faster, then sometimes there won't be new data for
> you, and so you'll just get the SYNCH.  If you're using Stage, then
> the data publication rate should be about 10Hz.
>
>     brian.
>

This however means, that using Stage (this is my case), with a poll rate
every 5 secs and with the replacement rule set, I should get data
message for every read. Is there any way to turn some kind of debug
logging on onto the console, so I could verify if the replacement rule
was set correctly and mainly if a new data message is in the bumper's
queue (with time stamp diplayed)? I could modify the driver and
recompile it then, but I don't know where to start or what to search
for. Or is there a global debugging switch in the configuration files?


Elod

>>> How do you know that you're not getting data for the bumpers?  Have
>>> you tried looking at the playerc_bumper_t structure?  It gets filled
>>> in as a side-effect of reading (this is actually libplayerc's default
>>> callback in action).  You can test for fresh data in any libplayerc
>>> device proxy by examining the 'info.fresh' field.
>>>
>>>    brian.
>>>
>>> On Feb 7, 2008, at 4:11 AM, Elod Kironsky wrote:
>>>
>>>> I tried to change the order to (1) set data mode to PULL, (2) set
>>>> replace rule, (3) subscribe to bumpers. It did
>>>> not work. However I figured out, that if I pull the packages in a
>>>> shorter interval, some data occasionally is sent
>>>> from the server. The shorter the interval the more data arrives.
>>>> Originally I was pulling data every 5 secs, just to
>>>> test if everything is fine, but I only got SYNCH messages. If I set
>>>> the
>>>> pull interval to 0.5 sec, I started to receive
>>>> data packages, but *not* for every data request. Is there a timeout
>>>> for
>>>> data packages waiting on the queue for an
>>>> interface? If yes, how can I change it?
>>>>
>>>> Elod
>>>>> Changing the order, as Kevin suggests, is definitely worth a try.  I
>>>>> suspect that we're not properly handling the case when data is
>>>>> already
>>>>> on the socket when the data mode and/or replacement rules are
>>>>> changed by
>>>>> the client.  So, set everything up, *then* subscribe.
>>>>>
>>>>> Here's a relevant post from a while back:
>>>>>
>>>>> https://sourceforge.net/mailarchive/message.php?msg_name=14825455.post%40talk.nabble.com
>>>>>
>>>>>
>>>>>
>>>>>    brian.
>>>>>
>>>>> Kevin Barry wrote:
>>>>>
>>>>>>> order of actions: subscribe to the bumber, set data mode, set
>>>>>>> replace mode?
>>>>>>>
>>>>>> I would try changing the order. I'm not sure it matters, but when
>>>>>> I've
>>>>>> done it, I always did set data mode first, then subscribe. Below is
>>>>>> some code that I've used (It's in MATLAB not C so don't copy/paste,
>>>>>> but the syntax is close so you'll get the idea)
>>>>>>
>>>>>>
>>>>>> client = player('client_create', config.player_host,
>>>>>> config.player_port);
>>>>>> player('client_connect', client);
>>>>>>
>>>>>> player('client_datamode', client, PLAYER_DATAMODE_PULL);
>>>>>> player('client_set_replace_rule', client, -1, -1,
>>>>>> PLAYER_MSGTYPE_DATA, -1, 1);
>>>>>>
>>>>>> camera = player('camera_create', client, config.player_camera_num);
>>>>>> player('camera_subscribe', camera, PLAYER_OPEN_MODE);
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Feb 6, 2008 7:29 AM, Elod Kironsky <elod.kironsky@avg.com> wrote:
>>>>>>
>>>>>>> Yes, I get the bumber data without any problems. Also in PULL
>>>>>>> mode, I
>>>>>>> get the data when requesting for it, but
>>>>>>> as soon as I set the replace rule I get only SYNCH messages. Is
>>>>>>> there
>>>>>>> any setting in cfg file that I could use to
>>>>>>> have the bumber print debug messages? Is the order of  commands
>>>>>>> sending
>>>>>>> to the server significant? I mean the
>>>>>>> order of actions: subscribe to the bumber, set data mode, set
>>>>>>> replace mode?
>>>>>>>
>>>>>>> Elod
>>>>>>>
>>>>>>>
>>>>>>>> Did you get bumper data in PUSH mode?
>>>>>>>>
>>>>>>>> Toby
>>>>>>>>
>>>>>>>> Elod Kironsky wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Any ideo on this problem please?
>>>>>>>>>
>>>>>>>>> Elod
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi!
>>>>>>>>>>
>>>>>>>>>> I'm trying to use PULL data mode in Player 2.0.5 using Stage
>>>>>>>>>> 2.0.4. I
>>>>>>>>>> send the PULL mode request message to the server. Then I set
>>>>>>>>>> the replace
>>>>>>>>>> rule for all data messages to have them replaced on the message
>>>>>>>>>> queue by
>>>>>>>>>> newer messages as described at:
>>>>>>>>>>
>>>>>>>>>> http://playerstage.sourceforge.net/doc/Player-2.0.0/player/group__libplayerc__datamodes.html
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Everything seems to work fine, I don't get any "*push onto full
>>>>>>>>>> message
>>>>>>>>>> queue error*" text. The only problem is, that when I send a
>>>>>>>>>> PLAYER_PLAYER_REQ_DATA request, I only get a SYNCH message. No
>>>>>>>>>> data
>>>>>>>>>> message arrives to me, although I'm subscribed to the bumber
>>>>>>>>>> device on
>>>>>>>>>> my robot (simulated in stage). Any clues what I'm doing wrong
>>>>>>>>>> or how I
>>>>>>>>>> could debug this (perhaps enable console debug logging in
>>>>>>>>>> player/stage
>>>>>>>>>> to see what is actually pushed onto the message queue)?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Elod
>>>>>>>>>>
>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This SF.net email is sponsored by: Microsoft
>>>>>>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>>>>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Playerstage-users mailing list
>>>>>>>>>> Playerstage-users@lists.sourceforge.net
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/playerstage-users
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This SF.net email is sponsored by: Microsoft
>>>>>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>>>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>>>>>> _______________________________________________
>>>>>>>>> Playerstage-users mailing list
>>>>>>>>> Playerstage-users@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/playerstage-users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> This SF.net email is sponsored by: Microsoft
>>>>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>>>>> _______________________________________________
>>>>>>>> Playerstage-users mailing list
>>>>>>>> Playerstage-users@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/playerstage-users
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Elod Kironsky
>>>>>>> Developer
>>>>>>> AVG Technologies
>>>>>>> Email: elod.kironsky@avg.com
>>>>>>> www.avg.com
>>>>>>> www.avg.cz
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> This SF.net email is sponsored by: Microsoft
>>>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>>>> _______________________________________________
>>>>>>> Playerstage-users mailing list
>>>>>>> Playerstage-users@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/playerstage-users
>>>>>>>
>>>>>>>
>>>>>> -------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> This SF.net email is sponsored by: Microsoft
>>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>>> _______________________________________________
>>>>>> Playerstage-users mailing list
>>>>>> Playerstage-users@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/playerstage-users
>>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> This SF.net email is sponsored by: Microsoft
>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>> _______________________________________________
>>>>> Playerstage-users mailing list
>>>>> Playerstage-users@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/playerstage-users
>>>>>
>>>>
>>>>
>>>> --
>>>> Elod Kironsky
>>>> Developer
>>>> AVG Technologies
>>>> Email: elod.kironsky@avg.com
>>>> www.avg.com
>>>> www.avg.cz
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>>
>>>>
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> Playerstage-users mailing list
>>>> Playerstage-users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/playerstage-users
>>>
>>
>>
>> --
>> Elod Kironsky
>> Developer
>> AVG Technologies
>> Email: elod.kironsky@avg.com
>> www.avg.com
>> www.avg.cz
>>
>>
>> -------------------------------------------------------------------------
>>
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Playerstage-users mailing list
>> Playerstage-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/playerstage-users
>


--
Elod Kironsky
Developer
AVG Technologies
Email: elod.kironsky@avg.com
www.avg.com
www.avg.cz


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
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