search

sparkfun / SparkFun_u-blox_GNSS_Arduino_Library

An Arduino library which allows you to communicate seamlessly with the full range of u-blox GNSS modules
Other
228 stars 100 forks source link

Neo M8U HNR-ATT data not changing when physicallly moving the device #143

Closed N129BZ closed 2 years ago

N129BZ commented 2 years ago

In the M8U Dead Reckoning Example 5 for auto HNR-ATT, the roll/pitch/heading data does not change when physically moving the device around.

Workbench

Steps to reproduce

When powering the M8U directly via USB and sending the appropriate UBX-CFG-HNR and UBX-CFG-MSG messages to enable a nav rate of 20hz and receive UBX-HNR-ATT messages, I get good data, i.e., moving the device around the 3 axes produces visible data change in roll, pitch, and heading. (using the U-Center application to communicate with U-BLOX devices)

When using Dead Reckoning Example5_getHNRData example in the Arduino IDE, I commented out the myGNSS.getHNRDyn and myGNSS.getHNRPVT blocks so as to isolate the data to only output from myGNSS.getHNRATT block. I get data output to the serial monitor, but moving the device around does not change the data - it always churns out the exact same numbers for roll. pitch, and heading.

Expected behavior

The roll, pitch, and heading numbers should reflect what is physically happening to the device when it is moved around the 3 axes.

Actual behavior

The roll, pitch, and heading numbers never changed when the device is moved around 3 axes.

PaulZC commented 2 years ago

Hi Brian (@N129BZ ),

Thanks for reporting. It will take me a few days to investigate this. I don’t have hardware with me at the moment.

Meanwhile, please try Example6. Does that give the same result?

Best wishes, Paul

N129BZ commented 2 years ago

Paul - it happens with either of the 2 examples, 5 or 6. I will look deeper to see if it is something simple like a struct not being cleared, etc.

PaulZC commented 2 years ago

Thanks Brian, I will investigate as soon as I have access to hardware. I took a look at the source code yesterday but couldn’t see anything obvious. Best wishes, Paul

PaulZC commented 2 years ago

Hi Brian (@N129BZ ),

I have access to hardware again.

So far, I cannot replicate your issue. I have an M8U connected to a SparkFun ESP32 Thing Plus. I'm running Example5 on the ThingPlus. I also have the M8U connected to u-center via USB. I see the same readings on both ports:

image

The Roll, Pitch and Heading do not change on either interface as I move the board.

It's always been my understanding that you have to calibrate the M8U before the orientation becomes valid. (By driving it around for a while.)

Is it possible that the M8U was calibrated when you were using u-center. And that you disconnected and reconnected the power before running the library example - with the M8U then uncalibrated?

Please try a test for me:

Best wishes, Paul

N129BZ commented 2 years ago

Hello Paul -

I should pre-qualify any results by letting you know that I actually had done the suggested calibration stuff before reporting the issue, by running the device off my laptop while driving around. (They suggest several right and left turns at 30 mph.) I don't know if that calibration stays on the device even if it has gone through the "Revert to default configuration" process.

I performed the test as you outlined, using USB from the device in U-Center. In a few minutes I confirmed that the u-blox was locked onto 24 satellites. I reverted the configuration to default, enabled the HNR rate of 10hz, and then enabled the UBX-HNR-ATT message.

The 3-axis data stayed static for a minute or so, and then after letting it sit for a couple minutes I moved the device around again. It definitely changed pitch, roll, and heading - as I moved/rotated/flip-flopped the device around.

I then repeated my original test using the RedBoard via USB to my laptop, with the M8U connected via Qwik cable to the RedBoard.

I opened up Example6 getAutoHNRData in the Arduino IDE. I commented out the if blocks for the usingAutoHNRDyn and usingAutoHNRPvt logging code, so the only message being processed in the serial monitor was the hnrATT message. After letting it sit for a couple minutes, the data would not change while I maneuvered the device.

It looks to me like data is either not being cleared between inputs or existing values are not being compared with new values and replaced when data is coming down the line... but I'm not familiar with the code in Wire.h or any of the "behind the scenes" includes that are being used by the example so I really don't know what is going on there.

The test bed I've been using for my own code is a test strap written in C# that accesses SerialPort. I'm specifically enabling a HNR nav rate of 20hz and the enabling the UBX-HNR-ATT message via config message I send to the device. I'm then reading bytes directly off the Serial Port and parsing the message and logging the data to a CSV file. That data definitely shows the 3 axes changing with device movement. (I'm also logging the PVT message separately and I can re-create a driven path with the Lat/Lon data.)

FWIW, I am also in the process of writing a test strap to test the M8U using i2c on a Raspberry Pi, so I will also be verifying the data from that as well. My ultimate goal is to see if I can incorporate the M8U IMU data into a AHRS application.

Thanks for your attention and I hope I'm not making an issue where none exists! Brian

N129BZ commented 2 years ago

Paul -

I just did another experiment using Arduino IDE with the example 6 code. I put the IDE window and the serial monitor window side-by-side. I would perform an upload in the IDE, and with a cleared serial monitor window immediately start moving the device around. For around 10 seconds or so, the roll/pitch/heading numbers would change as expected, but would then "settle in" on a set of 3 numbers that would not change.

PaulZC commented 2 years ago

Hi Brian,

Thanks for the update. I think we might be in "making an issue where none exists" territory, but I'm not sure.

I'm essentially a desk-jockey. My set-up is all desk-located and my antennas are permanently mounted on the roof. It is not easy for me to perform a 'mobile' test.

If/when you have time, please:

As you perform the calibration, is there a point where the Roll/Pitch/Yaw become well defined? Especially where Yaw accurately follows the heading of your vehicle? If so, then we have our answer.

The library does no additional processing of the HNR-ATT messages, it simply reports their content. As far as I can tell, it is faithfully doing that. My side-by-side comparison of the messages on USB (via u-center) and I2C (via our library and examples) show the exact same content. I can't see a difference.

Best wishes, Paul

N129BZ commented 2 years ago

Paul -

I guess I'm completely misunderstanding the UBX-HNR-ATT message. I thought it was supposed to output the vehicle roll, pitch, and heading. Assuming the sensor is securely mounted in the vehicle and is properly calibrated with any deviations in mount angles either set via a UBX-CFG-ESFALG message defining those angles or optionally the bitmap value for doAutoMntAlg set to 1 so it will "automatically" self-align, shouldn't the UBX-HNR-ATT message contain the current vehicle roll, pitch and heading, and should'nt I expect to see that dynamic data when moving?

In my experiments I'm expecting to see changing numbers, like if I'm cornering in the vehicle and it's leaning, or if I'm going up or down hills, or what heading I'm currently on., and I see those numbers changing when I get the UBX-HNR-ATT message over the USB port in my test application.

N129BZ commented 2 years ago

Another observation: My test setup is Ubuntu Linux 22.04 LTS, .NET Core version 6, using Visual Studio Code latest version, with the Neo M8U plugged into a USB port. With this setup I see immediate change in values when manipulating the device.

My WIndows test platform with U-Center is a Windows 10 virtual machine running on VirtualBox, with the serial port mapped to COM3. Sometimes I do see the same behavior you see when I run in that environment, the numbers don't change when manipulating the device, but other times it works fine. I have attached a screen video showing the values changing quite rapidly as I move the device around. [simplescreenrecorder-2022-07-02_21.05.18.mkv.zip](https://github.com/sparkfun/SparkFun_u-blox_GNSS_Arduino_Library/files/9033961/simplescreenrecorder-2022-07-02_21.05.18.mkv.zip)

PaulZC commented 2 years ago

Hi Brian,

Many thanks for the video - that's helpful. I'm not able to replicate those changing values. The best I could do was to attach my M8U and antenna to my Windows laptop and walk around the garden with them. The HNR-ATT roll, pitch and heading do change - but nowhere near as fast as your values. I suspect it is using values based on the GNSS position, not the built-in sensors.

image

It is possible for you to have both u-center and your RedBoard + Library Example5 running at the same time? If you see the same values in both u-center and on the RedBoard COM data, changing at the same rate, then we know the library is doing its job correctly. (And that everything else is down to how the sensors are 'calibrated' or 'aligned'.)

From my side, I do believe the library is working correctly. I do see the same values from both:

image

Best wishes, Paul

PaulZC commented 2 years ago

Hi Brian,

Just for fun, I put the laptop in the car and went for a drive. I used u-center to log the HNR-ATT messages at 10Hz. The antenna was Blu-Tack'd to the roof rail via a long cable. The signal strengths weren't great, but I did have a 3D fix.

There were times when the HNR-ATT messages were changing every 100ms (see the "Good" video attachment).

Then there were times when the Roll/Pitch/Heading 'froze' and the accuracy degraded steadily (see the "Lost_Lock" video). The messages were still being logged at 10Hz, just the values did not change.

The best ESF-ALG Alignment Status I achieved was "COARSE":

image

In summary, based on this experience, I think is is 'normal' for the ATT data to remain static depending on conditions like: signal reception; whether the sensors are calibrated; etc..

I'd like to close this issue as I think we've proved there's nothing wrong with the library. (But we both have some work to do to understand how ATT behaves!)

Best wishes, Paul

https://user-images.githubusercontent.com/5690545/177031765-1816ae22-706c-4d06-a6c1-c223005ce5f4.mp4

https://user-images.githubusercontent.com/5690545/177031774-a5644453-2c9e-4dd0-8d67-05ab7b3bd1e4.mp4

N129BZ commented 2 years ago

Hi Paul - I agree. I think your experiments are excellent, and the issue can be closed. I now think the differences I see are due to several things, including I have been experimenting with a higher HNR rate (all the way to 30hz) and satellite locks. I don't know where you are located, but here in wide-open Texas Hill Country, I always get a 3D fix and locks on at least 12 satellites, even with a small GPS antenna sitting on my desktop. Thanks for all your effort!!

PaulZC commented 2 years ago

Hi Brian,

Not a problem. We always enjoy the feedback - it keeps us on our toes. Please reach out again if you see anything which isn’t quite right or where improvements can be made. Or if you just need a bit of advice!

Good luck with your project, Paul

N129BZ commented 2 years ago

Paul - thanks for being so responsive. I started experimenting with the Neo M8U because a fellow aviator used one in his Stratux unit (a Raspberry Pi based traffic/ahrs/positioning device: https://github.com/b3nn0/stratux ) and he was getting wildly inaccurate headings. He was surveying pipeline routes and when looking at the Stratux logs he couldn't re-create his routes from the GPS lat/long data... turned out it was the M8U sensor fusion setup. Once he got his ESF mount angles configured, it was perfect. That whole thing got me interested in the device.

Thanks again - SparkFun is AWESOME. Brian