Hi Blaise, are you guys at Willow maybe running a newer kernel version? On our PR2, we have version 2.6.29.6-rt24 and top shows that processes like sirq-net-rx/6 eat up quite some cpu (up to 10%) on an idle robot. Lorenz > Hi Ulrich, > > I just did some tests on one of our robots, and it is rock solid, except for: > 1. glitches every few multiples of 10 seconds because of the trigger > controller refresh I got you to try taking out. > 2. glitches that coincide with ethercat dropping packets (you can see > this in the diagnostics for eth Ethercat Master, in the Motors > section. > > From the data you sent me, you are getting glitches that are not > related to case 1. Can you have a look to see if dropped packets are > being reported by the ethercat master diagnostics? > > Do these glitches occur even when the computers are under light load? > (Nothing running except robot.launch and the image viewers.) > > If you are dropping packets every few seconds under light load, then > there may be a problem with your robot, and I would recommend opening > a support ticket. > > Thanks, > Blaise > > On Thu, Sep 23, 2010 at 11:21 AM, Blaise Gassend > wrote: > > Hi Ulrich, > > > > I had a look at your bags, and I am noticing that there is a lot of > > oscillation in the image intensity. Auto-gain/exposure don't work well > > with alternating mode, and I would recommend switching them off. > > > >> Thomas Rühr could help me out -i could not be in the lab today - and > >> recorded two bags with a synchronization node including the code changes you > >> proposed. > > > > Thanks for the bags. I see in the textured an interval of 3 seconds > > between flashes. Is that interval always the same, or is it different > > each time? > > > > Can you confirm that both cameras have problems at the same time? > > > > From the times at which the images are being sent, it looks like there > > may be an extra or missing trigger pulse. I'm going to try to > > reproduce this on one of our robots... > > > > I wonder if you could send me a bag of the following topics: > > /head_camera_trigger/waveform, /projector_trigger/waveform, > > /head_camera_trigger/trigger_narrow_stereo_both, > > /projector_trigger/on_time, /projector_trigger/off_time, > > /narrow_stereo/left/camera_info, > > /narrow_stereo_textured/left/camera_info, > > /narrow_stereo/right/camera_info, > > /narrow_stereo_textured/right/camera_info. You can make this one > > pretty long, say a minute, as it is a lot less data. > > > >> Do you think, that is solvable at all? > > > > Hard to know until we know what the problem is. > > > >> Can the projector be switched on and > >> off instead of being modulated? > > > > The projector cannot be turned on continuously because it would > > overheat. It is limited to 2 ms pulses (I forget the exact duty > > cycle). You can of course turn it off all the time, but I don't see > > how that would help you if you need alternating mode. > > > > One last thing: if you want to be able to filter out the images that > > are having trouble, I believe that you can use the image timestamp. > > The timestamps should be totally periodic when things are working > > well. When you get the bad images, the interval between two images > > will be different from what it usually is. > > > > Cheers, > > Blaise > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > -- Lorenz Mösenlechner | moesenle@in.tum.de Technische Universität München | Boltzmannstr. 3 85748 Garching bei München | Germany http://ias.cs.tum.edu/ | Tel: +49 (89) 289-26910