java-player-users

[Java-player-users] Weird sonar issue -

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

Hi -

I'm just starting work with playerclient using stage 1.3.5 and I'm 
encountering some really bizarre sonar readings.  Here's a code snippet:

----
        ...
        SonarInterface si = pc.requestInterfaceSonar(0, 'r');
        ...
        while (yes == 1) {
            si.readData();
            int [] r = si.getRanges();
           
            System.out.println(r[0] + " " + r[1] + " " + r[2] + " " +
                                            r[3] + " " + r[4] + " " + r[5]);

            try { Thread.sleep(1000); }
            catch (InterruptedException e) {e.printStackTrace(); }
        }
----

As you can see, all it's doing is reading sonar and printing out the 
first six values.  The simulated robot that's executing this code is 
completely stationary.  And yet, here's a chunk of the readings:

----
5000 5000 5000 5000 5000 5000
5000 5000 5000 5000 5000 5000
34835 34835 34816 0 0 0
4115 34835 34835 34835 34835 34835
0 0 0 0 0 0
5000 5000 5000 5000 5000 5000
0 0 25 0 0 0
0 0 0 0 0 0
5000 5000 5000 5000 5000 5000
5000 5000 5000 5000 5000 5000
5000 5000 5000 5000 5000 5000
5000 5000 5000 5000 5000 5000
5000 5000 5000 5000 5000 5000
----

As you can see, I'm getting lots of weird bouncing around.  The robot is 
stationary, so the readings shouldn't change (especially since this 
example has the robot in the middle of empty space.)  When I execute the 
same program with the same stage world using the C++ client the readings 
are rock steady.

Does anyone know what's going on? Do I need to be checking the status of 
the sonar and waiting for it to be ready or something?  (Since there are 
virtually no examples available I'm doing this by looking at the c++ 
code that comes with player and trying to backport it.  Some real 
examples would be REALLY useful.)

Thanks,

Shane

Re: [Java-player-users] Weird sonar issue -

[Nils O. T. <no...@gm...>]

Hi Shane,
I guess its related to the way you poll your data from the sensor, try


pc.runThreaded (-1, -1);

in the initialization section end delete the si.readData() stuff. As far 
as I see from my working code its not necessary this way.


Hope this helps

Ole

Shane Hoversten wrote:
> Hi -
> 
> I'm just starting work with playerclient using stage 1.3.5 and I'm 
> encountering some really bizarre sonar readings.  Here's a code snippet:
> 
> ----
>        ...
>        SonarInterface si = pc.requestInterfaceSonar(0, 'r');
>        ...
>        while (yes == 1) {
>            si.readData();
>            int [] r = si.getRanges();
>                      System.out.println(r[0] + " " + r[1] + " " + r[2] + 
> " " +
>                                            r[3] + " " + r[4] + " " + r[5]);
> 
>            try { Thread.sleep(1000); }
>            catch (InterruptedException e) {e.printStackTrace(); }
>        }
> ----
> 
> As you can see, all it's doing is reading sonar and printing out the 
> first six values.  The simulated robot that's executing this code is 
> completely stationary.  And yet, here's a chunk of the readings:
> 
> ----
> 5000 5000 5000 5000 5000 5000
> 5000 5000 5000 5000 5000 5000
> 34835 34835 34816 0 0 0
> 4115 34835 34835 34835 34835 34835
> 0 0 0 0 0 0
> 5000 5000 5000 5000 5000 5000
> 0 0 25 0 0 0
> 0 0 0 0 0 0
> 5000 5000 5000 5000 5000 5000
> 5000 5000 5000 5000 5000 5000
> 5000 5000 5000 5000 5000 5000
> 5000 5000 5000 5000 5000 5000
> 5000 5000 5000 5000 5000 5000
> ----
> 
> As you can see, I'm getting lots of weird bouncing around.  The robot is 
> stationary, so the readings shouldn't change (especially since this 
> example has the robot in the middle of empty space.)  When I execute the 
> same program with the same stage world using the C++ client the readings 
> are rock steady.
> 
> Does anyone know what's going on? Do I need to be checking the status of 
> the sonar and waiting for it to be ready or something?  (Since there are 
> virtually no examples available I'm doing this by looking at the c++ 
> code that comes with player and trying to backport it.  Some real 
> examples would be REALLY useful.)
> 
> Thanks,
> 
> Shane
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Java-player-users mailing list
> Jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-player-users
> 
> 

Re: [Java-player-users] Weird sonar issue -

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

Hi Nils -

> I guess its related to the way you poll your data from the sensor, try
>
>
> pc.runThreaded (-1, -1);
>
> in the initialization section end delete the si.readData() stuff. As 
> far as I see from my working code its not necessary this way.

You don't need the readData stuff?  Really?  If you don't put that in 
then I assume the sensor just reads at some default frequency?

I have not yet been able to try runThreaded(-1, -1) as you suggest, but 
what I have found is that there appears to be some race conditions.  If 
I sleep for 500 milliseconds after si.readData() then the readings are 
sanet.  I would have expected readData() to block until it put something 
sensible in the range data, but perhaps that's not done for a reason.  
I'll try your suggestion tonight to see if I can get rid of my hack.

Thanks for your response,

Shane

[Java-player-users] Fiducial problems

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

Hi everyone -

I'm trying to get fiducials to work with stage 1.3.5, player 1.6.5, and 
the latest javaclient.  My worldfile seems to be ok, since on the stage 
GUI I can see the little numbers that come up when a fiducial comes in 
range of the laser finder, but just for reference here's a robot from 
the worldfile:

shane_pioneer( color "blue" name "robot1"
               port 6666 pose [3.753 7.901 -2.915 ]
          fiducial_id 88)


Here is the function that updates the fiducials:

    ///////////////////////////////////////////////   
    public void updateFid() {

        FiducialInterface fi = getFidInterface();
       
        int numFids = fi.getFiducialCount();
        boolean isReady = fi.isIDReady();
       
        pl("numFids is " + numFids + " isReady " + isReady);
       
        if (numFids > 0 && isReady == true) {
            PlayerFiducialItem[] fs = fi.getFiducials();
            for (PlayerFiducialItem fItem : fs) {
                if (fItem == null) {
                    pl("Null fi!");
                    break;
                } else {
                    pl (getName() + " fItem.id " + fItem.getID());
                }
            }
        }
    }

Here is an excerpt of what it outputs:

----
[Fiducial] : Error when reading payload: java.lang.NullPointerException
[Fiducial] : Error when reading payload: java.lang.NullPointerException
numFids is 2 isReady false
numFids is 2 isReady false
numFids is 2 isReady false
[Fiducial] : Error when reading payload: java.lang.NullPointerException
numFids is 2 isReady false
[Fiducial] : Error when reading payload: java.lang.NullPointerException
numFids is 2 isReady false
numFids is 2 isReady false
numFids is 2 isReady false
[Fiducial] : Error when reading payload: java.lang.NullPointerException
----

I'm at a loss for what's going on.  The numFids count is right - there 
are indeed two fiducial objects in range.  If I move the robot around 
and get it out of range - so that numFids is 0 - all these 
NullPointerExceptions go away.  (Note that these NullPointerException 
messages are coming in on stderr - it's javaclient generating them, not 
my code.)

It's weird that javaclient/player knows there are 2 fids, but none of 
them ever get returned, and isReady is always false.  (Note that if you 
take out the isReady == true test it prints out "Null fi!" every time - 
there's no fiducial info there.)

Does anyone have any clue about what's going on?  Advice of what I can 
try next?  Working code samples that show how to work with the fiducial 
interface?

Thanks a lot.

Shane

PS: In the interest of science, or karma, I'll donate all of my code to 
the javaclient project when I'm done with it, so newbies can have some 
working examples to look at.  It's been really frustrating that there's 
so little actual working code available that does anything, not just for 
javaclient but for player/stage in general.  I don't get it; this is 
open source, is it not?  We're all about sharing here?

[Java-player-users] Bug in FiducialInterface.java in javaclient 1.6.4

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

Hi -

In trying to figure out why Fiducials don't seem to work, I discovered a 
series of copy and paste bugs in FiducialInterface.java in the 
readData() function.  None of the fields in the PlayerFiducialItem get 
set except Pos, and that gets set several times to the wrong values.

Take a look, you'll see what I mean.  The fix is trivial.  Sadly this 
doesn't solve my problem, which I described yesterday, but maybe it can 
help somebody else.

The fact that nobody's complained about this implies that nobody is 
actually using fiducials with javaclient 1.6.4?  Weird.

Shane

[Java-player-users] Second bug in FiducialInterface.java in javaclient 1.6.4

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

Hi -

I solved my problem.  There was a second bug in javaclient.  In the 
constructor for FiducialInterface you have to add:

    for (int i = 0; i < PLAYER_FIDUCIAL_MAX_SAMPLES; i++) {
        fiducials[i] = new PlayerFiducialItem();
    }

The space for the array was being allocated, but the elements of the 
array were not.

Things seem to work now, by which I mean the robot will run without 
javaclient crashing and the fiducials will output data.  Perhaps there 
are more bugs.

Shane

Re: [Java-player-users] Second bug in FiducialInterface.java in javaclient 1.6.4

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

Hey Shane,

Wow, you were really fast at reporting, identifying and correcting the 
problem. :) Sorry, but I just managed to read my e-mail. I wish I could 
have done it sooner to help you out.

Anyway, it seems that you got that one sorted out. Can you please send 
me a diff file so I can commit it to the CVS repository ?

Yes, I totally agree that we should have more examples on how to use 
Player/Stage with or without Javaclient. I am willing to help anyone who 
wants to write some with technical aspects, but I just don't seem to 
have the time to sit down and do it myself :(

We could also use ideas and/or code contributions for the other parts of 
the client.

PS. I just realized that I have some old hacked code lying around on 
some of my web pages. Maybe it could be useful for any of you who are 
using Javaclient and want to get into neural networks as well (Joone). 
The source codes are really crappy because I had to move and didn't get 
around to fix them, but if somebody wants to actually clean them up, we 
could post them on the Javaclient examples web page (which is empty 
right now - I think). Anyway, the URL for the source codes (including a 
small tutorial) is 
http://www.robotux.info/ai/included/read.php?cat=neural&article=Radu%20Bogdan%20Rusu_On%20Data%20Fusion%20Methods%20Using%20Neural%20Networks,%20From%20a%20Practical%20Implementation%20POV


Thanks,
Radu.

Shane Hoversten wrote:

>
> Hi -
>
> I solved my problem.  There was a second bug in javaclient.  In the 
> constructor for FiducialInterface you have to add:
>
>    for (int i = 0; i < PLAYER_FIDUCIAL_MAX_SAMPLES; i++) {
>        fiducials[i] = new PlayerFiducialItem();
>    }
>
> The space for the array was being allocated, but the elements of the 
> array were not.
>
> Things seem to work now, by which I mean the robot will run without 
> javaclient crashing and the fiducials will output data.  Perhaps there 
> are more bugs.
>
> Shane
>
-- 
| Radu Bogdan Rusu
| http://rbrusu.com
| http://www9.cs.tum.edu/people/rusu
| Intelligent Autonomous Systems
| Technische Universitaet Muenchen

[Java-player-users] More fiducial interface problems

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

Hi everyone -

Back to fiducials.  When I call FiducialInterface.getViewAngle() and 
getMax() and getMin() I'm always getting zeroes.  Looking at the code I 
see that all of these things start off as zero and are updated when 
handleResponse() gets the PLAYER_FIDUCIAL_GET_FOV msg.  This msg is 
presumably received in reponse to the PLAYER_FIDUCIAL_GET_FOV msg which 
is generated by the call to getFOV().  Right?  Or is this another cut 
and paste error?  Should these both be the same msg?

To put it another way: I call getFOV() but the P_F_G_F msg is never 
received in response, and so javaclient never updates the values.  Am I 
doing something wrong, or is this a bug?

Thanks for any help,

Shane

Re: [Java-player-users] More fiducial interface problems

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

Hi Shane,

The configuration request/reply mechanism in the Player server works 
like this:
- first you send a configuration request of type PLAYER_MSGTYPE_REQ 
(PLAYER_FIDUCIAL_GET_FOV in our case) to Player
- then Player will reply back with a message of type 
PLAYER_MSGTYPE_RESP_ACK (if everything went ok) or 
PLAYER_MSGTYPE_RESP_NACK otherwise

FiducialInterface.getFOV () sends a configuration request with 
PLAYER_FIDUCIAL_GET_FOV. The reply of the Player server is caught by 
PlayerClient.read (), which in turn will call 
FiducialInterface.handleResponse () if the type of the messaged that 
returned is ACK. FiducialInterface.handleResponse () checks to see if 
the reply came back for the configuration request 
PLAYER_FIDUCIAL_GET_FOV, and then it fills in those attributes with 
their appropriate values.

The order of operations for your program should be:
- getFOV ();
- check if isFOVReady () is true
- if fovReady is true, then get the values you need using getMinRage (), 
getMaxRange () and getViewAngle ().

In case you send the request but you do not get any reply back, it could 
be an internal Player problem. But it's okay, we can have a look there 
as well, to see what the problem is.

I hope this helps,
Radu.

Shane Hoversten wrote:

> Hi everyone -
>
> Back to fiducials.  When I call FiducialInterface.getViewAngle() and 
> getMax() and getMin() I'm always getting zeroes.  Looking at the code 
> I see that all of these things start off as zero and are updated when 
> handleResponse() gets the PLAYER_FIDUCIAL_GET_FOV msg.  This msg is 
> presumably received in reponse to the PLAYER_FIDUCIAL_GET_FOV msg 
> which is generated by the call to getFOV().  Right?  Or is this 
> another cut and paste error?  Should these both be the same msg?
>
> To put it another way: I call getFOV() but the P_F_G_F msg is never 
> received in response, and so javaclient never updates the values.  Am 
> I doing something wrong, or is this a bug?
>
> Thanks for any help,
>
> Shane


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

Re: [Java-player-users] More fiducial interface problems

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

Hi Radu -

Thanks for the quick and thorough response.

> The configuration request/reply mechanism in the Player server works 
> like this:
> - first you send a configuration request of type PLAYER_MSGTYPE_REQ 
> (PLAYER_FIDUCIAL_GET_FOV in our case) to Player
> - then Player will reply back with a message of type 
> PLAYER_MSGTYPE_RESP_ACK (if everything went ok) or 
> PLAYER_MSGTYPE_RESP_NACK otherwise

It looks like the second case is what's happening - after I send the 
PLAYER_FIDUCIAL_GET_FOV via getFOV() something apparently goes awry; 
PlayerDevice .handleNARMessage() gets called.  So something is 
apparently going wrong, but no real error msg gets printed, just "Need 
to handle a NAR message." 

Output in my stage simulator gave me an error message, so I dug through 
the stage source code and found that requests are processed in 
fiducialfinderdevice.cc, in the UpdateConfig function.  It appears that 
Stage 1.3.5 only handles the PLAYER_FIDUCIAL_GET_GEOM msg, not the 
GET_FOV msg getFOV() is sending.

I assume from this that the getFOV() sort of functionality is only 
supported in editions of Stage later than 1.3.5?

Shane

I started digging through the player/stage code and found that it

Do you know where I might be able to trace   gets some sort of

>
> FiducialInterface.getFOV () sends a configuration request with 
> PLAYER_FIDUCIAL_GET_FOV. The reply of the Player server is caught by 
> PlayerClient.read (), which in turn will call 
> FiducialInterface.handleResponse () if the type of the messaged that 
> returned is ACK. FiducialInterface.handleResponse () checks to see if 
> the reply came back for the configuration request 
> PLAYER_FIDUCIAL_GET_FOV, and then it fills in those attributes with 
> their appropriate values.
>
> The order of operations for your program should be:
> - getFOV ();
> - check if isFOVReady () is true
> - if fovReady is true, then get the values you need using getMinRage 
> (), getMaxRange () and getViewAngle ().
>
> In case you send the request but you do not get any reply back, it 
> could be an internal Player problem. But it's okay, we can have a look 
> there as well, to see what the problem is.
>
> I hope this helps,
> Radu.
>
> Shane Hoversten wrote:
>
>> Hi everyone -
>>
>> Back to fiducials.  When I call FiducialInterface.getViewAngle() and 
>> getMax() and getMin() I'm always getting zeroes.  Looking at the code 
>> I see that all of these things start off as zero and are updated when 
>> handleResponse() gets the PLAYER_FIDUCIAL_GET_FOV msg.  This msg is 
>> presumably received in reponse to the PLAYER_FIDUCIAL_GET_FOV msg 
>> which is generated by the call to getFOV().  Right?  Or is this 
>> another cut and paste error?  Should these both be the same msg?
>>
>> To put it another way: I call getFOV() but the P_F_G_F msg is never 
>> received in response, and so javaclient never updates the values.  Am 
>> I doing something wrong, or is this a bug?
>>
>> Thanks for any help,
>>
>> Shane
>
>
>

Re: [Java-player-users] More fiducial interface problems

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

Hi Shane,

Shane Hoversten wrote:

> Hi Radu -
>
> Thanks for the quick and thorough response.

No problem. My pleasure.

>> The configuration request/reply mechanism in the Player server works 
>> like this:
>> - first you send a configuration request of type PLAYER_MSGTYPE_REQ 
>> (PLAYER_FIDUCIAL_GET_FOV in our case) to Player
>> - then Player will reply back with a message of type 
>> PLAYER_MSGTYPE_RESP_ACK (if everything went ok) or 
>> PLAYER_MSGTYPE_RESP_NACK otherwise
>
>
> It looks like the second case is what's happening - after I send the 
> PLAYER_FIDUCIAL_GET_FOV via getFOV() something apparently goes awry; 
> PlayerDevice .handleNARMessage() gets called.  So something is 
> apparently going wrong, but no real error msg gets printed, just "Need 
> to handle a NAR message."
> Output in my stage simulator gave me an error message, so I dug 
> through the stage source code and found that requests are processed in 
> fiducialfinderdevice.cc, in the UpdateConfig function.  It appears 
> that Stage 1.3.5 only handles the PLAYER_FIDUCIAL_GET_GEOM msg, not 
> the GET_FOV msg getFOV() is sending.
>
> I assume from this that the getFOV() sort of functionality is only 
> supported in editions of Stage later than 1.3.5?

Yes, as far as I know it got supported in Stage 1.6. Any reason not to 
upgrade to 2.0a?

>
> Shane
>
> I started digging through the player/stage code and found that it
>
> Do you know where I might be able to trace   gets some sort of
>
Did something happen to your message here? All i got are these truncated 
phrases.

Cheers,
Radu.

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

Re: [Java-player-users] More fiducial interface problems

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

Hi Radu -

> Yes, as far as I know it got supported in Stage 1.6. Any reason not to 
> upgrade to 2.0a?

Unfortunately, yes - my project requires pucks and grippers, some of 
which aren't included in versions after 1.3.5.   After all the problems 
I've had it's turning out that it might have been easier just to 
implement them in 2.0.

...

> Did something happen to your message here? All i got are these 
> truncated phrases.

Yup, bad editing on my part.

Thanks again for the responses.  I'm trying something different to get 
around the crippled fiducials in 1.3.5, hopefully it will be a smoother 
path.

Shane

Re: [Java-player-users] More fiducial interface problems

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

Shane Hoversten wrote:

> Hi Radu -

Hey Shane,

>> Yes, as far as I know it got supported in Stage 1.6. Any reason not 
>> to upgrade to 2.0a?
>
>
> Unfortunately, yes - my project requires pucks and grippers, some of 
> which aren't included in versions after 1.3.5.   After all the 
> problems I've had it's turning out that it might have been easier just 
> to implement them in 2.0.
>
> ...

I see. I remember reading something on playerstage-developers about 
Stage and grippers. Either Richard said that he will implement them 
soon, or someone else already did a quick patch for that. If I am wrong 
though, it shouldn't be too hard to "port" them from 1.3.5 to 2.0.


>> Did something happen to your message here? All i got are these 
>> truncated phrases.
>
>
> Yup, bad editing on my part.
>
> Thanks again for the responses.  I'm trying something different to get 
> around the crippled fiducials in 1.3.5, hopefully it will be a 
> smoother path.
>
> Shane

No problemos Shane. Anytime.

Radu.

-- 
| 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

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

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