UM982 isn't providing heading data

MuhammadBilal1 · November 8, 2023, 11:10am

Hi,
We bought H-RTK Unicore UM982 (Dual Antenna) from Holybro a few months ago to use in our UAV.

Purpose of using UM982:
The purpose of buying this item was to fix the YAW problem (UAV not turning in Mission flight) which was due to the higher amount of EMF around the GPS module (M8N) and the Pixhawk 4.

UAV Setup details:

GPS Module: H-RTK Unicore UM982 (Dual Antenna)
AutoPilot: Pixhawk 6C (GPS port 1)
Firmware: PX4 (1.14.0 stable)
Antennas Configuration: Primary Antenna (Nose), Secondary Antenna (Tail) (distance among both is almost 50cm)

We followed all the installation instructions on the PX4 and Holybro UM982 websites.

Issue:

We aren’t getting the data of the heading. Moreover, we are losing the GPS position data as well.
Our UAV shows it’s in position flight mode, but the logs show the position data is missing during the flight (Position mode).
We tried to do a mission flight, but it immediately went to Altitude mode because of no global position. Here (flightreview) is the log of that flight.

Verification of Heading Data on Uprecise application:
To verify the heading data from the UM982, we connect the UM982 directly with laptop using the USB C type cable and installed the Uprecise application.

Upon checking the heading information from the “Messages” tab under the “NMEA” section, we found out that the “HDT” & “TRA” are disabled and no heading data is available in the “VTG” tab also.

We checked the configurations under the “Receiver Configurations - Message configuration” and found out that all “NMEA Message” protocols are unchecked.

Upon enabling all options under the “NMEA Message” and HEADING/HEADING2 options under “Unicore Message”, we found out that now heading information is appearing in the “Message - VTG”. After seeing the data of heading in “Message - VTG”, we connected the UM982 with Pixhawk as told above, but still the heading data isn’t available in the mavlink inspector section.

We then again connected the UM982 with laptop via USB C cable, and found out that the “Message - VTG” is again not showing the data.

Upon disconnecting and connecting the UM982 again to laptop after saving the “NMEA Message”, the heading data goes away. (Maybe an EPROM issue)

Tried solutions?
1- We reset the UM982 module using the Uprecise application and the instructions from the Holybro documentation. But the result is same.
2- Tried the command UNIHEADINGA COM1 0.2 in Uprecise. But still the result is same.
3- Tried the following commands, but the solution is still not working.

FRESET
GPGGA COM1 0.2  
GPRMC COM1 0.2
AGRICA COM1 0.2
UNIHEADINGA COM1 0.2
config com1 230400
saveconfig

All the detailed snapshots are attached with this post.
Please do let us know if you need more information.

JulianOes · November 10, 2023, 10:12pm

One comment on “heading: nan”. This is because the heading field is always immediately set back to nan after a value is published. So when you do gps status, it’s likely nan.

This means that heading should still work even if you see NaN there.

Now, do you have a flight log, or just a log outside where it logs GPS data? If so, please upload it with logs.px4.io and share the link here, and I’ll take a look.

MuhammadBilal1 · November 11, 2023, 6:27am

Yes, I do have the logs.

Here are the links of flight logs we carried with the installation of UM982.

Log # 1 - Mission flight:
https://review.px4.io/plot_app?log=ad2586c0-763f-4b6f-b5e5-98e8bfcb896b

Log # 2 - Position flight:
https://review.px4.io/plot_app?log=b8b0652c-2c53-4df4-b1b6-8685845aac8c

Log # 3 - Position flight:
https://review.px4.io/plot_app?log=d470865e-2b65-4d76-b51f-9dc459acb7be

JulianOes · November 12, 2023, 7:54pm

Right, I don’t see any heading information in the log.

Can you try building from latest release/1.14 branch (not tag) which includes this [BACKPORT v1.14] gps: update submodule by julianoes · Pull Request #22019 · PX4/PX4-Autopilot · GitHub.

So it would be something like:

git switch release/1.14
git pull
git submodule update --init --recursive

And then clean build and flash.

MuhammadBilal1 · November 16, 2023, 11:46am

@JulianOes
I created the new build from the branch that you gave.
Performed a flight from that build and the log is given below.

Log: https://review.px4.io/plot_app?log=a01230a5-f710-4b05-a89f-248c8e557762

I didn’t feel any difference in the performance, but actually, the behavior was aggressive.

JulianOes · November 17, 2023, 1:57am

Thanks for testing. I still don’t see it.

I will have to test this next week.

JulianOes · November 20, 2023, 10:39pm

Ok, I’m trying to reproduce this.

I have flashed latest release/1.14 branch (not the v1.14.0 tag).

And I see this:

    heading: nan
    heading_offset: 0.00000
    heading_accuracy: 0.01496

So heading is nan because it gets overwritten after publishing with NaN each time, however, heading_accuracy is set and tells me it’s working.

And actually, in one of your screenshots above I can see it working as well!

JulianOes · November 20, 2023, 10:54pm

I did a quick test flight and you can see that the heading accuracy is logged but heading itself is not. (I will create a pull request to fix logging of heading for the future.)

You can also see that heading is used in the estimator though.

MuhammadBilal1 · November 21, 2023, 2:00am

Ok.
I will also try to test again in a couple of days hopefully, but what about the test I had done with my drone?

Log # 1 - Mission flight:
https://review.px4.io/plot_app?log=ad2586c0-763f-4b6f-b5e5-98e8bfcb896b

It just rejected the Mission flight mode from the arming and went to Altitude mode.

JulianOes · November 21, 2023, 4:56pm

But it’s in position mode?

MuhammadBilal1 · November 21, 2023, 6:25pm

Sorry, sent the wrong log.
Here is the correct log link:
https://review.px4.io/plot_app?log=778ab7a8-7553-4c9a-b3b8-405423cb188e

We gave a mission and the drone immediately switched to the “Altitude” mode.
Message is visible in the Log messages.

JulianOes · November 23, 2023, 3:55pm

I had a look at the log and I see estimator_status.filter_fault_flags go from 0 to 65536. This means bit 16 is set which is:

github.com

PX4/PX4-Autopilot/blob/a99a7d2abdad4c8f804aabc3bbcddadff0ed8fda/msg/EstimatorStatus.msg#L67


      
          # 6 - true if fusion of the synthetic sideslip constraint has encountered a numerical error
          # 7 - true if fusion of the optical flow X axis has encountered a numerical error
          # 8 - true if fusion of the optical flow Y axis has encountered a numerical error
          # 9 - true if fusion of the North velocity has encountered a numerical error
          # 10 - true if fusion of the East velocity has encountered a numerical error
          # 11 - true if fusion of the Down velocity has encountered a numerical error
          # 12 - true if fusion of the North position has encountered a numerical error
          # 13 - true if fusion of the East position has encountered a numerical error
          # 14 - true if fusion of the Down position has encountered a numerical error
          # 15 - true if bad delta velocity bias estimates have been detected
          # 16 - true if bad vertical accelerometer data has been detected
          # 17 - true if delta velocity data contains clipping (asymmetric railing)
          
          float32 pos_horiz_accuracy # 1-Sigma estimated horizontal position accuracy relative to the estimators origin (m)
          float32 pos_vert_accuracy # 1-Sigma estimated vertical position accuracy relative to the estimators origin (m)
          uint16 innovation_check_flags # Bitmask to indicate pass/fail status of innovation consistency checks
          # 0 - true if velocity observations have been rejected
          # 1 - true if horizontal position observations have been rejected
          # 2 - true if true if vertical position observations have been rejected
          # 3 - true if the X magnetometer observation has been rejected
          # 4 - true if the Y magnetometer observation has been rejected

→ # 16 - true if bad vertical accelerometer data has been detected

Axel_Schnitger · September 11, 2024, 11:15am

Hi @MuhammadBilal1 did you solve the problem? I´m looking for purchasing that GPS and I want to know if it works properly.

Thanks in advance.

MuhammadBilal1 · September 11, 2024, 6:05pm

Hi,
No, the UM982 didn’t worked for me. The GPS wasn’t providing the required data.
I switched to SIRIUS RTK GNSS ROVER (F9P + RM3100) and it’s working fine.

Vincentpoont2 · September 12, 2024, 6:04am

@JulianOes Any idea what happened in this case? This GPS is being used by many others in PX4 without issue.

javiAldazabal · September 12, 2024, 1:49pm

It seems that two Holybro’s DroneCAN H-RTK F9P Helical GPS neither provides with the heading. Is that configuration process correct?

dbitetto · September 12, 2024, 7:11pm

Hi Muhammad,

The H-RTK Unicore UM982 (Dual Antenna) has not worked for me. The GPS was not providing the heading.

So this device SIRIUS RTK GNSS ROVER (F9P + RM3100) works and it s easy to configure for position and heading?

JulianOes · October 25, 2024, 6:33am

I’m sorry but from the logs that @MuhammadBilal1 provided I was not able to actually see what the problem was.

AngelAlbeniz · October 30, 2024, 12:05pm

Hi,

I am going to share with you my experience using the Holybro H-RTK Unicore UM982 modules to see if this can help you. I would also like to ask for some help with the problems I am having with them now.

I have been using these modules in two quadcopters for a few months now, and what I can confirm is that the heading works. In configuration I have all the compasses disabled and the vehicle flies and navigates correctly only with the GPS heading. The correct behavior of the heading can be checked using the QGC MAVLink Inspector and looking at the GPS_RAW_INT/yaw. If you rotate the drone, outdoors with a good GPS fix, this value should change indicating heading.

One strange thing I see in MAVLink Inspector is that the YAW value updates slower than the rest of the GPS values, so then it oscillates between value 0 and the correcte value, creating a “saw tooth” on the graph. I think this is only a visualization problem of MAVLink Inspector because the drone then navigates correctly. But I could be wrong.

On the other hand, due to what I believe to be a bug in the PX4 logger, the GPS heading (sensor_gps.00 / heading) is never logged.

With the first flights we had many problems with the altitude estimation, where the altitude estimation (calculated by the EKF) and the measured altitude (by baro, GPS and distance meter) differed a lot and caused fast and dangerous ascents and descents. At first we thought that these problems might be caused by the laser rangefinder. But in the end we found out that the cause of the problem was the GPS.
The UM982 does not report the Z speed correctly. It always reports 0, which confuses the EKF and causes these problems.

We solved the problem by setting the parameter EKF2_GPS_CTRL to value 11 so that EKF2 doesn’t use the velocities reported by the GPS in the estimations. With the disadvantage that this way it also does not use horizontal speeds N and E, which are correct.

With this configuration we have performed many successful flights. But from time to time we have navigation errors and this is where I would like to ask for your help / feedback.

In one hand when we power on the vehicle, it does not fix its global position, although it has an excellent quality of GPS fix. The only way to get it to set the global position is to manually lift it off the ground and move it (rotate it an move it few meter, an place it again in the landing pad) only then we can take off in “Position” or “Auto”.
This is a very serious problem for us since this vehicle is intended to operate autonomously and unattended from a nest. Therefore, it cannot be moved manually before takeoff.

And on the other hand, and the most serious problem, is that very occasionally in some flights we have a serious navigation error. Where in mid-flight the EKF loses navigation, the GNSS data fusion stops and a navigation failsafe is triggered. If in manual flight mode “Position” is switched to “Altitude” and if in “Auto” is switched to “Land”.

This is a very serious problem for us since we normally fly big missions in auto and a navigation failure results in a “blind landing” which is very dangerous. In these navigation failsafe events the accuracy reported by the GPS (epv and eph) spikes over the maximum values fixed in EKF2_REQ_EPH and EKF2_REQ_EPV.

We do not know why this happens only on some flights as these accuracy metrics remain low on all other flights. We have flights where we use RTK corrections where these metrics are kept very low. But there are flights where we do not use RTK corrections but these values also remain below the maximums.

Flight logs attached:

Good flights, no erros, navigating with only GPS heading:
With RTK: https://review.px4.io/plot_app?log=d2f76546-05c2-4378-b2ee-f08542c942bf
With RTK: https://review.px4.io/plot_app?log=25c3a8f8-8887-4b80-8422-96be416d1242
No RTK: https://review.px4.io/plot_app?log=cdfe0c48-87a9-4689-96e5-31b4b2b6ba9d
Navigation error in flight:
No RTK: https://review.px4.io/plot_app?log=27f57e57-38a0-4014-aeaf-cbffae0389ef
In ground, no global position until moved:
No RTK: https://review.px4.io/plot_app?log=f65c2a43-8424-4da6-aca9-1290a110a5e1

Marc_Schneebeli · November 7, 2024, 12:35pm

Hello
Thank you for sharing your experience. I would be interested to know how your UM982 is configured. Did you use the the holybro factory configuration (i.e., with UNIHEADINGA enabled)? Could you share how the messages provided by the UM982 look like, e.g., by connecting it to the Uprecise tool (which is not the most user friendly application). I’m experiencing a similar behavior as you do, especially with respect to the YAW value updates in GPS_RAW_INT observed in MAVLINK inspector, with the difference that the values appear less regularly than yours. As a consequence, I’m still unsure if this item is actually suitable for obtaining heading estimates.

Topic		Replies	Views
Verifying GPS Use for Heading PX4 Autopilot	6	279	January 29, 2025
Firmware v1.15 stable _ GPS not detected _ CUBE orange _ Herelink PX4 Autopilot	16	418	November 6, 2024
Position drift and wrong takeoff altitude Flight Testing & Log Analysis	20	3431	April 8, 2019
GPS horizontal drift and disarm after arming QGroundControl	24	7536	December 1, 2019
PX4 offboard mode( EKF2) not working with px4 mini fmuv5 - ERROR in odometer message, and also cannot see vision_pose(mocap data is published and advertised) topic in uorb command Flight Testing & Log Analysis	31	3825	July 19, 2019

UM982 isn't providing heading data

Related topics