RE: [Playerstage-developers] gz_position/3d and c/c++ client inconsistencies

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

On Thu, 1 Jul 2004, Kratochvil, Bradley Eugene wrote:

> Ben Grocholsky said:
>
> > I'm not sure about the need to change to milliradians. Ideally,  to
> > reduce mistakes everything would be in metres and radians unless you 
> > have a good reason like saving resources by storing floats in short 
> > ints. Any arbitrary scaling that offers the desired resolution is 
> > equally problematic.

We do stick to integers on the wire, but not to save resources.  Rather,
because we haven't found a platform-independent format for transmitting
floating point numbers.  Integers are easy: just pick a byteorder (we
use big-endian, which is the network standard; blame Sun for that).

The formats I could find for floats, on ther other hand, such as XDR, are
not so simple, and usually require a helper library on either end to pack
and unpack the data.  This is not necessarily a bad thing, for we could
eliminate a lot of dumb bugs by not doing data (de)marshalling ourselves.
But it would be a big change, and we've never carried through with it.

(*Please* let me know if I've missed a simple-to-use platform-independent
floating point format!)

So, on the wire, we pick use fixed-point representations, in units
that provide enough range and precision for the job.  Of course, range,
precision, and size trade off against each other, so sometimes we add a
unit multiplier to allow the selection of a particular range/precision,
given a fixed size (e.g., the 'range_res' field in the laser data packet).

> Now, this leads to some confusion when writing the client libraries.
> Everything that they output needs to be in mks per the recent change, so
> they have to do different types of conversions for the different types.

I'm not so concerned about confusion when writing client libraries.
That work gets done once per programming language, usually by people
familiar with the code, who can get the conversions right if they read
the documentation.  The client libs exist primarily to hide the gory
details of the Player protocol, wrapping the underlying socket(s) so as to
present a consistent interface to the user (this is why I normalized the
C++ client lib to use MKS throughout, rather than just in some proxies).

To me, arc-seconds are just as good, and nearly as arbitrary, as
milliradians (btw, arc-seconds offer greater precision: 0.00027 <
0.05730).  Whether in the client lib you do one transformation (angle *
3600.0 * M_PI/180.0) or another (angle / 1e3) to get the units you like
is not, in my opinion, a big deal.

So, although it would be nice to have consistent units for similar
values *inside* the Player protocol, I don't see that on its own as a
sufficient argument to make protocol changes that will in turn require
changes throughout all client libs.

> By switching to mradians for passing over the wire in both the position
> and position3d interfaces, we make writing the client libraries simpler
> and allow the user to have more precision (than the current position
> interface which only supports degrees).

Now, if we need greater precision (or range), that's a different matter,
and it might be worth making some changes.  

So, for those of you still reading, especially those working in 3D, and/or
doing state estimation, some questions:

- What range and precision do your applications require for linear
  positions?  Linear velocities? Linear accelerations?

- What range and precision do your applications require for angular
  positions? Angular velocites? Angular accelerations?

        brian.

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