[ros-users] [Pr2-users] How to calibrate camera_synchronizer_node?

Blaise Gassend blaise at willowgarage.com
Thu Sep 23 19:44:01 UTC 2010


The robot I tested on is running 2.6.31.12-rt21. Sirq-net-rx using up
around 10% CPU is normal as an "idle" robot is streaming about 500Mbps
of camera data.

I talked to Derek King, and from what he tells me, you should not be
seeing any dropped packets in the Ethercat Master, certainly not a few
times per second. Are you seeing dropped ethercat packets in the
diagnostics?

2010/9/23 Lorenz Mösenlechner <moesenle at in.tum.de>:
> 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
>> <blaise at willowgarage.com> 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 at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>
> --
> Lorenz Mösenlechner            | moesenle at 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
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>



More information about the ros-users mailing list