gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

InertialSense uINS Support


From: Isaac Gutekunst
Subject: InertialSense uINS Support
Date: Fri, 5 Jun 2020 19:33:20 +0000

Hi GPSD Developers,


I just purchased a nice, tiny, GPS+INS module from InertialSense:

https://inertialsense.com/%C2%B5ins-dual/#DUAL-sensors


I'd love to use it with GPSD, and have taken the first steps to hack in
support for it. I wanted to reach out and ask for help and guidance in
getting my code in a good state for merging with the gpsd. 

I have read through https://gpsd.gitlab.io/gpsd/hacking.html, and I
apologize if I missed something. I plan on adding test coverage, and
re-reading before submitting a formal patch.

Before then, I have a few questions:

1. Do you think it will be possible to merge in some MIT licensed code
from InertialSense? 
 
There licence is standard MIT: 
https://github.com/inertialsense/InertialSenseSDK/blob/master/LICENSE


I'm wondering from both a legal and architectural point of view. 

From an architectural and code quality point of view, their SDK is
pretty complete and does packet parsing, and handles some vector math
to transform INS readings into various standard formats. It seems well
written and perhaps valuable code. However, it may duplicate some of
the functionality already in gpsd.

Notably, I've hacked in their parser by looking for 0xFF and then
sending all bytes up to a 0xFE to the InertialSense parser, rather than
added any further parsing to the state machine. Their SDK then handles
determine what packet type it is, and parsing into nice C structures. I
the mostly copy the values over to the newdata fields.  

Assuming I fix it and split the state machine to also handle Zodiac
packets (0xFF, 0x81,...), vs Inertial Sense (0xFF, [0-32],...0xFE),
rather than just slurping up all packets starting with 0xFF, does this
seem like a good way forward?

The other thing that may be objectionable is I've added InertialSense
defined structures into the driver union, since their driver maintains
it's own state machine. I could inline the struct definition, leaving
the burden of keeping it in sync with the header file for future
version bumps of the InertialSense SDK.

I would not be surprised if there are other considerations I've missed,
so feel free to point them out.



Here's the code as is if you want to take a look (I don't necessarily
recommend it yet): 
https://gitlab.com/igutekunst/gpsd/-/commit/1c7339245e124080c077ac3d3e96748be7230dcb



Kind Regards,
Isaac












reply via email to

[Prev in Thread] Current Thread [Next in Thread]