From: Radu B. R. <ru...@cs...> - 2006-02-08 09:45:59
|
Heya, Raymond Sheh wrote: > Hi 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. > > =================== > <...> > 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. > <...> > =================== > > 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. > 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. > > Cheers! > > - Raymond PS. If you use some messaging software, I might be able to help you directly in the evening (as I talk to Josh quite often on MSN, since that's when you guys wake up :). Cheers mate! Radu. > > At 05:28 PM 7/02/2006 +0100, you wrote: > >> Hey Reymond, >> (good to have you onboard!) >> >> I just checked the Camera interface, and you are right, it wasn't >> processing the images correctly. The fix was trivial though (I might >> have missed it since my tests were done with cameras with very low >> resolution). >> >> Basically you need to modify CameraInterface.java and replace the >> following two lines (in readData()): >> - for (int i = 0; i < PLAYER_CAMERA_IMAGE_SIZE; i++) >> - image[i] = (byte)is.readUnsignedByte (); /* >> compressed image data */ >> with: >> + int totalBytes = 13; >> + int bytes; >> + while (totalBytes < this.size) >> + { >> + // read the compressed image data >> + bytes = is.read (image, totalBytes - 13, >> this.size - totalBytes); >> + totalBytes += bytes; >> + } >> >> I have also attached a patch (use patch -p1 < >> javaclient.camera.patch) to this e-mail, and have also commited these >> changes to the CVS SF repository. Please, if possible, use the >> Javaclient HEAD (from CVS) - see instructions at >> http://sourceforge.net/cvs/?group_id=135304 - and Player 1.6.5. >> >> Ah, I also added an example on how to use the Camera to our examples >> web page (http://java-player.sourceforge.net/examples.php). >> >> P.S. No need to use cam.readData() if you run the client in threaded >> mode (runThreaded...). >> >> PPS. I just discovered a bug in the non-threaded version of the >> client, so please, if possible, use in threaded mode at all times >> until I get a chance to fix it. >> >> Cheers, >> Radu. >> >> -- >> | Radu Bogdan Rusu | http://rbrusu.com/ >> | http://www9.cs.tum.edu/people/rusu/ >> | Intelligent Autonomous Systems >> | Technische Universitaet Muenchen >> >> >> Raymond Sheh wrote: >> >>> Hi all! >>> >>> I'm trying to get CameraInterface working, much like Sunny was (list >>> email 2005-09-15, can't figure out how to reply to the same thread >>> since I just joined). I'm getting really weird things coming in and >>> it looks like things are getting somewhat mixed up. This is before I >>> even try to decode the image - the headers look a little messed up. >>> >>> Here's my code, basically a gutted version of SpaceWandererExample: >>> >>> =============== >>> public class Blah >>> { >>> public static void main (String[] args) >>> { >>> PlayerClient interlink = new >>> PlayerClient("192.168.1.10", 6665); >>> CameraInterface cam = >>> interlink.requestInterfaceCamera(1, 'r'); >>> interlink.runThreaded (-1, -1); >>> try { Thread.sleep (1000); } catch (Exception e) { } >>> while (true) >>> { >>> cam.readData(); >>> System.out.println("Got data\n"); >>> System.out.println("Camera size is " + >>> cam.getWidth() + "/" + cam.getHeight()); >>> } >>> } >>> } >>> =============== >>> >>> Here's the output I get: >>> =============== >>> $ java Blah >>> Player v.1.6.4 >>> [PlayerClient] : Got response for device 40(cameracompress) with >>> access: r >>> [PlayerClient] : Unknown message type received in read() >>> [PlayerClient] : Unknown message type received in read() >>> [PlayerClient] : Unknown message type received in read() >>> [PlayerClient] : Unknown message type received in read() >>> [PlayerClient] : Unknown message type received in read() >>> [PlayerClient] : Unknown message type received in read() >>> [PlayerClient] : Unknown message type received in read() >>> [PlayerClient] : Unknown message type received in read() >>> Got data >>> >>> Camera size is 5121/6898 >>> [PlayerClient] : Unknown message type received in read() >>> [PlayerClient] : Unknown message type received in read() >>> Got data >>> >>> Camera size is -2647/-9978 >>> [PlayerClient] : Unknown message type received in read() >>> <...> >>> =============== >>> Funnily enough, the program seems to block for a long time at the >>> line "cam.readData();" (generally the "Got data" line appears after >>> a long pause). >>> >>> I'm sure the Player server side of things works - we have another >>> Player client that connects via the standard C++ interface libraries >>> and it seems to behave nicely. The camera itself is the standard V4L >>> driver hooked through CameraCompress (but the same thing happens >>> when I direct Player to any of the other cameras on our robots). >>> >>> >>> Anyone have any ideas as to what might be happening? I notice the >>> documentation says something about this interface not being intended >>> for server-client, what does that actually mean in terms of >>> useability? Radu, what did you have to do when you dived into the >>> player driver as you mentioned in your reply to Sunny's email? >>> >>> >>> Cheers! >>> >>> - Raymond >> >> >> >> >> diff -r -u javaclient-cvs/CameraInterface.java >> javaclient/CameraInterface.java >> --- javaclient-cvs/CameraInterface.java 2005-06-01 21:05:47.000000000 >> +0200 >> +++ javaclient/CameraInterface.java 2006-02-07 16:50:56.000000000 >> +0100 >> @@ -17,7 +17,7 @@ >> * along with this program; if not, write to the Free Software >> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA >> 02111-1307 USA >> * >> - * $Id: CameraInterface.java,v 1.3 2005/06/01 19:05:47 veedee Exp $ >> + * $Id: CameraInterface.java,v 1.6 2006/02/07 15:50:56 veedee Exp $ >> * >> */ >> package javaclient; >> @@ -31,6 +31,7 @@ >> * @author Radu Bogdan Rusu >> * @version >> * <ul> >> + * <li>v1.6.5 - bug fixes (image data was corrupted previously) >> * <li>v1.6.3 - Player 1.6.3 (all interfaces) supported >> * <li>v1.6.2 - Player 1.6.2 supported, Javadoc documentation, >> several bugfixes >> * </ul> >> @@ -99,8 +100,15 @@ >> fdiv = (short)is.readUnsignedShort (); /* scale >> divisor */ >> compression = (byte)is.readUnsignedByte (); /* image >> compression status */ >> image_size = is.readInt (); /* size >> of image data */ >> - for (int i = 0; i < PLAYER_CAMERA_IMAGE_SIZE; i++) >> - image[i] = (byte)is.readUnsignedByte (); /* >> compressed image data */ >> + >> + int totalBytes = 13; >> + int bytes; >> + while (totalBytes < this.size) >> + { >> + // read the compressed image data >> + bytes = is.read (image, totalBytes - 13, >> this.size - totalBytes); >> + totalBytes += bytes; >> + } >> } catch (Exception e) { >> System.err.println ("[Camera] : Error when reading >> payload: " + e.toString ()); >> } >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Java-player-users mailing list > Jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-player-users -- | Radu Bogdan Rusu | http://rbrusu.com/ | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |