Crate(s) for working with nav data

xadaemon commented 4 years ago

Proposal:

Crate(s) for working with nav data, both in parsing raw data from GPS modules and similar devices with a concise API between them.

Objectives:

A set of crates that can be used in processing nav data as in assisting with calculations using said data, parsing the data from raw sources and protocols and eventually operating together with GIS systems to help in processing the data.

Motivation:

I find this is an important part of aerospace and would benefit a large group of people even those who only work with nav data and are not in the aerospace industry.

o0Ignition0o commented 4 years ago

I worked on an NMEA-0183 parser (which is based on nom5) https://github.com/YellowInnovation/nmea-0183 but I haven't had time to battletest it yet. Maybe it could be forked / transfered here, The deploy keys are mine and I think I'm the only contributor

xadaemon commented 4 years ago

A fork would be likely a good option as we need to be sure about the IP of it before transferring I think.

Dushistov commented 4 years ago

@o0Ignition0o

I am maintainer of https://crates.io/crates/nmea ( https://github.com/dushistov/rust-nmea ). I use/used it in my paratrooper project. Would you like share effort?

Dylan-DPC-zz commented 4 years ago

Yeh the license is copyright to Yellow Innovation. So better to fork it

o0Ignition0o commented 4 years ago

@Dushistov oh yeah I would love to !

xadaemon commented 4 years ago

would you guys want some help I'm up to it.

Dushistov commented 4 years ago

@o0Ignition0o

oh yeah I would love to

So about merge two projects into one?

I am not sure about names: nmea and nmea-0183, is it possible to use two names for the same crate, and if no which one should be marked as deprecated?

From quick code reading:

https://github.com/YellowInnovation/nmea-0183 looks like more standard oriented, while my https://github.com/dushistov/rust-nmea is more oriented on real life usage (it used for navigation with at least 3 different satellite receivers).

For example my gives latitude as f64, while your in two fields: like north/south + degrees.

Plus my crate has unique state machine on top of parser, that combine several nmea sentences into one structure. It is important, because of for moving object you want coordinates + speed + time in one structure and do not want mistakes like coordinates for time t and speed from next measure t + dt, this may cause all sorts of hard detectable problems.

So what about nmea crate that contains low level parsers functions

on top of parser state machine to combine several sentences into one (optional feature)
may be some state machine to filter data before parser that split data into lines and take care about too long lines (some kind of https://doc.rust-lang.org/std/io/trait.BufRead.html#method.read_line , but for no_std with knowledge that line may not exceed ~200 characters, so there is no need for memory allocations) ?

o0Ignition0o commented 4 years ago

IIRC I created this crate because it seemed to me like too much work to add nom5 to your crate (back then, congrats on adding it!) and because I needed to make sure I could parse any message as defined in the U-BLOX documentation https://www.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_%28UBX-13003221%29_Public.pdf That's also the reason why I went for West/East etc (it was specified in the docs).

I think your crate is much more tested and provides more features.

Your suggestion makes a lot of sense to me, it would allow us to separate the logic from the parsing, and I wouldn't mind marking nmea-0183 as deprecated, or maybe specialise it in parsing only, leaving the combining / filtering / state machine to an other crate.

Dushistov commented 4 years ago

it seemed to me like too much work to add nom5 to your crate

This is thanks to @fparat (Dushistov/rust-nmea#4) .

That's also the reason why I went for West/East

may be I din't describe it clear, east/west is encrypted into sign of f64, this is because of it is convenient representation for various applications like calculate distance on ellipsoid, bearing to some point from current etc, but there is no unanimous decision about negative number is west or east, so for low level parser it is wise to give enum west/east, while for usage of gps data is f64 is much better choice.

I wouldn't mind marking nmea-0183 as deprecated, or maybe specialise it in parsing only, leaving the combining / filtering / state machine to an other crate

may be then migrate dushistov/nmea to aerorust and then you provide review what is bad and what missed, and then when we have free time any one of us pick sub-issue from your review and implement it?

I have access to garmin and u-blox receiver plus numerous android phones (Android API allow get nmea data from internal GPS receiver), plus already existing tests that should be enough for refactoring.

elpiel commented 4 years ago

@Dushistov we have @o0Ignition0o interested in this and talking on discord about it. Is it possible to join as well? (as a faster means of communication)

I wouldnt mind at all but I'm not really sure that would be the easiest path, given
@dushitov (not really sure if they are in the discord) probably has a less
complete but better tested lib, and more important, they have the hardware
to test things on, which I unfortunately don't anymore
oh by better tested i mean in real life with real devices
so i m not really sure where to go from here, i think the best step
would be to discuss it with @dushitov directly, maybe they
can integrate the nmea message types I have in my crate,
and we can switch to their

https://discord.gg/RXNsMXc

We've created a dedicated channel for #nmea

Dylan-DPC-zz commented 4 years ago

cc @flxo (who wrote the original nmea crate) as well in case they are interested

flxo commented 4 years ago

@Dylan-DPC Thanks!

And thanks guys for your effort!

Feel free to use the nmea crate name. Most of the code I originally wrote has been (luckily) replaced by @Dushistov work in the meantime anyway... I currently do not have any NMEA related project.

elpiel commented 4 years ago

One last thing, I found another crate dealing with NMEA-0183 and it's also intended for embedded (no_std) + it doesn't have dependencies (I haven't looked through the code though).

https://crates.io/crates/nmea0183 (https://github.com/nsforth/nmea0183)

I am only mentioning it as it might be good to join together or to have diversity in the other case.

Edit: It would have been better if I tagged him as well: @nsforth

o0Ignition0o commented 4 years ago

no_std support is definitely a plus!

For information IIRC I got scared of the BSD-3-Clause license (Which I don't know about at all) on this crate which was the reason why I decided not to go for this one.

EDIT: the BSD3 License seems fine so it's a great idea as well https://opensource.org/licenses/BSD-3-Clause

pwnorbitals commented 4 years ago

Seeing how great the NMEA crate is going, can this issue be closed, or is any other complementary crate needed ?

o0Ignition0o commented 4 years ago

I think Nix has done a super good job so far, and we can close this, we now have one crate, and a good idea of what's left for us to do

AeroRust / WorkingGroup