How do we publish NMEA messages?

[arpaterson]

I haven't had success yet, but I'm working on this, and if it does work, a closed issue covering it off will help any others in future. (I'd also like to do something similar for RTCM messages if I have time, so I can pass them from one receiver to another using mqtt_client as a ros to ros bridge, enabling RTK without internet ntrip casters or lora radios.)

Describe the bug It appears that as of this commit in master branch, ublox_gps should be able to publish nmea sentences into ros. I have checked out this commit, run rosdep install and made sure new dependancy nmea_msgs is installed. But I can't see any NMEA output,

I am using a sparkfun zed-f9p SMA board.

To Reproduce Steps to reproduce the behavior:

1. Checkout the above commit into your catkin workspace

2. rosdep install --from-paths src --ignore-src -r -y

3. Configure the receiver using u-center, don't disable nmea messages in u-center.

4. add this to the example zed_f9p.yaml, leaving config_on_startup: false, publish: all: true nmea: true

5. my launch file entry for the ublox node:

   <!-- ublox_f9p node -->       
   <include file="$(find ublox_gps)/launch/ublox_device.launch" if="$(arg enable_ublox)">
   <arg name="param_file_name"     value="zed_f9p" />
   <arg name="param_file_dir"      value="$(find gnss)/config" />
   <arg name="node_name"           value="ublox" />
   <arg name="output"              value="screen" />
   <arg name="respawn"             value="true" />
   <arg name="respawn_delay"       value="30" />
   <arg name="clear_params"        value="true" />
   </include>

6. See this param entry on launch

7. See valid, populated NavPVT being published, but no sign of nmea.

Expected behavior Expected ublox/nmea topic to appear with nmea_msgs/Sentence msgs containing NMEA strings.

Desktop (please complete the following information):

• Ubuntu 20.04
• ROS1 Noetic

Additional context Jetson Orin zed-f9p

[arpaterson]

@haho12 Could you weigh in on this? Presumably it works, and I am doing something wrong.

[haho12]

@arpaterson Do debug this, could you first check if the NMEA messages are actually received by the program? In ublox_serialization/include/ublox/serialization.h would you dump unuseddata to stdout after the for loop in line ~214 ? unuseddata stores all data which is not recognized as a u-blox raw message, e.g. NMEA strings. HH

[haho12]

Or more easily, setting this parameter should dump received NMEA messages as well, I guess: debug: 4

[Interrollipsis]

Somewhat beginner to Ros here, it seems like were somewhat working on the same issue. Currently, is there no simple way to have a fixed base station/rover setup with 2 f9p's using this package? A simple way to subscribe to a working RTCM topic? I'm becoming exceedingly frustrated and confused and wondering what the point even is of this package.

[arpaterson]

@arpaterson Do debug this, could you first check if the NMEA messages are actually received by the program? In ublox_serialization/include/ublox/serialization.h would you dump unuseddata to stdout after the for loop in line ~214 ? unuseddata stores all data which is not recognized as a u-blox raw message, e.g. NMEA strings. HH

I set debug 4, but I'm not sure what I am looking for as it prints a lot of binary that doesn't look like NMEA.

Do you use an f9p? It would be helpful to confirm it is user error, or have a known good starting point.

I have tried config_on_startup: false and true, But as I understand it, leaving it false just means all firmware setup needs to be done through u-center, and when it is true, not all firmware config can be done by ublox_gps due to the f9p using a newer protocol.

The publish: section (+ frameid ) configures the ublox_gps node and publication of messages into ros.

The nmea: section I am also unsure about. I would want to disable all filtering of GxXXX strings.

I know it produces GNGGA (as it is a GNSS receiver, not just GPS), I've observed it in u-center.

[arpaterson]

Adding the following

      else {
          unused_data_.push_back(data_[0]);
          fprintf( stdout, "\n\n \e[0;31m unused_data_: %s \e[0m \n ", unused_data_.c_str() );
      }
    }

    return data_;
  }

resulted in

unused_data_: $GLGSV,<obscured>
$GLGSV,<obscured>
$GLGSV,<obscured>
$GAGSV,<obscured>
$GAGSV,<obscured>
$GAGSV,<obscured>
$GAGSV,<obscured>
$GAGSV,<obscured>
$GBGSV,<obscured>
$GBGSV,<obscured>
$GBGSV,<obscured>
$GBGSV,<obscured>
$GBGSV,<obscured>
$GBGSV,<obscured>
$GQGSV,<obscured>
$GNGLL,<obscured>

Notably no GxGGA messages.

But... there are nmea strings being published to /ublox/nmea.

[arpaterson]

Setting config_on_startup: true, and using nmea: etc to configure the nmea sentences, disable filters and set talker id to GP seems to have had an effect. I can see $GPGGA messages now.

But I have issues with the connection to the receiver though. More so with config_on_startup: true.

I basically have to unplug and plug in the f9p before every launch, and I get ASIO Read errors, or the usb port refuses to mount the f9p anymore until I reboot the system.

terminate called after throwing an instance of 'std::runtime_error'
  what():  U-Blox: Could not open serial port :/dev/serial/by-id/usb-u-blox_AG_-_www.u-blox.com_u-blox_GNSS_receiver-if00 open: No such file or directory

'std::runtime_error'
  what():  Could not configure serial baud rate

[ERROR] [1666067951.657745848]: U-Blox ASIO input buffer read error: Operation canceled, 0

[ INFO] [1666067971.783018524]: U-Blox: Reset serial port /dev/serial/by-id/usb-u-blox_AG_-_www.u-blox.com_u-blox_GNSS_receiver-if00
[DEBUG] [1666067971.783944577]: U-Blox sent 9 bytes: 
b5 62 06 00 01 00 01 08 22 
[ERROR] [1666067972.783779000]: Resetting Serial Port: Could not read polled UART1 CfgPRT message
[FATAL] [1666067972.784002009]: Error configuring u-blox: Failed to cold reset device after configuring GNSS

[haho12]

Here's the config file that I use on my f9k. Any improvement? f9k_jetbot.yaml.txt

[arpaterson]

Thank you!

Yes I made some progress. But only with config_on_startup: false.

I cannot for the life of me avoid issues at startup with it enabled.

I think I am beginning to understand the limitations of this node with the f9p. this issue suggests that the receiver configuration is checked, and if it differs (from whats on the receiver? or defaults?) then the config message is sent, and if necessary the device is reset. It also suggests we want to avoid that (why? I'm not sure, but it doesn't work). So we set the config yaml to match so that those steps are not attempted.

Right now, I am setting everything very granularly in u-center, saving to the memory, and a file, and then disabling 'config_on_startup' in the yaml file.

I can then start the node a bit more reliably, instead of borking my serial port and having to reboot every second time. It still does not start reliably a second time, though.

With current master checkedout, and the desired nmea messages enabled/disabled in u-center, plus the talkerid configured again from u-center, it is now publishing nmea messages.

I will look into using the config_on_startup a bit more later, but right now its just too flaky and I don't have time for it. Your config file will be a great help.

Thanks for your contribution.regarding nmea publishing. I will use it with ntrip_client. Previously I was assembling and partially spoofing a GGA sentence from the published nav messages.

I will look into publishing RTCM data in the same way as you implemented NMEA pass through. I want rtcm_msgs published on rtcm_out, so I can pass it directly to another ublox_node (eliminating ntrip altogether and making an offline RTK setup). Just off the top of your head does that sound like a good approach? I think your

[arpaterson]

BTW I assumed you are using the ros1 branch, since your contribution was there?

[haho12]

The idea of this package is that no settings in u-center are done since this is barely reproducible. Instead the receiver should be configured by the ROS params and saved to EEPROM if there's any change. If any change is detected, the receiver is rebooted. I've seen the reboot issue you describe as well. But if you set the params once for permanent, then this doesn't matter much. (And yes, I'm still on ROS1 here.)

[haho12]

So can we close this issue as "not a bug" or do you want to commit an update on the readme ?

[arpaterson]

The idea of this package is that no settings in u-center are done since this is barely reproducible. Instead the receiver should be configured by the ROS params and saved to EEPROM if there's any change. If any change is detected, the receiver is rebooted. I've seen the reboot issue you describe as well. But if you set the params once for permanent, then this doesn't matter much. (And yes, I'm still on ROS1 here.)

Yes, I understand that is the goal, but I have not had any luck with it. As it stands, at least with the f9p, using the node to do the full configuration is not exactly straight forward. The node most often just does not launch successfully. I will have to revisit that. My grasp of it isn't good enough at this point to make a decent contribution to the documentation.

I think we can close this regarding the publish nmea feature as not a bug. (Thank you again for that feature)

Did you have any thoughts on the rtcm_msgs/Message publishing / pass through? I would be interested in implementing that feature.

[akrv]

I am using swiftnav for RTCM corrections and F9P on the rover. I am not able to publish the NMEA sentences out of the driver. This seems necessary for the NTRIP client to send to the server to get RTCM corrections. Is it possible to share the config file that worked?

if I set NMEA to true, then I have to set the version and other dependent vars that I do not find the docs to set it properly.

@arpaterson can you post your config yaml file?

[arpaterson]

I am using swiftnav for RTCM corrections and F9P on the rover. I am not able to publish the NMEA sentences out of the driver. This seems necessary for the NTRIP client to send to the server to get RTCM corrections. Is it possible to share the config file that worked?

if I set NMEA to true, then I have to set the version and other dependent vars that I do not find the docs to set it properly.

@arpaterson can you post your config yaml file?

Make sure nmea messages are enabled in the receiver firmware. My config files uses config_on_startup: false so it does not configure receiver firmware options. I checked/enabled nmea message output on the appropriate receiver USB/serial port using u-center.

Then also configure the ublox_gps node to publish nmea_msgs/Sentence messages by first making sure you have checked out a late enough commit for that feature, and second by enabling nmea publishing in your config file. the only releveant line in my config file is

publish:
    all: true
    nmea: true

[akrv]

Interesting. Only difference seems to be I did the cli api install and didn't pull the master branch.

I'll try that and report back

(AGX Xavier with 18.04 Melodic)

[arpaterson]

Yep, well if a feature is on a git branch, but has not been released into rosdep/apt, that’ll happen. Something to keep in mind with ros packages. you can include the package as a git sub module at the specific commit.