Add support for RTCM & NTRIP GNSS corrections forwarding to ELLIPSE-N & ELLIPSE-D

[rsiryani]

We should update the driver to accept incoming RTCM streams that is directly forwarded to the ELLIPSE-N & ELLIPSE-D.
We can use the already existing message: [http://docs.ros.org/en/noetic/api/mavros_msgs/html/msg/RTCM.html]
Also look at [https://github.com/dayjaby/ntrip_ros/blob/master/scripts/ntripclient.py]

A dedicated node should be created to:

• connect to a NTRIP client and publish received data to the RTCM message
• listen for NavSatFix messages to publish a GGA message to the NTRIP caster

Thanks to that, ELLIPSE-N/D can provide INS/RTK solutions using one single serial connection and minimal user conf/code.

Please let me know if this could be of interest for some customers / users.

[tomlogan501]

Hi,
This feature could be interested indeed. We use for now Datalink from Septentrio for that purpose.

[jajberni]

I think this is will be awesome and will allow most users to avoid using an RS232 split cable to inject RTCM correction to the Ellipse-N/D units (as we currently do).

The proposed solution based on the existing ublox implementations seems quite straightforward. You only need to specify the ROS topic with the RTCM and forward this to the serial port (that should already be opened).

Happy to help/test!

[Neel1302]

@rsiryani Yes, this is especially important for autonomous driving applications where RTK corrections are necessary and would not be possible without integration of this into a single driver due to issues regarding opening the same serial port multiple times. At present, if a user wants to send RTCM corrections from a NTRIP client via serial concurrently with a connection to the GPS via ROS, the use of another serial connection and a custom cable is necessary along with purchase of another cable (CA-ELI-SPLIT-RS232-DB-0.5M). If the ROS driver itself provides this functionallity, TX on the computer side can be used for sending RTCM corrections and RX on the computer side can be used for fetching the GPS data via a single USB cable directly.

[koralm]

It will be very useful. You can use this to receive messages https://github.com/dayjaby/ntrip_ros.
Similar solution is available for Xsens devices: https://xsenstechnologies.force.com/knowledgebase/s/article/Using-an-NTRIP-client-with-the-Xsens-ROS-driver?language=en_US

[bjajoh]

I might be able to add some insights.
I used RTK RCTM correction data with the ublox f9p last year and it worked really great after figuring out how.
For that I wrote a python3 ntrip ros client: https://github.com/bjajoh/ntrip_ros_python3
Using the ros rctm messages: https://github.com/tilk/rtcm_msgs
I would suggest to implement it the same way for the ellipse. Simply subscribing to the ntrip messages and forwarding the correction data when available to the ellipse.

[rsiryani]

Hello,
Thanks for the insights.

It is roughly the way we wanted to do it. A dedicated python based NTRIP client and update the ELLIPSE driver to accept RTCM messages. We have already seen your ntrip ros repo.

However, if I am not mistaken, the last time I have checked, your implementation was not able to read automatically a position from a ROS message to send it to the NTRIP server.

It could be a great improvement and much better than needing directly a GGA message (much more versatile to generate the GGA directly in the python NTRIP client).

Have you already though about this improvement?

Thanks for the feedback,

[bjajoh]

Hi,

correct, it involved this manual step of generating the gga code.
I guess it would be possible to simply subscribe to the gnss driver wait for the first gps message and generate the gga directly.
That would be a really nice and simple process.

Best,
Bjarne

[arpaterson]

ntrip_client subscribes to topic nmea, and will forward an nmea_msgs/Sentence message which just contains a string, which needs to be a $GPGGA, to the ntrip caster it is connecting to, if it received one. It then publishes rtcm messages to topic rtcm.

I think it's useful for any ros GNSS drivers to be able to publish valid nmea sentences in ros, and not just the ros nav messages. At least $GxGGA.

Another use would be to extract rtcm from one receiver (base) and send into another (rover) without leaving ros (no ntrip server/caster or packet radios).

I wrote a node to translate a NavSatFix topic back to a $GPGGA and publish it in an nmea_msgs/Sentence, (spoofing some of the fields). To get ntrip_client to connect to virtual mountpoints that require the nmea msg.

[grischi]

Hello @rsiryani, are you already working on this topic? I would really appreciate such a feature!

Some remarks:

• It would be fine if the rtcm msg is defined directly in this driver - I would even prefer that over an additional dependency to e.g. mavros_msgs.
• I'm not sure if I correctly understood your feature description, especially regarding this dedicated node you mention. For me, the important part of this feature would be the extension of the driver (actually sbg_ros2_driver) about a rtcm input topic and forwarding corresponding messages to the device. That 'dedicated node' you describe sounds rather generic to me, so that could also be part of a different package/project.

[rsiryani]

Hello @grischi,

Thank you for the feedback.

Could you please confirm it is fine for you to have a Python3 dependency to implement the NTRIP client?
Do you also confirm your are working on ROS2?

Finally, we would like a dedicated node than handles the NTRIP client itself and an other node that handles the sbgECom protocol.
The NTRIP client might be written in Python, so we don't want to have one single package to avoid Python dependencies for sbgECom driver.

[grischi]

Hello @rsiryani, thank you for your response. I can confirm both your statements. That design with separate nodes for sbgECom and NTRIP client sounds good 👍.

[snick-m]

@rsiryani Hello! Hope you're doing well. I'd like to ask if you're still working on this and whether there's been any sufficient progress or not. I'm in need of this feature in a short time and I'll start working on this as well if you haven't done any significant progress yet. Thanks!

[djaniel]

I have tested the ublox_gps driver and Lord-microstrain ntrip client togegher on ROS2; it works as mentioned RTCM are being forwarded to the gps module using a ros topic. I think this feature is still not implemented.

[cledant]

Hello @djaniel, work has been done on devel branch for both sbg_ros_driver and sbg_ros2_driver to:

• Subscribe to a topic containing RTCM message and forward it to the device.
• Publish NMEA GGA on a specified topic

It should work well with Lord-microstrain ntrip client.

Regards,

[djaniel]

Hello @cledant, thank you for your reply. You are correct, I checked the 'devel' branch and there is support for RTCM forwarding. I setup the ntrip client ant the sbg driver on the devel branch. I had to add some lines at the end of the configuration file for ellipse D :

rtcm:
      # Should ros driver subscribe to RTCM topic
      subscribe: true
      # Topic on which RTCM is published
      topic_name: rtcm
      # Namespace where topic is published
      namespace: ntrip_client

Unfortunately the status does not show RTK precision :

header:
  stamp:
    sec: 1717595010
    nanosec: 229342522
  frame_id: imu_link_ned
time_stamp: 445965000
status:
  status: 0
  type: 3
  gps_l1_used: true
  gps_l2_used: true
  gps_l5_used: false
  glo_l1_used: true

  glo_l2_used: true
gps_tow: 308628200
latitude: 45.861354166
longitude: 1.295996438
altitude: 343.3056983886719
undulation: 47.442901611328125
position_accuracy:
  x: 0.29649999737739563
  y: 0.29649999737739563
  z: 0.4781000018119812
num_sv_used: 21
base_station_id: 65535
diff_age: 65535

status.type= 3 corresponds to 'Standard Pseudorange Differential Solution (DGPS).' It is weird to me that the 'base_station_id' is equal to 0xffff. Probably my configuration is not correct on the Ntrip client (RTCM messages)?

Here is my configuration file for the driver.
ellipseD.csv
ellipseD.csv
ellipseD.csv

I would greatly appreciate your opinion on this issue. Hopefully I can achieve GPS RTK precision status.type=7.

[cledant]

Hello @djaniel, I think you also need to configure your Ellipse device for it to accept RTCM correction.

In the README.md, there is a paragraph named Configure for RTK/DGPS with every step needed for RTK.

You should follow this step:
For ELLIPSE, simply use the sbgCenter and in Assignment panel, RTCM should be set to Port A.

[djaniel]

Thank you, it is working now.

[arpaterson]

Is the sbg gps node able to produce/publish rtcm messages as a reference station?
To be clear, the rtcm messages would be flowing in the reverse direciton - a ROS based stationary receiver, with known/surveyed location, producing rtcm messages, which could then be forwarded to an ntrip caster or shared thru other means of briding ROS machines.