[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: InertialSense uINS Support
From: |
Gary E. Miller |
Subject: |
Re: InertialSense uINS Support |
Date: |
Fri, 5 Jun 2020 20:15:09 -0700 |
Yo Isaac!
On Fri, 5 Jun 2020 19:33:20 +0000
Isaac Gutekunst <isaac@safe7y.com> wrote:
> I just purchased a nice, tiny, GPS+INS module from InertialSense:
> https://inertialsense.com/%C2%B5ins-dual/#DUAL-sensors
Cool. Looks like a bare chip?
> 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.
One good way is to put the code you have so far as a merge Reqquest on
GitLab.
Looking at the doc, there are some NMEA extentions that don't look
to hartd to add.
The binary protocol is a bit funcky. I doubt it can coexist with
other binary protocols in gpsd. Could be handled with a special
build, but not in the standard build.
> I have read through https://gpsd.gitlab.io/gpsd/hacking.html, and I
> apologize if I missed something.
That is OK, no one understands it all.
> I plan on adding test coverage, and
> re-reading before submitting a formal patch.
No need. gpsd has built in regression tests, all it needs is sample
data.
> Before then, I have a few questions:
>
> 1. Do you think it will be possible to merge in some MIT licensed code
> from InertialSense?
I have been told by those supposed to know that our BSD 2-Clause is
essentially the same as the MIT License. As long as we keep the
copyright and license notices. You should also ask them.
> There licence is standard MIT:
> https://github.com/inertialsense/InertialSenseSDK/blob/master/LICENSE
A bigger problem is they used C++. There is no, and will not be, c++
in the gpsd daemon. OK for clients, just not the daemon.
Prolly be easier just to re-write in C, using gpsd internals, than
try to port that.
Worse, the code is written non-portably. It assume endianness as well
as structure packeting. It has to be re-written. Nothing on their
GitHub is useable.
> Assuming I fix it and split the state machine to also handle Zodiac
> packets (0xFF, 0x81,...), vs Inertial Sense (0xFF, [0-32],...0xFE),
Is that really Zodiac? gpsd already does Zodiac. If the GPS stuff
is rodiac, and the IMU is kinda sorta almost Zodiac, then shoehorn it
into the Zodiac driver.
> since their driver maintains
> it's own state machine.
That also has to go. gpsd can handle many simultaineous conenctions:
PPS, NTRIP, clients, receivers, TCP, RDP, etc. You have to use
the existing state machine.
> 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
That's gonna need a lot of work. Just removing the duplicate functions,
like RTCM (ISComm.c) and ecef (ISEarth.c) stuff, will take real work.
Some of the stuff is just wrong, like the E_SQ define.
The code style is not the kinda-sorta Linux Kernal style that gpsd
uses. Things like 80 char lines, brace placement, etc. seem simple,
but are tedious to fix.
Code like this is just broken:
#ifdef INERTIAL_SENSE_ENABLE
if (c == 0xff) {
lexer->length = 0;
return character_pushback(lexer, INERTIAL_SENSE_SOF);
break;
}
#endif /* INERTIAL_SENSE_ENABLE */
#ifdef ZODIAC_ENABLE
if (c == 0xff) {
lexer->state = ZODIAC_LEADER_1;
break;
}
#endif /* ZODIAC_ENABLE */
The second c == -xff test is totally masked by the first one. It needs
a major rethink. If the GPS is kinda sorta Zodiac, than stuff like that
gets merged together.
I do not see in packet.c where you handle byte stuffing. That will also
be a PITA.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgpQEOPmMdO42.pgp
Description: OpenPGP digital signature