The Player Project

I'm beginning a redesign of the gripper interface, so I need to know 
what people want in a gripper.

The current interface is essentially direct hardware access to a Pioneer 
gripper (not the one on the end of the arm). It's pretty useless for 
controlling anything else.

First up, we need some commands.

Open gripper
Close gripper
Stop gripper
Set precise position?

We also need some data from the gripper

Regular updated data:
Gripper state (open, closed, maybe precise position?)
Geometry data:
Gripper (servo) open position, closed position (to help with setting 
precise position)?
Gripper size (width when open?)

I don't know if the pioneer gripper supports controlling its precise 
position (I don't have the manual with me), but I know the one on the 
end of the pioneer arm does, and I'm sure others do, too. On the other 
hand, if people really want that sort of control, they could use the 
actarray interface, and personally I think this would be the better way 
to do it rather than trying to add it to the gripper interface.

I'd like to get this implemented fairly soon. What are peoples' thoughts?

Geoff

-- 
Robotics research group, University of Auckland
http://www.ece.auckland.ac.nz/~gbig005/

To encapsulate the capabilities of the current interface you will also 
need a 'state' variable in the data. The pioneer gripper has two light 
gates that report wether something is in the gripper. An int could be 
used a bit field that reported wether the sensor had detected an object, 
0 for free and then a bit combination for how far into the gripper the 
object is.

For example in the case of the pioneer 1 for the front, 2 for the back 
and 3 for both. for simpler grippers just 0 or 1, for more complicated 
ones other mappings of the bit field...

Toby

Geoffrey Biggs wrote:
> I'm beginning a redesign of the gripper interface, so I need to know 
> what people want in a gripper.
> 
> The current interface is essentially direct hardware access to a Pioneer 
> gripper (not the one on the end of the arm). It's pretty useless for 
> controlling anything else.
> 
> First up, we need some commands.
> 
> Open gripper
> Close gripper
> Stop gripper
> Set precise position?
> 
> We also need some data from the gripper
> 
> Regular updated data:
> Gripper state (open, closed, maybe precise position?)
> Geometry data:
> Gripper (servo) open position, closed position (to help with setting 
> precise position)?
> Gripper size (width when open?)
> 
> I don't know if the pioneer gripper supports controlling its precise 
> position (I don't have the manual with me), but I know the one on the 
> end of the pioneer arm does, and I'm sure others do, too. On the other 
> hand, if people really want that sort of control, they could use the 
> actarray interface, and personally I think this would be the better way 
> to do it rather than trying to add it to the gripper interface.
> 
> I'd like to get this implemented fairly soon. What are peoples' thoughts?
> 
> Geoff
>

Geoff,

I assume that you will encapsulate *all* of the current capabilities. I'm
not sure what the gripper in the latest Stage and Gazebo uses to "eat" a
puck (or whatever), but we have other simulators that mimmick that abilit=
y
by using store/deploy. That is a common need for simulated grippers to do
(for ALife-style simulations), even though it is very unlike the real
world.

Of course, you can call it what you want, but I hope that we can have
those functions in Stage/Gazebo, and others. It will be great to have the
same interface on the end of a simulated arm.

-Doug

> To encapsulate the capabilities of the current interface you will also
> need a 'state' variable in the data. The pioneer gripper has two light
> gates that report wether something is in the gripper. An int could be
> used a bit field that reported wether the sensor had detected an object=
,
> 0 for free and then a bit combination for how far into the gripper the
> object is.
>
> For example in the case of the pioneer 1 for the front, 2 for the back
> and 3 for both. for simpler grippers just 0 or 1, for more complicated
> ones other mappings of the bit field...
>
> Toby
>
> Geoffrey Biggs wrote:
>> I'm beginning a redesign of the gripper interface, so I need to know
>> what people want in a gripper.
>>
>> The current interface is essentially direct hardware access to a Pione=
er
>> gripper (not the one on the end of the arm). It's pretty useless for
>> controlling anything else.
>>
>> First up, we need some commands.
>>
>> Open gripper
>> Close gripper
>> Stop gripper
>> Set precise position?
>>
>> We also need some data from the gripper
>>
>> Regular updated data:
>> Gripper state (open, closed, maybe precise position?)
>> Geometry data:
>> Gripper (servo) open position, closed position (to help with setting
>> precise position)?
>> Gripper size (width when open?)
>>
>> I don't know if the pioneer gripper supports controlling its precise
>> position (I don't have the manual with me), but I know the one on the
>> end of the pioneer arm does, and I'm sure others do, too. On the other
>> hand, if people really want that sort of control, they could use the
>> actarray interface, and personally I think this would be the better wa=
y
>> to do it rather than trying to add it to the gripper interface.
>>
>> I'd like to get this implemented fairly soon. What are peoples'
>> thoughts?
>>
>> Geoff

What are the particular capabilities of the stage/gazebo gripper? The 
current gripper interface is based on the capabilities of the Pioneer 
gripper. I don't know the full details of that device (hence why I'm 
asking here), but I think there are parts of that that would be better 
controlled with a different interface. Specifically, the lift component 
could be handled by the actuator array interface, by making it an array 
of a single actuator with a range from 0 to 1 (nothing in between). So I 
don't want to just duplicate the capabilities of the current interface 
without good reason.

Taking this and what Toby said into account, that would give us:

Commands:

- Open gripper
- Close gripper
- Stop gripper
- Store (to "eat" the thing it's holding)
- Deploy (to throw up the thing it stored :)
- Set precise position?

Gripper state (regular message):
  - open/closed, maybe precise position?)
  - gripper contents - int (with a bit mask?) describing the position of 
the thing the gripper is holding, eg interrupting light beams on the 
pioneer gripper

Geometry data:
- Gripper (servo) open position, closed position (to help with setting 
precise position)?
- Gripper size (width when open?)

Geoff

dblank@... wrote:
> Geoff,
> 
> I assume that you will encapsulate *all* of the current capabilities. I'm
> not sure what the gripper in the latest Stage and Gazebo uses to "eat" a
> puck (or whatever), but we have other simulators that mimmick that ability
> by using store/deploy. That is a common need for simulated grippers to do
> (for ALife-style simulations), even though it is very unlike the real
> world.
> 
> Of course, you can call it what you want, but I hope that we can have
> those functions in Stage/Gazebo, and others. It will be great to have the
> same interface on the end of a simulated arm.
> 
> -Doug
> 
>> To encapsulate the capabilities of the current interface you will also
>> need a 'state' variable in the data. The pioneer gripper has two light
>> gates that report wether something is in the gripper. An int could be
>> used a bit field that reported wether the sensor had detected an object,
>> 0 for free and then a bit combination for how far into the gripper the
>> object is.
>>
>> For example in the case of the pioneer 1 for the front, 2 for the back
>> and 3 for both. for simpler grippers just 0 or 1, for more complicated
>> ones other mappings of the bit field...
>>
>> Toby
>>
>> Geoffrey Biggs wrote:
>>> I'm beginning a redesign of the gripper interface, so I need to know
>>> what people want in a gripper.
>>>
>>> The current interface is essentially direct hardware access to a Pioneer
>>> gripper (not the one on the end of the arm). It's pretty useless for
>>> controlling anything else.
>>>
>>> First up, we need some commands.
>>>
>>> Open gripper
>>> Close gripper
>>> Stop gripper
>>> Set precise position?
>>>
>>> We also need some data from the gripper
>>>
>>> Regular updated data:
>>> Gripper state (open, closed, maybe precise position?)
>>> Geometry data:
>>> Gripper (servo) open position, closed position (to help with setting
>>> precise position)?
>>> Gripper size (width when open?)
>>>
>>> I don't know if the pioneer gripper supports controlling its precise
>>> position (I don't have the manual with me), but I know the one on the
>>> end of the pioneer arm does, and I'm sure others do, too. On the other
>>> hand, if people really want that sort of control, they could use the
>>> actarray interface, and personally I think this would be the better way
>>> to do it rather than trying to add it to the gripper interface.
>>>
>>> I'd like to get this implemented fairly soon. What are peoples'
>>> thoughts?
>>>
>>> Geoff
> 
> 
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=k&kid0709&bid&3057&dat1642
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers

On Apr 22, 2006, at 5:49 PM, Pooya Karimian wrote:

> Hi,
>
> I added them here to a wiki page:
>
> http://autolab.cs.sfu.ca/wiki/PlayerStageSummerCode
>
> Please add your ideas and also if you are willing to be a mentor  
> for any
> project.

Looks we missed our chance to participate this year.  The SOC page  
(http://code.google.com/soc/) says they're "no longer accepting  
applications for new mentoring organizations."

	brian.

Since there have been no further comments, I've gone ahead and made a 
new gripper interface. When it's done I'll supply a patch for player to 
update the relevant files, and hopefully, if I can get through the code, 
one for stage as well. For those interested, this is the interface I'm 
implementing. I've encapsulated as much of the gripper functionality as 
I think make sense for a generalised gripper interface. You'll note that 
exact positioning has been left out. I think for grippers capable of 
that, it makes more sense to provide an actuator array interface for 
those who need exact positioning and a gripper interface for those who 
just want to open and close. Similarly, the "lift" functionality present 
on the pioneer and stage grippers should now be provided by an actuator 
array interface.

If you have any comments, please make them now to save me work. :)

/** @ingroup interfaces
  * @defgroup interface_gripper gripper
  * @brief A  gripper

The @p gripper interface provides access to a robotic gripper.    */

/** @ingroup interface_gripper
  * @{ */

/** Gripper state: open */
#define PLAYER_GRIPPER_STATE_OPEN 1
/** Gripper state: closed */
#define PLAYER_GRIPPER_STATE_CLOSED 2
/** Gripper state: error */
#define PLAYER_GRIPPER_STATE_ERROR 3

/** Data subtype: state */
#define PLAYER_GRIPPER_DATA_STATE 1

/** Request subtype: get geometry */
#define PLAYER_GRIPPER_REQ_GET_GEOM 1

/** Command subtype: open */
#define PLAYER_GRIPPER_CMD_OPEN 1
/** Command subtype: close */
#define PLAYER_GRIPPER_CMD_CLOSE 2
/** Command subtype: stop */
#define PLAYER_GRIPPER_CMD_STOP 3
/** Command subtype: store */
#define PLAYER_GRIPPER_CMD_STORE 4
/** Command subtype: deploy */
#define PLAYER_GRIPPER_CMD_RETRIEVE 5

/** @brief Data: state (@ref PLAYER_GRIPPER_DATA_STATE)

The @p gripper interface returns the current state of the gripper
and information on a potential object in the gripper.
state may be @ref PLAYER_GRIPPER_STATE_OPEN, @ref 
PLAYER_GRIPPER_STATE_CLOSED,
or @ref PLAYER_GRIPPER_STATE_ERROR.
beams provides information on how far into the gripper an object is. For 
most
grippers, this will be a bit mask, with each bit representing whether a beam
has been interrupted or not.
*/
typedef struct player_gripper_data
{
   /** The gripper's state */
   uint8_t state;
   /** The position of the object in the gripper */
   uint32_t beams;
} player_gripper_data_t;

/** @brief Request/reply: get geometry

The geometry (pose, outer size and inner size) of the gripper device can be
queried by sending a null @ref PLAYER_GRIPPER_REQ_GET_GEOM request.
*/
typedef struct player_gripper_geom
{
   /** Gripper pose, in robot cs (m, m, m, rad, rad, rad). */
   player_pose3d_t pose;
   /** Outside dimensions of gripper (m, m, m). */
   player_bbox3d_t outer_size;
   /** Inside dimensions of gripper, i.e. the size of the space between the
   fingers when they are fully open (m, m, m) */
   player_bbox3d_t inner_size;
} player_gripper_geom_t;

/** @brief Command: Open (@ref PLAYER_GRIPPER_CMD_OPEN)

Tells the gripper to open. */
typedef struct player_gripper_cmd_open
{
} player_gripper_cmd_open_t;

/** @brief Command: Close (@ref PLAYER_GRIPPER_CMD_CLOSE)

Tells the gripper to close. */
typedef struct player_gripper_cmd_close
{
} player_gripper_cmd_close_t;

/** @brief Command: Stop (@ref PLAYER_GRIPPER_CMD_STOP)

Tells the gripper to stop. */
typedef struct player_gripper_cmd_stop
{
} player_gripper_cmd_stop_t;

/** @brief Command: Store (@ref PLAYER_GRIPPER_CMD_STORE)

Tells the gripper to store whatever it is holding. */
typedef struct player_gripper_cmd_store
{
} player_gripper_cmd_store_t;

/** @brief Command: Retrieve (@ref PLAYER_GRIPPER_CMD_RETRIEVE)

Tells the gripper to retrieve a stored object (so that it can
be put back into the world). The opposite of store. */
typedef struct player_gripper_cmd_retrieve
{
} player_gripper_cmd_retrieve_t;

/** @} */

Geoff


-- 
Robotics research group, University of Auckland
http://www.ece.auckland.ac.nz/~gbig005/

Thanks Geoff. Stage now has a gripper simulated I think, so you would just need 
to modify the player driver part.  If so that should be easy to modify. It might 
also not be too picky about whether an object is exactly within the paddles. 
Stage also has more states: open, closed, opening, closing, moving up, moving down.

Can you store more than one object? Is "store" the same as moving the gripper up 
off the floor so you can carry the object (while still holding the object in the 
gripper)? Or does it mean that you could store more than one object (so you can 
grab some new object while the old ones are stored)?

If you don't want to do the stage stuff I can do that in a few weeks maybe... 
pretty busy right now.

Can you define in the docs with more detail what the gripper is supposed to be 
and what exactly the operations ought to do?  This would differentiate it from 
the actuator array.

For example:

"A gripper is a device capable of closing around and carrying an object of 
suitable size and shape. On a mobile robot, a gripper it typically mounted near 
the floor on the front, and typically consists of two "fingers" that close 
around an object. Some grippers can detect whether an object is within the 
gripper.  Some grippers may also have the ability to move an carried object into 
a storage system, freeing it to pick up a new object [that's my interpretation 
of "store"...]."


If indeed "store" means to store more than one object, can you define what 
happens if you try to store more than one object?  Do they get stacked? Does the 
retrieve then get the last object stored?   If a gripper can't  support store 
and retrieve, what do the store and retrieve operations do? Is there a way to 
find out whether it supports store/retrieve?

Also, if a gripper doesn't support breakbeams but you don't know this, and you 
keep getting 0 for the 'beams' value, you'll be stuck :) So you need a way to 
find out from the gripper whether it has breakbeams or not.

Reed

On Wed, 03 May 2006, Reed Hedges wrote:

> 
> Thanks Geoff. Stage now has a gripper simulated I think, so you would just 
> need to modify the player driver part.  If so that should be easy to 
> modify. It might also not be too picky about whether an object is exactly 
> within the paddles. Stage also has more states: open, closed, opening, 
> closing, moving up, moving down.
> 
> Can you store more than one object? Is "store" the same as moving the 
> gripper up off the floor so you can carry the object (while still holding 
> the object in the gripper)? Or does it mean that you could store more than 
> one object (so you can grab some new object while the old ones are stored)?
> 
> If you don't want to do the stage stuff I can do that in a few weeks 
> maybe... pretty busy right now.
> 
> Can you define in the docs with more detail what the gripper is supposed to 
> be and what exactly the operations ought to do?  This would differentiate 
> it from the actuator array.
> 
> For example:
> 
> "A gripper is a device capable of closing around and carrying an object of 
> suitable size and shape. On a mobile robot, a gripper it typically mounted 
> near the floor on the front, and typically consists of two "fingers" that 
> close around an object. Some grippers can detect whether an object is 
> within the gripper.  Some grippers may also have the ability to move an 
> carried object into a storage system, freeing it to pick up a new object 
> [that's my interpretation of "store"...]."
> 
> 
> If indeed "store" means to store more than one object, can you define what 
> happens if you try to store more than one object?  Do they get stacked? 
> Does the retrieve then get the last object stored?   If a gripper can't  
> support store and retrieve, what do the store and retrieve operations do? 
> Is there a way to find out whether it supports store/retrieve?
> 
> Also, if a gripper doesn't support breakbeams but you don't know this, and 
> you keep getting 0 for the 'beams' value, you'll be stuck :) So you need a 
> way to find out from the gripper whether it has breakbeams or not.
> 
> Reed

This is interesting timing, because I am currently in the process of
defining an interface which I was planning to propose for marsupial
robotics.  We are planning to do some research on the subject and need
a simulation of our interface.   It looks like this gripper interface
is heading toward marsupials, but I was thinking of a fairly generic
abstract interface which would be usable on many different types.   
This pushes much of the actual movement of actuators and polling of
sensors for the actual marsupial behavior out to the driver, which is
preferable in my opinion because drivers can be provided by a plugin
and this type of interface will most likely have custom
implementations for new types of marsupials.

Here is what I currently have: 

/** @ingroup interfaces
 * @defgroup interface_marsupial marsupial
 * @brief Store and deploy other robots

The @p marsupial interface provides abstract functionality for storing
and deploying other robots from a robot which is capable.
*/ 

/** @ingroup interface_marsupial 
 * @{ */ 

/** Data subtype: state */ 
#define PLAYER_MARSUPIAL_DATA_STATE 1

/** Bay State: Open (ready to store or deploy robot) */ 
#define PLAYER_MARSUPIAL_STATE_BAY_OPEN 1
/** Bay State: Closed (not ready to accept robot) */ 
#define PLAYER_MARSUPIAL_STATE_BAY_CLOSED 2
/** Bay State: Error */ 
#define PLAYER_MARSUPIAL_STATE_BAY_ERROR 3 

/** Request subtype: queue type */
#define PLAYER_MARSUPIAL_REQ_QUEUE_TYPE 1

/* Queue types */ 
#define PLAYER_MARSUPIAL_QUEUE_FIFO 1
#define PLAYER_MARSUPIAL_QUEUE_LIFO 2
#define PLAYER_MARSUPIAL_QUEUE_DEQUE 3  # can store/deploy from either end
#define PLAYER_MARSUPIAL_QUEUE_PICKPLACE 4  # can store/deploy any robot

/** Request subtype: get geometry */
#define PLAYER_MARSUPIAL_REQ_GEOMETRY 1

/** Command subtype: store */ 
#define PLAYER_MARSUPIAL_CMD_STORE 1
/** Command subtype: deploy */ 
#define PLAYER_MARSUPIAL_CMD_DEPLOY 1

/** @brief Data: state (@ref PLAYER_MARSUPIAL_DATA_STATE)

The @p marsupial interface returns the current state of the bay of the 
marsupial robot.
*/ 

typedef struct player_marsupial_data 
{ 
  /** Bay state */ 
  uint8_t bay_state;
  /** Stored robots: -1 for unknown */ 
  uint32_t robots_inside;
} player_marsupial_data_t;

/** @brief Request/reply: get geometry

The pose of the bay (where robots are accepted or deployed)
*/ 

typedef struct player_marsupial_geom
{ 
  /** Bay pose in robot coords */ 
  player_pose3d_t pose; 
  /** Outside dimensions */ 
  player_bbox3d_t outer_size; 
  /** Bay doors (need better term) size */ 
  player_bbox3d_t door_size;
} player_marsupial_geom_t;

/** @brief Request/reply: get queue type

The type of queueing which is used */
typedef player_marsupial_queuetype 
{ 
  /** Type of queueing used. */ 
  uint8_t queue_type;
  /** Max number of robots stored */ 
  uint32_t max_stored;
} player_marsupial_queuetype_t;

/** @brief command: store (@ref PLAYER_MARSUPIAL_CMD_STORE)

Store a robot. */ 

typedef struct player_marsupial_cmd_store 
{ 
  /** Where to store to: differs for different queue types */ 
  uint32_t spot;
} player_marsupial_cmd_store_t; 

/** @brief command: deploy (@ref PLAYER_MARSUPIAL_CMD_DEPLOY)

Deploy a robot. */ 

typedef struct player_marsupial_cmd_deploy
{ 
  /** Where to store to: differs for different queue types */ 
  uint32_t spot;
} player_marsupial_cmd_deploy_t; 

-- 
Michael Janssen --- Jamuraa --- jamuraa@... --- jamuraa@...

Reed Hedges wrote:
> Thanks Geoff. Stage now has a gripper simulated I think, so you would 
> just need to modify the player driver part.  If so that should be easy 
> to modify. It might also not be too picky about whether an object is 
> exactly within the paddles. Stage also has more states: open, closed, 
> opening, closing, moving up, moving down.

I realised soon after I sent that message that I'd forgotten about 
moving grippers, so I added a PLAYER_GRIPPER_STATE_MOVING state. Is 
there a need to have separate OPENING and CLOSING states, or is a single 
MOVING state enough? Moving up and down are lift functionality, not gripper.

> Can you store more than one object? Is "store" the same as moving the 
> gripper up off the floor so you can carry the object (while still 
> holding the object in the gripper)? Or does it mean that you could store 
> more than one object (so you can grab some new object while the old ones 
> are stored)?

"Store" for a gripper means to store the object it's holding (eg in a 
holding pen behind the gripper?) so that the gripper is free to pick up 
another object. Similarly, retrieve would pull a stored object out of 
the holding pen and put it in the gripper (drivers should be intelligent 
enough to not do this if there's already something in the gripper). 
Being able to store more than one object (or any at all) would be 
device-dependant, I would expect. There was some desire to have this 
functionality from others on the list for AI stuff. I imagine it would 
be possible in a real gripper too, although I can't think of one that 
actually does have it.

> Can you define in the docs with more detail what the gripper is supposed 
> to be and what exactly the operations ought to do?  This would 
> differentiate it from the actuator array.
> 
> For example:
> 
> "A gripper is a device capable of closing around and carrying an object 
> of suitable size and shape. On a mobile robot, a gripper it typically 
> mounted near the floor on the front, and typically consists of two 
> "fingers" that close around an object. Some grippers can detect whether 
> an object is within the gripper.  Some grippers may also have the 
> ability to move an carried object into a storage system, freeing it to 
> pick up a new object [that's my interpretation of "store"...]."

That's the gist of it. I'll expand the docs in player.h to explain 
things in more detail. Basically, the gripper interface is to provide a 
  simple open/close functionality, while the actuator array provides 
complex position control functionality. I think having a simple 
interface for grippers where you don't need to worry about position is 
important.

Also, remember that we're not just talking about the common pioneer 
gripper here. The pioneer arm also has a gripper on the end of it which 
does nothing but open/close (it doesn't even have any breakbeams).

> If indeed "store" means to store more than one object, can you define 
> what happens if you try to store more than one object?  Do they get 
> stacked? Does the retrieve then get the last object stored?   

This would be device-dependant.

> If a 
> gripper can't  support store and retrieve, what do the store and 
> retrieve operations do? Is there a way to find out whether it supports 
> store/retrieve?

The gripper interface isn't the only one that faces this problem. How do 
you find out whether a position2d device supports position commands, 
velocity commands or both? The only way I'm aware of is to read the docs 
for the specific driver.

> Also, if a gripper doesn't support breakbeams but you don't know this, 
> and you keep getting 0 for the 'beams' value, you'll be stuck :) So you 
> need a way to find out from the gripper whether it has breakbeams or not.

I'll add a field to the geometry message, "number of breakbeams."

Geoff

-- 
Robotics research group, University of Auckland
http://www.ece.auckland.ac.nz/~gbig005/

Geoffrey Biggs wrote:
> "Store" for a gripper means to store the object it's holding (eg in a 
> holding pen behind the gripper?) so that the gripper is free to pick up 
> another object. Similarly, retrieve would pull a stored object out of 
> the holding pen and put it in the gripper (drivers should be intelligent 
> enough to not do this if there's already something in the gripper). 
> Being able to store more than one object (or any at all) would be 
> device-dependant, I would expect. There was some desire to have this 
> functionality from others on the list for AI stuff. I imagine it would 
> be possible in a real gripper too, although I can't think of one that 
> actually does have it.

Maybe there should really be two devices? The gripper and the storage? Somehow 
connected?  Then you could also pick up objects with a full arm and store them?

Well, regardless, grippers/storage devices could have a configurable total 
storage capacity, even 1 or 0. And it would also be nice if the client could 
find this out.   Maybe return as part of the state and breakbeam information the 
"current free space" in storage (number of objects that could be stored right 
now)? If a gripper doesn't support storage at all then this value would always 
be 0, even if nothing has been stored yet.  OR, total capacity could be a value 
in the geometry and it would be up to the client to keep track.

Of course the whole storage idea assumes you're storing objects of very similar 
size and shape, right?


> Also, remember that we're not just talking about the common pioneer 
> gripper here. The pioneer arm also has a gripper on the end of it which 
> does nothing but open/close (it doesn't even have any breakbeams).
> 

Right.  I guess you could represent an arm like that as an arm plus "gripper" 
(however deficient in features).  Or the end effector would just be another 
joint or a special property of the arm interface.  Is the latter approach the 
normal and preferred one in general with Player?


> 
> The gripper interface isn't the only one that faces this problem. How do 
> you find out whether a position2d device supports position commands, 
> velocity commands or both? The only way I'm aware of is to read the docs 
> for the specific driver.

No reason not to include that information, arguably any interface that has 
"optional" features also should have a way to find out whether a particular 
instance of that device supports them or not, right?

Reed

There has a been a feature request for a long time for capability 
reporting/querying. This is even more important in player 2 with its 
more complex interfaces (i.e. multiple commands and data).

At the moment request capabilities can be tested by making a request 
(you'll get a NACK if it isn't supported) but I would like to see formal 
capabilities querying, just haven't had time to look into it personally yet.

Toby

Reed Hedges wrote:
> Geoffrey Biggs wrote:
>> "Store" for a gripper means to store the object it's holding (eg in a 
>> holding pen behind the gripper?) so that the gripper is free to pick 
>> up another object. Similarly, retrieve would pull a stored object out 
>> of the holding pen and put it in the gripper (drivers should be 
>> intelligent enough to not do this if there's already something in the 
>> gripper). Being able to store more than one object (or any at all) 
>> would be device-dependant, I would expect. There was some desire to 
>> have this functionality from others on the list for AI stuff. I 
>> imagine it would be possible in a real gripper too, although I can't 
>> think of one that actually does have it.
>
> Maybe there should really be two devices? The gripper and the storage? 
> Somehow connected?  Then you could also pick up objects with a full 
> arm and store them?
>
> Well, regardless, grippers/storage devices could have a configurable 
> total storage capacity, even 1 or 0. And it would also be nice if the 
> client could find this out.   Maybe return as part of the state and 
> breakbeam information the "current free space" in storage (number of 
> objects that could be stored right now)? If a gripper doesn't support 
> storage at all then this value would always be 0, even if nothing has 
> been stored yet.  OR, total capacity could be a value in the geometry 
> and it would be up to the client to keep track.
>
> Of course the whole storage idea assumes you're storing objects of 
> very similar size and shape, right?
>
>
>> Also, remember that we're not just talking about the common pioneer 
>> gripper here. The pioneer arm also has a gripper on the end of it 
>> which does nothing but open/close (it doesn't even have any breakbeams).
>>
>
> Right.  I guess you could represent an arm like that as an arm plus 
> "gripper" (however deficient in features).  Or the end effector would 
> just be another joint or a special property of the arm interface.  Is 
> the latter approach the normal and preferred one in general with Player?
>
>
>>
>> The gripper interface isn't the only one that faces this problem. How 
>> do you find out whether a position2d device supports position 
>> commands, velocity commands or both? The only way I'm aware of is to 
>> read the docs for the specific driver.
>
> No reason not to include that information, arguably any interface that 
> has "optional" features also should have a way to find out whether a 
> particular instance of that device supports them or not, right?
>
> Reed
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job 
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers

Reed Hedges wrote:
> Maybe there should really be two devices? The gripper and the storage? 
> Somehow connected?  Then you could also pick up objects with a full arm 
> and store them?

This is an interesting idea, but I'm not sure how it would work, or if 
it's necessary to go that far. For example, doing it with an arm would 
require linking the actarray or limb interface (whichever the arm driver 
provides) into it as well. The complex process of an arm/gripper combo 
storing an object may be something we'd prefer to leave to the client side.

> Well, regardless, grippers/storage devices could have a configurable 
> total storage capacity, even 1 or 0. And it would also be nice if the 
> client could find this out.   Maybe return as part of the state and 
> breakbeam information the "current free space" in storage (number of 
> objects that could be stored right now)? If a gripper doesn't support 
> storage at all then this value would always be 0, even if nothing has 
> been stored yet.  OR, total capacity could be a value in the geometry 
> and it would be up to the client to keep track.

That sounds like a good way to do it. I'll add a "capacity" bit to the 
geometry message and a "currently stored" count to the data message. 
Then the driver can keep track easily enough. Possibly also a "set 
currently stored" request for people who want to load up their storage 
bin by hand? I don't want to make the storage stuff overly complex given 
that I don't think it's likely to be used in the real world much and the 
AI people just want to "swallow" whatever they're holding.

> Of course the whole storage idea assumes you're storing objects of very 
> similar size and shape, right?

I would say so. :) You'd definitely run into problems if you tried to 
store a baseball in a golf ball sized container. We could add a "storage 
size" to the geometry request, or we could assume that if the gripper 
can hold it, it can store it.

> Right.  I guess you could represent an arm like that as an arm plus 
> "gripper" (however deficient in features).  Or the end effector would 
> just be another joint or a special property of the arm interface.  Is 
> the latter approach the normal and preferred one in general with Player?

The way I'm doing it with the p2os driver is providing an actuator array 
interface that can control every joint on the arm as well as a limb 
interface that can control the end effector position (both of these are 
already in, and have been for a while), plus a gripper interface for the 
gripper on the end of the arm. This way, users can use the limb 
interface to move the gripper to a position and the gripper interface to 
open/close it.

> No reason not to include that information, arguably any interface that 
> has "optional" features also should have a way to find out whether a 
> particular instance of that device supports them or not, right?

I absolutely agree. In the case of the gripper, I'd like to make sure 
it's available to figure out some how, and storage capacity info would 
do this. In the long run, though, what functionality a driver provides 
is an issue that I think needs to be address player-wide. It's never 
going to be possible to guarantee that all hardware will support all 
aspects of the interface it goes with. But that's another discussion 
entirely...

Geoff

-- 
Robotics research group, University of Auckland
http://www.ece.auckland.ac.nz/~gbig005/

Geoffrey Biggs wrote:
 > I don't want to make the storage stuff overly complex given
> that I don't think it's likely to be used in the real world much and the 
> AI people just want to "swallow" whatever they're holding.

Well, not neccesarily always swallowing.  For now at least it would only be in 
simulation, though.

> we could assume that if the gripper 
> can hold it, it can store it.

Yes, this is reasonable.


> It's never 
> going to be possible to guarantee that all hardware will support all 
> aspects of the interface it goes with. But that's another discussion 
> entirely...

Yes.  Though sometimes you can emulate features and sometimes you can't.  If you 
can expect any driver to either support a feature natively, or it can be 
emulated without too much pain and suffering, then that feature is OK to be 
"REQUIRED". Otherwise, it must be optional and the client must be able to find 
out if it's optional or not through whatever mechanism.

Reed

I've submitted a (fairly substantial) patch that implements the new 
gripper interface.

The patch adds the new interface to player.h and related, redoes the C 
and C++ client libs, other misc files, and makes some large changes to 
the P2OS driver: the standard gripper is provided by a named gripper 
interface, the lift is controlled by a named actarray interface, and the 
gripper on the end of the arm can be used via another named gripper 
interface. The docs for the driver give details on how to use it all. 
Since we don't have standard grippers for our pioneers, just arms, I 
haven't been able to test the gripper or lift support at all. It should, 
in theory work, but we all know about "in theory." :) I'd be grateful if 
someone who does have a gripper could test it for me.

Oh, and the patch also adds a big chunk of capabilities request support 
to P2OS, too. It's not complete yet, I have to go through the driver and 
figure out what is actually supported still, but if you want an example 
of how to do it for other drivers, that's a good place to look.

I haven't had a chance to update stage to the new interface yet. Gazebo 
might also need updating. I'm unsure if that has gripper support or not.

http://sourceforge.net/tracker/index.php?func=detail&aid=1483740&group_id=42445&atid=433166

Geoff

-- 
Robotics research group, University of Auckland
http://www.ece.auckland.ac.nz/~gbig005/

I've added a quick patch to this for stage that makes it compile with 
the new gripper interface. It isn't fully functional as I haven't had 
time to figure out how to split the gripper model to support two 
interfaces. This patch provides all the gripper functionality but none 
of the lift functionality.

http://sourceforge.net/tracker/index.php?func=detail&aid=1483740&group_id=42445&atid=433166

Once these two patches are committed to player and stage respectively 
one of the oldest feature requests can finally be closed. :)

Geoff

Geoffrey Biggs wrote:
> I've submitted a (fairly substantial) patch that implements the new 
> gripper interface.
> 
> The patch adds the new interface to player.h and related, redoes the C 
> and C++ client libs, other misc files, and makes some large changes to 
> the P2OS driver: the standard gripper is provided by a named gripper 
> interface, the lift is controlled by a named actarray interface, and the 
> gripper on the end of the arm can be used via another named gripper 
> interface. The docs for the driver give details on how to use it all. 
> Since we don't have standard grippers for our pioneers, just arms, I 
> haven't been able to test the gripper or lift support at all. It should, 
> in theory work, but we all know about "in theory." :) I'd be grateful if 
> someone who does have a gripper could test it for me.
> 
> Oh, and the patch also adds a big chunk of capabilities request support 
> to P2OS, too. It's not complete yet, I have to go through the driver and 
> figure out what is actually supported still, but if you want an example 
> of how to do it for other drivers, that's a good place to look.
> 
> I haven't had a chance to update stage to the new interface yet. Gazebo 
> might also need updating. I'm unsure if that has gripper support or not.
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=1483740&group_id=42445&atid=433166 

-- 
Robotics research group, University of Auckland
http://www.ece.auckland.ac.nz/~gbig005/