java-player-developers — Developers list

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

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

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

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

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



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

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

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

Hi Gareth,

First of all, thanks for the e-mail. Your idea sounds rather good, and I 
think it should be put somewhere on the top "to do" things for the next 
version of Javaclient, including the ability to handle Player 2.0.

However, I'm a bit caught up with another research project at the 
moment, and I can't really do much coding for Javaclient, at least until 
Player 2.0 is officially out. I was wondering if you would like to 
implement the exception handling yourself, with help from me, or any 
other members of the community. I can be at your disposal with 
information about the Javaclient internal structures, provided that you 
need any.

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,
>
>I notice from reading your code that you do not handle exceptions in a
>safe way. Serious errors need to reported to whatever code is using
>this client. If execution cannot continue because of an outright
>failure, that needs to be "admitted" immediately while the execution
>flow is still near to the problem, not glossed over by catching the
>exception :-) For instance, in:
>java-player/javaclient/PlayerDevice.java revision 1.4, you do this:
>
>    protected synchronized void readHeader() {
>        try {
>            t_sec    = is.readInt ();
>[snip]
>        } catch (Exception e) {
>            System.err.println ("[PlayerDevice] : Error when reading
>header: " + e.toString ());
>        }
>    }
>
>If any exception occurs then mysterious failures will occur later in
>the application with little indication as to what caused them. The
>"rules" in Java are:
>
>1. Throw checked exceptions for conditions that the caller could
>reasonably be expected to handle e.g. java.io.FileNotFoundException.
>Wouldn't it be bad if a method hid this exception and a user only found
>out much later that their data hadn't been processed correctly?
>
>2. Throw unchecked exception for programming errors or conditions that
>are completely unrecoverable. e.g. A
>java.lang.NegativeArrayIndexException is normally end of program - it
>is clearly the fault of the programmer.
>
>3. Don't "catch Exception" - it's too broad and you might catch
>something that should be propagated back to the caller.
>
>
>>From these rules, I would rewrite this method (and all the others), to
>throw a custom exception e.g. PlayerException.
>
>    protected synchronized void readHeader() throws PlayerException {
>        try {
>            t_sec    = is.readInt ();
>            t_usec   = is.readInt ();
>            ts_sec   = is.readInt ();
>            ts_usec  = is.readInt ();
>            reserved = is.readInt ();
>            size     = is.readInt ();
>        } catch (IOException e)  // Only one that we need to catch
>        {
>            // Allow the caller to handle this exception, if it can,
>and store the cause.
>            throw new PlayerException("[PlayerDevice] : Error when
>reading header", e);
>        }
>    }
>
>Personally, from what I've seen so far of the code I'd make the
>PlayerException a checked exception, i.e. public class PlayerException
>extends Exception. That's because it looks to me like reestablishing a
>connection would be a sensible way in which a client could recover
>(i.e. there is a way). However, that will change the published API (for
>the better). If you instead make it an unchecked exception then it will
>extend RuntimeException.
>
>
>As it currently stands I think that this exception hiding is a
>significant limitation of the library, but if you're using Eclipse, as
>you've said you are, then I don't think this will take too long to
>refactor and will provide real benefits :-)
>
>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
>
>
>-------------------------------------------------------
>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-developers mailing list
>Jav...@li...
>https://lists.sourceforge.net/lists/listinfo/java-player-developers
>  
>

[Java-player-developers] Need to be propagate exceptions, not hide them.

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

Hi,

I notice from reading your code that you do not handle exceptions in a
safe way. Serious errors need to reported to whatever code is using
this client. If execution cannot continue because of an outright
failure, that needs to be "admitted" immediately while the execution
flow is still near to the problem, not glossed over by catching the
exception :-) For instance, in:
java-player/javaclient/PlayerDevice.java revision 1.4, you do this:

    protected synchronized void readHeader() {
        try {
            t_sec    = is.readInt ();
[snip]
        } catch (Exception e) {
            System.err.println ("[PlayerDevice] : Error when reading
header: " + e.toString ());
        }
    }

If any exception occurs then mysterious failures will occur later in
the application with little indication as to what caused them. The
"rules" in Java are:

1. Throw checked exceptions for conditions that the caller could
reasonably be expected to handle e.g. java.io.FileNotFoundException.
Wouldn't it be bad if a method hid this exception and a user only found
out much later that their data hadn't been processed correctly?

2. Throw unchecked exception for programming errors or conditions that
are completely unrecoverable. e.g. A
java.lang.NegativeArrayIndexException is normally end of program - it
is clearly the fault of the programmer.

3. Don't "catch Exception" - it's too broad and you might catch
something that should be propagated back to the caller.


From these rules, I would rewrite this method (and all the others), to
throw a custom exception e.g. PlayerException.

    protected synchronized void readHeader() throws PlayerException {
        try {
            t_sec    = is.readInt ();
            t_usec   = is.readInt ();
            ts_sec   = is.readInt ();
            ts_usec  = is.readInt ();
            reserved = is.readInt ();
            size     = is.readInt ();
        } catch (IOException e)  // Only one that we need to catch
        {
            // Allow the caller to handle this exception, if it can,
and store the cause.
            throw new PlayerException("[PlayerDevice] : Error when
reading header", e);
        }
    }

Personally, from what I've seen so far of the code I'd make the
PlayerException a checked exception, i.e. public class PlayerException
extends Exception. That's because it looks to me like reestablishing a
connection would be a sensible way in which a client could recover
(i.e. there is a way). However, that will change the published API (for
the better). If you instead make it an unchecked exception then it will
extend RuntimeException.


As it currently stands I think that this exception hiding is a
significant limitation of the library, but if you're using Eclipse, as
you've said you are, then I don't think this will take too long to
refactor and will provide real benefits :-)

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-developers] Javaclient 1.6.5 released

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

Hellos,

Thanks to our users, Javaclient 1.6.5 is up at SF 
(http://sourceforge.net/project/showfiles.php?group_id=135304). The 
latest changes from the CVS repository have been integrated in the 
package. Some of the most recent changes were:
- A bug was fixed in the PlannerInterface (PlayerPlannerWaypointT was 
created but not initialized);
- Added getHypothCount () for LocalizeInterface;
- Several bugs were fixed in FiducialInterface (thanks to Shane 
Hoversten from NYU);
- Added setAllowedError (int err) to HeadingControl and PositionControl, 
as well as support for debugging mode.

Because of the overwhelming requests for examples, I've put together a 
couple of them (yesterday night and this morning) and uploaded them on 
SourceForge.
They should work fine with Javaclient 1.6.5, Player 1.6.5 and Stage 
2.0.0a. You can check them out at 
http://java-player.sourceforge.net/examples.php. As usual, comments are 
welcome :)

Cheers,
Radu.

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

[Java-player-developers] Javaclient class diagram

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

Hallo,

I've added two big jpeg files to the documentation page of Javaclient
(http://java-player.sourceforge.net/documentation.php). One of them is an
attempt to build a UML class architectural scheme of the project, and the
other is just a list of the Javaclient users (I built it using information
from this mailing list and Google). 

I would appreciate any help for updating the users list. A short e-mail with
the research group/institution where you work, university/company and
country should suffice.

Thanks a lot!

Yours sincerely,
Radu Bogdan Rusu
--
| Radu Bogdan Rusu | http://www.rbrusu.com
| Intelligent Autonomous Systems Group
| Technische Universitaet Muenchen

Re: [Java-player-developers] Fixes for the FiducialInterface

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

Done. Commited. Thanks. :)

Cheers,
Radu.

On Thu, Aug 11, 2005 at 01:43:40AM -0700, Moshe Sayag wrote:
> Here it is again
> 
> 1. The items of the array of the fiducials were never
> created so every access to them resulted in NPE.
> 
> 2. Due to a poor copy&paste setPos(...) was used
> everywhere instead of the appropriate methods (such as
> setRot(...) )
> 
> 3. Erroneous loop indexing (i and j were used wrongly)
> 
> Moshe
> 
> > 
> > Hi Moshe,
> > 
> > Can you please send me the fixes again? I moved from
> > the Technical 
> > University of Cluj-Napoca, Romania to the Technical
> > University of Munich 
> > in Germany, and I cannot seem to access my old
> > account anymore.
> > 
> > As soon as I get it I will have a look at it and
> > then submit it to the CVS.
> > 
> > Thanks! :)
> 
> 
> 		
> ____________________________________________________
> Start your day with Yahoo! - make it your home page 
> http://www.yahoo.com/r/hs 
>  
Content-Description: 2734622341-FiducialInterface.java
> /*
>  *  Player Java Client - FiducialInterface.java
>  *  Copyright (C) 2002-2005 Maxim A. Batalin & Radu Bogdan Rusu
>  *
>  *
>  *  This program is free software; you can redistribute it and/or modify
>  *  it under the terms of the GNU General Public License as published by
>  *  the Free Software Foundation; either version 2 of the License, or
>  *  (at your option) any later version.
>  *
>  *  This program is distributed in the hope that it will be useful,
>  *  but WITHOUT ANY WARRANTY; without even the implied warranty of
>  *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>  *  GNU General Public License for more details.
>  *
>  *  You should have received a copy of the GNU General Public License
>  *  along with this program; if not, write to the Free Software
>  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>  *
>  * $Id: FiducialInterface.java,v 1.4 2005/05/25 21:55:48 veedee Exp $
>  *
>  */
> package javaclient;
> 
> import javaclient.structures.PlayerFiducialItem;
> 
> /**
>  * The fiducial interface provides access to devices that detect coded fiducials 
>  * (markers) placed in the environment. It can also be used for devices the 
>  * detect natural landmarks.
>  * @author Maxim A. Batalin, Radu Bogdan Rusu & Moshe Sayag
>  * @version
>  * <ul>
>  *      <li>v1.6.4 - Player 1.6.4 bug fixes
>  *      <li>v1.6.3 - Player 1.6.3 (all interfaces) supported
>  *      <li>v1.6.2 - Player 1.6.2 supported, Javadoc documentation, several bugfixes  
>  *      <li>v1.5a &nbsp;- Player 1.5 supported (most popular devices)
>  * </ul>
>  */
> public class FiducialInterface extends PlayerDevice {
> 
>     private static final boolean isDebugging = PlayerClient.isDebugging;
> 
>     /* fiducial detector */
>     private final short PLAYER_FIDUCIAL_CODE = PlayerClient.PLAYER_FIDUCIAL_CODE;
> 
>     /* the player message types (see player.h) */
>     private static final short PLAYER_MSGTYPE_REQ = PlayerClient.PLAYER_MSGTYPE_REQ;
> 
>     /** The maximum number of fiducials that can be detected at one time */ 
>     public static final short PLAYER_FIDUCIAL_MAX_SAMPLES = 32;
>     /** The maximum size of a data packet exchanged with a fiducial at one time */ 
>     public static final short PLAYER_FIDUCIAL_MAX_MSG_LEN = 32;
> 
>     /* request packet subtypes */ 
>     protected final short PLAYER_FIDUCIAL_GET_GEOM     = 1;
>     protected final short PLAYER_FIDUCIAL_GET_FOV      = 2;
>     protected final short PLAYER_FIDUCIAL_SET_FOV      = 3;
>     protected final short PLAYER_FIDUCIAL_SEND_MSG     = 4;
>     protected final short PLAYER_FIDUCIAL_RECV_MSG     = 5;
>     protected final short PLAYER_FIDUCIAL_EXCHANGE_MSG = 6;
>     protected final short PLAYER_FIDUCIAL_GET_ID       = 7;
>     protected final short PLAYER_FIDUCIAL_SET_ID       = 8;
> 
>     /* the number of detected fiducials */
>     private int count; 
>     /* list of detected fiducials */
>     private PlayerFiducialItem[] fiducials = new PlayerFiducialItem[PLAYER_FIDUCIAL_MAX_SAMPLES];
>     
>     /* pose of the detector in the robot cs (x, y, orient) in units if (mm, mm, degrees) */ 
>     private int[] detectPose    = new int[3];
>     /* size of the detector in units of (mm, mm) */
>     private int[] detectSize    = new int[2];
>     /* dimensions of the fiducials in units of (mm, mm) */
>     private int[] fiducial_size = new int[2];
>     
>     private boolean geometryReady, fovReady, idReady;
>     
>     /* the minimum and maximum ranges of the sensor in mm */
>     private int minRange, maxRange;
>     /* the receptive angle of the sensor in degrees */
>     private int viewAngle;
>     
>     private int id;     /* the value displayed */
>     
>     /**
>      * Constructor for FiducialInterface.
>      * @param pc a reference to the PlayerClient object
>      * @param indexOfDevice the index of the device
>      */
>     public FiducialInterface (PlayerClient pc, short indexOfDevice) {
>         super(pc);
>         device    = PLAYER_FIDUCIAL_CODE;
>         index     = indexOfDevice;
>         
>         // create the new items
>         for (int i = 0; i < fiducials.length; i++) {
>             fiducials[i] = new PlayerFiducialItem();
>         }
>     }
> 
>     /**
>      * Read the fiducial data packet (all fiducials).
>      */
>     public synchronized void readData () {
>         readHeader ();
>         try {
>             count = is.readUnsignedShort ();        /* the number of detected fiducials */ 
>             for (int i = 0; i < count; i++) {
>                 /* the fiducial id */
>                 fiducials[i].setID (is.readShort ());
>                 
>                 int[] pos  = new int[3];
>                 for (int j = 0; j < 3; j++) {
>                     pos[j] = is.readInt ();         /* fiducial position */
>                 }
>                 fiducials[i].setPos (pos);
>                 
>                 int[] rot  = new int[3];
>                 for (int j = 0; j < 3; j++)
>                     rot[j] = is.readInt ();         /* fiducial orientation */
>                 fiducials[i].setRot (rot);
>                 
>                 int[] upos = new int[3];
>                 for (int j = 0; j < 3; j++)
>                     upos[j] = is.readInt ();        /* uncertainty in the measured pose */
>                 fiducials[i].setUPos (upos);
>                 
>                 int[] urot = new int[3];
>                 for (int j = 0; j < 3; j++)
>                     urot[j] = is.readInt ();        /* uncertainty in fiducial orientation */
>                 fiducials[i].setURot (urot);
>             }
>         } catch (Exception e) {
>             System.err.println ("[Fiducial] : Error when reading payload: " + e.toString ());
>         }
>     }
>    
>     /**
>      * Configuration request: Get geometry.
>      * <br><br>
>      * See the player_fiducial_geom structure from player.h
>      */
>     public void getGeometry () {
>         try {
>             sendHeader (PLAYER_MSGTYPE_REQ, 1);     /* 1 byte payload */
>             os.writeByte (PLAYER_FIDUCIAL_GET_GEOM);
>             os.flush ();
>         } catch (Exception e) {
>             System.err.println ("[Fiducial] : Couldn't send PLAYER_FIDUCIAL_GET_GEOM " +
>                     "command: " + e.toString ());
>         }
>     }
> 
>     /**
>      * Handle acknowledgement response messages (threaded mode).
>      * @param size size of the payload
>      */
>     public void handleResponse (int size) {
>         if (size == 0) {
>             if (isDebugging)
>                 System.err.println ("[Fiducial][Debug] : Unexpected response of size 0!");
>             return;
>         }
>         try {
>             /* each reply begins with a uint8_t subtype field */
>             byte subtype = is.readByte ();
>             switch (subtype) {
>                 case PLAYER_FIDUCIAL_GET_GEOM: {
>                     /* pose of the detector in the robot cs (x, y, orient) 
>                      * in units if (mm, mm, degrees) */ 
>                     for (int i = 0; i < 3; i++)
>                         detectPose[i] = is.readShort ();
>                     
>                     /* size of the detector in units of (mm, mm) */
>                     for (int i = 0; i < 2; i++)
>                         detectSize[i] = is.readUnsignedShort ();
>                     
>                     /* dimensions of the fiducials in units of (mm, mm) */
>                     for (int i = 0; i < 2; i++)
>                         fiducial_size[i] = is.readUnsignedShort ();
>                     
>                     geometryReady = true;
>                     break;
>                 }
>                 case PLAYER_FIDUCIAL_GET_FOV: {
>                     /* the minimum range of the sensor in mm */
>                     minRange  = is.readUnsignedShort ();
>                     
>                     /* the maximum range of the sensor in mm */
>                     maxRange  = is.readUnsignedShort ();
>                     
>                     /* the receptive angle of the sensor in degrees */
>                     viewAngle = is.readUnsignedShort ();
>                     
>                     fovReady = true;
>                 	break;
>                 }
>                 case PLAYER_FIDUCIAL_SET_FOV: {
>                 	break;
>                 }
>                 case PLAYER_FIDUCIAL_GET_ID: {
>                 	id = is.readInt ();    /* the value displayed */
> 
>                     idReady = true;
>                     break;
>                 }
>                 default:{
>                     System.err.println ("[Fiducial] : Unexpected response " + subtype + 
>                             " of size = " + size);
>                     break;
>                 }
>             }
>         } catch (Exception e) {
>             System.err.println ("[Fiducial] : Error when reading payload " + e.toString ());
>         }
>     }
>     
>     /**
>      * Check if geometry data is available.
>      * @return true if ready, false if not ready 
>      */
>     public boolean isGeomReady () {
>         if (geometryReady) {
>             geometryReady = false;
>             return true;
>         }
>         return false;
>     }
>     
>     /**
>      * Get the pose of the detector in the robot cs (x, y, orient) 
>      * in units if (mm, mm, degrees).
>      * @return an array of integers filled with the pose of the detector 
>      */
>     public synchronized int[] getDetectPose () { return detectPose; }
> 
>     /**
>      * Get the size of the detector in units of (mm, mm).
>      * @return the size of the detector in units of (mm, mm) as an integer array.
>      */
>     public synchronized int[] getDetectSize () { return detectSize; }
> 
>     /**
>      * Get the dimensions of the fiducials in units of (mm, mm).
>      * @return the dimensions of the fiducials in units of (mm, mm) as an integer
>      * array.
>      */
>     public synchronized int[] getFiducialSize () { return fiducial_size; }
>     
>     /**
>      * Configuration request: Get sensor field of view.
>      * <br><br>
>      * The field of view of the fiducial device can be set using the 
>      * PLAYER_FIDUCIAL_SET_FOV request, and queried using the 
>      * PLAYER_FIDUCIAL_GET_FOV request. The device replies to a SET request 
>      * with the actual FOV achieved. In both cases the request and reply 
>      * packets have the same format.
>      * <br><br>
>      * See the player_fiducial_fov structure from player.h
>      */
>     public void getFOV () {
>         try {
>             sendHeader (PLAYER_MSGTYPE_REQ, 1);     /* 1 byte payload */
>             os.writeByte (PLAYER_FIDUCIAL_GET_FOV);
>             os.flush ();
>         } catch (Exception e) {
>             System.err.println ("[Fiducial] : Couldn't send PLAYER_FIDUCIAL_GET_FOV " +
>                     "command: " + e.toString ());
>         }
>     }
>     
>     /**
>      * Check if FOV data is available.
>      * @return true if ready, false if not ready 
>      */
>     public boolean isFOVReady () {
>         if (fovReady) {
>             fovReady = false;
>             return true;
>         }
>         return false;
>     }
> 
>     /**
>      * Get the minimum range of the sensor in mm.
>      * @return the minimum range of the sensor in mm as an integer
>      */
>     public synchronized int getMinRange () { return minRange; }
> 
>     /**
>      * Get the maximum range of the sensor in mm.
>      * @return the maximum range of the sensor in mm as an integer
>      */
>     public synchronized int getMaxRange () { return maxRange; }
>     
>     /**
>      * Get the receptive angle of the sensor in degrees.
>      * @return the receptive angle of the sensor in degrees as an integer
>      */
>     public synchronized int getViewAngle () { return viewAngle; }
>     
>     /**
>      * Configuration request: Set sensor field of view.
>      * <br><br>
>      * The field of view of the fiducial device can be set using the 
>      * PLAYER_FIDUCIAL_SET_FOV request, and queried using the 
>      * PLAYER_FIDUCIAL_GET_FOV request. The device replies to a SET request 
>      * with the actual FOV achieved. In both cases the request and reply 
>      * packets have the same format.
>      * <br><br>
>      * See the player_fiducial_fov structure from player.h
>      */
>     public void setFOV (int newMinRange, int newMaxRange, int newViewAngle) {
>         try {
>             sendHeader (PLAYER_MSGTYPE_REQ, 7);     /* 7 byte payload */
>             os.writeByte (PLAYER_FIDUCIAL_SET_FOV);
>             /* the minimum range of the sensor in mm */
>             os.writeShort (newMinRange);
>             /* the maximum range of the sensor in mm */
>             os.writeShort (newMaxRange);
>             /* the receptive angle of the sensor in degrees */
>             os.writeShort (newViewAngle);
>             os.flush ();
>         } catch (Exception e) {
>             System.err.println ("[Fiducial] : Couldn't send PLAYER_FIDUCIAL_SET_FOV " +
>                     "command: " + e.toString ());
>         }
>     }
> 
>     /**
>      * Configuration request: Get fiducial value.
>      * <br><br>
>      * Some fiducial finder devices display their own fiducial. They can use the 
>      * PLAYER_FIDUCIAL_GET_ID config to report the identifier displayed by the 
>      * fiducial. Make the request using the player_fiducial_id_t structure. The 
>      * device replies with the same structure with the id field set. 
>      * <br><br>
>      * Some devices can dynamically change the identifier they display. They can 
>      * use the PLAYER_FIDUCIAL_SET_ID config to allow a client to set the currently 
>      * displayed value. Make the request with the player_fiducial_id_t structure. 
>      * The device replies with the same structure with the id field set to the value 
>      * it actually used. You should check this value, as the device may not be able 
>      * to display the value you requested.
>      * <br><br>
>      * Currently supported by the stg_fiducial driver.
>      * <br><br>
>      * See the player_fiducial_id structure from player.h
>      */
>     public void getFiducialVal () {
>         try {
>             sendHeader (PLAYER_MSGTYPE_REQ, 1);     /* 1 byte payload */
>             os.writeByte (PLAYER_FIDUCIAL_GET_ID);
>             os.flush ();
>         } catch (Exception e) {
>             System.err.println ("[Fiducial] : Couldn't send PLAYER_FIDUCIAL_GET_ID " +
>                     "command: " + e.toString ());
>         }
>     }
>     
>     /**
>      * Check if fiducial value data is available.
>      * @return true if ready, false if not ready 
>      */
>     public boolean isIDReady () {
>         if (idReady) {
>             idReady = false;
>             return true;
>         }
>         return false;
>     }
> 
>     /**
>      * Get the fiducial data value displayed.
>      * @return the fiducial data value as an integer
>      */
>     public synchronized int getID () { return id; }
> 
>     /**
>      * Configuration request: Get fiducial value.
>      * <br><br>
>      * Some fiducial finder devices display their own fiducial. They can use the 
>      * PLAYER_FIDUCIAL_GET_ID config to report the identifier displayed by the 
>      * fiducial. Make the request using the player_fiducial_id_t structure. The 
>      * device replies with the same structure with the id field set. 
>      * <br><br>
>      * Some devices can dynamically change the identifier they display. They can 
>      * use the PLAYER_FIDUCIAL_SET_ID config to allow a client to set the currently 
>      * displayed value. Make the request with the player_fiducial_id_t structure. 
>      * The device replies with the same structure with the id field set to the value 
>      * it actually used. You should check this value, as the device may not be able 
>      * to display the value you requested.
>      * <br><br>
>      * Currently supported by the stg_fiducial driver.
>      * <br><br>
>      * See the player_fiducial_id structure from player.h
>      */
>     public void setFiducialVal (int newID) {
>         try {
>             sendHeader (PLAYER_MSGTYPE_REQ, 5);     /* 5 byte payload */
>             os.writeByte (PLAYER_FIDUCIAL_SET_ID);
>             os.writeInt (newID);                    /* the value displayed */
>             os.flush ();
>         } catch (Exception e) {
>             System.err.println ("[Fiducial] : Couldn't send PLAYER_FIDUCIAL_SET_ID " +
>                     "command: " + e.toString ());
>         }
>     }
> 
>     /**
>      * Get the number of fiducials.
>      * @return the number of fiducials as an integer.
>      */
>     public int getFiducialCount() {
>     	return this.count; 
>     }
> 
>     /**
>      * Get the fiducials.
>      * @return an array of PlayerFiducialItem.
>      */
>     public PlayerFiducialItem[] getFiducials () {
>     	return this.fiducials;
>     }
>     
>     // TO DO: implement fiducial messaging once Player supports it
> }


-- 

Yours sincerely,
Radu Bogdan Rusu
--
| Radu Bogdan Rusu | http://www.rbrusu.com
| Intelligent Autonomous Systems Group
| Technische Universitaet Muenchen

Re: [Java-player-developers] Fixes for the FiducialInterface

[Moshe S. <mos...@ya...>]

Here it is again

1. The items of the array of the fiducials were never
created so every access to them resulted in NPE.

2. Due to a poor copy&paste setPos(...) was used
everywhere instead of the appropriate methods (such as
setRot(...) )

3. Erroneous loop indexing (i and j were used wrongly)

Moshe

> 
> Hi Moshe,
> 
> Can you please send me the fixes again? I moved from
> the Technical 
> University of Cluj-Napoca, Romania to the Technical
> University of Munich 
> in Germany, and I cannot seem to access my old
> account anymore.
> 
> As soon as I get it I will have a look at it and
> then submit it to the CVS.
> 
> Thanks! :)


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

[Java-player-developers] Fixes for the FiducialInterface

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

Hi Moshe,

Can you please send me the fixes again? I moved from the Technical 
University of Cluj-Napoca, Romania to the Technical University of Munich 
in Germany, and I cannot seem to access my old account anymore.

As soon as I get it I will have a look at it and then submit it to the CVS.

Thanks! :)

--
| Radu Bogdan Rusu | http://www.rbrusu.com
| Intelligent Autonomous Systems Group
| Technische Universitaet Muenchen

[Java-player-developers] Fixes for FiducialInterface

[Moshe S. <mos...@ya...>]

Hi Radu,

I was trying to use FiducialInterface but I found it
very buggy (unusable) and fixed it.

The main problems were:
- The items of the array of the fiducials were never
created so every access to them resulted in NPE.
- Due to a poor copy&paste setPos(...) was used
everywhere instead of the appropriate methods (such as
setRot(...) )

The fixed class is attached.
Please review and commit it to the cvs.

Moshe

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Java-player-developers] interfaces and indexes

[Moshe S. <mos...@ya...>]

I'll look into it.

--- Radu Bogdan Rusu <ve...@in...> wrote:

> 
> You are right. I sent an e-mail some time ago on the
> list about this. :(
> Unfortunately, we do not support the indexing of
> player interfaces yet.
> 
> I will fix this asap, but I don't know when exactly,
> since I am in the
> process of moving to Munich these days.
> 
> Would you be kind enough to give us a hand on this
> matter? We can discuss
> here what needs to be done of course, and I could
> apply your patches through
> the SF CVS system. Thanks.
> 
> Cheers,
> Radu.
> 
> On Thu, Jul 07, 2005 at 11:04:02PM +0200, Moshe
> Sayag wrote:
> > I've noticed that all the requestInterfaceX()
> methods expect "int
> > index" as the first argument, but it is never used
> and just adds to
> > the confusion when users look for explanation
> about its value.
> > What was the original need for this argument?
> > If the is no need anymore, can it be removed?
> > 
> > Thanks,
> > 
> > Moshe
> 
> --
> | Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
> | PhD student/researcher
> | Robotics Research Group, Technical University of
> Cluj-Napoca[.ro]
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With
> Dual!' webinar happening
> July 14 at 8am PDT/11am EDT. We invite you to
> explore the latest in dual
> core and dual graphics technology at this free one
> hour event hosted by HP,
> AMD, and NVIDIA.  To register visit
> http://www.hp.com/go/dualwebinar
> _______________________________________________
> Java-player-developers mailing list
> Jav...@li...
>
https://lists.sourceforge.net/lists/listinfo/java-player-developers
> 



		
____________________________________________________
Sell on Yahoo! Auctions – no fees. Bid on great items.  
http://auctions.yahoo.com/

Re: [Java-player-developers] interfaces and indexes

[Radu B. R. <ve...@in...>]

You are right. I sent an e-mail some time ago on the list about this. :(
Unfortunately, we do not support the indexing of player interfaces yet.

I will fix this asap, but I don't know when exactly, since I am in the
process of moving to Munich these days.

Would you be kind enough to give us a hand on this matter? We can discuss
here what needs to be done of course, and I could apply your patches through
the SF CVS system. Thanks.

Cheers,
Radu.

On Thu, Jul 07, 2005 at 11:04:02PM +0200, Moshe Sayag wrote:
> I've noticed that all the requestInterfaceX() methods expect "int
> index" as the first argument, but it is never used and just adds to
> the confusion when users look for explanation about its value.
> What was the original need for this argument?
> If the is no need anymore, can it be removed?
> 
> Thanks,
> 
> Moshe

--
| Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
| PhD student/researcher
| Robotics Research Group, Technical University of Cluj-Napoca[.ro]

[Java-player-developers] interfaces and indexes

[Moshe S. <ms...@gm...>]

I've noticed that all the requestInterfaceX() methods expect "int
index" as the first argument, but it is never used and just adds to
the confusion when users look for explanation about its value.
What was the original need for this argument?
If the is no need anymore, can it be removed?

Thanks,

Moshe

[Java-player-developers] Javaclient 1.6.4 released

[Radu B. R. <ve...@in...>]

Javaclient 1.6.4 is up at SF.

Changes:
- Implemented Heading and Position control using PIDs. Use setDiffHeading
and setHeading for differential and absolute heading control for your robot,
and moveRobot for moving your robot for a specified distance. Thanks to
Marius Borodi;
- Changed getXPos, getYPos and getZPos in Position*Interface to getX, getY,
getZ;
- Several bugfixes to P*Controller;
- Small modifications to BlobfinderInterface;
- Added support for IR interface configuration requests
(PLAYER_IR_POSE_REQ).

Since 1.6.3, the jar, API docs and classes are automatically included.
We're encouraging our users to use the jar instead of modifying the
Javaclient sources directly. And as always, we're open to suggestions.

Yours sincerely,
Radu Bogdan Rusu
--
| Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
| PhD student/researcher
| Robotics Research Group, Technical University of Cluj-Napoca[.ro]

Re: [Java-player-developers] packages and directories

[Radu B. R. <ve...@in...>]

On Wed, Jun 15, 2005 at 02:52:52AM +0300, Moshe Sayag wrote:
> Some IDEs (as NetBeans, the great IDE that I'm using) look for the
> java files at the location they were suppose to be and thus can not
> find them so unless Imanually change the location, the editing /
> debugging cycle is harmed.

We switched entirely to Eclipse, which doesn't have this problem. From 1.6.3
upwards we encourage our users to use the jar and the API documentation
instead of directly modifying/importing the sources. I'm quite sure you
could tweak your IDE too, or instead you could just copy the src/* to
javaclient/src/* each time you upgrade to a newer version (we don't update
that often :) ).

Yours sincerely,
Radu Bogdan Rusu
--
| Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
| PhD student/researcher
| Robotics Research Group, Technical University of Cluj-Napoca[.ro]

[Java-player-developers] packages and directories

[Moshe S. <ms...@gm...>]

Hi Radu,

Many thanks for the efforts you spend to keep this library up to date.

I noticed that the java files are located right below src/ and not
under a directory named the same as the package.
For example, the file PlayerClient.java is located at
src/PlayerClient.java and not at src/javaclient/PlayerClient.java as
it should be.
Some IDEs (as NetBeans, the great IDE that I'm using) look for the
java files at the location they were suppose to be and thus can not
find them so unless Imanually change the location, the editing /
debugging cycle is harmed.

Please fix the problem.

Thanks,

Moshe

[Java-player-developers] Javaclient 1.6.3.2 released

[Radu B. R. <ve...@in...>]

Decided to build Javaclient 1.6.3.2 today, in case some of you guys have CVS
issues. So, 1.6.3.2 is up at SF. Changes:

- We got a new subpackage called javaclient.extra, where I've included some
basic controllers (P, PI, PD, PID). Here's an example on how to use a simple
P controller (first put your robot at a 45 degree heading for instance):
...
        PController pid = new PController (3);
        pid.setGoal (90);
        while (true) {
            double now = pi.getYaw (); // PositionInterface
            if (now < 0)
                now += 360;
            try {
                Thread.sleep (100);
            } catch (Exception e) {}
            
            int command = (int)pid.getCommand (now);
            pi.setSpeed (0, command);
            System.out.println (now + " / " + command);
        }
...
- Changed some parameters for the BlobfinderInterface and PtzInterface
methods to accept int instead of short/byte;
- Added getFiducialCount() and getFiducials() in FiducialInterface (thanks
to R. Paul Wiegand);
- Fixed some GEOM_REQ bugs in Position*Interface;
- Added Push(), Pop(), Read(), Clear() and setCapacity() to MComInterface;
- Small bug (short -> int) modified in GripperInterface;
- Added documentation for extra/*Controller.java;
- Fixed a few bugs for SonarInterface and IRInterface. Added AUTOSERVO
support for PtzInterface (tested with CMUcam2).

More to come. Stay tuned.

Yours sincerely,
Radu Bogdan Rusu
--
| Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
| PhD student/teaching assistant
| Robotics Research Group, Technical University of Cluj-Napoca[.ro]

[Java-player-developers] upcoming 1.6.3.2

[Radu B. R. <ve...@in...>]

Added a new sub-package, called javaclient.extra which includes an abstract
controller and then some simple P, PI, PD, PID controllers built upon it.

Should we re-think it and try to create an architecture for larger scale
controllers?

Btw, I think the indexing doesn't work in Javaclient. I don't have time to
test right now, but I'm guessing that we can't use "interface:0" and
"interface:1" at the same time. I'll dig some more...

Yours sincerely,
Radu Bogdan Rusu
--
| Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
| PhD student/teaching assistant
| Robotics Research Group, Technical University of Cluj-Napoca[.ro]

[Java-player-developers] Javaclient 1.6.3.1 released

[Radu B. R. <ve...@in...>]

Javaclient 1.6.3.1 is up at SF. Changes:
- Fixed an ugly bug in the Laser and Position interfaces (they used to
overlap data - actually there was data left after laser.read()). Thanks to
Hugo Gravato Marques;
- Fixed a bug in PositionX interfaces that was not allowing a user to use
positions or velocities equal with -1.

As always, the CVS is up to date.

Yours sincerely,
Radu Bogdan Rusu
--
| Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
| PhD student/teaching assistant
| Robotics Research Group, Technical University of Cluj-Napoca[.ro]

[Java-player-developers] Javaclient 1.6.3 released

[Radu B. R. <ve...@in...>]

Javaclient 1.6.3 is *finally* up at SF. :)

Changes:
- added full support for the following interfaces: fiducial, mcom, motor,
position2d and position3d; (***)
- fixed "a lot" (TM) of bugs on the PositionInterface; (Please upgrade!)
- GoTo() from PositionInterface (which was not working btw) has changed to
setPosition();
- minor cosmetic changes on some other interfaces.

*** = Finally, we support all the interfaces from Player's manual 1.6.3. :)
Here's the list: 
 * player             - PlayerClient.java
 * power              - PowerInterface.java
 * gripper            - GripperInterface.java
 * motor              - MotorInterface.java
 * position           - PositionInterface.java
 * position2d         - Position2DInterface.java
 * position3d         - Position3DInterface.java
 * sonar              - SonarInterface.java
 * laser              - LaserInterface.java
 * blobfinder         - BlobfinderInterface.java
 * ptz                - PtzInterface.java
 * camera             - CameraInterface.java
 * audio              - AudioInterface.java
 * audiodsp           - AudioDSPInterface.java
 * audiomixer         - AudioMixerInterface.java
 * waveform           - WaveformInterface.java
 * blinkenlight       - BlinkenlightInterface.java
 * fiducial           - FiducialInterface.java
 * speech             - SpeechInterface.java
 * gps                - GPSInterface.java
 * bumper             - BumperInterface.java
 * truth              - TruthInterface.java
 * simulation         - SimulationInterface.java
 * dio                - DIOInterface.java
 * aio                - AIOInterface.java
 * joystick           - JoystickInterface.java
 * wifi               - WiFiInterface.java
 * ir                 - IRInterface.java
 * localize           - LocalizeInterface.java
 * map                - MapInterface.java
 * mcom               - MComInterface.java
 * nomad              - NomadInterface.java
 * sound              - SoundInterface.java
 * energy             - EnergyInterface.java
 * planner            - PlannerInterface.java
 * log                - LogInterface.java
 * speech_recognition - SpeechRecognitionInterface.java

The CVS has been updated a few moments ago too.

From now on, most of my "javaclient time" will be dedicated to write
examples on how to use each of these interfaces. Again, any help is more
than welcome. :)

PS. Javaclient 1.6.3 also contains the jar, classes and documentation
already built, just in case some people don't know how to use Ant yet.

Yours sincerely,
Radu Bogdan Rusu
--
| Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
| PhD student/teaching assistant
| Robotics Research Group, Technical University of Cluj-Napoca[.ro]

[Java-player-developers] Javaclient 1.6.2e released

[Radu B. R. <ve...@in...>]

Javaclient 1.6.2e is up at SF. Changes:
- added full support for the following interfaces: audiodsp, audiomixer,
blinkenlight, camera, energy, joystick, nomad, speech_recognition and
waveform;
- added preliminary support for the following interfaces: fiducial and mcom;
- fixed several other bugs.

Version 1.6.3 will be released when all the rest of the interfaces (motor,
position2D, position3D plus fiducial and mcom) will be fully supported and
tested.

Yours sincerely,
Radu Bogdan Rusu
--
| Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
| PhD student/teaching assistant
| Robotics Research Group, Technical University of Cluj-Napoca[.ro]
| The optimist sees a task in every problem.
| The pessimist sees a problem in every task.

[Java-player-developers] Interfaces status

[Radu B. R. <ve...@in...>]

The following interfaces are not yet supported in 1.6.2d:
-motor
-position2D
-position3D
-camera
-audiodsp
-audiomixer
-fiducial
-nomad
+-mcom
+energy
+speech_recognition
+joystick
+waveform
+blinkenlight 

The interfaces with "+" are already done, I just need to add them to the
main tree. I will try to build and upload 1.6.2e sometime tomorrow.

PS. The interface list is taken from the Player HEAD manual. If any
interfaces are missing there, then they are missing from Javaclient too (I'm
assuming they are either obsolete, or have been replaced by other interfaces).

Yours sincerely,
Radu Bogdan Rusu
--
| Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
| PhD student/teaching assistant
| Robotics Research Group, Technical University of Cluj-Napoca[.ro]
| The optimist sees a task in every problem.
| The pessimist sees a problem in every task.

[Java-player-developers] Javaclient 1.6.2d released

[Radu B. R. <ve...@in...>]

Javaclient 1.6.2d is up at SF. Changes:
- added support for the Map, Planner and Log interfaces;
- added a PlayerClient.stopOnEOFException property
(use SetProperty before you create the PlayerClient object to set it)
which will stop the Javaclient if the Player server is stopped, thus an
EOFException occurs;
- some bugfixes.

There is a bug in player 1.6.2 and player-head (as of 29.04.05), so you
won't be able to use the Map interface properly unless you patch it
yourself. I already sent the small fix to playerstage-developers@ and
hopefully it will be merged into HEAD. The fix consists in adding a
"memcpy(&info, request, len); " call in the "HandleGetMapInfo(void *client,
void *request, int len)" function from the three *.cc files (mapcspace.cc,
mapfile.cc and mapscale.cc) in the server/drivers/map subdirectory. You need
to add that call somewhere around the following lines:
...
  // convert to pixels / kilometer
  info.scale = htonl((uint32_t)rint(1e3 / this->resolution));

  info.width = htonl((uint32_t) (this->size_x));
  info.height = htonl((uint32_t) (this->size_y));
...

After that issue a "make" call in the same subdirectory, and then another
"make" call in the server/ directory to rebuild the player binary. Or you
can just wait for Brian or someone else to merge the fix and then just CVS
:) Your choice.

The CVS repository has not been updated since 1.6.2c, so please do not use
it until later next week when hopefully I will be able to update it. Thanks
for understanding.

PS. Does anyone feel like writing a few examples for each interface we
support? I'd do it, but my time is sort of limited until June. Thanks.

Yours sincerely,
Radu Bogdan Rusu
--
| Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
| PhD student/teaching assistant
| Faculty of Automation & Computer Science @ UTCluj , Romania
| The optimist sees a task in every problem.
| The pessimist sees a problem in every task.

[Java-player-developers] Javaclient 1.6.2c released

[Radu B. R. <ve...@in...>]

Javaclient 1.6.2c is up at SF. Changes:
- added support for the Simulation interface;
- more bugfixes.

I also commited the changes to the CVS repository. The name of the new
module should be javaclient.

Yours sincerely,
Radu Bogdan Rusu
--
| Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com
| PhD student/teaching assistant
| Faculty of Automation & Computer Science @ UTCluj , Romania
| The optimist sees a task in every problem.
| The pessimist sees a problem in every task.