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@...> 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@...>
> 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@...
> >>>>>>>>>> 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@...
> >>>>>>>>> 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@...
> >>>>>>>> https://lists.sourceforge.net/lists/listinfo/playerstage-users
> >>>>>>>>
> >>>>>>>>
> >>>>>>> --
> >>>>>>> Elod Kironsky
> >>>>>>> Developer
> >>>>>>> AVG Technologies
> >>>>>>> Email: elod.kironsky@...
> >>>>>>> http://www.avg.com
> >>>>>>> http://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@...
> >>>>>>> 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@...
> >>>>>> 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@...
> >>>>> https://lists.sourceforge.net/lists/listinfo/playerstage-users
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Elod Kironsky
> >>>> Developer
> >>>> AVG Technologies
> >>>> Email: elod.kironsky@...
> >>>> http://www.avg.com
> >>>> http://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@...
> >>>> https://lists.sourceforge.net/lists/listinfo/playerstage-users
> >>>
> >>
> >>
> >> --
> >> Elod Kironsky
> >> Developer
> >> AVG Technologies
> >> Email: elod.kironsky@...
> >> http://www.avg.com
> >> http://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@...
> >> https://lists.sourceforge.net/lists/listinfo/playerstage-users
> >
>
>
> --
> Elod Kironsky
> Developer
> AVG Technologies
> Email: elod.kironsky@...
> http://www.avg.com
> http://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@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-users
>
--
This email is intended for the addressee only and may contain privileged
and/or confidential information
|