[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
✘NEO-M8U, ADR and UDR
Gary E. Miller
✘NEO-M8U, ADR and UDR
Tue, 29 Jun 2021 19:26:06 -0700
TL:DR: The NEO-M8U is a big disappointment.
The u-blox 8-series and 9-series modeuls have extra cost versions
that add a 6-axis IMU. A bit odd since 9-axis IMU's are customary
The u-blox modules with IMU's are called either Automotive Dead
Reckoning (ADR) and Untethered Dead Reckoning (UDR). The main
difference between them is that the ADR versions also use Wheel Tick
(WT) input(s) for better accuracy.
Sparkfun has a USB-C board with NEO-M8U for $70 now. But do not bother
to buy one unless you are going to bolt it to a car. More on that below.
The ADR and UDR firmware has seen may updates, be sure you have at least
UDR firmware version 1.50 (protVer 19.20), and a copy of gpsd from git
head, to duplicate my results. The new data can flood the serial port,
so direct USB connection is recommended.
External Sensor Fusion Messages:
U-blox added the External Sensor Fusion Messages (UBX-ESF-) to output
the new IMU and WT data. Both ubxtool and gpsd can now decode these new
To poll most of them with ubxtool:
ubxtool -p ESF
Or enable most of them for periodic output:
ubxtool -e ESF
Sadly, this will yield empty data:
iTOW 155049000 version 2 reserved1 20 2 0 0 0 0 0
fusionMode 0 reserved2 0 numSens 6
fusionMode (Initialization mode)
sensStatus1 85 sensStatus2 4 freq 10 faults 0
type (gyro z) used No ready Yes
sensStatus1 8d sensStatus2 4 freq 10 faults 0
type (gyro y) used No ready Yes
sensStatus1 8e sensStatus2 4 freq 10 faults 0
type (gyro x) used No ready Yes
sensStatus1 90 sensStatus2 4 freq 10 faults 0
type (accel x) used No ready Yes
sensStatus1 91 sensStatus2 4 freq 10 faults 0
type (accel y) used No ready Yes
sensStatus1 92 sensStatus2 4 freq 10 faults 0
type (accel z) used No ready Yes
iTOW 155049000 version 1 flags x90 error x0 reserved1 x20
yaw 0 pitch 0 roll 0
flags () status (user-defined/fixed angles)
bitfield0 x1 reserved1 x0 iTOW 155049000
xAngRate 0 yAngRate 0 zAngRate 0
xAccel 0 yAccel 0 zAccel 0
bitfield0 (version 1 )
Note that yaw, pitch, roll, acceleration and angular rates are all zero.
And they stay that way until "Initialization Mode" is complete.
Turning off doAutoMntAlg does not help:
ubxtool -p CFG-ESFALG,0
The ADR part will not output data until the device has been driver
around a bit in a car. Then "Initialization Mode" ends. So ESF-ALG and
ESF-INS are useless for any application other than bolted to a car that
has been moving.
The curious may want to enable periodic output of the semi-processed
sensor data, with an arbitrary time stamp. Worse, the time stamp that
jumps back and forth:
Enable ESF-MEAS, rate ignored, as long as it is non-zero:
ubxtool -P 19 -p CFG-MSG,16,2,1
The sensor data is very noisy, but at least not all zeros.
And to drown in the raw data, with different arbitrary time stamp:
enable ESF-RAW, rate ignored, as long as it is non-zero:
ubxtool -P 19 -p CFG-MSG,16,3,1
Now the time stamps are in order, the data seems to be a bit less noisy,
but the readings are batched, so not good for real time use.
You will quickly tire of that flood of data, so turn it all back off:
ubxtool -d ESF
ubxtool -P 19 -p CFG-MSG,16,2,0
ubxtool -P 19 -p CFG-MSG,16,3,0
High Navigation Rate Messages:
U-blox added the HIgh Navigation Rate Messages (UBX-HNR-) to output
interpolated, and/or dead-reckoning, data by combining (Fusing) the
IMU data wit the GNSS data.
The maximum GNSS solution rate is 2Hz, combined with the ESF data, HNR
solutions can be output up to 30Hz. HNR solutions can even be computed
when the satellite signals are lost (Dead Reckoning).
You can poll the HNR messages:
$ ubxtool -p HNR -v 2
highNavRate 10 reserved 0 0 0
iTOW 160981000 time 2021/6/28 20:42:43 valid x37
nano 9 gpsFix 3 flags x1d reserved1 x2712
lon -1213141213 lat 440688670 height 1114211 hMSL 1135561
gSpeed 7 speed 9 headMot 23703286 headVeh 23703286
hAcc 1447 vAcc 2060 sAcc 182 headAcc 3467072 reserved2 x342a3030
valid (validDate ValidTime fullyResolved)
flags (GpsFixOK WKNSET TOWSET headVehValid)
iTOW 160981000 version 1 reserved1 xf4 7a 0
roll 0 pitch 3575948 heading 23703286
accRoll 2000000 accPitch 2697010 accHeading 3467072
bitfield0 x34300000 reserved1 x2e323432 iTOW 160981000
xAngRate 0 yAngRate 0 zAngRate 0
xAccel 0 zAccel 0 zAccel 0
Note the fix is still 3D, and not GPS-DR. No "Fusion".
But it looks like we are getting roll, pith, yaw (heading) data.
So enable the HNR messages at 10 hZ:
$ ubxtool -e HNR
Then move the M8U around, and confirm the roll, pitch, yaw, acceleration
and angular rate never changes. So much for IMU/DR on the desk...
By default, the receiver will send UBX-NAV-PVT once a second, and
UBX-HNR-PVT about once every 100 milli-seconds. But things are funcky.
I see this, which looks normal:
Followed by NAV-PVT, late:
The rest of the NAV stuff for that epoch, finished by NAV-EOE
And then back to HNR-PVT:
And sometimes before .400 instead of after it. Clients will get
gpsd and clients:
The new data, when sent by the receiver, is decoded by gpsd, and sent on
in JSON ATT and PVT messages. The user can see them in cgps, gpspipe,
xgps and other gpsd clients. Pretty to look at, but not useful until
you can driver around and unlock the sensors...
So much promise, so little delivered...
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
email@example.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
Description: OpenPGP digital signature
|[Prev in Thread]
||[Next in Thread]|
- ✘NEO-M8U, ADR and UDR,
Gary E. Miller <=