java-player-users — General discussions on how to use Javaclient

Re: [Java-player-users] Using latest Javaclient with Player 1.6.4

[Radu B. R. <ru...@cs...>]

Hey Josh,

Yup, I'm talking about Player 2.0.

I've been coding the 2.x interfaces for the last couple of days (I was 
about to start a thread here and on playerstage-users/developers *IF* we 
actually need a Java client anymore, provided that we can generate - to 
a certain extent - some basic functionality via SWIG), and it seems like 
the whole thing is getting close to release. How close it's hard to 
say... if it would be my call, we'd all work together to finish the damn 
thing until the end of the week, so we can all mind our AI/robotics 
high-level research afterwards. :) As about SWIG, don't get me 
started... I'm not the most prolific Java coder out there, but looking 
over some generated SWIG code (Yuck!) is what actually made me start 
porting Javaclient 1.6.5 to 2.0 anyway. :)

Besides, what's the point of having a Java client, if you link against a 
system library, thus being unable to just copy a JAR nicely and use it 
on whatever operating system you want (JVM-enabled)?

What interfaces would you need for your class? I can make sure that we 
finish working on those first.

I will also send a mail to ps-developers and jump in to help them finish 
2.0 sooner. I was too busy with other stuff until now to actually do 
something in that direction.

You *could* also still use Player/Javaclient 1.6.5, which should still 
work nicely. Make a list of whatever interfaces you are going to use, 
hardware (drivers) and simulators, and we can look to see if they are 
bug-free.

Cheers,
Radu.

Josh Beitelspacher wrote:

>Radu,
>
>Thanks for the quick response.  How soon is soon?  I'm the teaching
>assistant for a class that is going to be using Javaclient, but I
>don't want to have to start with the current version and then switch
>everyone over.
>
>When you say 2.x API, are you still using Player 1.6.5, or the beta Player 2.0?
>
>Thanks,
>Josh
>
>On 2/13/06, Radu Bogdan Rusu <ru...@cs...> wrote:
>  
>
>>Hey Josh,
>>
>>Yes, Javaclient from CVS should work nicely with 1.6.4 (although I
>>always test against 1.6.5 and latest 1.6.5 CVSed).
>>
>>I am currently wrapping up the last classes for Javaclient2, and I think
>>that we should all concentrate our efforts of testing/developing and
>>using on the 2.x API.
>>
>>I will have a beta version soon online. Any requests ? (I will integrate
>>Gareth's exception patches)
>>
>>Btw, functions like the ones above (from AudioMixerInterface) will be
>>obsolete. Instead you will just get something like:
>>
>>AudioMixerInterface ami = request...
>>ami.getLevels (); // request a PLAYER_AUDIOMIXER_GET_LEVELS
>>... // wait in a loop
>>if (isConfigReady ())
>>  PlayerAudiomixerConfig pac = ami.getConfig ();
>>
>>... and then access pac.getMaster_left, pac.getMaster_right,
>>pac.getPcm_left...etc
>>
>>So basically all the Player structures will be accessible directly from
>>now on using get/set methods. I think this will ease things a lot.
>>
>>Some feedback would be nice :)
>>
>>Cheers,
>>Radu.
>>    
>>
>
>
>-------------------------------------------------------
>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=k&kid3432&bid#0486&dat1642
>_______________________________________________
>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

Re: [Java-player-users] Using latest Javaclient with Player 1.6.4

[Josh B. <jo...@ne...>]

Radu,

Thanks for the quick response.  How soon is soon?  I'm the teaching
assistant for a class that is going to be using Javaclient, but I
don't want to have to start with the current version and then switch
everyone over.

When you say 2.x API, are you still using Player 1.6.5, or the beta Player =
2.0?

Thanks,
Josh

On 2/13/06, Radu Bogdan Rusu <ru...@cs...> wrote:
> Hey Josh,
>
> Yes, Javaclient from CVS should work nicely with 1.6.4 (although I
> always test against 1.6.5 and latest 1.6.5 CVSed).
>
> I am currently wrapping up the last classes for Javaclient2, and I think
> that we should all concentrate our efforts of testing/developing and
> using on the 2.x API.
>
> I will have a beta version soon online. Any requests ? (I will integrate
> Gareth's exception patches)
>
> Btw, functions like the ones above (from AudioMixerInterface) will be
> obsolete. Instead you will just get something like:
>
> AudioMixerInterface ami =3D request...
> ami.getLevels (); // request a PLAYER_AUDIOMIXER_GET_LEVELS
> ... // wait in a loop
> if (isConfigReady ())
>   PlayerAudiomixerConfig pac =3D ami.getConfig ();
>
> ... and then access pac.getMaster_left, pac.getMaster_right,
> pac.getPcm_left...etc
>
> So basically all the Player structures will be accessible directly from
> now on using get/set methods. I think this will ease things a lot.
>
> Some feedback would be nice :)
>
> Cheers,
> Radu.

Re: [Java-player-users] Using latest Javaclient with Player 1.6.4

[Radu B. R. <ru...@cs...>]

Hey Josh,

Yes, Javaclient from CVS should work nicely with 1.6.4 (although I 
always test against 1.6.5 and latest 1.6.5 CVSed).

I am currently wrapping up the last classes for Javaclient2, and I think 
that we should all concentrate our efforts of testing/developing and 
using on the 2.x API.

I will have a beta version soon online. Any requests ? (I will integrate 
Gareth's exception patches)

Btw, functions like the ones above (from AudioMixerInterface) will be 
obsolete. Instead you will just get something like:

AudioMixerInterface ami = request...
ami.getLevels (); // request a PLAYER_AUDIOMIXER_GET_LEVELS
... // wait in a loop
if (isConfigReady ())
  PlayerAudiomixerConfig pac = ami.getConfig ();

... and then access pac.getMaster_left, pac.getMaster_right, 
pac.getPcm_left...etc

So basically all the Player structures will be accessible directly from 
now on using get/set methods. I think this will ease things a lot.

Some feedback would be nice :)

Cheers,
Radu.

Josh Beitelspacher wrote:

>Is it possible to use the latest version of Javaclient from CVS with
>Player 1.6.4?  It seems that I'd loose a lot of recent bug fixes by
>going back to an old version of Javaclient, but I don't know if this
>combination will cause me any problems.
>
>Also, I've noticed that the HEAD revision in CVS generates several
>"the field is never read locally" errors in Eclipse.  A few of these
>are actually bugs cause by a trivial oversight when copying and
>pasting:
>
>Index: javaclient/AudioMixerInterface.java
>===================================================================
>--- javaclient/AudioMixerInterface.java
>+++ javaclient/AudioMixerInterface.java (working copy)
>@@ -148,11 +148,11 @@
>     public synchronized int getMasterLeft  () { return masterLeft;  }
>     public synchronized int getMasterRight () { return masterRight; }
>     public synchronized int getPCMLeft     () { return pcmLeft;     }
>-    public synchronized int getPCMRight    () { return pcmLeft;     }
>+    public synchronized int getPCMRight    () { return pcmRight;     }
>     public synchronized int getLineLeft    () { return lineLeft;    }
>-    public synchronized int getLineRight   () { return lineLeft;    }
>+    public synchronized int getLineRight   () { return lineRight;    }
>     public synchronized int getMicLeft     () { return micLeft;     }
>-    public synchronized int getMicRight    () { return micLeft;     }
>+    public synchronized int getMicRight    () { return micRight;     }
>     public synchronized int getIGain       () { return iGain;       }
>     public synchronized int getOGain       () { return oGain;       }
> }
>
>
>Thanks,
>Josh
>  
>

-- 
| Radu Bogdan Rusu | http://rbrusu.com/
| http://www9.cs.tum.edu/people/rusu/
| Intelligent Autonomous Systems
| Technische Universitaet Muenchen

[Java-player-users] Using latest Javaclient with Player 1.6.4

[Josh B. <jj_...@ou...>]

Is it possible to use the latest version of Javaclient from CVS with
Player 1.6.4?  It seems that I'd loose a lot of recent bug fixes by
going back to an old version of Javaclient, but I don't know if this
combination will cause me any problems.

Also, I've noticed that the HEAD revision in CVS generates several
"the field is never read locally" errors in Eclipse.  A few of these
are actually bugs cause by a trivial oversight when copying and
pasting:

Index: javaclient/AudioMixerInterface.java
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- javaclient/AudioMixerInterface.java
+++ javaclient/AudioMixerInterface.java (working copy)
@@ -148,11 +148,11 @@
     public synchronized int getMasterLeft  () { return masterLeft;  }
     public synchronized int getMasterRight () { return masterRight; }
     public synchronized int getPCMLeft     () { return pcmLeft;     }
-    public synchronized int getPCMRight    () { return pcmLeft;     }
+    public synchronized int getPCMRight    () { return pcmRight;     }
     public synchronized int getLineLeft    () { return lineLeft;    }
-    public synchronized int getLineRight   () { return lineLeft;    }
+    public synchronized int getLineRight   () { return lineRight;    }
     public synchronized int getMicLeft     () { return micLeft;     }
-    public synchronized int getMicRight    () { return micLeft;     }
+    public synchronized int getMicRight    () { return micRight;     }
     public synchronized int getIGain       () { return iGain;       }
     public synchronized int getOGain       () { return oGain;       }
 }


Thanks,
Josh

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 

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

[Radu B. R. <ru...@cs...>]

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

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

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

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 ());
>          }
>

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

[Radu B. R. <ru...@cs...>]

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
>

[Java-player-users] More JavaClient camera woes

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

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

[Java-player-users] Re: [Java-player-developers] Need to propagate exceptions, not hide them.

[Radu B. R. <ru...@cs...>]

Hi Gareth,

Got your mail. Thanks ;) I will look at it and try to include the 
changes asap.

I just posted the RFID patch to 
http://www9.cs.tum.edu/people/rusu/playerstage/ and sent a message to 
the ps mailing lists. If anybody has problems running it or building 
Javaclient applications that use the RFIDInterface, please let me know.

Best regards,
Radu.

Gareth Randall wrote:

>Note to list:
>
>I've sent Radu a GNU tar.gz of my changes.
>
>This is what I've done:
>
>1. Changed all occurrences of catch(Exception e) to only catch the
>specific exception that can be thrown.
>
>2. Changed all cases of catch(Exception e) followed by a
>System.err.println to throw an exception instead. The caller can log
>the exception if desired.
>
>3. Rewrote dangerous catching of NullPointerException.
>
>4. Handled InterruptedException in Thread methods.
>
>Yours,
>
>Gareth Randall
>  
>

-- 
| Radu Bogdan Rusu | http://rbrusu.com/
| http://www9.cs.tum.edu/people/rusu/
| Intelligent Autonomous Systems
| Technische Universitaet Muenchen

[Java-player-users] Re: [Java-player-developers] Need to propagate exceptions, not hide them.

[Gareth R. <g_j...@ya...>]

Note to list:

I've sent Radu a GNU tar.gz of my changes.

This is what I've done:

1. Changed all occurrences of catch(Exception e) to only catch the
specific exception that can be thrown.

2. Changed all cases of catch(Exception e) followed by a
System.err.println to throw an exception instead. The caller can log
the exception if desired.

3. Rewrote dangerous catching of NullPointerException.

4. Handled InterruptedException in Thread methods.

Yours,

Gareth Randall



		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

[Java-player-users] Re: [Java-player-developers] Need to propagate exceptions, not hide them.

[Radu B. R. <ru...@cs...>]

Hey Gareth,

Thanks. I know that all Javaclient users will appreciate this. :)

I am slowly preparing to start coding the diffs for handling Player 2.0. 
In the meantime, I have coded a new interface (RFID) for Player and the 
appropriate code for Javaclient and the C/C++ client. I will post the 
patches here and on my web page as soon as possible, and with a little 
bit of luck, I shall be able to convince Brian to merge them with the 
Player2 repo, once it's stabilized. Right now I am handling two brands 
of RFID readers, but I'm sure that once the code is out, people will add 
support for their own.

If anyone here is working with RFID and has any requests on what this 
interface should contain, please speak now. For beginning, I'm adding 
Select and then Read/Write support to the tags, but we might make use of 
encryption functions later too, if anybody needs them (Inside readers 
have a bunch of techniques for that).

PS. Gareth, you might want to CC e-mails related to this subject to 
java-player-users@sf, since I know for a fact that some of our users 
aren't subscribed to -developers, and vice-versa. Thanks.

Best regards,
Radu.

-- 
| Radu Bogdan Rusu | http://rbrusu.com/
| http://www9.cs.tum.edu/people/rusu/
| Intelligent Autonomous Systems
| Technische Universitaet Muenchen


Gareth Randall wrote:

>Hi Radu,
>
>I'll see what I can do over the next 2 weeks, and send CVS diffs :-)
>
>Does anyone on the list have views as to whether exceptions arising
>from calling javaclient methods should be checked or unchecked
>exceptions?
>
>Most of the issues that are being caught look rather serious -
>sufficiently serious that most callers of the code will not want to try
>to handle them. E.g. if something is serious enough for you to be
>calling System.exit(1) then it's unlikely that a client will be able to
>recover !
>
>This suggests that they should be unchecked (i.e. extend
>RuntimeException). If a caller really wants to then they can catch
>them, but otherwise they need not be burdened with the extra code.
>
>A further argument for unchecked comes from SQLException. One of the
>(many) criticisms of "java.sql.SQLException" is that most database
>errors are simply unrecoverable without human intervention, and that
>there is no point in a caller being forced to catch them. This argument
>seems to apply to javaclient.
>
>
>Unchecked is best unless someone can think of a compelling reason
>otherwise.
>
>Yours,
>
>Gareth Randall
>  
>

[Java-player-users] how to use MComInterface?

[<tig...@ho...>]

hi,
 everyone!
 If there are two robots(rb1,rb2) and rb1 want to send a message to rb2,how 
to do? 
                                                             Thunder
                                                           2005.12.20

_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。  http://www.hotmail.com  

Re: [Java-player-users] using camera interface

[Paul O. <new...@ki...>]

Radu Bogdan Rusu wrote:
> Hi Paul,
> 
> I haven't really dealt with applets, but it should be pretty 
> straightforward. After all, you need to instantiate an object of type 
> CameraInterface, and then use the awt graphics to display the results in 
> the applet image.
I was guessing it must be done that way, but my problem was with awt: I 
didn't know how to display image that comes from memory, not from URL or 
a file. Another problem was with jpeg compression, since all video 
sources I have are compressed. Finally I have found JPEG codec in SUN 
Java documentation that creates BufferedImage object which is easy to 
show. I have attached example applet (which can also be used as a plain 
application since I have prepared main() method). Unfortunately, there's 
a big problem with it: it works much too slow. I have realised that the 
most time consuming method is readAll() (to realise this I had to use 
non-threaded implementation).
Also, to use this class as an applet in web browser I had to remove all 
(two) calls to System.getProperty in PlayerClient.java (it causes 
Permission Denied exception).
> I was thinking that since you've already done enough work for 
> Player/Stage, maybe you would like to contribute something for our 
> Javaclient community as well.
Well... I'm not saying yes nor not. I had to use Java for one particular 
project (simple demo for vlab.pjwstk.edu.pl) and I don't know if I write 
something more in near future. I guess Javaclient will be included in 
our project, since we plan that our users would be able to upload their 
programs written in many different languages and run them on our server 
to operate our robots that way.
> I am also thinking about talking to Brian 
> and see if there is a way to actually "insert" Javaclient directly into 
> P/S at some point. Or use SWIG to generate some basic functionality and 
> then extend it with the stuff that we've already done.
In my opinion, all bindings (including Javaclient and guileplayer) 
should be included to main Player distribution.
This would lead to better usability of whole thing.
Best regards,
Paul

Re: [Java-player-users] problems using blobfinder

[Radu B. R. <ru...@cs...>]

Hi Alberto,

The segmentation fault is on Player side. Hopefully v2.0 will not be 
that "picky" on this little details. :)

I am not sure if the Gazebo part (changing the tracked color on the fly) 
is implemented. I know for a fact that it works fine with a CMUcam2 
camera connected to Player, so it might be that the Gazebo driver is not 
supporting it properly.

I'll have a look at Stage today and report later.

Cheers,
Radu.

-- 
| Radu Bogdan Rusu | http://rbrusu.com/
| http://www9.cs.tum.edu/people/rusu/
| Intelligent Autonomous Systems
| Technische Universitaet Muenchen


Alberto Amengual wrote:

> Hi Radu,
>
> Thanks a lot, now it works. If you have a minute to briefly explain 
> the threading trick, that'd be great. Or maybe you can point me to 
> some doc.
>
> A couple of notes:
>
> * I had to do the request for the blobfinder interface in mode 'r', 
> mode 'a' causes a segmentation fault, so
> "BlobFinderInterface bfi = robot.requestInterfaceBlobfinder(0, 'r');"
>
> * I have tried to track a particular color, but it didn't work. For 
> example for orange:
> "bfi.setTrackingColor(255,255,128,128,0,0)" but the blobs are still 
> the same as without that line. I mean that's no big problem, then I 
> just have to go through the blobs and look for the orange one. 
> Probably that line is not enough, because on the client I get a "Need 
> to handle a EAR message", and on the server "PlayerQueue::Push(): 
> trying to push from non-allocated queue".
>
> Best,
>
> Alberto
>
>
> Radu Bogdan Rusu wrote:
>
>> Hello Alberto,
>>
>> Sorry for replying so late (hmm, looks like I'm the only one actually 
>> doing that on this mailing list :)). I just uploaded a basic 
>> Blobfinder example to the Javaclient examples web page. Maybe that 
>> will help.
>>
>> Please modify your source code according to the following guidelines, 
>> and try again:
>> - before the while (true), add a line like "robot.runThreaded (-1, -1);"
>> - remove the "bfi.readData();" from the main while loop;
>> - add a delay such as "try { Thread.sleep (100); } catch (Exception 
>> e) { }" in the main while loop.
>>
>> I don't know about Gazebo, but I will have a look.
>>
>> Best regards,
>> Radu.
>>
>
>
>
>
> -------------------------------------------------------
> 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Java-player-users mailing list
> Jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-player-users

Re: [Java-player-users] problems using blobfinder

[Alberto A. <ame...@IC...>]

Hi Radu,

Thanks a lot, now it works. If you have a minute to briefly explain the 
threading trick, that'd be great. Or maybe you can point me to some doc.

A couple of notes:

* I had to do the request for the blobfinder interface in mode 'r', mode 
'a' causes a segmentation fault, so
"BlobFinderInterface bfi = robot.requestInterfaceBlobfinder(0, 'r');"

* I have tried to track a particular color, but it didn't work. For 
example for orange:
"bfi.setTrackingColor(255,255,128,128,0,0)" but the blobs are still the 
same as without that line. I mean that's no big problem, then I just 
have to go through the blobs and look for the orange one. Probably that 
line is not enough, because on the client I get a "Need to handle a EAR 
message", and on the server "PlayerQueue::Push(): trying to push from 
non-allocated queue".

Best,

Alberto


Radu Bogdan Rusu wrote:

> Hello Alberto,
> 
> Sorry for replying so late (hmm, looks like I'm the only one actually 
> doing that on this mailing list :)). I just uploaded a basic Blobfinder 
> example to the Javaclient examples web page. Maybe that will help.
> 
> Please modify your source code according to the following guidelines, 
> and try again:
> - before the while (true), add a line like "robot.runThreaded (-1, -1);"
> - remove the "bfi.readData();" from the main while loop;
> - add a delay such as "try { Thread.sleep (100); } catch (Exception e) { 
> }" in the main while loop.
> 
> I don't know about Gazebo, but I will have a look.
> 
> Best regards,
> Radu.
> 

Re: [Java-player-users] using camera interface

[Radu B. R. <ru...@cs...>]

Hi Paul,

I haven't really dealt with applets, but it should be pretty 
straightforward. After all, you need to instantiate an object of type 
CameraInterface, and then use the awt graphics to display the results in 
the applet image.

The "installation" of javaclient is easy... just copy javaclient.jar or 
the classes provided with the source package and use them wherever you 
want.

I was thinking that since you've already done enough work for 
Player/Stage, maybe you would like to contribute something for our 
Javaclient community as well. I am also thinking about talking to Brian 
and see if there is a way to actually "insert" Javaclient directly into 
P/S at some point. Or use SWIG to generate some basic functionality and 
then extend it with the stuff that we've already done.

Best regards,
Radu.

-- 
| Radu Bogdan Rusu | http://rbrusu.com/
| http://www9.cs.tum.edu/people/rusu/
| Intelligent Autonomous Systems
| Technische Universitaet Muenchen


Paul Osmialowski wrote:

> Hello Everyone!
> I'm new here and I have two questions.
> 1. I'd like to write an applet that shows image from subscribed Camera 
> device. This device will provide compressed (JPEG) image. What is the 
> best way to show this in my applet? I'd like to use standard awt widgets.
> 2. Javaclient package does not provide any installation script. What 
> is the best way to perform system-wide installation?
>
> Cheers,
> Paul

[Java-player-users] using camera interface

[Paul O. <new...@ki...>]

Hello Everyone!
I'm new here and I have two questions.
1. I'd like to write an applet that shows image from subscribed Camera 
device. This device will provide compressed (JPEG) image. What is the 
best way to show this in my applet? I'd like to use standard awt widgets.
2. Javaclient package does not provide any installation script. What is 
the best way to perform system-wide installation?

Cheers,
Paul

Re: [Java-player-users] problems using blobfinder

[Radu B. R. <ru...@cs...>]

Hello Alberto,

Sorry for replying so late (hmm, looks like I'm the only one actually 
doing that on this mailing list :)). I just uploaded a basic Blobfinder 
example to the Javaclient examples web page. Maybe that will help.

Please modify your source code according to the following guidelines, 
and try again:
- before the while (true), add a line like "robot.runThreaded (-1, -1);"
- remove the "bfi.readData();" from the main while loop;
- add a delay such as "try { Thread.sleep (100); } catch (Exception e) { 
}" in the main while loop.

I don't know about Gazebo, but I will have a look.

Best regards,
Radu.

-- 
| Radu Bogdan Rusu | http://rbrusu.com/
| http://www9.cs.tum.edu/people/rusu/
| Intelligent Autonomous Systems
| Technische Universitaet Muenchen


Alberto Amengual wrote:

> Hello everybody,
>
> This is the first time I am using javaclient and also Player/Gazebo. I 
> am trying to detect a blue cylinder using blobfinder, but it's not 
> working. I don't know if my problem is the way I am using the java 
> client, or might be related with the color file in cmvision, or other 
> things.
>
> In the world file, I have a Pioneer2AT robot with a SonyVID30 camera, 
> and a couple of SimpleSolids, one of which is a cylinder, with 
> <color>0.0 0.0 1</color> (the others are not blue).
>
> Then, in the player file, I have
>
> driver
> (
>     name "gz_camera"
>     provides ["camera:0"]
>     gz_id "camera1"
> )
>
> driver
> (
>     name "cmvision"
>     provides ["blobfinder:0"]
>     requires ["camera:0"]
>     colorfile ["colorfile"]
> )
>
> The client code I am trying is:
>
> PlayerClient robot = new PlayerClient("localhost", 6665);
> BlobfinderInterface bfi = new robot.requestInterfaceBlobFinder(0,'r');
> short numBlobs = 0;
> bfi.setTrackingColor(0,0,0,0,250,255);
> while (true) {
>    bfi.readData();
>    numBlobs = bfi.getBlobCount();
>    System.out.println("num blobs="+numBlobs);
> }
>
> I get different values back for num blobs (0, 10, 88, 4608, ...), and 
> also sometimes in the client I get an "outofBounds" exception,
> "Error when reading payload: java.lang.ArrayIndexOutOfBoundsException: 
> 256", I guess that the number of "detected" blobs might be too big.
>
> Anybody can help???
>
>
>
> Many thanks,
>
> Alberto Amengual

[Java-player-users] problems using blobfinder

[Alberto A. <ame...@IC...>]

Hello everybody,

This is the first time I am using javaclient and also Player/Gazebo. I 
am trying to detect a blue cylinder using blobfinder, but it's not 
working. I don't know if my problem is the way I am using the java 
client, or might be related with the color file in cmvision, or other 
things.

In the world file, I have a Pioneer2AT robot with a SonyVID30 camera, 
and a couple of SimpleSolids, one of which is a cylinder, with 
<color>0.0 0.0 1</color> (the others are not blue).

Then, in the player file, I have

driver
(
     name "gz_camera"
     provides ["camera:0"]
     gz_id "camera1"
)

driver
(
     name "cmvision"
     provides ["blobfinder:0"]
     requires ["camera:0"]
     colorfile ["colorfile"]
)

The client code I am trying is:

PlayerClient robot = new PlayerClient("localhost", 6665);
BlobfinderInterface bfi = new robot.requestInterfaceBlobFinder(0,'r');
short numBlobs = 0;
bfi.setTrackingColor(0,0,0,0,250,255);
while (true) {
    bfi.readData();
    numBlobs = bfi.getBlobCount();
    System.out.println("num blobs="+numBlobs);
}

I get different values back for num blobs (0, 10, 88, 4608, ...), and 
also sometimes in the client I get an "outofBounds" exception,
"Error when reading payload: java.lang.ArrayIndexOutOfBoundsException: 
256", I guess that the number of "detected" blobs might be too big.

Anybody can help???



Many thanks,

Alberto Amengual

Re: [Java-player-users] multiclient?

[Radu B. R. <ru...@cs...>]

What do you mean by multiplayerclient ?

=C0=D7 =B1=F3 wrote:

> Everyone,
> Who knows how to create multiplayerclient use javaclient? If I want to
> create 10 clients,how should I to do ?
>
Cheers,
Radu.

--=20
| Radu Bogdan Rusu | http://rbrusu.com/
| http://www9.cs.tum.edu/people/rusu/
| Intelligent Autonomous Systems
| Technische Universitaet Muenchen

[Java-player-users] multiclient?

[<tig...@ho...>]

Everyone,
   Who knows how to create multiplayerclient use javaclient? If I want to 
create 10 clients,how should I to do ?

_________________________________________________________________
免费下载 MSN Explorer:   http://explorer.msn.com/lccn/  

Re: [Java-player-users] readAll necessary?

[Shane H. <sr...@ny...>]

Hi Radu -

> - runThreaded () calls read () automatically, as can be seen in this 
> snippet of code (3rd line of run ()):

Thanks for the illustration. 

>
> If you send me your piece of code, I can have a quick look at it 
> probably today or tomorrow (not THAT busy today :) and send you a 
> corrected version back. Who knows, maybe we discovered another bug in 
> FiducialInterface (I haven't really used it).

Thank you for the kind offer, but I needed to move on.  I'm working on a 
project that' imminently due, and have to do whatever I can to get the 
damn thing to work.  (I'm sure you know how that goes.)  The fiducial 
interface has been so frustrating I finally said to hell with it - I use 
it only to get a list of fiducials I can see, and I use the truth 
interface for everything else and write some code to make it sloppy.  
This is a long way from a pure solution but desperate times call for 
desperate measures. :)

> What I normally do is ... connect to Player, request the interfaces, 
> then start the client in threaded mode, and then I control the robot 
> in an infinite while loop (with the appropriate sleep of course).

Yup, that's what I'm doing too.  (What do you consider the appropriate 
sleep, btw?  Though it probably doesn't much matter in my case, since 
with a lot of robots competing for time the average sleep will be a lot 
longer than that specified...)

> Can you check the examples that I just uploaded to the Javaclient web 
> page please, and see if they can help?

I will do that in the future.  Thanks for your help; it's all the more 
impressive that you take the time to help people considering how many 
other obligations you must have.  It is very much appreciated.

Shane

Re: [Java-player-users] readAll necessary?

[Radu B. R. <ru...@cs...>]

Hey Shane,

- runThreaded () calls read () automatically, as can be seen in this 
snippet of code (3rd line of run ()):
    /**
     * Start a threaded copy of Javaclient.
     * @param millis number of miliseconds to sleep between calls
     * @param nanos number of nanoseconds to sleep between calls
     */
    public void runThreaded (long millis, int nanos) {
        if (isThreaded) {
            System.err.println ("[PlayerClient] : A second call for 
runThreaded, ignoring!");
            return;
        }
        this.millis = millis;
        this.nanos  = nanos;
        isThreaded  = true;
        this.start ();
    }
   
    /**
     * Start the Javaclient thread. Ran automatically from runThreaded ().
     */
    public void run () {
        try {
            while (isThreaded) {
                while (read () != PLAYER_MSGTYPE_SYNCH && isThreaded);
                if (millis < 0)
                    Thread.yield ();
                else
                    if (nanos <= 0)
                        Thread.sleep (millis);
                    else
                        Thread.sleep (millis, nanos);
            }
        } catch (Exception e) { e.printStackTrace (); }
    }
- setNotThreaded () just sets isThreaded to false, so you have to call 
readAll () manually:
    /**
     * Change the mode Javaclient runs to non-threaded.
     */
    public void setNotThreaded() {
        isThreaded = false;
    }
    /**
     * Read the Player server replies in non-threaded mode.
     */
    public void readAll () {
        if (isThreaded) return;
        while (read () != PLAYER_MSGTYPE_SYNCH);
    }

If you send me your piece of code, I can have a quick look at it 
probably today or tomorrow (not THAT busy today :) and send you a 
corrected version back. Who knows, maybe we discovered another bug in 
FiducialInterface (I haven't really used it).


What I normally do is ... connect to Player, request the interfaces, 
then start the client in threaded mode, and then I control the robot in 
an infinite while loop (with the appropriate sleep of course). Can you 
check the examples that I just uploaded to the Javaclient web page 
please, and see if they can help?


Cheers,
Radu.

Shane Hoversten wrote:

> Hey all -
>
> I've been confused for awhile about reading data using javaclient.  If 
> I do a runThreaded() do I ever need to explicitly readData()?  So far, 
> w/respect to sensors, things have mostly "just worked."  But now I'm 
> having these goofy intermittent problems (w/ fiducials again, of 
> course) where sometimes I get meaningful rotation readings, and 
> sometimes I get nothing.  There seems to be no rhyme or reason to how 
> this is working, and of course considering the series of problems I've 
> had with fiducials it could be just more of the same bugs that crop up 
> w/ 1.3.5.  But it strikes me that it could be something more fundamental.
>
> So - can someone give me a quick explanation of how and when to read 
> interface data?
>
> Thanks,
>
> Shane
>
>
> -------------------------------------------------------
> 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> 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

[Java-player-users] readAll necessary?

[Shane H. <sr...@ny...>]

Hey all -

I've been confused for awhile about reading data using javaclient.  If I 
do a runThreaded() do I ever need to explicitly readData()?  So far, 
w/respect to sensors, things have mostly "just worked."  But now I'm 
having these goofy intermittent problems (w/ fiducials again, of course) 
where sometimes I get meaningful rotation readings, and sometimes I get 
nothing.  There seems to be no rhyme or reason to how this is working, 
and of course considering the series of problems I've had with fiducials 
it could be just more of the same bugs that crop up w/ 1.3.5.  But it 
strikes me that it could be something more fundamental.

So - can someone give me a quick explanation of how and when to read 
interface data?

Thanks,

Shane