some thoughts regarding gps and granularity in general (all of it we've
said more than once before, just trying to write it down).
there're two types of granularity: a) interface definition and b)
interface implementation (components). in the case of GPS, i think alex b.
is proposing to fragment both (the Gps interface and the Gps component).
A) INTERFACES
in general, I think having one data type per interface should NOT be
an objective. there's certain attraction in this approach but, if taken
to extreme, it leads to orca1 patterns. in terms of implementation things
were fairly simple: a few patterns implemented as templates over a set of
data types. but the approach was not flexible enough even for simple
systems, was difficult to understand at first glance, and did not scale
well to bigger systems.
in this particular case, I'm for splitting it up (with some reservations).
but I'll try to write down the process which I think we apply when
discussing interface definitions.
0. start with a lump of functionality we want to implement.
1. for any part of the remaining functionality
- can it be covered by an existing interface?
if YES, use it, remove this functionality, repeat 1.
if NO, continue.
2. for any part of the remaining functionality
- can it be used in the context of another component/application?
(i.e. should this be a 'standard' interface?) OR
- would it make sense for some reason to implement it separately?
if YES, create new interface, remove this functionality, repeat 2.
if NO, create one new interface, exit.
let's try to apply it to 'GPS functionality'.
- 'locally-flat-earth coordinates functionality'. this is basically
Localise3d interface with a couple of complications (do we need zone info?
what if we cross from one zone to another? are the errors given in standard
deviations? do we need position type?). If we can use standard Localise3d,
I would definitely do it. If we have to create Localise3dGps, I would
still do it but not as happily. The argument for it, is that we can split
implementation as Alex B. suggests (see my thoughts below). The argument
against is that, to me at least, this is part of GPS stuff and it cannot
be used for anything else.
- 'clock functionality'. such interface does not exist but there's nothing
very GPS about it, so maybe it could be useful in general. should we
create orca::Clock interface?
- 'non-flat-earth coordinates functionality'. this is raw GPS info. in
addition to spherical coordinates it has a bunch of custom info. i can't
think of any part of it used in a different context. by the way, should we
create orca::SphericalPoint structure in bros1.ice and use it here? I would
do it to be consistent. the only doubt I have is that GPS provides
'altitude above elipsoid' which is not really a spherical coord. sys.
nothing else is left, I guess. So, assuming that we can use standard
Localise3d:
component Gps
{
inerface Clock
interface Gps
interface Localise3d
}
B) IMPLEMENTATION
i have doubts about splitting Gps into Gps and GpsToXxxx. but maybe i just
don't understand how it's actually used.
for example, would a filter which fuses INS/GPS/Odometry use the raw GPS
signal? then I can see the analogy between Gps/GpsToXxxx and
Odometry/FaithLocaliser (is GpsLocaliser a better name?)
but if other components mostly use 'mapgrid' data then i think it makes
sense to leave the way it is now.
cheers, alex m.
--
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
|