UM982 isn't providing heading data

AngelAlbeniz · November 7, 2024, 4:22pm

Hi,

We were changing settings and I think we ended up with different parameters than the factory settings of Holybro. But we still use the UNIHEADING message.
Attached are some screenshots of the message configuration from Uprecise.

I updated the Uprecise application recently. And I notice that there are a lot of changes in this new version. There are many more messages to configure but I have not been able to find any documentation explaining it.

Do any of you know of any documentation or configurations that people use on these GPSs?

And as for the behavior of MAVLINK inspector. The parameter is not always updated so regularly, sometimes the period is much longer. This might be similar to what you are seeing.

Marc_Schneebeli · November 8, 2024, 7:24am

Hello Angel
Thank you. For me the configuration looks similar to the standard factory settings, maybe with some changes in the update rates.

I have made some additional tests and still I don’t know if the gps heading is actually working or not, I would appreciate if somebody has an explanation for the observed behavior:

Since I only want to use the heading of the GPS I set the PX4 parameters as follows:
SYS_HAS_MAG = 0 # No magnetometer
EKF2_MAG_TYPE = None # magnetometer not used for yaw estimation
EKF2_GPS_CTRL = 15 # use dual gps heading

After this, I observe the dual gps heading measurement as well as the telemetry yaw:
->MAVLINK Inspector: → GPS_RAW_INT → yaw: 3521xx → i.e. 352.1 degrees
→ correct value (verified with an external compass)
->MAVLINK Inspector: → ATTITUDE → yaw: 0.028… → i.e. 0.028/pi*180 = 1.604 degrees → wrong (maybe due to magnetic interference)

In addition, I have a ‘No valid local position estimate’ , and ‘no valid global position estimate error’, so I can’t take off.

Then I change
SYS_HAS_MAG = 1

→ MAVLINK Inspector: → GPS_RAW_INT → yaw: 0 (i.e., yaw not provided by GPS)
→ MAVLINK Inspector: → ATTITUDE → yaw: 0.01

‘No valid local position estimate’ and ‘no valid global position estimate error’ persist.

Finally:
SYS_HAS_MAG = 1
EKF2_MAG_TYPE = AUTOMATIC

→ MAVLINK Inspector: → GPS_RAW_INT → yaw: 0 (i.e., yaw not provided by GPS)
→ MAVLINK Inspector: → ATTITUDE → yaw: -0.433 → 360-0.433/pi*180 = 335.2 → wrong

I only get yaw in GPS_RAW_INT if the magnetometer is disabled. However, this yaw value then does not correspond to the telemetry yaw and the drone can’t take off. So if anybody has an idea on how to use the gps yaw, I would be happy to know. Thanks

AngelAlbeniz · November 8, 2024, 8:32am

Hi Marc,

The configuration I use to fly with this GPS is almost identical to the one you put in the first case.

SYS_HAS_MAG = 0 # No magnetometer
EKF2_MAG_TYPE = 5 / None # magnetometer not used for yaw estimation
EKF2_GPS_CTRL = 11 # to use dual gps heading and not use 3D velocities

This are my GPS configuration parameters:

With this configuration my vehicle flies using only the GPS YAW.

Regarding the problem of not obtaining local and global position for arming with this setup. As I explained in one of the previous posts, in my case it is also difficult for the vehicle to obtain its global position. For one thing it has to have good GPS reception in an open area. And also sometimes I have 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 it fixes global position.

On the other hand, I believe that this GPS does not report vertical and horizontal accuracy values (EPV and EPH) properly. Testing this GPS against other units (Ublox F9P or Ublox M8N) all without RTK corrections. I have the feeling that this one (Unicore) has better accuracy since in landing it consistently lands with an error of less than 20cm and the Ublox units can easily have an error of 1m to 1.5m in landing. But the Unicore reports very bad EPH and EPV values (3.5m and 5.5m respectively). This is why I have had to raise the EKF2_REQ_EPH and EKF2_REQ_EPV values. Without these values raised, the drone does not fix the gobal position on the ground and can get navigation failsafes in flight.

I recommend that you look at the flight LOGs to see what EPH and EPV values you are getting from the GPS and raise the EKF2_REQ_EPH and EKF2_REQ_EPV accordingly.

dronesalot · November 8, 2024, 12:47pm

I encountered similar issues with my UM980. It isn’t the Holybro unit, instead just an embedded module connected to a UART. I have found multiple issues with the NMEA implementation, and although I’ve patched and tested them, I haven’t yet figured out how to submit the fixes. From what I can tell, QGroundControl becomes angry when it sees an update rate of 0.

I didn’t fully understand the intent behind the NMEA implementation, so I hesitate to point fingers saying it’s “wrong”. Have a look here:

github.com/PX4/PX4-Autopilot

[Bug] NMEA Protocol doesn't keep stats

opened 12:25AM - 07 Nov 24 UTC

dronesalot

bug-report

### Describe the bug When PX4 is connected to a NMEA GPS unit (UM980 in my case…) the GPS status reports a rate of 0 B/s and an update rate of 0hz. Typical output shown above. ### To Reproduce connect a NMEA GPS to a serial port and configure it as a GPS. Run gps status and examine the results: Connect the drone to a NEMA GPS. Run gps status. nsh> gps status ``` INFO [gps] Main GPS INFO [gps] protocol: NMEA INFO [gps] status: OK, port: /dev/ttyS5, baudrate: 921600 INFO [gps] sat info: enabled INFO [gps] rate reading: 0 B/s INFO [gps] rate position: 0.00 Hz INFO [gps] rate velocity: 0.00 Hz INFO [gps] rate publication: 0.00 Hz INFO [gps] rate RTCM injection: 0.00 Hz sensor_gps timestamp: 1166797117 (0.077381 seconds ago) timestamp_sample: 0 ``` ### Expected behavior I have already developed a patch, although I have identified some additional issues with the GPS code, This is the result from the patched code. ``` nsh> gps status INFO [gps] Main GPS INFO [gps] protocol: NMEA INFO [gps] status: OK, port: /dev/ttyS5, baudrate: 921600 INFO [gps] sat info: enabled INFO [gps] rate reading: 3299 B/s INFO [gps] rate position: 5.00 Hz INFO [gps] rate velocity: 2.00 Hz INFO [gps] rate publication: 6.79 Hz INFO [gps] rate RTCM injection: 0.00 Hz sensor_gps timestamp: 34211212 (0.029154 seconds ago) ``` I haven't yet figured out how to submit a patch, but this issue is fixed with the following: ``` diff --git a/src/drivers/gps/gps.cpp b/src/drivers/gps/gps.cpp index dff88ecbdc..9a6825f95b 100644 --- a/src/drivers/gps/gps.cpp +++ b/src/drivers/gps/gps.cpp @@ -475,6 +475,9 @@ int GPS::pollOrRead(uint8_t *buf, size_t buf_length, int timeout) if (_interface == GPSHelper::Interface::UART) { ret = _uart.readAtLeast(buf, buf_length, math::min(character_count, buf_length), timeout_adjusted); + if (ret > 0) { + _num_bytes_read += ret; + } // SPI is only supported on LInux #if defined(__PX4_LINUX) ``` ``` diff --git a/src/nmea.cpp b/src/nmea.cpp index a330c9a..3941bd5 100644 --- a/src/nmea.cpp +++ b/src/nmea.cpp @@ -853,13 +853,19 @@ int GPSDriverNMEA::handleMessage(int len) _gps_position->satellites_used = MAX(_sat_num_gns, _sat_num_gsv); } - if (_VEL_received && _POS_received) { + /** update the stats for the velocity. */ + if (_VEL_received) { + ret = 1; + _VEL_received = false; + _rate_count_vel++; + } + + /** update the stats for the velocity. lat/long is considered to be a gps position update whereas velocity may not be */ + if (_POS_received) { ret = 1; _gps_position->timestamp_time_relative = (int32_t)(_last_timestamp_time - _gps_position->timestamp); _clock_set = false; - _VEL_received = false; _POS_received = false; - _rate_count_vel++; _rate_count_lat_lon++; } ``` ### Screenshot / Media _No response_ ### Flight Log _No response_ ### Software Version I'm running PX4 v 1.15.1 on a CubePilot Orange ### Flight controller _No response_ ### Vehicle type Multicopter ### How are the different components wired up (including port information) _No response_ ### Additional context _No response_

Someone has added a dedicated unicore parser to process some of their extended message types, so your accuracy may also be related to the parsing of standard NMEA messages. As soon as I manage to get the RTK correction data going to the unicore module, I will tackle this issue separately.

dronesalot · November 8, 2024, 1:07pm

Here is what I have. Some are not used (yet) as I’d like to re-write the parser so it can understand more messages, and decode them in a more efficient way. I suggest adding the following 3 items.
VTG provides heading information.
ZDA provides time info (may not be useful)
GNS gives you HDOP and altitude

ROT not parsed yet.
GRS not parsed yet.
GLL not parsed yet.
DTM not parsed yet.
THS not parsed yet.
GBS not parsed yet, but mentioned in the comments of the source (typo perhaps)

Now, the final point, all the NME for Unicore extensions are special as they add heading information. Since my unit is the 980, it doesn’t implement these, but I suspect in your application, they may be needed. Hope to have more info when I get my own RTK going.

JulianOes · November 11, 2024, 2:14am

Thanks for your message!

I think that’s exactly right.

Regarding velocity estimates, could you try out these improvements:

AngelAlbeniz · November 14, 2024, 8:03am

Hi,

As suggested by @dronesalot I tried to add 3 more NMEA messages to the UNICORE output. With UPrecise I added NMEA VTG, ZDA and GNS messages on top of the messages I was already outputting.

With this modification I have done more tests and further problems occur. Spikes appear in altitude and HDOP readings. I noticed these spikes looking at MAVlink inspector but thought it might be the same visualization bug that occurs with heading data. But no, looking at the flight LOGs, it becomes clear that they are spikes in the parsing of this data.

What I think is happening is that when adding these messages there is some error in the GPS driver where in some read / parse cycles there is some error and the data is read wrong for those values.

Removed the output of these messages it works “fine” again.

What I think happens to this GPS is that being relatively new and much less common and less used than Ublox GPSs. Therefore its integration with PX4, its driver, is neither as developed nor as tested. So under an exact configuration you can make it barely works, but with multiple bugs and problems as we are commenting in this post. Correct me if you think otherwise.

.

Fira · November 17, 2024, 2:51pm

Reviewing the sensor’s orientation and ensuring it’s calibrated correctly for heading data output. It may also be worth checking if the proper parameters are enabled for the sensor’s data stream in the firmware.

dronesalot · November 18, 2024, 6:45pm

Not sure how to get the pull request approved, but I’ve found the fixed the issue here:

github.com/PX4/PX4-GPSDrivers

bugfix: altitude parsing problem

PX4:main ← dronesalot:GPS-NMEA-fixes

opened 04:58PM - 17 Nov 24 UTC

dronesalot

+78 -19

### Solved Problem The NMEA format allows for multiple fix quality characters. …The default implementation allows only 4 of these items to be parsed from the stream. When using a newer UM980 GPS unit, it supports 5 different types and causes the parser to mis-read the altitude message. This results in the GPS altitude jumping to 0 whenever a GNS message is received. This resolves the issue by ignoring any additional characters in the parsed message. The PR also adds the ability to intrepret GLL messages from the GPS. Fixes #23903 ### Solution - fixes a bug in the NMEA parsing that is specific to newer GPS units ### Changelog Entry For release notes: ``` Feature/Bugfix Add parsing for the GLL message and fix a parsing bug in the GNS if posMode is more than 4 chars

It turns out the UM series of GPS units supports more satellite systems than the parser could handle. This was causing the GNS message to be incorrectly parsed. As a result, the GPS altitude would jump up and down.

The patch should be very easy to apply to earlier firmware versions as I’ve run and tested it on the 1.15.2 series.

hamid_sadeqzadeh · January 22, 2025, 12:56pm

Hello. Did you solve the problem? I also have the problem of manually moving the bird before taking off to make the bird’s head visible.

AngelAlbeniz · January 29, 2025, 9:57am

Hi,

I have been doing some testing on the new version which has these fixes. For one thing, I can confirm that the GPS speed problem seems to have been fixed. The sensor_gps.00/vel_d_m_s now parses and logs correctly.

So I am going to try to reactivate the use of 3D velocity in the EKF2_GPS_CTRL parameter, which I had disabled, and make a test flight.

On the other hand, I see that many other things are still not working properly.

The heading value in sensor_gps.00/heading is still not logged. Although it is parsing correctly as it can be seen live in QGC Mavlink inspector.

The flag cs_gnss_yaw, which indicates whether gps yaw is being used, is never set to 1, even though the yaw measurements given by Unicore are being used correctly. And I can confirm that as the drone navigates in flight correctly and shows the correct heading in QGC and has no other heading source such as a compass in use.

And finally, the problem that bothers me the most. When initialize the drone and leave it still on the ground, no matter how long you wait it never fixes global position until you “move it”.

It remains constantly in a state where it has not performed the Heading alignment (Local frame orientation), so the drone heading is still seen in QGC as 0 even though it is already receiving heading data from Unicore (it is seen in Mavlink inspector). In addition, GNSS data fusion has not yet started.

When the drone is moved all this things happen at once. The heading alignment (Local frame orientation) is performed, the GNSS data fusion start and therefore the global position is fixed.

As to what I mean by “ move the drone”. I have done multiple experimental tests and have concluded that what it needs is to be moved horizontally with a certain speed. Rotating it about any axis, regardless of the rotational speed and without horizontal movement, has no effect. In addition, moving the drone horizontally, very very slowly, regardless of the distance it moves, has no effect either. The key is to move it horizontally, it does not need to be a long distance (around 1m is enough), but with a certain speed measurable by GPS.

The only thing I can think of is that a certain GPS speed is needed to get a ground course measurement and there is some confusion between ground course and heading that prevents the heading alignment from being performed. This is purely my speculation and I have not been able to verify it.

If someone could help me out and try to figure out what might be going on with this last thing. I would appreciate it very much.

I attach flight LOGs, from boot and disarmed, where this event con be seen (I download the log and analyze it in PlotJuggler):

https://review.px4.io/plot_app?log=78232b58-eb00-4078-8f60-5eb129246d4f

https://review.px4.io/plot_app?log=57174495-6172-4dd2-b977-911eedb8c1a1

If any of you can think of a test I can perform, let me know and I will do it.

Thank you!

JulianOes · February 3, 2025, 8:07pm

Thanks for your report. I have not seen these issues myself. I wonder if the problem happened because of whatever merge or submodule checkout you were doing… From the logs, I can’t tell which version exactly that you’re using.

AngelAlbeniz · February 4, 2025, 7:54am

You probably won’t be able to see which version I’m using because I am running APX4 3.2.1 over and Auterion Skynode X flight controller. But this version of APX4 should be almost identical to the latest release of PX4 (1.15.2).

Nevertheless this problem is not new to this version of PX4, its been occurring to me since I’m been using this Unicore hardware. I was hoping that with some of the fixes that have been made this problem would also be over. But I see that it has not. I also see, from other people who have written here. That the problem is not only mine.

Feel free to ask me for more feedback or questions about this problem.

JulianOes · February 4, 2025, 11:43pm

You need my fixes from PX4 v1.15.4 of which the tag doesn’t exist yet, so you need the latest release/1.15 branch.

I’ll try to get a v1.15.4 branch out soon.

AngelAlbeniz · February 5, 2025, 7:54am

Hi,

I was told by Auterion than the fixes regarding this issue were included in the last version of APX4 (3.2.1). I see that there can be confusion on this. I myself am not sure what changes are or are not included in this release. Release notes don’t say anything about any of these issues related to Unicore. The only thing I have been able to verify is that now the GPS down velocitie is being parsed and logged correctly and I can use GPS velocities.

Please, if you can, let me know when you release the new branch or make any changes about this matter.

Thanks for your help,