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

[address@hidden]

Hallo,

 

for a quick solution, Eric suggestion would be for me the way to go.

 

I would prefer to code it in "C".

 

I have considered such a solution too, but i had to concentrate on the nmea2000 code and test bench at the moment.

 

For me, it is not clear, how the daemon, that merge the data, can select the specific position sources with its gps_open() call.

 

If you connect only the position sources to the first gpsd, and all other sensors to the second, all should be fine,

but for a nmea2000 system, i can not do this, so here all unneeded messages from other sensors has be forwarded by the

intermediate daemon.

 

Reinhard

 

-----Original-Nachricht-----

Von: Olivier Cornu <address@hidden>

An: address@hidden

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

Datum: Thu, 12 Jul 2012 14:49:32 +0200

 

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