Menu
▾
▴
java-player-users
|
From: Raymond S. <rsh...@ra...> - 2006-02-07 08:08:59
|
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
|
|
From: Radu B. R. <ru...@cs...> - 2006-02-07 18:12:29
Attachments:
smime.p7s
javaclient.camera.patch
|
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
>
|
|
From: Raymond S. <rsh...@ra...> - 2006-02-08 00:46:51
|
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:
===================
<...>
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 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).
Any ideas as to where to look?
Cheers!
- Raymond
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 ());
> }
>
|
|
From: Radu B. R. <ru...@cs...> - 2006-02-08 09:45:59
Attachments:
smime.p7s
|
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
|
|
From: Raymond S. <rsh...@ra...> - 2006-02-08 12:20:37
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X