Reach RS ROS driver

Hi all,

in our company we use the Reach RS as a GNSS receiver on a mobile outdoor vehicle. We started off using the nmea_tcp_driver but soon added more features to it to improve robustness and monitoring capabilities.

We would like to share this ROS driver with everyone who is interested:

As we want to fuse the GNSS position information with other sensor data using robot_localization package it was also especially important for us that we can specify the covariance matrix of the output.

The main features we added compared to nmea_tcp_driver are:

  • automatic reconnection behaviour after connection is lost
  • use the diagnostics system of ROS to provide status information
  • ability to specifiy a covariance matrix for the position (especially useful when fusing sensor data)

We are open to any feedback, also feel free to further improve on this!

Jacob Seibert (Enway)



This is an awesome contribution, thank you!

Love your product idea, any chance you could share some pictures with Reach RS on your vehicle? :slight_smile:

Yes sure! It’s an autonomous sweeper and you can see the GNSS receiver on top of it next to the LIDAR sensor:


Wow, so cool!

How is the RTK performance in your typical usage scenario? I believe this sweeper is mostly intended for city streets, so urban canyons?

Yes you are right, it’s mostly intended for urban environments. That’s why conditions are far away from being ideal and the performance strongly depends on the environment. In some areas of our testing site the position accuracy of GNSS is below 1 meter but in other areas (high buildings) it’s likely to be off by 10-15 meters.

So of course we can’t rely on GNSS as our single source of position data but combine it with other position data from other sources such as SLAM.

I recently also created a ROS driver for the Reach RTK, not sure if that works for the Reach RS but thought I would post it here.

You might want to checkout how I do the covariances, as you can get that based on other messages that are published to get the lat,log,alt accuracy standard deviations. I like the reconnecting part of your driver, have not build that into the driver I linked about.

Very interesting, thanks for sharing your driver as well!

Do you know how those standard deviations are computed? I guess it most probably can not take into account any effects of the environment, e.g. “urban canyons”.

For the sensor fusion it’s safer to overestimate the covariance, that’s why we thought it would be better to have a large fixed covariance than a dynamic one than could be underestimated…

From what I can see it is computed here and inserted into the GST message:

Looks like it grabs it from the solution object, and then converts it all into the ENU frame of reference.
This covariance is the square root’ed and exported through the GST message.

To actually compute it, it looks like it does a least square estimation which takes into account all satellites, ionospheric, tropospheric, time, biases etc. Not that sure about the details as there are not any comments linking to any reference reports.

Calculation of the linear system:

Of course in the end one could fix the covariance, and in practice the covariance should be inflated to take into account things not captured by the driver’s model. Hope this helps.

Thanks for your detailed post @goldbattle. This covariance computation seems to be at least more sophisticated than the hdop based computation in the original nmea_navsat_driver package. May I ask, what are typical covariance values you get in your scenario (which order of magnitude roughly)?

I think about 100 when not using the RTK, and around 0.01 when using RTK.
Which matches with 10m and 10cm accuracy.
Have not done any extensive testing, just got these units a week ago.

One of the problems it that it doesn’t take into account the uncertainty of the base station, I think it just takes the base as “true” so this isn’t modeling any error in the base station position.

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.