Re: [Java-player-users] More JavaClient camera woes

[Raymond S. <rsh...@ra...>]

Hey Radu,


>>Thanks for that! It seems to be working a lot more sensibly now ... I can 
>>get images coming through nicely but the problem is every now and again I 
>>get warnings from the server side:
>
>Yup, that always happens (even with the C client).. mostly because the 
>packets are way too big to be transmitted over the network. Player 
>actually tries to send the whole thing as one big packet (write()).. 
>especially if you enable-bigmess. Up until 1.6.4, the server would 
>actually segfault because it was trying to allocate too much memory 
>(stack), but it was fixed in the CVS later. Now it will just spit those 
>warnings but it will still work as it should.
>
>If possible, can you try the following?
>- get player 1.6.5 from CVS:
>$ cvs -z3 -d:pserver:ano...@cv...:/cvsroot/playerstage login
>$ cvs -z3 -d:pserver:ano...@cv...:/cvsroot/playerstage co 
>-r release-1-6-5 player
>- compile
>$ cd player/ ; ./bootstrap ; ./compile [--whatever you want]; make
>- get Javaclient 1.6.5 and apply the patch from yesterday, or get it from 
>CVS directly (same as for player).
>
>... and see if you still run into problems with that combination.

Hmm ... OK I'll try that, we're still on 1.6.4 ... actually I've just 
remembered that we did hack some stuff in our version of Player (in 
addition to enable-bigmess) to change how it dealt with big messages in an 
attempt to stop some segfaulting, maybe there's an interaction with that 
(if I'm not mistaken, we implemented a similar sort of fix to the later 
version of Player).




>>===================
>><...>
>>warning : 21117 bytes leftover on write() to client
>>warning : 50498 bytes leftover on write() to client
>>warning : 10374 bytes leftover on write() to client
>>warning : 3077 bytes leftover on write() to client
>><...>
>>===================
>>
>>When I get these, the images have varying degrees of corruption and often 
>>they're also associated with the client giving the error:
>>
>>===================
>><...>
>>[PlayerClient] : Unknown message type received in read()
>
>This is the part that troubles me, as this *shouldn't* happen, unless 
>something else is screwed up. Can you explain a little bit more about your 
>set up, and maybe send the snippets of code that doesn't work? That would 
>speed things up in fixing the issue. Oh, also send one or two images that 
>get corrupted, maybe I can understand what's going on better there.

Hmm ... strange thing ... I just tried to recreate the problem and the 
error messages went away! I'll be sure to save a snapshot of my setup next 
time I see it happen ...

I'm still getting image corruption though, and it seems worse when I run in 
a tight loop (both in terms of severity and frequency - if I call it 
occasionally like every second or so I might lose the last row or 2 of 
blocks every 5 or 6 captures but otherwise it seems to work beautifully). 
I've put a zipfile of my code (basically your CameraExample.java with a 
couple of modifications) and a few sample images up at 
http://raybot.cse.unsw.edu.au/cameraexample-corruptimages.zip (around 2MB) 
if you want to have a look. Frame 19 is the first uncorrupted image in that 
sequence. My version of JavaClient is straight from your website with the 
exception of the modifications you posted. The source is the camerav4l 
driver (set to 640x480 and attached to a Logitec QuickCam Pro) being passed 
through the cameracompressed driver. Apologies for the uninteresting scene :-)

I might also try running in a tight loop with our C++ client - how does the 
Player server react if it keeps getting a pile of requests? It occurs to me 
this may be the server side freaking out due to the high frequency of 
requests. Still, I don't recall any corruption using our normal client when 
we run at 5fps though (and I can't find any looking back through our 
archives) ... *shrug*

The other thing that makes me think this might be possibly an interaction 
between something in JavaClient and the server (and in particular 
CameraCompress) is that we've got another camera on the robot that's 
feeding raw grayscale values (the SwissRanger), I haven't tried running 
that in a tight loop but I haven't noticed any corruption at all on that 
stream running it a few times a second (when at the same time I've been 
getting minor corruption on the CameraCompress stream). The interesting 
thing is that the raw grayscale images are about 4 times bigger than the 
JPEGs coming off cameracompress. This is all quite weird ...




>><...>
>>===================
>>
>>This tends to happen less if I use the CameraCompress driver rather than 
>>the v4l driver (and modify the file handling code at the client end 
>>appropriately) presumably because the data size is smaller but it seems 
>>to still happen every now and again (especially if the data size is above 
>>about 55k or so).
>
>With the patch I sent you yesterday, it shouldn't matter how big the data 
>size is.

I'll try and check with the later version of Player and double check our 
modifications ... now that I think of that, there's a chance those might be 
causing some weirdness (although from memory it should be an all-or-nothing 
thing - I wouldn't have expected it to corrupt the images like that). But 
first I must sleep - I'm having trouble tapping the keys in a coherent 
pattern! :-D



>>Any ideas as to where to look?
>
>Can you also try the small test with Gazebo to see if you get the same 
>thing? If Gazebo doesn't work, then it's something related to your set up.

Ugh! OK ... never set up Gazebo before (and I'm running Cygwin) ... wish me 
luck! :-)


Thanks!

- Raymond