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!
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.
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)?