Re: [Playerstage-users] Sensoray

[Brian G. <ge...@ro...>]

On Fri, 23 Apr 2004, Kratochvil, Bradley Eugene wrote:

> I am looking to add a driver for the Sensoray 626 analog and digital I/O
> board to the Player server.  I'm starting off with the player-mod, and
> working from there.  We are currently using the Sensoray board for other
> motion control applications in our lab, and I would like to use it
> primarily as programmable motor controller (with additional A/D I/O) in
> Player.
> 
> My idea for the driver is to build a mixed mode driver that supports the
> existing aio and dio interfaces.  I was also planning on creating a new
> motor interface for this.  Does anyone have any input on what they would
> like in a motor interface?  I was thinking of adding velocity and
> position control along with the config options necessary for these
> control methods.  It will probably end up similar to the position
> interface, but only it will be for 1 axis.  (Side note: I've been
> thinking it may be cleaner to have position1d, postion2d, and position3d
> interfaces in the future.)
> 
> Are there any mixed mode drivers that would be a particularly suitable
> reference point for this process?
> 
> Along the mixed mode driver lines, I would eventually like to use the
> motor drivers in another Player driver that will support the position
> interface (2d).  Can this be done, or am I completely off my rocker?

hi Brad,

The question of what to put in a motor interface is a hairy one.  I think
the most general answer is something like: N derivates of position in each
dimension, with flags labeling each value as being a target or a limit.
Now, that's obvious not viable, so we've been satisfied so far with
giving the 0th and/or 1st derivates (i.e., position and/or velocity),
intepreting them as targets, and setting one flag to indicate which
to use.  Then there are some (mostly device-specific) config requests
to set and get certain parameters.

For your application, rather than build a new 1d position interface, I
suggest that you use the (2d) position interface.  You can just ignore
the 'y,' 'yspeed,' 'yaw,' and 'yawspeed' fields.  It's not the most
elegant solution, but adds minimal message overhead, and you'll find
it much easier than adding an interface: you won't have to modify the
server at all, and you get automatic client-side support.  We already
have a couple of examples of this kind of thing: compass and gyro drivers
that supports the (2d) position interface, but only fill in the 'yaw' or
'yawspeed' field in data packets.  Likewise, any differentially-driven
robot ignores the 'yspeed' field in both command and data packets.

As for a reference point, it depends on what you want to do.  If you're
happy to support only one interface at a time (e.g., either position
or AIO), then the segwayrmp driver is a good example: it can support
either the position or the position3d interface.  If you want to support
multiple interfaces simultaneously, then I suppose that the p2os driver
is your best bet.  Unfortunately, it's pretty hairy.

Btw, I'm planning to add support sometime soon for one driver to
simultaneously and naturally support multiple interfaces, without the
machinery that's found in the p2os driver.

        brian.

-- 
Brian P. Gerkey                    ge...@ro...
Stanford AI Lab                    http://ai.stanford.edu/~gerkey