Sorry for the typo, I meant to say that playback on *cturtle* invoked the callback 2494 times. On Fri, Jul 30, 2010 at 10:26 AM, Jeremy Leibs wrote: > Daniel, > > For very high-rate things across many channels, what Blaise is talking > about might lead to problems.  However, I don't think it is in this > particular case. > > I ran your tests and checked with rxbag and the packets seem to be > nicely distributed as we would want. > > I am 99% confident that this is a problem with rosbag in boxturtle. > The old rosbag (which actually called through to rosplay), had a lot > of problems in the timing engine that led to this kind of bursty > behavior on playback.  For cturtle, I rewrote the rosbag timing engine > and I believe it is now far more robust and well-behaved. > > I just confirmed playback from boxturtle only invoked the callback 54 > times.  Playback on boxturtle invoked the callback 2494 times. > > If you can possibly move to cturtle, I believe that should solve your > issues.  If you really need to work with boxturtle I can investigate > the possibility of patching in some of these timing fixes. > > --Jeremy > > On Fri, Jul 30, 2010 at 10:03 AM, Daniel Grollman > wrote: >> Hi Blaise, >> >>        Thanks for this info, I hadn't thought to consider the scheduler. >> However, opening up my bagfile with rxbag (and zooming in very close), >> it looks like there is indeed a packet every 2ms.  I'll try to confirm >> this with the API. >> >> Dan >> >> On 07/30/2010 06:15 PM, Blaise Gassend wrote: >>> As far as I know, rosbag can only rely on message arrival times when it >>> records a data stream. At 500 Hz, your messages are being sent at a rate >>> that is fast compared with Linux's scheduling granularity, so on a >>> loaded system, I would not expect rosbag to necessarily be scheduled >>> each time it receives a message. Hence it will receive the messages in >>> clumps, and during replay, messages will be played back in clumps. You >>> can verify whether this is the case by looking at the timestamps in the >>> bag. I think rxbag should allow you to view the timestamps graphically. >>> The python bag API should allow you to view the timestamps directly. >>> >>> You might be able to improve things by puting rosbag on one of the >>> "realtime" queues using schedtool. >>> >>> You can also see the scheduling happening using the kernel ftrace >>> mechanism. >>> >>> On Fri, 2010-07-30 at 14:02 +0200, Daniel Grollman wrote: >>>> Hello, >>>> >>>>      I've noticed some odd behavior with rosbag.  I'm generating data at >>>> 500hz, and recording a bag.  However, when playing back the bag, only a >>>> fraction of the messages reach my callback.  I believe that rosbag is >>>> 'bursting' the messages, i.e., sporadically sending them at much faster >>>> than 500 Hz, so they are then getting lost as my queue size is only 1 >>>> (which is what I want). >>>> >>>> I'm running ros 1.0.4, and ubuntu 9.10.  I've put together a little demo >>>> of this issue, code is here: >>>> >>>> http://lasa.epfl.ch/~dang/rosbag_test.tar.gz >>>> >>>> Thank you, >>>> >>>> Dan Grollman >>>> EPFL >>>> _______________________________________________ >>>> ros-users mailing list >>>> ros-users@code.ros.org >>>> https://code.ros.org/mailman/listinfo/ros-users >>> >>> >>> _______________________________________________ >>> ros-users mailing list >>> ros-users@code.ros.org >>> https://code.ros.org/mailman/listinfo/ros-users >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users >> >