[gpsd-dev] Virtual devices (as a solution to multiple sources location)

[Olivier Cornu]

Thanks everyone for the feedback, comments and suggestions.
There seem to be some interest in harvesting multi-source capabilities
even if there is no consensus yet on how such code should work or
where it would belong.

What do we agree on?
- We all agree that such capabilities are, as Eric mentioned, "policy
driven": they go beyond the mechanical multiplexing gpsd has been
devoting itself to so far.
- We agree that multi-source capabilities are powerful, already used
in real-life critical environments like aeronautics as Gary noted, and
can get much smarter (see Thornston's link) than the basic stuff i
have in mind for my own use.
- We also seem to agree that such policies will require flexibility in
the code to accommodate to particular use cases, as Chris (config
settings) and Reinhard (policy plugins) suggested.
- Hopefully, we agree that as location technologies become ubiquitous
and diverse, multiple location sensors are becoming the default setup,
thus there should soon be a "policy layer" hub (or compound location
provider) to get the most out of it.

I would advocate that there is much (market) value in being the
default location provider for a platform.
I believe gpsd already is the default location provider on open
platforms, although it perhaps only sees itself as a GPS multiplexer.
Because it's the last layer clients talk to, and most clients
rightfully expect all the dirty location job is done at this point
(they expect one clean location). That's why i expected more than
multiplexing when i plugged my second device, and i should know
better: contrary to most users, i peeked and poked into gpsd code
already.
I would advocate that most users would expect this stuff to be somehow
part of gpsd as well. And i believe we could add it to gpsd without
compromising the mechanical multiplexing it does right.


To make things simpler, we can see this policy layer as functionally
distinct from the mechanical multiplexing gpsd does. It is thus
tempting to push it back in its own daemon.
However, if we look closer, both layers have some tight links that
will be hard to stretch that much. Timing issues (when computing a
single position from asynchronous location speakers), definition of a
3D fix (takes one more satellite in aeronautics), raw device state
knowledge and control (ability to detect and right to shut down a
device in case of incorrect behaviour), and probably more.
They also have a lot in common. Frankly, if i needed to average
locations for my own use i'd just add 3 lines to consume_packets(); I
wouldn't code a whole gpsd proxy for that, be it in python.
Anyway, i think it makes sense to talk about the policy layer in terms
of the current gpsd architecture, no matter where it ends up (library
or daemon).


As i see it, we just need virtual devices.
Basically, virtual devices are like real devices: they have their own
driver (implementing policy) and spit their own stream of JSON
location events for client apps.
But virtual devices are also local clients, as they subscribe and
consume real devices output.
Finally, virtual devices have a little bit of their own interaction
with gpsd (if they can shut down/reboot a device, for example).

Let's take a simple example: the /dev/aero/ttyUSB0 virtual device,
which provides the very same streams /dev/ttyUSB0 provides, except
that it needs one more satellite to call it a 3D fix.
I like this example because it's not even a compound sources provider,
yet it makes perfect sense as a policy.

The good point here is that we'd piggyback on existing gpsd paradigm,
interfaces and well-tested code. The remaining code could be
conditioned to a precompiler switch.
Let's not fool ourselves: even though there's a need for flexibility
(drivers) and possibilities are infinite, what we'd probably end up
with is just a few virtual device drivers that make 95% of gpsd users
happy. Location sources redundancy is no different than, say,
hard-drive redundancy (the set of original efficient strategies is
small).
Overall, i believe it would be a reasonably small addition relatively
to gpsd current size.


Looking forward to your comments.

--
Olivier Cornu