px4 / px4-gpsdrivers

Platform independent GPS drivers

GPS Drivers

Overview

This repository contains user-space gps drivers, used as a submodule in PX4-Autopilot and QGroundControl.

All platform-specific stuff is done via a callback function and a definitions.h header file.

In order for the project to build, definitions.h must include definitions for sensor_gnss_relative_s, sensor_gps_s and satellite_info_s. For example, check the implementation in PX4 Autopilot or QGroundControl.

Parser tests

To test parsers, build and run the cmake project:

cmake -Bbuild -H.
cmake --build build && build/gps-parser-test

px4-gpsdrivers's Issues

Convert ITOW to UTC

In GPSDriverUBX::payloadRxDone(), an ITOW value is incorrectly stored into a UTC field (see here). There's a TODO comment to update this. I'm unsure how to convert correctly (is the surrounding code a good example?) or I'd submit a PR with the patch myself.

where can I find the implementation of gps_absolute_time() ?

Where can I find the implementation of the function gps_absolute_time() used in ubx.cpp?

Feature Request: SPARTN compatiblity

Hello,

I open the discussion regarding SPARTN integration in PX4. In my case, I use SPARTN with PointPerfect (from ublox). I succeed to forward the SPARTN data through UART to ublox device by doing the following:

• Add parameter in ubx.h #define UBX_CFG_KEY_CFG_UART1INPROT_SPARTN 0x10730005
• Enable it in ubx.cpp cfgValset<uint8_t>(UBX_CFG_KEY_CFG_UART1INPROT_SPARTN, 1, cfg_valset_msg_size);
• Send the data with send_rtcm_data() function of MAVSDK

Using ucenter, I can see the SPARTN package received but it never switches to RTK mode (which it does if I send directly the same data without going through PX4)

I guess the limitation of 180 bytes of the GPS_RTCM_DATA could be an issue as we have sometimes bigger messages.

Happy to share my work and see how we can successfully integrate this functionality in PX4 !

Feature Request: Enable and Parse RXM-COR and RXM-RTCM messages from a UBX module

UBX-RXM-COR: Differential correction input status
UBX-RXM-RTCM: RTCM input status

These two messages give visibility into the RTCM input status. This would be very useful during debugging or checking whether RTK is working correctly. The proposal is to enable these 2 messages on the module, add logic to parse these messages in the driver, and then publish the important status information to a uORB topic.

sensor_gnss_relative_s type not defined

Since #101 there is the type sensor_gnss_relative_s introduced which is nowhere to be found, unless you build within PX4.

@dagar.

Feature Request: Implement configuration of used GNSS systems

Many GPS receivers are also capable of receiving other GNSS systems, like GLONASS, Galileo and BeiDou. But it depends on the factory settings, which systems are enabled by default. It would be quite useful to have a way to configure the set of GNSS systems used.
See PX4/PX4-Autopilot#16370 for details and discussion on how the parameter should be designed.

This issue should keep track on the state of implementing this new PX4 parameter in all the GPS receiver drivers:

• Ashtech
• Emlid Reach
• Femtomes
• MTK
• SBF
• uBlox

GNSS accuracy loss for Trimble MB-two caused by wrong Type casting

Reproduced on: PX4-Autopilot 1.13.0 beta2
Symptom: lat and lon has only zeros after decimal point

Our Pixhawk6C with v1.13.0 beta2 cannot parse GNSS message from Trimble MB-two.
Accessing Trimble module via its built-in web server returns far accurate position.

We assume wrong type cast in 038a13f causing this problem.
I'm trying to build a firmware with fixed code, which I haven't succeeded yet.

Old:
_gps_position->lat = static_cast<int>((int(lat * 0.01) + (lat * 0.01 - int(lat * 0.01)) * 100.0 / 60.0) * 10000000);
New:
_gps_position->lat = static_cast<int>((static_cast<int>(lat * 0.01) + static_cast<int>(lat * 0.01 - int(lat * 0.01)) * 100.0 / 60.0) * 10000000);
Suggestion:
_gps_position->lat = static_cast<int>((static_cast<int>(lat * 0.01) + (lat * 0.01 - static_cast<int>(lat * 0.01)) * 100.0 / 60.0) * 10000000);

After fixing the baudrate, M8N module can not be detected.

1. GPS Baudrate setting
   If I set the param "SER_GPS1_BAUD" as "Auto", my M8N receiver can be detected and its protocol is UBX, baudrate is 115200, at the same time, the "GPS_RAM_INT" message showed in MAVLINK message.
   But, when I change the "SER_GPS1_BAUD" to "115200", my receiver can not be detected(or half detected), the "GPS_RAM_INT" message did not show in MAVLINK message.
   They are shown below.

2. What's more, my UWB module output as NEMA@115200, and meet the same problem as case 2.

I want to know what wrong with it, thank you very much!

receive function never returns in some conditions for UBX drivers

I don't know if it is intended, but I have the following conditions:

• ret > 0
• _interface == Interface::UART
  => There is no return.
  Because of that, the configure function is never returning and I am stuck in an infinite loop.

https://github.com/PX4/GpsDrivers/blob/e84bb0a7a702320fedade6c83bbdf2324e3be8fb/src/ubx.cpp#L431-L485

Enable SBAS for UBlox

Looking at the code it looks like UBX_CONFIGURE_SBAS is not defined, so it seems for the ublox sbas is disabled. What is the reasoning behind this?

https://github.com/PX4/GpsDrivers/blob/master/src/ubx.cpp#L221

UBX _buf.payload_rx_nav_pvt.nano can become negative

In my setup using an Pixhawk 4 GPS, sometimes the nanoseconds in the UBX_MSG_NAV_PVT can become negative.

This is not a severe problem since PX4-Firmware doesn't use nanoseconds since CONFIG_RTC_HIRES is disabled thus it only uses the epoch in seconds.

Add UBX-CFG-RST to force a Cold Start

I am finding that the Ublox MAX-M8 can get in a bad state when being powered on and off indoors for short periods of time. Once taken outside, it can take 1-2 hours to acquire satellites.

When booting up a fresh MAX-M8 outside, it only takes ~45 seconds to acquire satellites.

On a unit that got into a bad state, I connected it to Ublox U-center and forced a Cold start. The unit then acquired satellites in ~45 seconds. On this design, I am averaging 18-22 satellites, so I'm certain the RF frontend is working well.

The UBX protocol on u-blox 8/M8 from protocol 15 up supports a Cold boot command using UBX-CFG-RST defined in section 31.11.26 UBX-CFG-RST (0x06 0x04) of u-blox8-M8_ReceiverDescrProtSpec_(UBX-13003221)

Holybro UM982 GPS heading

Hello

I am trying to integrate UM982 with Pixhawk cube orange on X500 V2. I followed all the instructions as per the Pixhawk website but could not get the heading from UM982. Later I checked output of UM982 with UPrecise from which i observed was
GPS output:

$GNGGA,091510.00,5057.25505246,N,00653.73013267,E,5,24,0.6,48.3615,M,46.9156,M,1.0,0*54
$GNRMC,091510.00,A,5057.25505246,N,00653.73013267,E,0.004,47.0,090823,2.5,E,F,C*7A
#AGRICA,81,GPS,FINE,2274,292528000,0,0,18,27;GNSS,232,23,8,9,9,15,10,5,4,7,5,6,-0.9135,1.4475,-0.0400,0.0541,0.0978,0.1225,0.5867,-0.4194,0.0000,0.003,0.001,0.002,-0.002,0.051,0.040,0.065,50.95425087438,6.89550221116,48.3615,3996923.3714,483362.5189,4930414.1171,0.0550,0.0981,0.1250,0.1175,0.0941,0.0748,50.95425908545,6.89548161083,95.3171,0.00000000000,0.00000000000,0.0000,292528000,1.000,46.991943,46.915642,0.000000,0.000000,6,0,0,0*c64c9770

Last data command has heading data but autopilot device code does not have any parser to use that data.
So I had to change UM982 output to get it working.
is it supposed to be like that?

UBX with u-blox neo-m9n does not work

I have this GNSS receiver witch uses the new u-blox neo-m9n module.

it appears that this module got rid of a couple of configuration items that are written to by px4's gps driver:

UBX_CFG_KEY_CFG_UART1OUTPROT_RTCM3X
UBX_CFG_KEY_CFG_USBOUTPROT_RTCM3X
UBX_CFG_KEY_NAVHPG_DGNSSMODE

writing to these causes a NAK message to come back and the gnss module to be misidentified as protocol_version<27 by the gps driver.

deleting the relevant lines of code makes my module work flawlessly, but I'm not sure if that breaks compatibility with some older model.

Position and velocity Hz ashtech

I am using the astech driver to another gnss that uses the nmea protocol.
When consulting the gps status in nsh the velocity frequency is 0.
In code, comparing to ublox driver i saw that is missing a _rate_count_vel++. Was that on purpose?

Another issue is that the position frequency is multiplied by 2. I think that is because of the gga and pos message. Is possible that they give differente position coordinates and because that the frequency is double?

Potential bug in GPSDriverUBX::receive

Hello, I'm not sure if this is actually a bug, or the comments are inaccurate.

During configuration phase GPSDriverUBX::receive returns -1. This happens once, and when I ignore it, everything seems to work fine.

I have looked a bit into it, and the cause seems to be in reveive() when handled is set to -1 by GPSDriverUBX::parseChar, which according to the comments should return 0, 1 or 2.

My workaround for now is to ignore the first -1 return, but I'd rather have a clean solution and appreciate any clarification. Thanks.

UBX noise-per-ms and jamming from MON-HW broken

5b146f6 broke reception of MON-HW because _rx_payload_length is reset to 0 before processing the received message.

cant connect Emlid Reach M+

hello . im try to connect Emlid Reach M+ to PX4 but no good luck.
Reach can output ERB, LLH, XYZ, ENU, and NMEA.
The gps driver is working well with ERB format?
Can work with NMEA?

Disabling UBX configuration

Hi all,
In order to share a common GNSS module (F9P) between both payload and drone, it would be nice to have an option to disable the automatic module configuration that takes place in the drivers which would otherwise disrupt the payload operation.
It is already possible to simply use the NMEA interface instead, but this introduces limitations with position precision, RTK heading use etc.
Cheers

SBF GPS Support

Hi @MatejFranceskin thanks for implementing the SBF driver. I wanted to check with you on recent updates from your end since I'd have some small changes I could push.

1. Enable "Support" log on Rover and Base by default, handy when analyzing GPS precision

2. Divide h- and v-accuracy by 2 because they report 2DRMS, otherwise it seems the EPH/EPV values are not comparable with what we get from uBlox for example.

Thoughts?

Plus I could add a PR for supporting it on the PX4 side.

Wrong mapping when reading UBX-NAV-SAT messages

It seems like "used" gets assigned the wrong value.

PX4-GPSDrivers/src/ubx.cpp

Line 1723 in 63990d2

_satellite_info->used[sat_index] = static_cast<uint8_t>(_buf.payload_rx_nav_svinfo_part2.flags & 0x01);

it checks bit 0 of the flags when according to the Interface Description (page 150/151) it should be bit 3.

M9N UART Broken on Latest Commit

I'm working on testing my M9N based CAN GPS. I rebased against master today and discovered that my GPS was no longer working. gps status showed not okay and it was not communicating. Reverting commit f3c4c97 fixes the issue. @Igor-Misic @bkueng

SBF driver

PX4-GPSDrivers/src/sbf.cpp

Line 393 in ddb1825

if (_buf.length <= 4 || _buf.crc16 != crc16(reinterpret_cast<uint8_t *>(&_buf) + 4, _buf.length - 4)) {

If the length bytes are corrupt(_buf.Len is meaningless), the length arg to the crc16 call could overrun and cause hardfault. You can check it for %4 == 0 for sanity, and use _rxReadBytes instead of _buf.len to ensure you don’t go beyond sizeof(_buf)

fyi @skimslozo

@Femtomes did you see my comment here?

@Femtomes did you see my comment here?

Originally posted by @bkueng in #49

Submodule not working

../src/GPS/Drivers/src/ubx.cpp:1981: error: no member named 'heading_accuracy' in 'sensor_gps_s'

Hi,
I've been developing QGC as a hobbyist, and the first I try to compile to QGC, I get this error. Anyway to sort it out??

please share cross platform compile steps

uBlox Protocol Parser Issue with NAV-SAT and NAV-SVINFO

We are experiencing a mismatch between the data in the satellite_info uORB message (and the GPS_STATUS MAVLink message) and the UART data stream from our Pixhawk 4 GPS module. We analyzed the raw UART data stream by enabling the GPS_DUMP parameter in PX4 and adding the corresponding topic to the list of logged topics.

While comparing the code in the driver with the uBlox protocol specification from the M8N module (Release R20, 26 June 2020) I noticed some differences in the data format:

• The repeated structure of NAV-SAT and NAV-SVINFO should be 12 bytes long according to uBlox
• ubx_payload_rx_nav_svinfo_part2_t actually contains 14 bytes. Compared to uBlox:
  • cno should be before elev
  • there should be no SNR field
  • there should be no PRN field
• ubx_payload_rx_nav_sat_part2_t actually contains 13 bytes. Compared to uBlox:
  • cno should be at third place
  • there should be no PRN field
• Shouldn't these be packed structs? As far as I understand, you're filling the data by some pointer arithmetic, right?

This also leads to some issues with the satellite_info uORB message and GPS_STATUS mavlink message. Currently the satellite_prn data of the MAVLink message is filled from the prn array of satellite_info.
But when this information is missing from the uBlox message:

• either the satellite_info.prn array should be filled with the ublox svId to ensure backwards compatibility
• or the MAVLink message should be using satellite_info.svid when satellite_info.prn is empty.

Conversion from degrees, minutes and seconds to degrees * 1e7

In https://github.com/PX4/GpsDrivers/blob/master/src/ashtech.cpp#L230
the conversion from degrees, minutes and seconds to degrees * 1e7 is right?

Consulting this https://www.uwgb.edu/dutchs/UsefulData/UTMFormulas.HTM

the formula should be dd.ff = dd + mm/60 + ss/3600

In the code is only used dd.ff = dd + mm/60