Using the Galileo High Accuracy Service (HAS)

Our robot is designed to perform on-farm outdoor tasks, such as non-chemical weeding as an environmentally friendly alternative to herbicide use. Therefore, the robot's typical operation will be in open fields, allowing for optimal reception of GNSS signals. Under these conditions standard single or dual band GNSS receivers can typically give positions at accuracies ranging from 1 to 10 meters. This is generally enough for consumer applications such as a fitness tracker or a maps app on a smartphone. But, for our robot decimeter/centimeter level accuracy is needed for accurate and repeatable path following.

To accomplish this, RTK (Real-Time Kinematics) can be utilised. RTK provides highly accurate positioning, achieving precision down to a few centimeters. However, there are a few practical drawbacks. RTK requires correction data to be transmitted from a base station with a location that is precisely known. This base station must also be within approximately 20km of the robot receiving these corrections. A possible option is to use an existing paid RTK service, such as Ublox's PointPerfectLive, however these services can become very expensive. Consequently to keep costs down when establishing a robot at a new location, a new base station must first be established. A 4G connection on the robot must be maintained to receive these real-time corrections transmitted from the RTK base-station. However, in a remote field, connectivity might be unreliable. While this potential limitation can be addressed using alternative technologies, such as LoRa or satellite internet, each have their own set of drawbacks.

To address these issues the European Space Agency is developing a new service called the Galileo High Accuracy Service (HAS). The Galileo HAS roadmap has 3 phases (0 to 2) and is currently at Phase 1, offering the “Galileo HAS Initial Service”. This means the Galileo HAS claims to provide a sub 20cm level of accuracy, with convergence times of less than 300 seconds (expected to drop to less than 100 seconds in phase 2), which are both suitable for the robot's requirements. It accomplishes this by sending correction signals to the receiver either by internet or directly from the satellite over the E6 frequency, with the latter being what we were interested in, as this removes the need for both a 4G signal and a base station.

By delivering corrections directly from space over the E6 frequency, Galileo HAS eliminates the need for 4G connectivity and local RTK infrastructure in remote fields.

Using the Galileo HAS requires a receiver and antenna compatible with E1, E5, and E6 signals; currently, only the newest generation of receivers offer this capability. To test the Galileo HAS I used a Unicore UM980 as the UM980 series receivers all have internal E6-HAS (Galileo HAS) engines. For all testing this was coupled with the Ublox ANN-MB2 antenna as this supports reception of the E6 signal.

To enable use of the Galileo HAS on the UM980 the receiver must first be set to receive the E6 signal, followed by enabling E6-HAS as the PPP service to be used.

UM980 Configuration

It is important to note that the UM980 can output multiple messages that contain a position solution; each sourced from a distinct solution engine within the device - for example with and without Precise Point Positioning (PPP), with the PPP solution being the Galileo HAS in this case. These positions may differ significantly between messages, potentially by several meters, at the same epoch depending on the solution used to generate them.

The receiver is first configured to the above configuration and then configured to output the following messages at 10Hz (Full definitions found here):

• The PPPNAVA message was used to get the position estimate generated using the E6-HAS signals.
• The GPRMC message is a standard GNSS message that follows the NMEA protocol. From my understanding this should be the UM980’s best position estimate.
• The GPGST message is a standard GNSS message that follows the NMEA protocol. This message contains the standard deviation of the latitude and longitude in meters, this is being used as a metric of accuracy for the position that the receiver is reporting, although there are some issues concerning this that will be discussed later.
• The RTKSTATUSA message was to check the status of RTK.

Choosing the correct output message is vital: different solution engines within the same receiver can report positions that differ by several meters at the same moment.

Testing the Galileo HAS

All testing was done with the UM980, with the antenna placed outside on the ground about 2m from the wall of our office, so convergence times and accuracies shown by the receiver are likely slightly worse than would be observed in an open field.

The positions on the graphs below are given as their relative distances from the point (51.047472178, -1.43602490649). This is the “true” position of the antenna. In the graphs presented:

• The current antenna position reported by the GPRMC message is indicated by the red dot, with the historical path shown by the blue line.
• The current E6-HAS antenna position reported by the PPPNAVA message is indicated by the green dot, with the historical path shown by the orange line.
• These positions are taken at the same time from the same receiver.

Using HAS without RTK assistance

Data for the following graphs were collected over a 30-minute period without the use of RTK.

The above image was taken 4 minutes after the UM980 started reporting positions. It shows the reported position using E6-HAS(orange line, green dot) and the reported position using standard GNSS techniques(blue line, red dot). As mentioned before, these positions can differ by a substantial amount, as the UM980 is not yet deciding to use the position output from the E6-HAS solution as its “best estimate” position.

Approximately 2 minutes after the previous graph was taken the UM980’s “best estimate” position(blue line, red dot), reported by the GPRMC NMEA messages, jumped to use the E6-HAS solution(orange line, green dot). The UM980 switches to using the E6-HAS engine as its “best estimate” positioning source as the E6-HAS engine reaches a certain accuracy threshold. This can be seen by the blue line jumping to meet the orange line, and the red dot can no longer be seen as it is now superposed by the green dot.

The graph above illustrates the standard deviation reported for the UM980's main position output. This is a metric for the error in the estimated position at that time. The standard deviation of latitude can be seen to slowly decrease from 4 meters at the start to around 1.5 meters over a period of a minute and a half. The error then stays at around 1.5 meters, which is the expected accuracy of using standard GNSS methods. Then at 330 seconds a large drop down to less than 30cm can be observed where the UM980 switches to using the E6-HAS solution as its best estimated position solution.

The above images show the position output of the UM980 after running for a further 20 minutes on E6-HAS and the reported standard deviation of the main UM980 position output. During this time the antenna has been kept in the same location. However, the position appears to have “wandered” up to a meter from the “true” position of the antenna even though the standard deviation of the position being reported has continued decreasing, dropping to less than 10cm. Additionally, by this point the receiver is reporting that the position is currently a “PPP” solution, meaning that it thinks the position using E6-HAS has converged to the correct location, though we have observed this is not the case.

Using HAS with RTK assistance

The data for the following graphs was collected over a 40-minutes period. RTK corrections were sent for the initial 16 minutes, with the remainder of the collection period proceeding without RTK assistance.

This above graph shows the UM980 best estimate position output(blue line, red dot) using the position generated using RTK, as this is accurate to around 2cm, whereas the E6-HAS position(orange line, green dot) is around 2.5m out in both latitude and longitude.

For around 16 minutes the reported position using E6-HAS(orange line, green dot) “wanders” and does not look to be converging to the true position, however at the 17 minute mark the E6-HAS position jumps to RTK position suggesting it has received some sort of assistance from the RTK, it is also at this point the PPP message claims “PPP” status suggesting it has converged.
RTK corrections were subsequently disabled to test whether the observed E6-HAS position would remain at the correct location.

The above image shows the reported position(orange line, green dot) after disabling RTK and relying solely on E6-HAS for around 20 minutes. During this time the latitude standard deviation reported did not increase above 10cm, whereas the position wandered to +- 20cm in latitude of the true position.

The above images suggest that the UM980's reported location accuracy may be misleading or inaccurate. Since the reported standard deviation remains consistently low, yet the HAS position begins to diverge and no longer align with the position reported when using RTK.

What are the possible causes of this?

1. The base station position being used to supply data for the RTK solution is wrong.
2. The reference frames used by the Galileo HAS and RTK are different and the receiver isn't taking this into account.
3. There is an issue with the receiver being used (firmware or otherwise).
4. The Galileo HAS is only operating in phase 1 so there are still issues.

1. The base station position being used to supply data for the RTK solution is wrong

The precise location for the static base station was determined using the CSRS-PPP service. This service takes 24 hours of raw GNSS data as input and uses post processing techniques to calculate the position to within a centimeter of accuracy. If this had been conducted incorrectly then it was possible that the Galileo HAS was giving the correct position and all RTK positions had been inaccurate.
To test this 24 hours of data was recollected from the base station and used with the CSRS-PPP service to get an updated position. The resulting position differed from the original base station position by 1.50 meters in both latitude and longitude.

What could have caused this?

• Tectonic plate activities can cause positions in Europe to change by around 2cm a year, however, it had only been 2 years since the original base station was established, so this was not the cause.
• The base station antenna could have physically moved, though this was manually observed to not have happened.
• There could have been an issue with the reference frames being used. The original base station position had been using the coordinates given for the NAD83 reference frame, a reference frame suited to positions in North America, consequently the position was incorrect by around 1.50m in the UK compared to the ITRF.

The graphs and data above were all collected after the RTK base-station was recalibrated to the correct ITRF reference frame, so the originally incorrect NAD83 frame is not relevant for the errors seen here.

2. The reference frames used by the Galileo HAS and RTK are different

As seen above, the reference frame being used can make a substantial difference in position as it is possible for the same coordinate to differ by a magnitude of meters between a region and global reference frame.
The Galileo HAS uses the GTRF, this is a realisation of the ITRF and is realised such that a position in the GTRF should not differ from the same position in the most recent ITRF by more than 3cm.
It is unclear what reference frame the UM980 is using, but it is most likely using WSG84, which also does not differ from the ITRF by more than a couple of centimeters.
So a simple reference frame mismatch is not likely to explain the large 30cm+ drift between the RTK position and E6-HAS position that we are observing.

3. There is an issue with the receiver being used (firmware or otherwise)

While the UM980 was used for testing, we ultimately selected the UM982 for the robot. Practically this was the better option as the UM982 supports dual antennas, meaning only one receiver was required on the robot, as opposed to the two required previously.
However, this receiver also experiences the same issue with the Galileo HAS where the position would drift away. This meant it wasn't an issue with the particular UM980 we had, but it could still be an issue with the firmware as they are from the same manufacturer and product series.
However, a post (linked here) in sparkfun's community stating that Quectel's LG290P also experiences a similar issue, meaning it is likely an issue with the Galileo HAS itself.

4. The Galileo HAS is only in phase 1 so there are still issues

As shown below the Galileo HAS is currently at Phase 1, therefore it is currently operating at a reduced version of Service Level 1. This means that atmospheric corrections are not yet being as they are exclusive to Service Level 2, in addition to this phase biases are not yet provided either.

This is most likely the cause of the mismatch being observed between RTK and E6-HAS positions, as when RTK is disabled and the E6-HAS position starts to differ from the true position, we do not observe a jump to another location, but rather a slow drift, suggesting that the receiver is missing the corrections.

Atmospheric corrections (discussed here) are performed in standard GNSS methods, this substantially mitigates only first-order ionospheric effects, which cause noise of around 0.1m- 1m in the position estimate, and is one of the reasons that dual band receivers perform better than single band receivers. However, in order to achieve centimeter level accuracy and reduce centimeter level noise, higher-order ionospheric effects need to be corrected for, corrections for which the Galileo HAS is currently missing. This centimeter level noise likely explains why the reported position produces the observed zig-zag patterns.

The low standard deviation reported by the receiver, despite the observed positional drift, is likely due to the position being calculated by the receiver staying consistent, as there is a persistent absence of phase and atmospheric corrections.

This is also why using standard deviation as a measure of accuracy can be problematic, as it might be better viewed as a confidence metric rather than a correctness metric. If your receiver is confidently wrong, as can happen when the RTK base station position is misaligned or when reporting the position using the Galileo HAS, then you can encounter issues like the ones seen above.