Open fbottarel opened 5 years ago
Hi @fbottarel , did you try to run the same test on both cameras?!?! if yes, i guess it is not hardware related but mainly software - firmware related, if not please do so and if it is just present in one camera, maybe the flat ribbon cable is damaged. Always in the case of your answer is YES, please try to launch the same test on green iCub, does it make the same thing? I would recommend you to talk to @barbalberto or @Nicogene about that.
Probably the black line is present also in the 640x480
image but it is too small to be seen since the resolution is higher.
It seems not a resolution-dependent problem, dragonfly2
device is pretty old and nobody changed since a while. The only thing changed are how the images are handled in yarp
(move semantics etc).
Unfortunately in these day I am at Erzelli. A check good check as @julijenv suggested is to visualize the image 320x240 on the green iCub.
@julijenv both cameras exhibit the same behaviour. I will test this on the green icub as soon as they are done with their tests today.
@Nicogene both resolutions feature the corruption. The corruption disappears if press the "Reset Camera" button in the FrameGrabberGui, and the camera goes back to a 640x480 resolution (but with no bayer encoding?!)
Also: I dumped some frames with yarpdatadumper
and the corrupted pixels are still there -> yarpview
is not the problem.
Update: camCalib
seems to be the culprit here. Here you can see images streamed from the raw camera feed and from camCalib
. The top left of the images streamed from camCalib
seems to be corrupted.
@Nicogene halp pls
So i think we can say that it is a software problem then I will move the issue in icub-main
It would be useful to know if it is reproducible also with usbCamera
(I guess yes) and if it affects icub-main
on master
or devel
branch.
I tryed with latest devel
both icub-main
and yarp
and the image look fine also 320x240 using the usbCamera
.
Could be the bayer? cc @barbalberto
I can get some raw image dumps and try on my laptop before updating the robot machines.
Usually those artifacts happens when the header is considered has part of the image, probably there is some byte alignment issue with the Bayer coding.
I thought we used Bayer encoding only for streaming 640x480 images, does that also happen for lower res?
Just to confirm, that I observed a similar or same problem. In my case the "flickering bar" is not at the very top and broader than what is depicted in the gifs above. I am using Bayer encoding here as recommended in the Wiki.
When trying to produce the gifs for this entry, once it ended up being as bad as in the following, but one one occasion no flickering bar at all occurred:
Description of the failure
Black lines started showing up at the top of the image streams
Detailed conditions and logs of the failure
The Dragonfly cameras output this kind of video stream at 320x240 (image is magnified for better identification of the issue). The top rows of pixels seem corrupted.
By resetting the camera via the frameGrabberGui, the image goes back to default parameters (640x480 resolution) and the feed corruption seems no longer present.
Rebooting either the cameras, the pc104 or the whole robot does not solve the problem.