septentrio-gnss / septentrio_gnss_driver Goto Github PK

View Code? Open in Web Editor NEW

80.0 80.0 38.0 52.46 MB

ROS 1 & 2 driver for Septentrio GNSS & INS receivers

License: BSD 3-Clause "New" or "Revised" License

CMake 1.54% C++ 97.59% C 0.09% Python 0.79%

automation gnss inertial-navigation-systems robotics ros

septentrio_gnss_driver's People

Contributors

Stargazers

Watchers

septentrio_gnss_driver's Issues

Namespace handling

Issue description

Specifying a namespace when launching the Septentrio node does not effect the names of the published topic - they are always published in the root name space.

For topics like /insnavgeod this is not much of an issue, it's clear they're from the Septentrio and there aren't other nodes that publish such topics, but for others like /imu and /pose this will cause confusion. Also, preferably nodes ought to operate in a given namespace when they are launched in that given namespace.

Steps to reproduce the issue

Setup Septentrio hard & software
Specify which namespace to launch the Septentrio nodes with in the Septentrio launch file
Launch with that launch file
Look at the names of the published topics

What's the expected result?

arne@laptop:~$ ros2 topic list
/<namespace>/insnavgeod
/<namespace>/imu
/<namespace>/pose
etc.

What's the actual result?

arne@laptop:~$ ros2 topic list
/insnavgeod
/imu
/pose
etc.

Additional details

This is likely due to the topics being defined with a preceding slash in septentrio_gnss_driver/src/septentrio_gnss_driver/communication/message_handler.cpp, e.g.

publish<INSNavCartMsg>("/insnavcart", last_insnavcart_);

instead of

publish<INSNavCartMsg>("insnavcart", last_insnavcart_);

Version

Compiled septentro_gnss_driver from source, branch ros2, HEAD commit 207c37bc.

Thank you in advance for addressing this. Should you need more details or information, please don't hesitate to ask.

Build error

Hi, i tried to build the latest release of your septentrio driver, but unfortunalty this is leading to a few problems:
it seems to mess up my colcon as well as it didnt build.

System specs:

OS: Ubuntu 22.04
Ros version: ROS2 Humble

Steps:

Copied packages into ros2 src folder of workspace
run colcon build --packages-select-septentrio_gnss_driver_ros2

Result:

colcon build --packages-select septentrio_gnss_driver_ros2
/home/johannes/.local/lib/python3.10/site-packages/setuptools/dist.py:723: UserWarning: Usage of dash-separated 'script-dir' will not be supported in future versions. Please use the underscore name 'script_dir' instead
warnings.warn(
/home/johannes/.local/lib/python3.10/site-packages/setuptools/dist.py:723: UserWarning: Usage of dash-separated 'install-scripts' will not be supported in future versions. Please use the underscore name 'install_scripts' instead
warnings.warn(
/home/johannes/.local/lib/python3.10/site-packages/setuptools_scm/_integration/setuptools.py:31: RuntimeWarning:
ERROR: setuptools==59.6.0 is used in combination with setuptools_scm>=8.x

Your build configuration is incomplete and previously worked by accident!
setuptools_scm requires setuptools>=61

Suggested workaround if applicable:

migrating from the deprecated setup_requires mechanism to pep517/518
and using a pyproject.toml to declare build dependencies
which are reliably pre-installed before running the build tools

warnings.warn(
[0.677s] WARNING:colcon.colcon_core.package_selection:ignoring unknown package 'septentrio_gnss_driver_ros2' in --packages-select
[0.705s] WARNING:colcon.colcon_ros.prefix_path.ament:The path '/home/johannes/ros2_ws/install/septentrio_gnss_driver' in the environment variable AMENT_PREFIX_PATH doesn't exist
[0.705s] WARNING:colcon.colcon_ros.prefix_path.catkin:The path '/home/johannes/ros2_ws/install/septentrio_gnss_driver' in the environment variable CMAKE_PREFIX_PATH doesn't exist

Summary: 0 packages finished [0.66s]

Compatibility with AsteRx2i HDC

Hello,

We have the following Septentrio GPS:
AsteRx2i HDC SN 900019725

Is this ROS package compatible with this specific model?
We did manage to run and open the serial port editing rover.yaml, but no message is published.

Serial ID of mosiac go heading not constant

Hey,
I have a MOSIAC GO heading evaluation kit. When searching for the device using "serial/by-id", I have two names for one device. Only when the connection is established using one of the ids, I am able to receive ROS messages. When using the other id, connection is established but there are no messages.
Moreover, the id through which the messages are received is not constant and changes between the two upon restart.

How do I fix it and why is it happening?

Thank you!

Best way to integrate global heading (dual antenna) to robot_localization

Hello together,

I've just installed the mosaic-h receiver to our robot and I wonder what is the best way to integrate the global heading (two antennas) into the robot_localization node. I have found the /pose topic, which would be in general an easy way to integrate (geometry_msgs/PoseWithCovarianceStamped.msg),but it looks like it doesn't include the global but local heading.

Thanks in advance

Building Package is not possible

Hello together,
I tried to launch the ROS2 Package of septrentio but I get the error message "file rover.py not found" I
System info:
Raspberry Pi 4
OS Ubuntu
Septentrio driver install via apt-get -- self building not a option due to crushing of Raspberry every time i do it.
Thank you in advance

integration of /localization odometry data to robot_localization node

Hello
I have been using septentrio's Asterx SBi3 pro+ with dual antenna setup. I have integrated it to robot_localization node via navsat_transform .
I would like to integrate directly /localization odometry topic data as it gives absolute heading. My doubts/questions are below

The frame ids of the /localization is "utm_32n" to child frame "base_link". How can i integrate this to robot _localization node as it needs map -> base_link? (to second ekf_map instance as I'm integrating lidar odom and IMU from INS receiver to first ekf instance)
2)which is the better way to integrate. is it navsatfix to navsat_transform or /localization to ekf_map instance?
3)this is a doubt, does /imu from this receiver already fused with dual antenna heading information?

Could some please clarify these?

working environment:
ROS2 umble
Jetson Orin AGX - ubuntu 22

Asterx-SBI 3 pro IMU orientation/lever arms leading to flyaway in position estimation

I have mobile robot setup with INS receiver + dual antenna setup.

My robot model is as follow:

<?xml version="1.0" ?>
<robot name="robot">
  <link name="/base_link"/>
  <link name="/imu_septentrio"/>
  <joint name="/base_link_to_imu_septentrio_joint" type="fixed">
    <parent link="/base_link"/>
    <child link="/imu_septentrio"/>
    <origin rpy="0 0 1.5708" xyz="-0.0973 -0.0296 0.23457"/>
  </joint>
  <link name="/ant_septentrio_aux"/>
  <joint name="/imu_septentrio_to_ant_septentrio_main_joint" type="fixed">
    <parent link="/imu_septentrio"/>
    <child link="/ant_septentrio_main"/>
    <origin rpy="0 0 0" xyz="-0.129 -0.069 -0.02"/>
  </joint>
  <link name="/ant_septentrio_main"/>
  <joint name="/ant_septentrio_main_to_ant_septentrio_aux_joint" type="fixed">
    <parent link="/ant_septentrio_main"/>
    <child link="/ant_septentrio_aux"/>
    <origin rpy="0 0 0" xyz="0.38 0.004 0.0"/>
  </joint>
  <link name="/vsm"/>
  <joint name="/base_link_to_vsm_joint" type="fixed">
    <parent link="/base_link"/>
    <child link="/vsm"/>
    <origin rpy="0 0 0" xyz="0 0 0"/>
  </joint>
</robot>

which results in this robot model (top view):

Receiver IMU has Z axis pointing up and Y opposite to robot's forward direction. Here's also a sketch of the robot:

The configuration yaml file does use both use_ros_axis_orientation: true, get_spatial_config_from_tf: true and configure_rx: true, so I expect the ros driver node to reconfigure the receiver once I launch the node using the information from my robot model. However, if I then check the web UI for INS settings, I see the receiver/imu orientation is set correctly, but lever arms (IMU<>MainARP and IMU<>base link) do not match what I would expect correctly set? What am i missing here?

This has clearly serious implications as the imu information is then poorly in the receiver and leads to flyaway estimates (red dots) when compared with another location information provider (blue dots)

Invalid or erroneous data like -20000000 in navsatfix messages

Hello,

I am using the Septentrio INS SBI Pro + and the official driver for my project, I have encountered an issue where the navsatfix topic occasionally publishes invalid values, specifically -20000000, under certain conditions (e.g., bad GNSS signal). This behavior can lead to complications in downstream applications such as localization and navigation systems.

Description of the issue:

The navsatfix messages from the driver sometimes contain latitude and longitude values of -20000000.
The status field of the navsatfix message during these instances is -1.

Impact:

These invalid values can disrupt the performance of localization systems that rely on accurate GPS data.
Filtering these values externally is a workaround but not an ideal solution, as it adds complexity and potential points of failure in the system.

Expected behavior:

It would be preferable for the driver to not publish navsatfix messages under these conditions.

Environment:

ROS Version: noetic
Septentrio Driver Version: 1.3.2 (2023-11-19)
Hardware/Platform: Ubuntu 20.04

I am looking forward to any suggestions, guidance, or fixes you can provide. Additionally, if there's any further information or testing I can assist with, please let me know.

Best regards,
Ayoub.

Angular velocity units in topic /imu

Issue description

The angular velocities published in the topic /imu appear to be expressed in unit deg/s instead of rad/s. Following the ROS message definition, it was expected that they are expressed in the latter and not the former units.

As a result, all existing ROS nodes (which assume rad/s) get the impression that the platform is rotating about 60 times faster than in reality, which results in control issues.

Steps to reproduce the issue

Setup Septentrio hardware and launch Septentrio ROS node.
Log output of topic /imu.
Rotate Septentrio setup at a known angular velocity, eg. 15°/s.
Read/visualized the recorded angular velocities in log file.
Compare the amplitude of the logged values with the applied known velocity.

What's the expected result?

The angular velocities are expressed in unit rad/s

as defined in the ROS message definition of the message sensor_msgs/msg/Imu , the type of the message published on the /imu topic.
and in line with REP 103, which recommends SI units.

What's the actual result?

The values are about 60 times larger than expected. They are probably expressed in °/s instead of rad/s

Additional details / screenshot

Graph created when rotating the Septentrio at a sine-modulated angular velocity in the order of 15 °/s:

Visualization using Plotjuggler

Visualization using rqt

Version

Compiled septentro_gnss_driver from source, branch ros2, HEAD commit 207c37bc.

We would appreciate if you could look into this. In case any other information is desired, please let know.

How to connect to device via serial?

We need to connect to the device via serial insted aof tcp-Ip, since the the-syscon-driver is not available for arm and we have problems to use the devices on jetson nano. We can connect to the device but did not receive any payload:
septentrio_gnss: Searching for serial port/dev/ttyACM2 [DEBUG] [1695029925.501838983]: /septentrio_gnss: Leaving initializeIO() method [DEBUG] [1695029925.501889266]: /septentrio_gnss: Called defineMessages() method [DEBUG] [1695029925.501941183]: /septentrio_gnss: Key 5914 successfully inserted into multimap: true [DEBUG] [1695029925.501989459]: /septentrio_gnss: Key $GPGGA successfully inserted into multimap: true [DEBUG] [1695029925.502032098]: /septentrio_gnss: Key $GPRMC successfully inserted into multimap: true [DEBUG] [1695029925.502079494]: /septentrio_gnss: Key 4006 successfully inserted into multimap: true [DEBUG] [1695029925.502143309]: /septentrio_gnss: Key 4007 successfully inserted into multimap: true [DEBUG] [1695029925.502217710]: /septentrio_gnss: Key 4028 successfully inserted into multimap: true [DEBUG] [1695029925.502308669]: /septentrio_gnss: Called connect() method [DEBUG] [1695029925.502367530]: /septentrio_gnss: Started timer for calling reconnect() method until connection succeeds [DEBUG] [1695029925.502424710]: /septentrio_gnss: Key 5905 successfully inserted into multimap: true [DEBUG] [1695029925.502506028]: /septentrio_gnss: Key 5906 successfully inserted into multimap: true [DEBUG] [1695029925.502565937]: /septentrio_gnss: Called reconnect() method [DEBUG] [1695029925.502633483]: /septentrio_gnss: Key 5908 successfully inserted into multimap: true [ INFO] [1695029925.502694819]: /septentrio_gnss: Connecting serially to device/dev/ttyACM2, targeted baudrate: 115200 [DEBUG] [1695029925.502727933]: /septentrio_gnss: Calling initializeSerial() method.. [DEBUG] [1695029925.502785033]: /septentrio_gnss: Key 5938 successfully inserted into multimap: true [DEBUG] [1695029925.502867118]: /septentrio_gnss: Key 5939 successfully inserted into multimap: true [DEBUG] [1695029925.502941016]: /septentrio_gnss: Key 4027 successfully inserted into multimap: true [ INFO] [1695029925.502998599]: /septentrio_gnss: Opened serial port /dev/ttyACM2 [DEBUG] [1695029925.503036614]: /septentrio_gnss: Our boost version is 107100. [DEBUG] [1695029925.503065131]: /septentrio_gnss: Creating new Async-Manager object.. [DEBUG] [1695029925.503136543]: /septentrio_gnss: Key GPST successfully inserted into multimap: true [DEBUG] [1695029925.503198368]: /septentrio_gnss: Setting the private stream variable of the AsyncManager instance. [DEBUG] [1695029925.503253391]: /septentrio_gnss: Key NavSatFix successfully inserted into multimap: true [DEBUG] [1695029925.503334594]: /septentrio_gnss: Key GPSFix successfully inserted into multimap: true [DEBUG] [1695029925.503414906]: /septentrio_gnss: Key 4013 successfully inserted into multimap: true [DEBUG] [1695029925.503495424]: /septentrio_gnss: Launching tryParsing() thread.. [DEBUG] [1695029925.503581452]: /septentrio_gnss: Key 4001 successfully inserted into multimap: true [DEBUG] [1695029925.503652366]: /septentrio_gnss: Called setManager() method [DEBUG] [1695029925.503692629]: /septentrio_gnss: Leaving setManager() method [DEBUG] [1695029925.503722766]: /septentrio_gnss: Gradually increasing the baudrate to the desired value... [DEBUG] [1695029925.503750889]: /septentrio_gnss: Initiated current_baudrate object... [DEBUG] [1695029925.503787621]: /septentrio_gnss: Key PoseWithCovarianceStamped successfully inserted into multimap: true [DEBUG] [1695029925.503841758]: /septentrio_gnss: Current baudrate is 115200 [ INFO] [1695029925.503895146]: /septentrio_gnss: Set ASIO baudrate to 115200, leaving InitializeSerial() method [DEBUG] [1695029925.503977075]: /septentrio_gnss: Key 5902 successfully inserted into multimap: true [DEBUG] [1695029925.504056902]: /septentrio_gnss: Leaving reconnect() method [DEBUG] [1695029925.504178742]: /septentrio_gnss: Leaving defineMessages() method [DEBUG] [1695029925.504256236]: /septentrio_gnss: Called configureRx() method [DEBUG] [1695029925.504412151]: /septentrio_gnss: Sent the following 22 bytes to the Rx: SSSSSSSSSSSSSSSSSSS [DEBUG] [1695029925.505133951]: /septentrio_gnss: Calling read_callback_() method, with number of bytes to be parsed being 5 [DEBUG] [1695029927.504530274]: /septentrio_gnss: Successully connected. Leaving connect() method [ INFO] [1695029935.505388750]: /septentrio_gnss: TryParsing() method finished since it did not receive anything to parse for 10 seconds..

Unable to enable NTRIP via ROS yaml

I am trying to enable and set up ntrip via the ROS driver but it does work. If I do it via the web interface it works fine but I am unable to change the params and have them take effect. I get the following error when running the node.
Internet via usb is enabled and network is shared with mosaic

[ INFO] [1712269543.763666999]: /mosaic_rover: Setting up Rx.
[ERROR] [1712269544.007263301]: /mosaic_rover: Invalid command just sent to the Rx! The Rx's response contains 62 bytes and reads:
 $R? setAntennaOffset: Tabular argument 'Antenna' is invalid!

[ERROR] [1712269544.008559705]: /mosaic_rover: Invalid command just sent to the Rx! The Rx's response contains 57 bytes and reads:
 $R? setNtripSettings: Tabular argument 'Cd' is invalid!

[ERROR] [1712269544.010540076]: /mosaic_rover: Invalid command just sent to the Rx! The Rx's response contains 57 bytes and reads:
 $R? setNtripSettings: Tabular argument 'Cd' is invalid!

[ERROR] [1712269544.011905323]: /mosaic_rover: Invalid command just sent to the Rx! The Rx's response contains 60 bytes and reads:
 $R? setNtripTlsSettings: Tabular argument 'Cd' is invalid!

RTK settings in the yaml


rtk_settings:
  ntrip_1:
    id: "NTRIP1"
    caster: ""
    caster_port: 2101
    username: ""
    password: ""
    mountpoint: ""
    version: "v2"
    tls: false
    fingerprint: ""
    rtk_standard: "auto"
    send_gga: "auto"
    keep_open: true
  ip_server_1:
    id: ""
    port: 0
    rtk_standard: "auto"
    send_gga: "auto"
    keep_open: true
  serial_1:
    port: ""
    baud_rate: 115200
    rtk_standard: "auto"
    send_gga: "auto"
    keep_open: true

[BUG] /extsensormeas node is broken

Hardware:
I am using the Septentrio AsteRx-i3 D Pro + on Ubuntu 18.04 and ROS Melodic.

Bug
The /extsensormeas node sends the correct angular rate but sends the exact same data for its accelerations.
Velocity, std_dev and temperature data are way off the real values.
IN RXTools Message Inspector View the correct data on acceleration, angular rate and tempreratur are shown.

Example
header:
seq: 7638
stamp:
secs: 1650352094
nsecs: 7669758
frame_id: "ins"
block_header:
sync_1: 36
sync_2: 64
crc: 14449
id: 4050
length: 100
tow: 198512000
wnc: 2206
n: 3
sb_length: 28
source: 32
sensor_model: 10
type: 1
obs_info: 1
acceleration_X: -0.0325
acceleration_Y: 0.47875
acceleration_Z: -0.08875
angular_rate_X: -0.0325
angular_rate_Y: 0.47875
angular_rate_Z: -0.08875
velocity_X: 9.12120139543e-33
velocity_Y: -1.25499999523
velocity_Z: 9.12119919138e-33
std_dev_X: 1.73937499523
std_dev_Y: -3.21864213941e+26
std_dev_Z: -1.42749989033
sensor_temperature: 28832
zero_velocity_flag: -0.0325

header:
seq: 7639
stamp:
secs: 1650352094
nsecs: 507891427
frame_id: "ins"
block_header:
sync_1: 36
sync_2: 64
crc: 63172
id: 4050
length: 72
tow: 198512500
wnc: 2206
n: 2
sb_length: 28
source: 32
sensor_model: 10
type: 1
obs_info: 1
acceleration_X: 0.01125
acceleration_Y: 0.47125
acceleration_Z: -0.15625
angular_rate_X: 0.01125
angular_rate_Y: 0.47125
angular_rate_Z: -0.15625
velocity_X: 4.05647994111e+29
velocity_Y: 1.05499994755
velocity_Z: -71.6799468994
std_dev_X: 1.7356249094
std_dev_Y: nan
std_dev_Z: -1.53124988079
sensor_temperature: -10491
zero_velocity_flag: 0.01125

[REQUEST] Formatter configuration file

This is not an issue but more of a suggestion/request. A standard configuration file for c++ autoformatter (eg .clang-format) would help to standardise formatting for contributors. Please look into including such configuration files

Parameter settings in the ROS driver are not reflected properly in the hardware

@tibordome @thomasemter
Hello. Thanks for your work ,

I use AsteRx-i3 S Pro+(firmware:version 1.3.2) and use the ros2 branch of this package.

In the process I encountered the following problem.

Even if I set theta_x in imu_orientation to 180, it is 0.0deg on WebUI(setting values within 90 degrees are reflected correctly).
https://github.com/septentrio-gnss/septentrio_gnss_driver/blob/ros2/config/rover.yaml#L112

aster rx is not able to access the RTK correction service correctly even if I set it according to the following

debf0e4#diff-b06a267690b8225807484c743113fa3cf06dc111f3a59de9c57f3b9f32c6303d
We confirmed that the ntrip configuration values were loaded internally in the hardware, but aster rx was not able to communicate with the correction information server.

So can you tell me how to set the settings correctly or how Aster settings are not done from the ROS driver?

Angular velocities on topic `/twist_ins` all zero

Issue description

The angular velocities published on the topic /twist_ins are all zeros even when the platform is rotating and angular velocities are being published on the the /imu topic.

Nodes that currently want to observe both angular and linear velocity have to subscribe to two topics (/twist_ins and /imu) instead of only /twist_ins.

Steps to reproduce the issue

Setup Septentrio hardware and launch Septentrio ROS node.
Look at the values of /twist_ins/twist/twist/angular/x.

What's the expected result?

The angular velocities in the geometry_msgs/msg/TwistWithCovarianceStamped message are the best available estimates for the platform's angular velocity. This can be just the gyro measurements, like published on /imu, though preferably these measurements are already corrected (e.g. bias correction). They are expressed in the frame stated in the frame_id of this message.

What's the actual result?

They are always zero.

Additional details / screenshot

Graph created while moving around, time axis on the horizontal:

Version

Compiled septentro_gnss_driver from source, branch ros2, HEAD commit 207c37bc.

Thank you in advance for your time. In case there's any setting we missed, or more information is required, please share.

Publish dual antenna attitude in "track" field of gpsfix message

Hi all,
We are using Septentrio receivers in dual antenna setup (we use both SB ProDirect and SBi3 Pro+).
We are used to subscribe to /gpsfix topic to get position, velocity and vehicle heading information.
In the configuration file I've set "multi_antenna" to true.
When the vehicle is in motion track is correctly published on the /gpsfix topic, however when the vehicle is standstill track seems to be no more available and the value is set to something like "-200000000000" (I think it is the default value to inform the user that the data is not available).
However, in the "/atteuler" topic the "heading" field is always available (both when the vehicle is in motion and when stanstill). I think that it would be more logic to always supply "track" in /gpfix too since that data is de facto available.
I'm not totally sure if track and heading are retrieved in the same way internally (from what I've seen, track is computed using Course Over Ground, while heading exploiting the presence of the 2 antennas); however I think that heading/track should always be published in the gpsfix topic since the receiver has that information at any time when running in dual antenna setup.
Please let me know what do you think.

Invalid argument for setting lever arm

The driver is reading frames from tf. The following is the message received from the receiver:

[ERROR] [1665063739.518137652]: /septentrio_gnss: Invalid command just sent to the Rx! The Rx's response contains 47 bytes and reads:
 $R? setINSAntLeverArm: Argument 'X' is invalid!

I am printing the exact string being formed prior to the sending, which is:

sial, 0.03639, 0.176597, -0.836319

Looking at the manual, this looks correct.

Why would the receiver respond this way?

Driver does not terminate on CTRL+C

When pressing CTRL+C to terminate the driver, the driver stops publishing messages but does not shutdown properly.

Ubuntu 20.04, official apt package for ROS Noetic, v1.06

Change publish rate for GNSS measurements

Hi!

Is there any parameter in the package to change the publish rate for all the GNSS topics? Right now, they are being published at 100 Hz, which causes are state estimator using the GNSS measurement to behave weirdly.

Ideally, we would like to set it to 1 Hz.

Is this possible?

Thanks!

SNR Logging

Hello,

Is there a quick way to record the Signal Noise Ratio on a ROS2 topic? I saw the C/n0 is used internally with the MeasEpochChannelType1(2).msg but it is not published to a topic.

Thanks in advance!

Heading offset

Hello,

I have a question regarding the antenna_offset:heading parameter: If i use this parameter with ros_axis_orientation is the offset applied to the values complying with the ros_axis_orientation(enu) or to the default NED frame?

Issue with Building septentrio_gnss_driver in ROS2: Missing Branch

I am currently trying to build the septentrio_gnss_driver in ROS2. However, the command git checkout ros2 does not work. When I check with git branch -a, only origin/master is available and the ros2 branch cannot be found. Can you help me with this issue?

BaseVectorGeod and BaseVectorCart blocks not available in driver

Am i correct in observing that the BaseVectorGeod and BaseVectorCart blocks ( the relative position of the rover w.r.t. the base station) are not retrieved and processed by the driver?

If not much trouble, can this be added?

[BUG] SBF log file playback feature failure

Description of bug

Driver fails to detect files when path to file is provided with slashes ('/').

Environment

Driver was compiled and launched in a Debian-stretch based docker container with ROS Melodic.

To Reproduce

Specify device in the parameter file as shown

device: file_name:/dir1/dir2/file.sbf

Expected behavior

Driver not able to recognise device.

Suspected cause of bug

Regex used to detect device specified seems to be incorrect.

Files

Suspected source of bug -

septentrio_gnss_driver/src/septentrio_gnss_driver/node/rosaic_node.cpp

Line 478 in dcc3adf

 else if (boost::regex_match(device_, match, boost::regex("(file_name):(\\w+.sbf)"))) 

Error "/septentrio_gnss: gnss" after launching rover.launch

Hello guys,

When I launched septentrio_gnss_driver rover.launch param_file_name:=rover, I got the error: [ERROR] [1684219558.118107529]: /septentrio_gnss: gnss. The hardware and software setup are described below:

Sensor: mosaic-go heading GNSS module evaluation kit .
Sensor firmware version: 4.12.1.
Port: USB.
ROS version: Noetic.

Additional notes:

I have tried to build the package from source and binary install, but both lead to the same error. In addition, I'm able to connect via Ethernet-over-USB IP address 192.128.3.1. A screenshot is attached below:

After some minutes I got the message in the terminal: [ INFO] [1684220890.105052450]: /septentrio_gnss: TryParsing() method finished since it did not receive anything to parse for 10 seconds..

Configuration Settings for the Rover Rx in the rover.yaml file:

GNSS/INS Parameters

device: tcp://192.168.3.1:28784

serial:
baudrate: 921600
rx_serial_port: USB1
hw_flow_control: off

frame_id: gnss

imu_frame_id: imu

poi_frame_id: base_link

vsm_frame_id: vsm

aux1_frame_id: aux1

vehicle_frame_id: base_link

local_frame_id: odom

insert_local_frame: false

get_spatial_config_from_tf: false

lock_utm_zone: true

use_ros_axis_orientation: true

receiver_type: gnss

multi_antenna: true

datum: Default

poi_to_arp:
delta_e: 0.0
delta_n: 0.0
delta_u: 0.0

att_offset:
heading: 0.0
pitch: 0.0

ant_type: "Unknown"
ant_serial_nr: "Unknown"
ant_aux1_type: "Unknown"
ant_aux1_serial_nr: "Unknown"

leap_seconds: 18

polling_period:
pvt: 500
rest: 500

use_gnss_time: false

rtk_settings:
ntrip_1:
id: ""
caster: ""
caster_port: 2101
username: ""
password: ""
mountpoint: ""
version: "v2"
tls: false
fingerprint: ""
rtk_standard: "auto"
send_gga: "auto"
keep_open: true
ip_server_1:
id: ""
port: 0
rtk_standard: "auto"
send_gga: "auto"
keep_open: true
serial_1:
port: ""
baud_rate: 115200
rtk_standard: "auto"
send_gga: "auto"
keep_open: true

publish:

For both GNSS and INS Rxs

navsatfix: false
gpsfix: true
gpgga: false
gprmc: false
gpst: false
measepoch: false
pvtcartesian: false
pvtgeodetic: true
basevectorcart: false
basevectorgeod: false
poscovcartesian: false
poscovgeodetic: true
velcovgeodetic: true
atteuler: false
attcoveuler: true
pose: false
twist: false
diagnostics: false

For GNSS Rx only

gpgsa: false
gpgsv: false

For INS Rx only

insnavcart: false
insnavgeod: false
extsensormeas: false
imusetup: false
velsensorsetup: false
exteventinsnavcart: false
exteventinsnavgeod: false
imu: false
localization: false
tf: false

INS-Specific Parameters

ins_spatial_config:
imu_orientation:
theta_x: 0.0
theta_y: 0.0
theta_z: 0.0
poi_lever_arm:
delta_x: 0.0
delta_y: 0.0
delta_z: 0.0
ant_lever_arm:
x: 0.0
y: 0.0
z: 0.0
vsm_lever_arm:
vsm_x: 0.0
vsm_y: 0.0
vsm_z: 0.0

ins_initial_heading: auto

ins_std_dev_mask:
att_std_dev: 5.0
pos_std_dev: 10.0

ins_use_poi: false

ins_vsm:
ros:
source: ""
config: [false, false, false]
variances_by_parameter: false
variances: [0.0, 0.0, 0.0]
ip_server:
id: ""
port: 0
keep_open: true
serial:
port: ""
baud_rate: 115200
keep_open: true

Logger

activate_debug_log: false

Publish RTCM

Not an issue, but a suggestion.

It would be nice to be able to simply publish and consume rtcm_msgs or similar in some admittedly more obscure set ups.

One such setup is a location with no internet connection, but with

one or more rovers (separate ROS instances with receivers),
data link (wifi, or other data link, with some method of ROS topic bridging)
and a local RTK reference station (another ROS instance, with another receiver and survey antenna).

With the above we can deploy at any site, without the requirement for any internet based NTRIP caster. Instead, using ROS messages to distribute RTCM. This keeps it nice and tidy, with no 'outside ROS' software or communications (eg. u-center, SNIP, which are both non-linux, or even any linux NTRIP caster).

I currently use an F9P, and don't have a Septentrio receiver to trial, unfortunately.
But this receiver looks promising and I hope to obtain one soon.

Driver crashing with double free or corruption error

Hi,

The driver seems to crash if I run it for a longer period of time. It gave a double free or corruption error.

My setup is as follows:
Asterx i3 D Pro+ connected over usb to a pc.
bnc ntrip client connecting on usb2 of the asterx i3.

Corrections VIA Serial

Hello,

I intend on communicating with the Astrex SBi3 via Ethernet (TCP IP), but i would like to provide differential corrections via Serial (COM1-GPIO).

Reading the code, im not sure this is possible.

In the configureRx() function, the "device" parameter is parsed, and if proto=="tcp", the corrections are assumed to be provided over TCP.

The same "device" paramter is parsed in the initializeIO() when connecting to the device.

Is it possible to use tcp to connect to device, and serial to provide corrections (i am not using NTRIP, i have a radio on board that received corrections for a local base station).

/imu topic gives .nan in orientation

Hello
I'm using ros2 (branch ros2) driver for AsteRx SBi3 Pro+ on Ubuntu 20.04 with ROS Foxy. I have been receiving ".nan" in the orientation field of the /imu topic. Everything else seems good. I have received the RTK FIxed status and connected to base station.
I also tried to checkout to dev2 branch but couldn't able to build it on foxy due to some errors.
Note* I also used drivers from dev2 branch with ros2 humble. it was built and working fine. /imu topic is also having accurate values.

Could someone help me out with this issue?

working environment:
ROS Foxy
Jetson Orin Nano

Septentrio AsteRx SBi3 Pro+ RTK status jumps and GNSS/INS data invalid with ROS driver

Hi,

We are using the septentrio_gnss_driver v1.3.2 (https://github.com/septentrio-gnss/septentrio_gnss_driver/releases/tag/v1.3.2) for AsteRx SBi3 Pro+ on Ubuntu 2.04 with ROS Noetic. We used the USB interface with AsteRx SBi3 Pro+.

We had two issues related to RTK and GNSS/INS output data. Before we use the device, I did the device initialization from this link (https://customersupport.septentrio.com/s/article/How-to-initialize-the-IMU-of-your-Septentrio-GNSS-INS-solution).

(1) We used HxGN SmartNet RTK service. We had the RTK Fixed worked. However, we found that whenever we drove our vehicle around, the RTK fixed status jumps to Disabled and the GNSS/INS output data also drifted

Note: I understand that which ROS topic to read for the status of the GNSS/INS, such as RTK float, RTK fixed, or no RTK in previous post. We checked the Internet connect, it was good for the 4G/LTE module.

(2) We also found that the GNSS/INS data became invalid quite often when we drove the vehicle outside. Sometime the invalid data stayed for quite a long time or never getting back to the normal values.

We also posted our recorded video here: https://youtu.be/jCihYPSxACE

We configured the AsteRx SBi3 Pro+ device through the webGUI, not the ROS driver as belows.

Any suggestion on above issues?

Thanks a lot for the help!

Best,
Hang

Issues trying to launch rover.launch file

Hello,
after following the steps to install the driver and populating the rover.yaml file to the desired values for my ins (AsteRx-i D UAS) i reiceive the following errors when trying to launch using the launch command: roslaunch septentrio_gnss_driver rover.launch param_file_name:=rover.

[ERROR] [1651696982.905807212]: /septentrio_gnss: Invalid command just sent to the Rx! The Rx's response contains 40 bytes and reads:
$R? sga, MultiAntenna : Invalid command!
[ERROR] [1651696983.164258781]: /septentrio_gnss: Invalid command just sent to the Rx! The Rx's response contains 55 bytes and reads:
$R? sivl, VSM1, -0.348, 0.546, 0.711 : Invalid command!
[ERROR] [1651696983.288957650]: /septentrio_gnss: Invalid command just sent to the Rx! The Rx's response contains 33 bytes and reads:
$R? siih, auto : Invalid command!

Tried troubleshooting myself but am not sure what I am missing. Any ideas?

`# Configuration Settings for the Rover Rx

GNSS/INS Parameters

device: tcp://192.168.3.1:28784

serial:
baudrate: 115200
rx_serial_port: USB0
hw_flow_control: off

frame_id: gnss

imu_frame_id: imu

poi_frame_id: base_link

vsm_frame_id: vsm

aux1_frame_id: aux1

vehicle_frame_id: base_link

get_spatial_config_from_tf: false

lock_utm_zone: true

use_ros_axis_orientation: true

receiver_type: ins

datum: ETRS89

poi_to_arp:
delta_e: 0.0
delta_n: 0.0
delta_u: 0.0

att_offset:
heading: 0.0
pitch: 0.0

ant_type: Unknown
ant_serial_nr: Unknown
ant_aux1_type: Unknown
ant_aux1_serial_nr: Unknown

leap_seconds: 18

polling_period:
pvt: 500
rest: 500

use_gnss_time: false

ntrip_settings:
mode: off
caster: 0
caster_port: 0
username: 0
password: 0
mountpoint: 0
ntrip_version: v2
send_gga: auto
rx_has_internet: false
rtcm_version: RTCMv2
rx_input_corrections_tcp: 6666
rx_input_corrections_serial: USB2

publish:

For both GNSS and INS Rxs

navsatfix: false
gpsfix: true
gpgga: false
gprmc: false
gpst : false
measepoch: false
pvtcartesian: false
pvtgeodetic: true
poscovcartesian: false
poscovgeodetic: true
velcovgeodetic: true
atteuler: true
attcoveuler: false
pose: true
diagnostics: false

For GNSS Rx only

gpgsa: false
gpgsv: false

For INS Rx only

insnavcart: false
insnavgeod: false
extsensormeas: false
imusetup: true
velsensorsetup: false
exteventinsnavcart: false
exteventinsnavgeod: false
imu: false
localization: false
tf: false

INS-Specific Parameters

ins_spatial_config:
imu_orientation:
theta_x: 180.0
theta_y: 0.0
theta_z: 180.0
poi_lever_arm:
delta_x: 0.0
delta_y: 0.0
delta_z: 0.0
ant_lever_arm:
x: -0.348
y: -0.546
z: -0.711
vel_sensor_lever_arm:
vsm_x: 0.0
vsm_y: 0.0
vsm_z: 0.0

ins_initial_heading: auto

ins_std_dev_mask:
att_std_dev: 5.0
pos_std_dev: 10.0

ins_use_poi: false

Logger

activate_debug_log: false`

Check confuguration of Ntrip corrections

First of all the driver is working pretty well and the documentation helps a lot. The only issue I have, is that I don't get Ntrip connections to work. I use the the Mosaic go heading evaluation kit.

The board is connected via USB port and tcp is used. All the activated messages arrive in ROS. I configured the ntrip settings according to the instructions i found to the following settings:

ntrip_1:
 id: "1"
 caster: "www.sapos.geonord-OD.de"
 caster_port: 2101
 username: "gast"
 password: "gast"
 mountpoint: "RTCM4G"
 version: "v2"
 tls: true
 fingerprint: ""
 rtk_standard: "RTCMv3"
 send_gga: "auto"
 keep_open: true

Is there an easy way to check, why ntrip is not working? What i want to check is, if the receiver has internet access and can query corrections from the ntrip caster. Any hints on how to debug this? The web interface of the receiver does not show any activated ntrip streams.

Install hyperlink to old ROS distribution on ros2 branch

In the ros2 branch the install link goes to 'https://docs.ros.org/en/humble/index.html' which is an older version? Should change it to 'https://docs.ros.org/en/iron/index.html'?

driver does not publish topics

When I launch rover.launch with the rover.yaml file the /septentrio_gnss node does only publishes to /rosout and /tf topic.
I changed the device and adapted the baudrate for my device, the rest is default.

device: serial:/dev/ttyACM0

serial:
  baudrate: 115200
  rx_serial_port: ACM0
  hw_flow_control: off

The node receives data via Serial port but does not publish any odometry or navsat messages.

process[septentrio_gnss-5]: started with pid [2744]
[DEBUG] [1690366183.397064203]: /septentrio_gnss: Called ROSaicNode() constructor..
[DEBUG] [1690366183.645232391]: /septentrio_gnss: IMU roll offset: 180.000000
[DEBUG] [1690366183.645283271]: /septentrio_gnss: IMU pitch offset: -0.000000
[DEBUG] [1690366183.645393205]: /septentrio_gnss: IMU yaw offset: -0.000000
[DEBUG] [1690366183.645429037]: /septentrio_gnss: Ant heading offset: -0.000000
[DEBUG] [1690366183.645457700]: /septentrio_gnss: Ant pitch offset: -0.000000
[ WARN] [1690366183.688190502]: /septentrio_gnss: AttEuler needs multi-antenna receiver. Multi-antenna setting automatically activated. Deactivate publishing of AttEuler if multi-antenna operation is not available.
[DEBUG] [1690366183.688234891]: /septentrio_gnss: Finished getROSParams() method
[DEBUG] [1690366183.688260394]: /septentrio_gnss: Called initializeIO() method
[DEBUG] [1690366183.688375014]: /septentrio_gnss: Searching for serial port/dev/ttyACM0
[DEBUG] [1690366183.688443967]: /septentrio_gnss: Leaving initializeIO() method
[DEBUG] [1690366183.688467093]: /septentrio_gnss: Called defineMessages() method
[DEBUG] [1690366183.688492509]: /septentrio_gnss: Key 4007 successfully inserted into multimap: true
[DEBUG] [1690366183.688517012]: /septentrio_gnss: Key 5906 successfully inserted into multimap: true
[DEBUG] [1690366183.688550000]: /septentrio_gnss: Called connect() method
[DEBUG] [1690366183.688594200]: /septentrio_gnss: Key 5908 successfully inserted into multimap: true
[DEBUG] [1690366183.688636792]: /septentrio_gnss: Key 5938 successfully inserted into multimap: true
[DEBUG] [1690366183.688673906]: /septentrio_gnss: Key 5939 successfully inserted into multimap: true
[DEBUG] [1690366183.688710510]: /septentrio_gnss: Key 4027 successfully inserted into multimap: true
[DEBUG] [1690366183.688751519]: /septentrio_gnss: Key NavSatFix successfully inserted into multimap: true
[DEBUG] [1690366183.688797077]: /septentrio_gnss: Key GPSFix successfully inserted into multimap: true
[DEBUG] [1690366183.688830181]: /septentrio_gnss: Key 4013 successfully inserted into multimap: true
[DEBUG] [1690366183.688869005]: /septentrio_gnss: Key 4001 successfully inserted into multimap: true
[DEBUG] [1690366183.688908102]: /septentrio_gnss: Key DiagnosticArray successfully inserted into multimap: true
[DEBUG] [1690366183.688948936]: /septentrio_gnss: Key 4014 successfully inserted into multimap: true
[DEBUG] [1690366183.689018041]: /septentrio_gnss: Key 4082 successfully inserted into multimap: true
[DEBUG] [1690366183.689061572]: /septentrio_gnss: Key 5902 successfully inserted into multimap: true
[DEBUG] [1690366183.689093404]: /septentrio_gnss: Leaving defineMessages() method
[DEBUG] [1690366183.689121600]: /septentrio_gnss: Called configureRx() method
[DEBUG] [1690366183.689148338]: /septentrio_gnss: Started timer for calling reconnect() method until connection succeeds
[DEBUG] [1690366183.689274291]: /septentrio_gnss: Called reconnect() method
[ INFO] [1690366183.689312854]: /septentrio_gnss: Connecting serially to device/dev/ttyACM0, targeted baudrate: 115200
[DEBUG] [1690366183.689339701]: /septentrio_gnss: Calling initializeSerial() method..
[ INFO] [1690366183.689493281]: /septentrio_gnss: Opened serial port /dev/ttyACM0
[DEBUG] [1690366183.689519236]: /septentrio_gnss: Our boost version is 106501.
[DEBUG] [1690366183.689556710]: /septentrio_gnss: Creating new Async-Manager object..
[DEBUG] [1690366183.689598457]: /septentrio_gnss: Setting the private stream variable of the AsyncManager instance.
[DEBUG] [1690366183.689724192]: /septentrio_gnss: Launching tryParsing() thread..
[DEBUG] [1690366183.689791967]: /septentrio_gnss: Called setManager() method
[DEBUG] [1690366183.689826916]: /septentrio_gnss: Leaving setManager() method
[DEBUG] [1690366183.689849724]: /septentrio_gnss: Gradually increasing the baudrate to the desired value...
[DEBUG] [1690366183.689870545]: /septentrio_gnss: Initiated current_baudrate object...
[DEBUG] [1690366183.689893544]: /septentrio_gnss: Current baudrate is 115200
[ INFO] [1690366183.689914272]: /septentrio_gnss: Set ASIO baudrate to 115200, leaving InitializeSerial() method
[DEBUG] [1690366183.689937896]: /septentrio_gnss: Leaving reconnect() method
[DEBUG] [1690366183.690029536]: /septentrio_gnss: Sent the following 22 bytes to the Rx: 
SSSSSSSSSSSSSSSSSSS
[DEBUG] [1690366183.706319800]: /septentrio_gnss: Calling read_callback_() method, with number of bytes to be parsed being 108
[DEBUG] [1690366183.724224402]: /septentrio_gnss: Calling read_callback_() method, with number of bytes to be parsed being 19
[DEBUG] [1690366183.754251459]: /septentrio_gnss: Calling read_callback_() method, with number of bytes to be parsed being 93
[DEBUG] [1690366183.808427245]: /septentrio_gnss: Calling read_callback_() method, with number of bytes to be parsed being 128
[DEBUG] [1690366183.808860588]: /septentrio_gnss: The NMEA message contains 125 bytes and is ready to be parsed. It reads: $GPGGA,000217.699,,,,,0,0,,,M,,M,,*4A???;
[DEBUG] [1690366183.809268898]: /septentrio_gnss: The NMEA message contains 49 bytes and is ready to be parsed. It reads: $GPGSA,A,1,,,,,,,,,,,,,,,*1E???/
[DEBUG] [1690366183.910394340]: /septentrio_gnss: Calling read_callback_() method, with number of bytes to be parsed being 108
[DEBUG] [1690366183.910556725]: /septentrio_gnss: The NMEA message contains 105 bytes and is ready to be parsed. It reads: $GPGGA,000217.800,,,,,0,0,,,M,,M,,*44I??;
[DEBUG] [1690366183.910746510]: /septentrio_gnss: The NMEA message contains 29 bytes and is ready to be parsed. It reads: $GPGSA,A,1,,,,,,,,,,,,,,,*1E,
[DEBUG] [1690366183.958226057]: /septentrio_gnss: Calling read_callback_() method, with number of bytes to be parsed being 93
[DEBUG] [1690366184.012219790]: /septentrio_gnss: Calling read_callback_() method, with number of bytes to be parsed being 153
[DEBUG] [1690366184.012419647]: /septentrio_gnss: The NMEA message contains 115 bytes and is ready to be parsed. It reads: $GPGSA,A,1,,,,,,,,,,,,,,,*1E]??N
[DEBUG] [1690366184.012669385]: /septentrio_gnss: The NMEA message contains 48 bytes and is ready to be parsed. It reads: $GPRMC,000217.900,V,,,,,0.00,0.00,060180,,,N*4F?
[DEBUG] [1690366184.018143287]: /septentrio_gnss: Calling read_callback_() method, with number of bytes to be parsed being 74
[DEBUG] [1690366184.018247420]: /septentrio_gnss: The NMEA message contains 36 bytes and is ready to be parsed. It reads: $GPVTG,0.00,T,,M,0.00,N,0.00,K,N*32�
[DEBUG] [1690366184.060196756]: /septentrio_gnss: Calling read_callback_() method, with number of bytes to be parsed being 93
[DEBUG] [1690366184.108256178]: /septentrio_gnss: Calling read_callback_() method, with number of bytes to be parsed being 112

~$ rosnode info /septentrio_gnss 
--------------------------------------------------------------------------------
Node [/septentrio_gnss]
Publications: 
 * /rosout [rosgraph_msgs/Log]
 * /tf [tf2_msgs/TFMessage]

Subscriptions: 
 * /tf [tf2_msgs/TFMessage]
 * /tf_static [tf2_msgs/TFMessage]

Services: 
 * /septentrio_gnss/get_loggers
 * /septentrio_gnss/set_logger_level


contacting node http://cpr-j100-0405:38911/ ...
Pid: 3924
Connections:
 * topic: /rosout
    * to: /rosout
    * direction: outbound (54435 - 127.0.0.1:41072) [27]
    * transport: TCPROS
 * topic: /tf
    * to: /septentrio_gnss
    * direction: outbound
    * transport: INTRAPROCESS
 * topic: /tf
    * to: /ekf_localization
    * direction: outbound (54435 - 127.0.0.1:41076) [28]
    * transport: TCPROS
 * topic: /tf
    * to: /septentrio_gnss (http://cpr-j100-0405:38911/)
    * direction: inbound
    * transport: INTRAPROCESS
 * topic: /tf
    * to: /imu_filter (http://cpr-j100-0405:40707/)
    * direction: inbound (38974 - cpr-j100-0405:42223) [23]
    * transport: TCPROS
 * topic: /tf
    * to: /robot_state_publisher (http://cpr-j100-0405:38435/)
    * direction: inbound (34090 - cpr-j100-0405:51243) [24]
    * transport: TCPROS
 * topic: /tf
    * to: /ekf_localization (http://cpr-j100-0405:38215/)
    * direction: inbound (39748 - cpr-j100-0405:42899) [25]
    * transport: TCPROS
 * topic: /tf
    * to: /jackal_node (http://cpr-j100-0405:41095/)
    * direction: inbound (56602 - cpr-j100-0405:55757) [26]
    * transport: TCPROS
 * topic: /tf_static
    * to: /robot_state_publisher (http://cpr-j100-0405:38435/)
    * direction: inbound (34074 - cpr-j100-0405:51243) [21]
    * transport: TCPROS
 * topic: /tf_static
    * to: /tf_imu (http://cpr-j100-0405:35627/)
    * direction: inbound (39558 - cpr-j100-0405:57601) [22]
    * transport: TCPROS
 * topic: /tf_static
    * to: /tf_gnss (http://cpr-j100-0405:44081/)
    * direction: inbound (50422 - cpr-j100-0405:34431) [29]
    * transport: TCPROS
 * topic: /tf_static
    * to: /tf_vsm (http://cpr-j100-0405:38325/)
    * direction: inbound (59446 - cpr-j100-0405:59081) [30]
    * transport: TCPROS
 * topic: /tf_static
    * to: /tf_aux1 (http://cpr-j100-0405:34213/)
    * direction: inbound (37030 - cpr-j100-0405:50933) [31]
    * transport: TCPROS

I know the device is currently reporting nonsense NMEA sentences, but I assumed that the node still would advertise any topics, or am I wrong there.

Maybe someone can help me with my issue,
thanks in advance.

Mosaic X5: ECEF is not output on ROS 1 (ROS Noetic) driver on Ubuntu 20.04

Using ros1 driver to get rostopic echo /septentrio_gnss/pose outputs the x,y in lat, long and z in meters.

How could we get the ecef coordinates ?

.nan in orientation filed of pose topic

I'm using ROS 2 (Humble on Ubuntu 22.04) with the septentrio_gnss_driver with mosaic-H and dual antenna setup. In the web gui I can see that a heading and pitch are being correctly reported. However the ROS "pose" topic contains only ".nan" for the "orientation" field.

Are you able to help please?

-20000000000 orientation values in dual-antenna setup

Good afternoon,

We are using the mosaic-H module in dual-antenna setup and have checked that the "multi-antenna" mode was selected, both in the config/rover.yaml that we are using and in the web interface.

Nonetheless, we are still faced with a value of -20000000000 in the fields "track", "pitch" and "roll" as long as the mosaic-H module is not moving, and as soon as it's not moving anymore. These fields do provide us with correct values when moving, but it's as if the module were in "MovingBase" mode (which it's not supposed to be in).

Moreover, contrary to another issue we read, in the "/atteuler" topic the "heading" field also displays a value of -20000000000 when the mosaic-H is at a standstill.

Could the issue stem from septentrio_gnss_driver?

Thank you very much for your time and attention

Mosaic X5: Ntrip of rtk_settings does not work for ROS 1 (ROS Noetic) driver on Ubuntu 20.04

We are using the following setting file on the yaml file. The ntrip settings work using the datalink, but not the ros driver.

# Configuration Settings for the Rover Rx

# GNSS/INS Parameters

device: tcp://192.168.3.1:28784

serial:
  baudrate: 921600
  hw_flow_control: "off"

stream_device:
  tcp:
    ip_server: ""
    port: 0
  udp:
    ip_server: ""
    port: 0
    unicast_ip: ""

configure_rx: true

login:
  user: ""
  password: ""

osnma:
  mode: "loose"
  ntp_server: ""
  keep_open: true

frame_id: gnss

aux1_frame_id: aux1

get_spatial_config_from_tf: true

use_ros_axis_orientation: true

receiver_type: gnss

multi_antenna: false

datum: Default

att_offset:
  heading: 0.0
  pitch: 0.0

ant_type: "Unknown"
ant_serial_nr: "Unknown"
ant_aux1_type: "Unknown"
ant_aux1_serial_nr: "Unknown"

polling_period:
  pvt: 0
  rest: 500

use_gnss_time: false

latency_compensation: false

rtk_settings:  
  ntrip_1:
    id: "RTS1"
    caster: "xx.com"
    caster_port: 2101
    username: "aa"
    password: "aa"
    mountpoint: "aa"
    version: "v2"
    tls: false
    fingerprint: ""
    rtk_standard: "auto"
    send_gga: "auto"
    keep_open: true
  ip_server_1:
    id: ""
    port: 0
    rtk_standard: "auto"
    send_gga: "auto"
    keep_open: true
  serial_1:
    port: ""
    baud_rate: 115200
    rtk_standard: "auto"
    send_gga: "auto"
    keep_open: true

publish:
  # For both GNSS and INS Rxs
  navsatfix: true
  gpsfix: true
  gpgga: true
  gprmc: true
  gpst: true
  measepoch: true
  pvtcartesian: true
  pvtgeodetic: true
  basevectorcart: false
  basevectorgeod: false
  poscovcartesian: true
  poscovgeodetic: true
  velcovcartesian: false
  velcovgeodetic: true
  atteuler: false
  attcoveuler: true
  pose: true
  twist: false
  diagnostics: true
  aimplusstatus: true
  galauthstatus: false
  # For GNSS Rx only
  gpgsa: false
  gpgsv: false
# logger

activate_debug_log: true

Terminal output

CLEAR PARAMETERS
 * /septentrio_gnss/

PARAMETERS
 * /rosdistro: noetic
 * /rosversion: 1.16.0
 * /septentrio_gnss/activate_debug_log: True
 * /septentrio_gnss/ant_aux1_serial_nr: Unknown
 * /septentrio_gnss/ant_aux1_type: Unknown
 * /septentrio_gnss/ant_serial_nr: Unknown
 * /septentrio_gnss/ant_type: Unknown
 * /septentrio_gnss/att_offset/heading: 0.0
 * /septentrio_gnss/att_offset/pitch: 0.0
 * /septentrio_gnss/aux1_frame_id: aux1
 * /septentrio_gnss/configure_rx: True
 * /septentrio_gnss/datum: Default
 * /septentrio_gnss/device: tcp://192.168.3.1...
 * /septentrio_gnss/frame_id: gnss
 * /septentrio_gnss/get_spatial_config_from_tf: True
 * /septentrio_gnss/latency_compensation: False
 * /septentrio_gnss/login/password: 
 * /septentrio_gnss/login/user: 
 * /septentrio_gnss/multi_antenna: False
 * /septentrio_gnss/osnma/keep_open: True
 * /septentrio_gnss/osnma/mode: loose
 * /septentrio_gnss/osnma/ntp_server: 
 * /septentrio_gnss/polling_period/pvt: 0
 * /septentrio_gnss/polling_period/rest: 500
 * /septentrio_gnss/publish/aimplusstatus: True
 * /septentrio_gnss/publish/attcoveuler: True
 * /septentrio_gnss/publish/atteuler: False
 * /septentrio_gnss/publish/basevectorcart: False
 * /septentrio_gnss/publish/basevectorgeod: False
 * /septentrio_gnss/publish/diagnostics: True
 * /septentrio_gnss/publish/galauthstatus: False
 * /septentrio_gnss/publish/gpgga: True
 * /septentrio_gnss/publish/gpgsa: False
 * /septentrio_gnss/publish/gpgsv: False
 * /septentrio_gnss/publish/gprmc: True
 * /septentrio_gnss/publish/gpsfix: True
 * /septentrio_gnss/publish/gpst: True
 * /septentrio_gnss/publish/measepoch: True
 * /septentrio_gnss/publish/navsatfix: True
 * /septentrio_gnss/publish/poscovcartesian: True
 * /septentrio_gnss/publish/poscovgeodetic: True
 * /septentrio_gnss/publish/pose: True
 * /septentrio_gnss/publish/pvtcartesian: True
 * /septentrio_gnss/publish/pvtgeodetic: True
 * /septentrio_gnss/publish/twist: False
 * /septentrio_gnss/publish/velcovcartesian: False
 * /septentrio_gnss/publish/velcovgeodetic: True
 * /septentrio_gnss/receiver_type: gnss
 * /septentrio_gnss/rtk_settings/ip_server_1/id: 
 * /septentrio_gnss/rtk_settings/ip_server_1/keep_open: True
 * /septentrio_gnss/rtk_settings/ip_server_1/port: 0
 * /septentrio_gnss/rtk_settings/ip_server_1/rtk_standard: auto
 * /septentrio_gnss/rtk_settings/ip_server_1/send_gga: auto
 * /septentrio_gnss/rtk_settings/ntrip_1/caster: polaris.pointonen...
 * /septentrio_gnss/rtk_settings/ntrip_1/caster_port: 2101
 * /septentrio_gnss/rtk_settings/ntrip_1/fingerprint: 
 * /septentrio_gnss/rtk_settings/ntrip_1/id: RTS1
 * /septentrio_gnss/rtk_settings/ntrip_1/keep_open: True
 * /septentrio_gnss/rtk_settings/ntrip_1/mountpoint: POLARIS
 * /septentrio_gnss/rtk_settings/ntrip_1/password: boHKUXL6
 * /septentrio_gnss/rtk_settings/ntrip_1/rtk_standard: auto
 * /septentrio_gnss/rtk_settings/ntrip_1/send_gga: auto
 * /septentrio_gnss/rtk_settings/ntrip_1/tls: False
 * /septentrio_gnss/rtk_settings/ntrip_1/username: uiVKaM9I
 * /septentrio_gnss/rtk_settings/ntrip_1/version: v2
 * /septentrio_gnss/rtk_settings/serial_1/baud_rate: 115200
 * /septentrio_gnss/rtk_settings/serial_1/keep_open: True
 * /septentrio_gnss/rtk_settings/serial_1/port: 
 * /septentrio_gnss/rtk_settings/serial_1/rtk_standard: auto
 * /septentrio_gnss/rtk_settings/serial_1/send_gga: auto
 * /septentrio_gnss/serial/baudrate: 921600
 * /septentrio_gnss/serial/hw_flow_control: off
 * /septentrio_gnss/stream_device/tcp/ip_server: 
 * /septentrio_gnss/stream_device/tcp/port: 0
 * /septentrio_gnss/stream_device/udp/ip_server: 
 * /septentrio_gnss/stream_device/udp/port: 0
 * /septentrio_gnss/stream_device/udp/unicast_ip: 
 * /septentrio_gnss/use_gnss_time: False
 * /septentrio_gnss/use_ros_axis_orientation: True

NODES
  /
    septentrio_gnss (septentrio_gnss_driver/septentrio_gnss_driver_node)
    tf_aux1 (tf2_ros/static_transform_publisher)
    tf_gnss (tf2_ros/static_transform_publisher)
    tf_imu (tf2_ros/static_transform_publisher)
    tf_vsm (tf2_ros/static_transform_publisher)

auto-starting new master
process[master]: started with pid [98532]
ROS_MASTER_URI=http://192.168.68.102:11311

setting /run_id to c8cbb85e-d5c5-11ee-bad2-7336b3283a47
process[rosout-1]: started with pid [98542]
started core service [/rosout]
process[tf_imu-2]: started with pid [98550]
process[tf_gnss-3]: started with pid [98551]
process[tf_vsm-4]: started with pid [98552]
process[tf_aux1-5]: started with pid [98554]
process[septentrio_gnss-6]: started with pid [98564]
[DEBUG] [1709075595.367863620]: /septentrio_gnss: Called ROSaicNode() constructor..
[DEBUG] [1709075595.383316718]: /septentrio_gnss: IMU roll offset: 180.000000
[DEBUG] [1709075595.383354303]: /septentrio_gnss: IMU pitch offset: -0.000000
[DEBUG] [1709075595.383366723]: /septentrio_gnss: IMU yaw offset: -0.000000
[DEBUG] [1709075595.383378147]: /septentrio_gnss: Ant heading offset: -0.000000
[DEBUG] [1709075595.383389239]: /septentrio_gnss: Ant pitch offset: -0.000000
[DEBUG] [1709075595.387879735]: /septentrio_gnss: Finished getROSParams() method
[DEBUG] [1709075595.387890406]: /septentrio_gnss: Called connect() method
[DEBUG] [1709075595.387895906]: /septentrio_gnss: Started timer for calling connect() method until connection succeeds
[DEBUG] [1709075595.387917853]: /septentrio_gnss: Called initializeIo() method
[DEBUG] [1709075595.387924438]: /septentrio_gnss: AsyncManager created.
[ INFO] [1709075595.388044026]: /septentrio_gnss: Connecting to tcp://192.168.3.1:28784...
[ INFO] [1709075595.388872117]: /septentrio_gnss: Connected to 192.168.3.1:28784.
[DEBUG] [1709075595.388943473]: /septentrio_gnss: Configure Rx.
[DEBUG] [1709075595.388951642]: /septentrio_gnss: Called configureRx() method
SSSSSSSSSS709075595.389037128]: /septentrio_gnss: AsyncManager sent the following 13 bytes to the Rx: 
[DEBUG] [1709075595.403938667]: /septentrio_gnss: handleCd: IP10>
SSSSSSSSSS709075595.404046424]: /septentrio_gnss: AsyncManager sent the following 13 bytes to the Rx: 
[DEBUG] [1709075595.405578521]: /septentrio_gnss: handleCd: IP10>
SSSSSSSSSS709075595.405701652]: /septentrio_gnss: AsyncManager sent the following 13 bytes to the Rx: 
[DEBUG] [1709075595.406815184]: /septentrio_gnss: handleCd: IP10>
[ INFO] [1709075595.406940210]: /septentrio_gnss: The connection descriptor is IP10
[ INFO] [1709075595.406972489]: /septentrio_gnss: Setting up Rx.
[DEBUG] [1709075595.407035277]: /septentrio_gnss: AsyncManager sent the following 27 bytes to the Rx: sso, all, none, none, off 
[DEBUG] [1709075595.428538794]: Trying to publish message of type [septentrio_gnss_driver/MeasEpoch/4cf9a1d78edfe10d2a772f4a50dd0645] on a publisher with type [septentrio_gnss_driver/MeasEpoch/4cf9a1d78edfe10d2a772f4a50dd0645]
[DEBUG] [1709075595.429645219]: Trying to publish message of type [septentrio_gnss_driver/PVTCartesian/98b7f07c88704d34a9797ee6019c2d54] on a publisher with type [septentrio_gnss_driver/PVTCartesian/98b7f07c88704d34a9797ee6019c2d54]
[DEBUG] [1709075595.430732756]: Trying to publish message of type [septentrio_gnss_driver/PVTGeodetic/4d3911a0efd862e13c076ba7d322cd3e] on a publisher with type [septentrio_gnss_driver/PVTGeodetic/4d3911a0efd862e13c076ba7d322cd3e]
[DEBUG] [1709075595.431444311]: Trying to publish message of type [sensor_msgs/TimeReference/fded64a0265108ba86c3d38fb11c0c16] on a publisher with type [sensor_msgs/TimeReference/fded64a0265108ba86c3d38fb11c0c16]
[DEBUG] [1709075595.432126714]: Trying to publish message of type [septentrio_gnss_driver/PosCovCartesian/6f9c694efd927f0282537b2693bfa92f] on a publisher with type [septentrio_gnss_driver/PosCovCartesian/6f9c694efd927f0282537b2693bfa92f]
[DEBUG] [1709075595.432918284]: Trying to publish message of type [septentrio_gnss_driver/PosCovGeodetic/d5a0ad571ba33ff67cc97dcff03d6b87] on a publisher with type [septentrio_gnss_driver/PosCovGeodetic/d5a0ad571ba33ff67cc97dcff03d6b87]
[DEBUG] [1709075595.433642995]: Trying to publish message of type [sensor_msgs/NavSatFix/2d3a8cd499b9b4a0249fb98fd05cfa48] on a publisher with type [sensor_msgs/NavSatFix/2d3a8cd499b9b4a0249fb98fd05cfa48]
[DEBUG] [1709075595.434409445]: Trying to publish message of type [septentrio_gnss_driver/VelCovGeodetic/b62aa4ae504c44f18ac72015246a1586] on a publisher with type [septentrio_gnss_driver/VelCovGeodetic/b62aa4ae504c44f18ac72015246a1586]
[DEBUG] [1709075595.435125066]: Trying to publish message of type [septentrio_gnss_driver/AttCovEuler/e0afc6c2dfb1f98f719a573ace215ea7] on a publisher with type [septentrio_gnss_driver/AttCovEuler/e0afc6c2dfb1f98f719a573ace215ea7]
[DEBUG] [1709075595.435734713]: Trying to publish message of type [geometry_msgs/PoseWithCovarianceStamped/953b798c0f514ff060a53a3498ce6246] on a publisher with type [geometry_msgs/PoseWithCovarianceStamped/953b798c0f514ff060a53a3498ce6246]
[DEBUG] [1709075595.436311908]: Trying to publish message of type [gps_common/GPSFix/3db3d0a7bc53054c67c528af84710b70] on a publisher with type [gps_common/GPSFix/3db3d0a7bc53054c67c528af84710b70]
[DEBUG] [1709075595.490975271]: /septentrio_gnss: The Rx's response contains 32 bytes and reads:
 $R: sso, all, none, none, off 

[DEBUG] [1709075595.491062759]: /septentrio_gnss: A message received:   SBFOutput, Stream1, none, none, off

[DEBUG] [1709075595.491095212]: /septentrio_gnss: A message received:   SBFOutput, Stream2, none, none, off

[DEBUG] [1709075595.491123871]: /septentrio_gnss: A message received:   SBFOutput, Stream3, none, none, off

[DEBUG] [1709075595.491177354]: /septentrio_gnss: A message received:   SBFOutput, Stream4, none, none, off

[DEBUG] [1709075595.491285265]: /septentrio_gnss: AsyncManager sent the following 27 bytes to the Rx: sno, all, none, none, off 
[DEBUG] [1709075595.491515849]: /septentrio_gnss: A message received:   SBFOutput, Stream5, none, none, off

[DEBUG] [1709075595.491590317]: /septentrio_gnss: A message received:   SBFOutput, Stream6, none, none, off

[DEBUG] [1709075595.491622001]: /septentrio_gnss: A message received:   SBFOutput, Stream7, none, none, off

[DEBUG] [1709075595.491668219]: /septentrio_gnss: A message received:   SBFOutput, Stream8, none, none, off

[DEBUG] [1709075595.491751402]: /septentrio_gnss: A message received:   SBFOutput, Stream9, none, none, off

[DEBUG] [1709075595.491838651]: /septentrio_gnss: A message received:   SBFOutput, Stream10, none, none, off

[DEBUG] [1709075595.491916533]: /septentrio_gnss: A message received:   SBFOutput, Res1, none, none, off

[DEBUG] [1709075595.491993608]: /septentrio_gnss: A message received:   SBFOutput, Res2, none, none, off

[DEBUG] [1709075595.492071214]: /septentrio_gnss: A message received:   SBFOutput, Res3, none, none, off

[DEBUG] [1709075595.492149196]: /septentrio_gnss: A message received:   SBFOutput, Res4, none, none, off

[DEBUG] [1709075595.492185889]: /septentrio_gnss: handleCd: IP10>
[DEBUG] [1709075595.549991918]: /septentrio_gnss: The Rx's response contains 32 bytes and reads:
 $R: sno, all, none, none, off 

[DEBUG] [1709075595.550074017]: /septentrio_gnss: A message received:   NMEAOutput, Stream1, none, none, off

[DEBUG] [1709075595.550099842]: /septentrio_gnss: A message received:   NMEAOutput, Stream2, none, none, off

[DEBUG] [1709075595.550122400]: /septentrio_gnss: A message received:   NMEAOutput, Stream3, none, none, off

[DEBUG] [1709075595.550242128]: /septentrio_gnss: AsyncManager sent the following 5 bytes to the Rx: grc 
[DEBUG] [1709075595.550462847]: /septentrio_gnss: A message received:   NMEAOutput, Stream4, none, none, off

[DEBUG] [1709075595.550531727]: /septentrio_gnss: A message received:   NMEAOutput, Stream5, none, none, off

[DEBUG] [1709075595.550586772]: /septentrio_gnss: A message received:   NMEAOutput, Stream6, none, none, off

[DEBUG] [1709075595.550772650]: /septentrio_gnss: A message received:   NMEAOutput, Stream7, none, none, off

[DEBUG] [1709075595.550833508]: /septentrio_gnss: A message received:   NMEAOutput, Stream8, none, none, off

[DEBUG] [1709075595.550901293]: /septentrio_gnss: A message received:   NMEAOutput, Stream9, none, none, off

[DEBUG] [1709075595.551076863]: /septentrio_gnss: A message received:   NMEAOutput, Stream10, none, none, off

[DEBUG] [1709075595.551140046]: /septentrio_gnss: handleCd: IP10>
[DEBUG] [1709075595.552215942]: /septentrio_gnss: The Rx's response contains 10 bytes and reads:
 $R: grc 

[DEBUG] [1709075595.553256576]: /septentrio_gnss: A message received:   ReceiverCapabilities, Main, GPSL1CA+GPSL1PY+GPSL2PY+GPSL2C+GPSL5+GLOL1CA+GLOL2P+GLOL2CA+GLOL3+GALL1BC+GALE6BC+GALE5a+GALE5b+GALE5+GEOL1+GEOL5+BDSB1I+BDSB2I+BDSB3I+BDSB1C+BDSB2a+BDSB2b+QZSL1CA+QZSL2C+QZSL5+QZSL1CB+LBAND+NAVICL5, DSK1+COM1+COM2+COM3+COM4+USB1+USB2+IP10+IP11+IP12+IP13+IP14+IP15+IP16+IP17+NTR1+NTR2+NTR3+NTR4+IPS1+IPS2+IPS3+IPS4+IPS5+IPR1+IPR2+IPR3+IPR4+IPR5, SBAS+DGNSSRover+DGNSSBase+RTKRover+RTKBase+RTCMv23+RTCMv3x+CMRv20+xPPSOutput+TimedEvent+InternalLogging+APME+RAIM+MovingBase+MeasAv+IM+DSK1, 10, 10

[DEBUG] [1709075595.553332195]: /septentrio_gnss: handleCd: IP10>
[DEBUG] [1709075595.553421639]: /septentrio_gnss: AsyncManager sent the following 11 bytes to the Rx: sgd, WGS84
[DEBUG] [1709075595.611827318]: /septentrio_gnss: The Rx's response contains 16 bytes and reads:
 $R: sgd, WGS84

[DEBUG] [1709075595.611927238]: /septentrio_gnss: A message received:   GeodeticDatum, WGS84

[DEBUG] [1709075595.611973033]: /septentrio_gnss: handleCd: IP10>
[DEBUG] [1709075595.612127415]: /septentrio_gnss: AsyncManager sent the following 51 bytes to the Rx: sao, Main, 0.000, 0.000, 0.000, "Unknown", Unknown
[DEBUG] [1709075595.671291174]: /septentrio_gnss: The Rx's response contains 56 bytes and reads:
 $R: sao, Main, 0.000, 0.000, 0.000, "Unknown", Unknown

[DEBUG] [1709075595.671381465]: /septentrio_gnss: A message received:   AntennaOffset, Main, 0.0000, 0.0000, 0.0000, "Unknown", "Unknown", 0

[DEBUG] [1709075595.671421395]: /septentrio_gnss: handleCd: IP10>
[DEBUG] [1709075595.671605275]: /septentrio_gnss: AsyncManager sent the following 17 bytes to the Rx: snts, RTS1, off 
[ERROR] [1709075595.673451374]: /septentrio_gnss: Invalid command just sent to the Rx! The Rx's response contains 57 bytes and reads:
 $R? setNtripSettings: Tabular argument 'Cd' is invalid!

[DEBUG] [1709075595.673473856]: /septentrio_gnss: handleCd: IP10>
[DEBUG] [1709075595.673526592]: /septentrio_gnss: AsyncManager sent the following 90 bytes to the Rx: snts, RTS1, Client, polaris.pointonenav.com, 2101, uiVKaM9I, boHKUXL6, POLARIS, v2, auto 
[ERROR] [1709075595.675336276]: /septentrio_gnss: Invalid command just sent to the Rx! The Rx's response contains 57 bytes and reads:
 $R? setNtripSettings: Tabular argument 'Cd' is invalid!

[DEBUG] [1709075595.675358074]: /septentrio_gnss: handleCd: IP10>
[DEBUG] [1709075595.675400714]: /septentrio_gnss: AsyncManager sent the following 17 bytes to the Rx: sntt, RTS1, off 
[ERROR] [1709075595.677072412]: /septentrio_gnss: Invalid command just sent to the Rx! The Rx's response contains 60 bytes and reads:
 $R? setNtripTlsSettings: Tabular argument 'Cd' is invalid!

[DEBUG] [1709075595.677112870]: /septentrio_gnss: handleCd: IP10>
[DEBUG] [1709075595.677216136]: /septentrio_gnss: AsyncManager sent the following 11 bytes to the Rx: sga, none 
[DEBUG] [1709075595.736061589]: /septentrio_gnss: The Rx's response contains 16 bytes and reads:
 $R: sga, none 

[DEBUG] [1709075595.736129061]: /septentrio_gnss: A message received:   GNSSAttitude, none

[DEBUG] [1709075595.736150843]: /septentrio_gnss: handleCd: IP10>
[DEBUG] [1709075595.736243022]: /septentrio_gnss: AsyncManager sent the following 21 bytes to the Rx: sto, -0.000, -0.000 
[DEBUG] [1709075595.795349426]: /septentrio_gnss: The Rx's response contains 26 bytes and reads:
 $R: sto, -0.000, -0.000 

[DEBUG] [1709075595.795496903]: /septentrio_gnss: A message received:   AttitudeOffset, 0.000, 0.000

[DEBUG] [1709075595.795553166]: /septentrio_gnss: handleCd: IP10>
[DEBUG] [1709075595.795676391]: /septentrio_gnss: AsyncManager sent the following 12 bytes to the Rx: sou, loose 
[DEBUG] [1709075595.857391424]: /septentrio_gnss: The Rx's response contains 17 bytes and reads:
 $R: sou, loose 

[DEBUG] [1709075595.857453209]: /septentrio_gnss: A message received:   GalOSNMAUsage, loose, ""

[DEBUG] [1709075595.857477795]: /septentrio_gnss: handleCd: IP10>
[DEBUG] [1709075595.857563631]: /septentrio_gnss: AsyncManager sent the following 97 bytes to the Rx: sso, Stream1, IP10, +ReceiverStatus +QualityInd +RFStatus +GALAuthStatus +ReceiverSetup, msec500
[DEBUG] [1709075595.860315670]: /septentrio_gnss: receiver setup firmware: 4.14.4
[DEBUG] [1709075595.917653463]: /septentrio_gnss: The Rx's response contains 102 bytes and reads:
 $R: sso, Stream1, IP10, +ReceiverStatus +QualityInd +RFStatus +GALAuthStatus +ReceiverSetup, msec500

[DEBUG] [1709075595.917785424]: /septentrio_gnss: A message received:   SBFOutput, Stream1, IP10, GALAuthStatus+ReceiverStatus+ReceiverSetup+QualityInd+RFStatus, msec500

[DEBUG] [1709075595.917927314]: /septentrio_gnss: handleCd: IP10>
[DEBUG] [1709075595.918011800]: /septentrio_gnss: AsyncManager sent the following 13 bytes to the Rx: sop, "", "" 
[DEBUG] [1709075595.920298971]: /septentrio_gnss: receiver setup firmware: 4.14.4
[DEBUG] [1709075595.977278544]: /septentrio_gnss: The Rx's response contains 18 bytes and reads:
 $R: sop, "", "" 

[DEBUG] [1709075595.977370351]: /septentrio_gnss: A message received:   ObserverParameters, "", ""

[DEBUG] [1709075595.977432868]: /septentrio_gnss: handleCd: IP10>
[DEBUG] [1709075595.977607395]: /septentrio_gnss: AsyncManager sent the following 9 bytes to the Rx: snti, GP
[DEBUG] [1709075596.007533785]: Trying to publish message of type [diagnostic_msgs/DiagnosticArray/60810da900de1dd6ddd437c3503511da] on a publisher with type [diagnostic_msgs/DiagnosticArray/60810da900de1dd6ddd437c3503511da]
[DEBUG] [1709075596.008823839]: Trying to publish message of type [septentrio_gnss_driver/RFStatus/6223e703baf4d3da19e391be72a94d34] on a publisher with type [septentrio_gnss_driver/RFStatus/6223e703baf4d3da19e391be72a94d34]
[DEBUG] [1709075596.010103838]: Trying to publish message of type [septentrio_gnss_driver/AIMPlusStatus/85cf4fc2fc2598dca0b9bb856cb2dcdd] on a publisher with type [septentrio_gnss_driver/AIMPlusStatus/85cf4fc2fc2598dca0b9bb856cb2dcdd]
[DEBUG] [1709075596.035534132]: /septentrio_gnss: The Rx's response contains 14 bytes and reads:
 $R: snti, GP

[DEBUG] [1709075596.035569626]: /septentrio_gnss: A message received:   NMEATalkerID, GP

[DEBUG] [1709075596.035582183]: /septentrio_gnss: handleCd: IP10>
[DEBUG] [1709075596.035636264]: /septentrio_gnss: AsyncManager sent the following 40 bytes to the Rx: sno, Stream2, IP10, +GGA +RMC, OnChange
[DEBUG] [1709075596.108394140]: Trying to publish message of type [nmea_msgs/Gprmc/02533bac67f17457b2e3538525ba1aae] on a publisher with type [nmea_msgs/Gprmc/02533bac67f17457b2e3538525ba1aae]
[DEBUG] [1709075596.109505008]: Trying to publish message of type [nmea_msgs/Gpgga/8f51cb504898f39d8ad9f698f0b6f9cd] on a publisher with type [nmea_msgs/Gpgga/8f51cb504898f39d8ad9f698f0b6f9cd]
[DEBUG] [1709075596.126800061]: /septentrio_gnss: The Rx's response contains 45 bytes and reads:
 $R: sno, Stream2, IP10, +GGA +RMC, OnChange

[DEBUG] [1709075596.126878306]: /septentrio_gnss: A message received:   NMEAOutput, Stream2, IP10, GGA+RMC, OnChange

[DEBUG] [1709075596.126915276]: /septentrio_gnss: handleCd: IP10>
[DEBUG] [1709075596.127053735]: /septentrio_gnss: AsyncManager sent the following 174 bytes to the Rx: sso, Stream3, IP10, +ReceiverTime +PVTCartesian +PVTGeodetic +PosCovCartesian +PosCovGeodetic +VelCovGeodetic +AttEuler +AttCovEuler +MeasEpoch +ChannelStatus +DOP, OnChange
[DEBUG] [1709075596.188288429]: /septentrio_gnss: The Rx's response contains 179 bytes and reads:
 $R: sso, Stream3, IP10, +ReceiverTime +PVTCartesian +PVTGeodetic +PosCovCartesian +PosCovGeodetic +VelCovGeodetic +AttEuler +AttCovEuler +MeasEpoch +ChannelStatus +DOP, OnChange

[DEBUG] [1709075596.188505461]: /septentrio_gnss: A message received:   SBFOutput, Stream3, IP10, MeasEpoch+AttEuler+PVTCartesian+PosCovCartesian+PVTGeodetic+PosCovGeodetic+VelCovGeodetic+DOP+ReceiverTime+ChannelStatus+AttCovEuler, OnChange

[DEBUG] [1709075596.188548986]: /septentrio_gnss: handleCd: IP10>
[DEBUG] [1709075596.188709547]: /septentrio_gnss: Leaving configureRx() method
[ INFO] [1709075596.188769319]: /septentrio_gnss: Setup complete.
[DEBUG] [1709075596.188799802]: /septentrio_gnss: Successully connected. Leaving connect() method
[DEBUG] [1709075596.188869958]: /septentrio_gnss: Leaving ROSaicNode() constructor..

Some msgs are dropped

Hello,
I bought asterxsbi3 pro and to read the data I use ros2 node. I saw that the topic twits_ins has a rate 100 Hz but checking some plot I saw some frames are dropped As you can see in the picture attached, some msgs have dissapeared.

twist_ins/linear/x

Any advise?

Wrong heading angle of Mosaic-H module

Hi,
We used the septentrio_gnss_driver with mosaic-H module and read the heading angle of ROS topic /atteuler. We found the heading/attitude angle of /atteuler was (1) not consistent with the heading angle from the web gui. (2) wrong at North, the heading angle of main antenna pointing to the aux antenna was 270. Should it be 0 or 360?

For example, taking the vector of the main antenna pointing to the aux antenna,
North: 0 degree
East: 90 degree
South: 180 degree
West: 270 degree

However, the output heading angle of /atteuler was confusing.

Thanks!

Issue with Serial

Greetings,

I've tried the driver with Raspberry Pi Serial and it's not working well.
I believe it's a problem with receiving/parsing SBF bytes. Sometimes it parses small byte chunks (like 1 byte).
The problem doesn't happen with USB serial. Maybe because it's virtual.

Thanks a lot

Dependecies failed to install

"Additional ROS packages have to be installed for the NMEA and GPSFix messages.
sudo apt install ros-$ROS_DISTRO-nmea-msgs ros-$ROS_DISTRO-gps-msgs"

This does not work and my DISTRO is Galactic and using ros2.

Error I gotten is
"E: Unable to locate package ros-galactic-nmea-msgs
E: Unable to locate package ros-galactic-gps-msgs"

I followed all the steps and cloned it already. What should I do?

Using the driver to publish from a recorded SBF log file

Hi,
I have a recorded SBF log file and want to use this ros driver to publish from it.
Is there any way to modify the code to do so?

No messages received via usb

I have a problem connecting to the Mosaic-X5 Board via USB connection. The setup is complete but the data streams never start:
Driver output, where the receiver hangs: `[ INFO] [1695217621.574985984]: /septentrio_gnss: Setup complete.
[DEBUG] [1695217621.575028507]: /septentrio_gnss: Successully connected. Leaving connect() method
[DEBUG] [1695217621.575107190]: /septentrio_gnss: Leaving ROSaicNode() constructor..
[DEBUG] [1695217621.575844638]: /septentrio_gnss: A message received: SBFOutput, Stream3, USB2, MeasEpoch+AttEuler+PVTCartesian+PVTGeodetic+PosCovGeodetic+VelCovGeodetic+DOP+ReceiverTime+ChannelStatus+AttCovEuler, msec50

[DEBUG] [1695217621.575914777]: /septentrio_gnss: handleCd: USB2>`

Asterx-SBI 3 pro INS: discrepancy between /navsatfix.status.status and /gpsfix.status.status with NMEA msgs

I have mobile robot setup with INS receiver + dual antenna setup and an active subscription with a local RTK provider over internet.

I have been observing a discrepancy between reported status/ gps quality from ros msgs /gpsfix.status.status /navsatfix.status.status and what the Septentrio web ui and the actual NMEA msg logged on the receiver itself.

On my tests I see msgs published with status 0 most of the time and jumps to 2 (augmented fix) a couple of times over multiple experiments while the frontend shows Fixed pose and GGA NMEA shows quality indicator 4 (RTK Fixed) and GNS mode indicator RRRN (Real-Time Kinematic. Satellite system used in RTK mode with fixed integers):

<google-sheets-html-origin><style type="text/css"><!--td {border: 1px solid #cccccc;}br {mso-data-placement:same-cell;}--></style>
$INGNS | 90200 | 5051.890218 | N | 440.1211738 | E | RRRN | 13 | 0.9
$INGGA | 90200.5 | 5051.890219 | N | 440.1211744 | E | 4 | 15 | 0.8
$INGNS | 90200.5 | 5051.890219 | N | 440.1211744 | E | RRRN | 15 | 0.8
$INGGA | 90201 | 5051.890217 | N | 440.121174 | E | 4 | 14 | 0.8
$INGNS | 90201 | 5051.890217 | N | 440.121174 | E | RRRN | 14 | 0.8
$INGGA | 90201.5 | 5051.890216 | N | 440.121175 | E | 4 | 15 | 0.8
$INGNS | 90201.5 | 5051.890216 | N | 440.121175 | E | RRRN | 15 | 0.8
$INGGA | 90202 | 5051.890216 | N | 440.1211736 | E | 4 | 15 | 0.8
$INGNS | 90202 | 5051.890216 | N | 440.1211736 | E | RRRN | 15 | 0.8
$INGGA | 90202.5 | 5051.890216 | N | 440.1211737 | E | 4 | 15 | 0.8
$INGNS | 90202.5 | 5051.890216 | N | 440.1211737 | E | RRRN | 15 | 0.8
$INGGA | 90203 | 5051.890216 | N | 440.1211733 | E | 4 | 15 | 0.8
$INGNS | 90203 | 5051.890216 | N | 440.1211733 | E | RRRN | 15 | 0.8
$INGGA | 90203.5 | 5051.890215 | N | 440.1211735 | E | 4 | 15 | 0.8
$INGNS | 90203.5 | 5051.890215 | N | 440.1211735 | E | RRRN | 15 | 0.8
$INGGA | 90204 | 5051.890218 | N | 440.1211742 | E | 4 | 15 | 0.8
$INGNS | 90204 | 5051.890218 | N | 440.1211742 | E | RRRN | 15 | 0.8
$INGGA | 90204.5 | 5051.890218 | N | 440.1211734 | E | 4 | 15 | 0.8
$INGNS | 90204.5 | 5051.890218 | N | 440.1211734 | E | RRRN | 15 | 0.8
$INGGA | 90205 | 5051.890218 | N | 440.1211725 | E | 4 | 15 | 0.8
$INGNS | 90205 | 5051.890218 | N | 440.1211725 | E | RRRN | 15 | 0.8
$INGGA | 90205.5 | 5051.890218 | N | 440.1211722 | E | 4 | 15 | 0.8
$INGNS | 90205.5 | 5051.890218 | N | 440.1211722 | E | RRRN | 15 | 0.8
$INGGA | 90206 | 5051.890218 | N | 440.1211727 | E | 4 | 15 | 0.8
$INGNS | 90206 | 5051.890218 | N | 440.1211727 | E | RRRN | 15 | 0.8
$INGGA | 90206.5 | 5051.890217 | N | 440.1211729 | E | 4 | 15 | 0.8
$INGNS | 90206.5 | 5051.890217 | N | 440.1211729 | E | RRRN | 15 | 0.8
$INGGA | 90207 | 5051.890217 | N | 440.1211733 | E | 4 | 15 | 0.8
$INGNS | 90207 | 5051.890217 | N | 440.1211733 | E | RRRN | 15 | 0.8
$INGGA | 90207.5 | 5051.890217 | N | 440.1211732 | E | 4 | 15 | 0.8
$INGNS | 90207.5 | 5051.890217 | N | 440.1211732 | E | RRRN | 15 | 0.8
$INGGA | 90208 | 5051.890217 | N | 440.1211726 | E | 4 | 15 | 0.8
$INGNS | 90208 | 5051.890217 | N | 440.1211726 | E | RRRN | 15 | 0.8
$INGGA | 90208.5 | 5051.890217 | N | 440.1211724 | E | 4 | 15 | 0.8
$INGNS | 90208.5 | 5051.890217 | N | 440.1211724 | E | RRRN | 15 | 0.8
$INGGA | 90209 | 5051.890216 | N | 440.1211721 | E | 4 | 15 | 0.8
$INGNS | 90209 | 5051.890216 | N | 440.1211721 | E | RRRN | 15 | 0.8
$INGGA | 90213.5 | 5051.890218 | N | 440.1211728 | E | 4 | 15 | 0.8
$INGNS | 90213.5 | 5051.890218 | N | 440.1211728 | E | RRRN | 15 | 0.8
$INGGA | 90214 | 5051.890218 | N | 440.1211725 | E | 4 | 15 | 0.8
$INGNS | 90214 | 5051.890218 | N | 440.1211725 | E | RRRN | 15 | 0.8
$INGGA | 90214.5 | 5051.890217 | N | 440.1211722 | E | 4 | 15 | 0.8
$INGNS | 90214.5 | 5051.890217 | N | 440.1211722 | E | RRRN | 15 | 0.8
$INGGA | 90215 | 5051.890218 | N | 440.1211725 | E | 4 | 15 | 0.8
$INGNS | 90215 | 5051.890218 | N | 440.1211725 | E | RRRN | 15 | 0.8
$INGGA | 90215.5 | 5051.890218 | N | 440.1211719 | E | 4 | 15 | 0.8
$INGNS | 90215.5 | 5051.890218 | N | 440.1211719 | E | RRRN | 15 | 0.8
$INGGA | 90216 | 5051.890218 | N | 440.1211711 | E | 4 | 13 | 0.8
$INGNS | 90216 | 5051.890218 | N | 440.1211711 | E | RRRN | 13 | 0.8
$INGGA | 90216.5 | 5051.890218 | N | 440.1211716 | E | 4 | 15 | 0.8
$INGNS | 90216.5 | 5051.890218 | N | 440.1211716 | E | RRRN | 15 | 0.8
$INGGA | 90217 | 5051.890218 | N | 440.121173 | E | 4 | 15 | 0.8
$INGNS | 90217 | 5051.890218 | N | 440.121173 | E | RRRN | 15 | 0.8
$INGGA | 90217.5 | 5051.890218 | N | 440.1211718 | E | 4 | 14 | 0.8
$INGNS | 90217.5 | 5051.890218 | N | 440.1211718 | E | RRRN | 14 | 0.8
$INGGA | 90218 | 5051.89022 | N | 440.1211741 | E | 4 | 15 | 0.8
$INGNS | 90218 | 5051.89022 | N | 440.1211741 | E | RRRN | 15 | 0.8
$INGGA | 90218.5 | 5051.890219 | N | 440.1211735 | E | 4 | 15 | 0.8
$INGNS | 90218.5 | 5051.890219 | N | 440.1211735 | E | RRRN | 15 | 0.8
$INGGA | 90219 | 5051.890219 | N | 440.1211766 | E | 4 | 15 | 0.8
$INGNS | 90219 | 5051.890219 | N | 440.1211766 | E | RRRN | 15 | 0.8
$INGGA | 90219.5 | 5051.890218 | N | 440.121179 | E | 4 | 15 | 0.8
$INGNS | 90219.5 | 5051.890218 | N | 440.121179 | E | RRRN | 15 | 0.8
$INGGA | 90220 | 5051.890216 | N | 440.1211844 | E | 4 | 15 | 0.8
$INGNS | 90220 | 5051.890216 | N | 440.1211844 | E | RRRN | 15 | 0.8
$INGGA | 90220.5 | 5051.890215 | N | 440.1211839 | E | 4 | 15 | 0.8
$INGNS | 90220.5 | 5051.890215 | N | 440.1211839 | E | RRRN | 15 | 0.8
$INGGA | 90221 | 5051.890215 | N | 440.121183 | E | 4 | 15 | 0.8
$INGNS | 90221 | 5051.890215 | N | 440.121183 | E | RRRN | 15 | 0.8
$INGGA | 90221.5 | 5051.890215 | N | 440.1211825 | E | 4 | 15 | 0.8
$INGNS | 90221.5 | 5051.890215 | N | 440.1211825 | E | RRRN | 15 | 0.8
$INGGA | 90222 | 5051.890214 | N | 440.1211828 | E | 4 | 15 | 0.8
$INGNS | 90222 | 5051.890214 | N | 440.1211828 | E | RRRN | 15 | 0.8
$INGGA | 90222.5 | 5051.890216 | N | 440.1211797 | E | 4 | 14 | 0.8
$INGNS | 90222.5 | 5051.890216 | N | 440.1211797 | E | RRRN | 14 | 0.8
$INGGA | 90223 | 5051.890214 | N | 440.1211814 | E | 4 | 8 | 1.4
$INGNS | 90223 | 5051.890214 | N | 440.1211814 | E | RRNN | 8 | 1.4
$INGGA | 90223.5 | 5051.890217 | N | 440.1211799 | E | 4 | 14 | 0.8
$INGNS | 90223.5 | 5051.890217 | N | 440.1211799 | E | RRRN | 14 | 0.8
$INGGA | 90224 | 5051.890218 | N | 440.1211797 | E | 4 | 15 | 0.8
$INGNS | 90224 | 5051.890218 | N | 440.1211797 | E | RRRN | 15 | 0.8
$INGGA | 90224.5 | 5051.890218 | N | 440.1211804 | E | 4 | 15 | 0.8
$INGNS | 90224.5 | 5051.890218 | N | 440.1211804 | E | RRRN | 15 | 0.8
$INGGA | 90225 | 5051.890219 | N | 440.1211801 | E | 4 | 15 | 0.8
$INGNS | 90225 | 5051.890219 | N | 440.1211801 | E | RRRN | 15 | 0.8
$INGGA | 90225.5 | 5051.890219 | N | 440.12118 | E | 4 | 14 | 0.8
$INGNS | 90225.5 | 5051.890219 | N | 440.12118 | E | RRRN | 14 | 0.8
$INGGA | 90226 | 5051.890218 | N | 440.1211788 | E | 4 | 15 | 0.8
$INGNS | 90226 | 5051.890218 | N | 440.1211788 | E | RRRN | 15 | 0.8
$INGGA | 90226.5 | 5051.890217 | N | 440.1211771 | E | 4 | 15 | 0.8
$INGNS | 90226.5 | 5051.890217 | N | 440.1211771 | E | RRRN | 15 | 0.8
$INGGA | 90227 | 5051.890216 | N | 440.1211757 | E | 4 | 15 | 0.8
$INGNS | 90227 | 5051.890216 | N | 440.1211757 | E | RRRN | 15 | 0.8
$INGGA | 90227.5 | 5051.890215 | N | 440.1211738 | E | 4 | 15 | 0.8
$INGNS | 90227.5 | 5051.890215 | N | 440.1211738 | E | RRRN | 15 | 0.8
$INGGA | 90228 | 5051.890218 | N | 440.1211727 | E | 4 | 15 | 0.8
$INGNS | 90228 | 5051.890218 | N | 440.1211727 | E | RRRN | 15 | 0.8
$INGGA | 90228.5 | 5051.890218 | N | 440.1211732 | E | 4 | 15 | 0.8
$INGNS | 90228.5 | 5051.890218 | N | 440.1211732 | E | RRRN | 15 | 0.8
$INGGA | 90229 | 5051.890219 | N | 440.121173 | E | 4 | 15 | 0.8
$INGNS | 90229 | 5051.890219 | N | 440.121173 | E | RRRN | 15 | 0.8
$INGGA | 90229.5 | 5051.890219 | N | 440.1211772 | E | 4 | 15 | 0.8
$INGNS | 90229.5 | 5051.890219 | N | 440.1211772 | E | RRRN | 15 | 0.8
$INGGA | 90230 | 5051.890218 | N | 440.1211756 | E | 4 | 12 | 1.2
$INGNS | 90230 | 5051.890218 | N | 440.1211756 | E | RRRN | 12 | 1.2
$INGGA | 90230.5 | 5051.890218 | N | 440.1211756 | E | 4 | 15 | 0.8
$INGNS | 90230.5 | 5051.890218 | N | 440.1211756 | E | RRRN | 15 | 0.8
$INGGA | 90231 | 5051.890219 | N | 440.1211788 | E | 4 | 15 | 0.8
$INGNS | 90231 | 5051.890219 | N | 440.1211788 | E | RRRN | 15 | 0.8
$INGGA | 90231.5 | 5051.890216 | N | 440.1211822 | E | 4 | 15 | 0.8
$INGNS | 90231.5 | 5051.890216 | N | 440.1211822 | E | RRRN | 15 | 0.8
$INGGA | 90232 | 5051.890216 | N | 440.1211846 | E | 4 | 15 | 0.8
$INGNS | 90232 | 5051.890216 | N | 440.1211846 | E | RRRN | 15 | 0.8
$INGGA | 90232.5 | 5051.890214 | N | 440.1211822 | E | 4 | 16 | 0.7
$INGNS | 90232.5 | 5051.890214 | N | 440.1211822 | E | RRRN | 16 | 0.7
$INGGA | 90233 | 5051.890217 | N | 440.1211788 | E | 4 | 15 | 0.8
$INGNS | 90233 | 5051.890217 | N | 440.1211788 | E | RRRN | 15 | 0.8
$INGGA | 90233.5 | 5051.890216 | N | 440.1211775 | E | 4 | 16 | 0.7
$INGNS | 90233.5 | 5051.890216 | N | 440.1211775 | E | RRRN | 16 | 0.7
$INGGA | 90234 | 5051.890214 | N | 440.1211795 | E | 4 | 16 | 0.7
$INGNS | 90234 | 5051.890214 | N | 440.1211795 | E | RRRN | 16 | 0.7
$INGGA | 90234.5 | 5051.890217 | N | 440.1211786 | E | 4 | 16 | 0.7
$INGNS | 90234.5 | 5051.890217 | N | 440.1211786 | E | RRRN | 16 | 0.7
$INGGA | 90235 | 5051.890216 | N | 440.1211739 | E | 4 | 16 | 0.7
$INGNS | 90235 | 5051.890216 | N | 440.1211739 | E | RRRN | 16 | 0.7
$INGGA | 90235.5 | 5051.890214 | N | 440.1211735 | E | 4 | 16 | 0.7
$INGNS | 90235.5 | 5051.890214 | N | 440.1211735 | E | RRRN | 16 | 0.7
$INGGA | 90236 | 5051.890215 | N | 440.1211722 | E | 4 | 16 | 0.7
$INGNS | 90236 | 5051.890215 | N | 440.1211722 | E | RRRN | 16 | 0.7
$INGGA | 90236.5 | 5051.890216 | N | 440.1211732 | E | 4 | 16 | 0.7
$INGNS | 90236.5 | 5051.890216 | N | 440.1211732 | E | RRRN | 16 | 0.7
$INGGA | 90237 | 5051.890215 | N | 440.1211735 | E | 4 | 9 | 1.3
$INGNS | 90237 | 5051.890215 | N | 440.1211735 | E | RRNN | 9 | 1.3
$INGGA | 90237.5 | 5051.890213 | N | 440.1211757 | E | 4 | 14 | 0.8
$INGNS | 90237.5 | 5051.890213 | N | 440.1211757 | E | RRRN | 14 | 0.8
$INGGA | 90238 | 5051.890202 | N | 440.1211796 | E | 4 | 14 | 0.8
$INGNS | 90238 | 5051.890202 | N | 440.1211796 | E | RRRN | 14 | 0.8
$INGGA | 90238.5 | 5051.890164 | N | 440.1211934 | E | 4 | 14 | 0.8
$INGNS | 90238.5 | 5051.890164 | N | 440.1211934 | E | RRRN | 14 | 0.8
$INGGA | 90239 | 5051.890106 | N | 440.1212414 | E | 4 | 14 | 0.8
$INGNS | 90239 | 5051.890106 | N | 440.1212414 | E | RRRN | 14 | 0.8
$INGGA | 90239.5 | 5051.890023 | N | 440.1212915 | E | 4 | 13 | 0.9
$INGNS | 90239.5 | 5051.890023 | N | 440.1212915 | E | RRRN | 13 | 0.9
$INGGA | 90240 | 5051.889932 | N | 440.1213363 | E | 4 | 14 | 0.8
$INGNS | 90240 | 5051.889932 | N | 440.1213363 | E | RRRN | 14 | 0.8
$INGGA | 90240.5 | 5051.889838 | N | 440.1213982 | E | 4 | 14 | 0.8
$INGNS | 90240.5 | 5051.889838 | N | 440.1213982 | E | RRRN | 14 | 0.8
$INGGA | 90241 | 5051.889738 | N | 440.1214666 | E | 4 | 14 | 0.8
$INGNS | 90241 | 5051.889738 | N | 440.1214666 | E | RRRN | 14 | 0.8
$INGGA | 90241.5 | 5051.889626 | N | 440.1215295 | E | 4 | 14 | 0.8
$INGNS | 90241.5 | 5051.889626 | N | 440.1215295 | E | RRRN | 14 | 0.8
$INGGA | 90242 | 5051.889502 | N | 440.1215845 | E | 4 | 14 | 0.8
$INGNS | 90242 | 5051.889502 | N | 440.1215845 | E | RRRN | 14 | 0.8
$INGGA | 90242.5 | 5051.889382 | N | 440.121677 | E | 4 | 14 | 0.8
$INGNS | 90242.5 | 5051.889382 | N | 440.121677 | E | RRRN | 14 | 0.8
$INGGA | 90243 | 5051.889261 | N | 440.1217537 | E | 4 | 13 | 0.9
$INGNS | 90243 | 5051.889261 | N | 440.1217537 | E | RRRN | 13 | 0.9
$INGGA | 90243.5 | 5051.88915 | N | 440.1217964 | E | 4 | 14 | 0.8
$INGNS | 90243.5 | 5051.88915 | N | 440.1217964 | E | RRRN | 14 | 0.8
$INGGA | 90244 | 5051.889041 | N | 440.121846 | E | 4 | 13 | 0.9
$INGNS | 90244 | 5051.889041 | N | 440.121846 | E | RRRN | 13 | 0.9
$INGGA | 90244.5 | 5051.888933 | N | 440.1218869 | E | 4 | 15 | 0.8
$INGNS | 90244.5 | 5051.888933 | N | 440.1218869 | E | RRRN | 15 | 0.8
$INGGA | 90245 | 5051.888815 | N | 440.1219342 | E | 4 | 15 | 0.8
$INGNS | 90245 | 5051.888815 | N | 440.1219342 | E | RRRN | 15 | 0.8
$INGGA | 90245.5 | 5051.888701 | N | 440.1220068 | E | 4 | 15 | 0.8
$INGNS | 90245.5 | 5051.888701 | N | 440.1220068 | E | RRRN | 15 | 0.8
$INGGA | 90246 | 5051.888582 | N | 440.1220597 | E | 4 | 15 | 0.8
$INGNS | 90246 | 5051.888582 | N | 440.1220597 | E | RRRN | 15 | 0.8
$INGGA | 90246.5 | 5051.88847 | N | 440.1221329 | E | 4 | 15 | 0.8
$INGNS | 90246.5 | 5051.88847 | N | 440.1221329 | E | RRRN | 15 | 0.8
$INGGA | 90247 | 5051.88835 | N | 440.1221936 | E | 4 | 15 | 0.8
$INGNS | 90247 | 5051.88835 | N | 440.1221936 | E | RRRN | 15 | 0.8
$INGGA | 90247.5 | 5051.888231 | N | 440.1222446 | E | 4 | 14 | 0.9
$INGNS | 90247.5 | 5051.888231 | N | 440.1222446 | E | RRRN | 14 | 0.9
$INGGA | 90248 | 5051.888118 | N | 440.1223207 | E | 4 | 14 | 0.9
$INGNS | 90248 | 5051.888118 | N | 440.1223207 | E | RRRN | 14 | 0.9
$INGGA | 90248.5 | 5051.887989 | N | 440.12238 | E | 4 | 14 | 0.9
$INGNS | 90248.5 | 5051.887989 | N | 440.12238 | E | RRRN | 14 | 0.9
$INGGA | 90249 | 5051.887858 | N | 440.122443 | E | 4 | 14 | 0.9
$INGNS | 90249 | 5051.887858 | N | 440.122443 | E | RRRN | 14 | 0.9
$INGGA | 90249.5 | 5051.887732 | N | 440.1225145 | E | 4 | 14 | 0.9
$INGNS | 90249.5 | 5051.887732 | N | 440.1225145 | E | RRRN | 14 | 0.9
$INGGA | 90250 | 5051.887602 | N | 440.1225785 | E | 4 | 14 | 0.9
$INGNS | 90250 | 5051.887602 | N | 440.1225785 | E | RRRN | 14 | 0.9
$INGGA | 90250.5 | 5051.887474 | N | 440.1226541 | E | 4 | 14 | 0.9
$INGNS | 90250.5 | 5051.887474 | N | 440.1226541 | E | RRRN | 14 | 0.9
$INGGA | 90251 | 5051.887353 | N | 440.1227167 | E | 4 | 14 | 0.9
$INGNS | 90251 | 5051.887353 | N | 440.1227167 | E | RRRN | 14 | 0.9
$INGGA | 90251.5 | 5051.887221 | N | 440.1227736 | E | 4 | 14 | 0.9
$INGNS | 90251.5 | 5051.887221 | N | 440.1227736 | E | RRRN | 14 | 0.9
$INGGA | 90252 | 5051.887095 | N | 440.1228544 | E | 4 | 13 | 0.9
$INGNS | 90252 | 5051.887095 | N | 440.1228544 | E | RRRN | 13 | 0.9
$INGGA | 90252.5 | 5051.886964 | N | 440.1229222 | E | 4 | 14 | 0.9
$INGNS | 90252.5 | 5051.886964 | N | 440.1229222 | E | RRRN | 14 | 0.9
$INGGA | 90253 | 5051.886847 | N | 440.1229803 | E | 4 | 14 | 0.9
$INGNS | 90253 | 5051.886847 | N | 440.1229803 | E | RRRN | 14 | 0.9
$INGGA | 90253.5 | 5051.886728 | N | 440.1230611 | E | 4 | 14 | 0.9
$INGNS | 90253.5 | 5051.886728 | N | 440.1230611 | E | RRRN | 14 | 0.9
$INGGA | 90254 | 5051.88661 | N | 440.123115 | E | 4 | 14 | 0.9
$INGNS | 90254 | 5051.88661 | N | 440.123115 | E | RRRN | 14 | 0.9
$INGGA | 90254.5 | 5051.886503 | N | 440.1231603 | E | 4 | 14 | 0.9
$INGNS | 90254.5 | 5051.886503 | N | 440.1231603 | E | RRRN | 14 | 0.9
$INGGA | 90255 | 5051.886398 | N | 440.1232161 | E | 4 | 14 | 0.9
$INGNS | 90255 | 5051.886398 | N | 440.1232161 | E | RRRN | 14 | 0.9
$INGGA | 90255.5 | 5051.886279 | N | 440.1232847 | E | 4 | 14 | 0.9
$INGNS | 90255.5 | 5051.886279 | N | 440.1232847 | E | RRRN | 14 | 0.9
$INGGA | 90256 | 5051.886166 | N | 440.1233499 | E | 4 | 14 | 0.9
$INGNS | 90256 | 5051.886166 | N | 440.1233499 | E | RRRN | 14 | 0.9
$INGGA | 90256.5 | 5051.886053 | N | 440.1234002 | E | 4 | 14 | 0.9
$INGNS | 90256.5 | 5051.886053 | N | 440.1234002 | E | RRRN | 14 | 0.9
$INGGA | 90257 | 5051.885955 | N | 440.1234582 | E | 4 | 13 | 1
$INGNS | 90257 | 5051.885955 | N | 440.1234582 | E | RRRN | 13 | 1
$INGGA | 90257.5 | 5051.885933 | N | 440.1234716 | E | 4 | 13 | 1
$INGNS | 90257.5 | 5051.885933 | N | 440.1234716 | E | RRRN | 13 | 1
$INGGA | 90258 | 5051.886011 | N | 440.1234337 | E | 4 | 13 | 1
$INGNS | 90258 | 5051.886011 | N | 440.1234337 | E | RRRN | 13 | 1
$INGGA | 90258.5 | 5051.886075 | N | 440.1233718 | E | 4 | 13 | 1
$INGNS | 90258.5 | 5051.886075 | N | 440.1233718 | E | RRRN | 13 | 1
$INGGA | 90259 | 5051.886112 | N | 440.1233372 | E | 4 | 11 | 1.3
$INGNS | 90259 | 5051.886112 | N | 440.1233372 | E | RRRN | 11 | 1.3
$INGGA | 90259.5 | 5051.886124 | N | 440.1233351 | E | 4 | 13 | 1
$INGNS | 90259.5 | 5051.886124 | N | 440.1233351 | E | RRRN | 13 | 1
$INGGA | 90300 | 5051.886134 | N | 440.123342 | E | 4 | 13 | 1
$INGNS | 90300 | 5051.886134 | N | 440.123342 | E | RRRN | 13 | 1
$INGGA | 90300.5 | 5051.886132 | N | 440.1233377 | E | 4 | 12 | 1
$INGNS | 90300.5 | 5051.886132 | N | 440.1233377 | E | RRRN | 12 | 1
$INGGA | 90301 | 5051.88613 | N | 440.123335 | E | 4 | 13 | 1
$INGNS | 90301 | 5051.88613 | N | 440.123335 | E | RRRN | 13 | 1
$INGGA | 90301.5 | 5051.886131 | N | 440.1233357 | E | 4 | 13 | 1
$INGNS | 90301.5 | 5051.886131 | N | 440.1233357 | E | RRRN | 13 | 1
$INGGA | 90302 | 5051.886129 | N | 440.1233375 | E | 4 | 13 | 1
$INGNS | 90302 | 5051.886129 | N | 440.1233375 | E | RRRN | 13 | 1
$INGGA | 90302.5 | 5051.886123 | N | 440.1233398 | E | 4 | 13 | 1
$INGNS | 90302.5 | 5051.886123 | N | 440.1233398 | E | RRRN | 13 | 1
$INGGA | 90303 | 5051.886122 | N | 440.1233132 | E | 4 | 13 | 1
$INGNS | 90303 | 5051.886122 | N | 440.1233132 | E | RRRN | 13 | 1
$INGGA | 90303.5 | 5051.886119 | N | 440.1232875 | E | 4 | 13 | 1
$INGNS | 90303.5 | 5051.886119 | N | 440.1232875 | E | RRRN | 13 | 1
$INGGA | 90304 | 5051.886122 | N | 440.1232573 | E | 4 | 14 | 0.9
$INGNS | 90304 | 5051.886122 | N | 440.1232573 | E | RRRN | 14 | 0.9
$INGGA | 90304.5 | 5051.886118 | N | 440.1232131 | E | 4 | 14 | 0.9
$INGNS | 90304.5 | 5051.886118 | N | 440.1232131 | E | RRRN | 14 | 0.9
$INGGA | 90305 | 5051.886121 | N | 440.1232448 | E | 4 | 13 | 1
$INGNS | 90305 | 5051.886121 | N | 440.1232448 | E | RRRN | 13 | 1
$INGGA | 90305.5 | 5051.886131 | N | 440.1232859 | E | 4 | 13 | 1
$INGNS | 90305.5 | 5051.886131 | N | 440.1232859 | E | RRRN | 13 | 1
$INGGA | 90306 | 5051.886118 | N | 440.1232314 | E | 4 | 14 | 0.9
$INGNS | 90306 | 5051.886118 | N | 440.1232314 | E | RRRN | 14 | 0.9
$INGGA | 90306.5 | 5051.886092 | N | 440.1231546 | E | 4 | 14 | 0.9
$INGNS | 90306.5 | 5051.886092 | N | 440.1231546 | E | RRRN | 14 | 0.9
$INGGA | 90307 | 5051.886037 | N | 440.1230673 | E | 4 | 13 | 1
$INGNS | 90307 | 5051.886037 | N | 440.1230673 | E | RRRN | 13 | 1
$INGGA | 90307.5 | 5051.885975 | N | 440.1230052 | E | 4 | 13 | 0.9
$INGNS | 90307.5 | 5051.885975 | N | 440.1230052 | E | RRRN | 13 | 0.9
$INGGA | 90308 | 5051.885918 | N | 440.1229774 | E | 4 | 12 | 1
$INGNS | 90308 | 5051.885918 | N | 440.1229774 | E | RRRN | 12 | 1
$INGGA | 90308.5 | 5051.885875 | N | 440.1229424 | E | 4 | 11 | 1.3
$INGNS | 90308.5 | 5051.885875 | N | 440.1229424 | E | RRRN | 11 | 1.3
$INGGA | 90309 | 5051.885855 | N | 440.1229571 | E | 4 | 12 | 1.2
$INGNS | 90309 | 5051.885855 | N | 440.1229571 | E | RRRN | 12 | 1.2
$INGGA | 90309.5 | 5051.885858 | N | 440.1229703 | E | 4 | 11 | 1.3
$INGNS | 90309.5 | 5051.885858 | N | 440.1229703 | E | RRRN | 11 | 1.3
$INGGA | 90310 | 5051.88589 | N | 440.1229732 | E | 4 | 12 | 0.9
$INGNS | 90310 | 5051.88589 | N | 440.1229732 | E | RRRN | 12 | 0.9
$INGGA | 90310.5 | 5051.885941 | N | 440.1229688 | E | 4 | 13 | 0.8
$INGNS | 90310.5 | 5051.885941 | N | 440.1229688 | E | RRRN | 13 | 0.8
$INGGA | 90311 | 5051.885957 | N | 440.123002 | E | 4 | 14 | 0.8
$INGNS | 90311 | 5051.885957 | N | 440.123002 | E | RRRN | 14 | 0.8
$INGGA | 90311.5 | 5051.885973 | N | 440.1230645 | E | 4 | 13 | 0.9
$INGNS | 90311.5 | 5051.885973 | N | 440.1230645 | E | RRRN | 13 | 0.9
$INGGA | 90312 | 5051.885949 | N | 440.1230796 | E | 4 | 13 | 0.9
$INGNS | 90312 | 5051.885949 | N | 440.1230796 | E | RRRN | 13 | 0.9
$INGGA | 90312.5 | 5051.885916 | N | 440.1231382 | E | 4 | 12 | 0.9
$INGNS | 90312.5 | 5051.885916 | N | 440.1231382 | E | RRRN | 12 | 0.9
$INGGA | 90313 | 5051.885925 | N | 440.1232371 | E | 4 | 11 | 1.3
$INGNS | 90313 | 5051.885925 | N | 440.1232371 | E | RRRN | 11 | 1.3
$INGGA | 90313.5 | 5051.885968 | N | 440.1233678 | E | 4 | 13 | 1
$INGNS | 90313.5 | 5051.885968 | N | 440.1233678 | E | RRRN | 13 | 1
$INGGA | 90314 | 5051.886013 | N | 440.1235141 | E | 4 | 13 | 0.9

I gave a quick look at how the messages are generated on the rosdriver and noticed for GNSS receiver the status bit is masked while this is not applied for INS receivers.
How should I interpret the data on the nav rostopics?

topic with heading information

I can't find the published topic used to output the absolute heading when using AsteRx-i3 D Pro+ with dual antenna configuration.

ntrip of rtk_settings does not work for ROS 1 (ROS Noetic) driver on Ubuntu 20.04

Hello,

We are using AsteRx SBi3 Pro+ for a self-driving project. We are using ROS Noetic (ROS 1) on Ubuntu 20.04. We connected the AsteRx SBi3 Pro+ through the USB cable and the computer had Internet access. We have the RTK service from SmartNet.

However, when we did the settings as below, the RTK did not work.

rtk_settings:
keep_open: true
ntrip_1:
id: ""
caster: "98.159.149.72"
caster_port: 9301
username: "uni01317601"
password: "xxxx"
mountpoint: "MSM_iMAX"
version: "v2"
tls: false
fingerprint: ""
rtk_standard: "auto"
send_gga: "auto"

We understand that on Windows we have to share the Internet over USB. However, we are using the Ubuntu linux. We are not sure whether the AsteRx SBi3 Pro+ has Internet access or not when it is connected to the computer through the USB cable.

We want to make the RTK work together with ROS. Could let us know how to configure the AsteRx SBi3 Pro+ device?

Thanks!

Best,
Hang

Communication settings mosaic-H and rover.yaml

I'm trying to integrate a mosaic-H GNSS board into ROS.

I'm currently connected to the Micro-USB port on the board and can ping the board via 192.168.3.1.
I therefore tried setting an IP server with TCP to this adress but the only mode working is UDP.

I set the NMEA Output accordingly to UDP server on port 1.

This is my rover.yaml:

Configuration Settings for the Rover Rx

GNSS/INS Parameters

device: tcp://192.168.3.1:1

serial:
baudrate: 921600
rx_serial_port: /dev/ttyAMC0
hw_flow_control: off

frame_id: gnss

imu_frame_id: imu

poi_frame_id: base_link

vsm_frame_id: vsm

aux1_frame_id: aux1

vehicle_frame_id: base_link

local_frame_id: odom

insert_local_frame: false

get_spatial_config_from_tf: false

lock_utm_zone: true

use_ros_axis_orientation: true

receiver_type: gnss

multi_antenna: true

datum: Default

poi_to_arp:
delta_e: 0.0
delta_n: 0.0
delta_u: 0.0

att_offset:
heading: 0.0
pitch: 0.0

ant_type: "Unknown"
ant_serial_nr: "Unknown"
ant_aux1_type: "Unknown"
ant_aux1_serial_nr: "Unknown"

leap_seconds: 18

polling_period:
pvt: 500
rest: 500

use_gnss_time: true

publish:

For both GNSS and INS Rxs

navsatfix: true
gpsfix: true
gpgga: true
gprmc: true
gpst: true
measepoch: true
pvtcartesian: true
pvtgeodetic: true
basevectorcart: true
basevectorgeod: true
poscovcartesian: true
poscovgeodetic: true
velcovgeodetic: true
atteuler: true
attcoveuler: true
pose: true
twist: true
diagnostics: true

For GNSS Rx only

gpgsa: true
gpgsv: true

For INS Rx only

insnavcart: false
insnavgeod: false
extsensormeas: false
imusetup: false
velsensorsetup: false
exteventinsnavcart: false
exteventinsnavgeod: false
imu: false
localization: false
tf: false

activate_debug_log: false

These are my last lines when is launch the driver:
setting /run_id to 1d03b03a-9b6a-11ed-a616-1d15bd112421
process[rosout-1]: started with pid [25574]
started core service [/rosout]
process[tf_imu-2]: started with pid [25582]
process[tf_gnss-3]: started with pid [25583]
process[tf_vsm-4]: started with pid [25584]
process[tf_aux1-5]: started with pid [25585]
process[septentrio_gnss-6]: started with pid [25587]
[ INFO] [1674511557.834914788]: /septentrio_gnss: Connecting to tcp://192.168.3.1:1...
[ INFO] [1674511557.836492184]: /septentrio_gnss: Connected to 192.168.3.1:1.
[ INFO] [1674511557.911378294]: /septentrio_gnss: The connection descriptor for the TCP connection is IPS5

Then nothing happens and rostopic list just gives me a published /tf and /tf_static topic. What did I do wrong?

Thank you for the help

How do i debug RTK?

I am currently trying to setup RTK with the rover_node.launch.py file. I have changed the rover_node.yaml to look like this:

rtk_settings:
ntrip_1:
id: "NTR1"
caster: "eu.skylark.swiftnav.com"
caster_port: 2101
username: "SECRET_USERNAME"
password: "SECRET_PASSWORD"
mountpoint: "CRS"
version: "v2"
tls: false
fingerprint: ""
rtk_standard: "auto"
send_gga: "auto"
keep_open: true

I saw in this thread: #113, that i can check the mode in /pvtgeodetic, which gives me a 6. I am unsure if this means the RTK is correctly enabled.

When i take it outside i am getting a fix that is at my location, but it is quite jumpy leading me to believe that the RTK isn't being used correctly. Also i get no difference in either logs or the /pvtgeodetic mode when i purposely put my username or password wrong.

These are the logs i get when i run the node:

septentrio-driver | [INFO] [launch]: All log files can be found below /root/.ros/log/2024-08-08-13-21-08-329850-rock-4c-plus-27348
septentrio-driver | [INFO] [launch]: Default logging verbosity is set to INFO
septentrio-driver | [INFO] [septentrio_gnss_driver_node-1]: process started with pid [27392]
septentrio-driver | [INFO] [static_transform_publisher-2]: process started with pid [27394]
septentrio-driver | [INFO] [static_transform_publisher-3]: process started with pid [27396]
septentrio-driver | [INFO] [static_transform_publisher-4]: process started with pid [27398]
septentrio-driver | [INFO] [static_transform_publisher-5]: process started with pid [27401]
septentrio-driver | [static_transform_publisher-2] 1723123268.903047134: [] [WARN] Old-style arguments are deprecated; see --help for new-style arguments
septentrio-driver | [static_transform_publisher-5] 1723123268.999132348: [] [WARN] Old-style arguments are deprecated; see --help for new-style arguments
septentrio-driver | [static_transform_publisher-2] 1723123269.074845289: [static_transform_publisher_tkHrwZdWzvDWTVYx] [INFO] Spinning until stopped - publishing transform
septentrio-driver | [static_transform_publisher-2] translation: ('0.000000', '0.000000', '0.000000')
septentrio-driver | [static_transform_publisher-2] rotation: ('0.000000', '0.000000', '0.000000', '1.000000')
septentrio-driver | [static_transform_publisher-2] from 'base_link' to 'imu'
septentrio-driver | [static_transform_publisher-3] 1723123269.086907128: [] [WARN] Old-style arguments are deprecated; see --help for new-style arguments
septentrio-driver | [static_transform_publisher-5] 1723123269.125299388: [static_transform_publisher_MqCNmNusSl3WFeY9] [INFO] Spinning until stopped - publishing transform
septentrio-driver | [static_transform_publisher-5] translation: ('0.000000', '0.000000', '0.000000')
septentrio-driver | [static_transform_publisher-5] rotation: ('0.000000', '0.000000', '0.000000', '1.000000')
septentrio-driver | [static_transform_publisher-5] from 'imu' to 'aux1'
septentrio-driver | [static_transform_publisher-4] 1723123269.128599337: [] [WARN] Old-style arguments are deprecated; see --help for new-style arguments
septentrio-driver | [static_transform_publisher-3] 1723123269.164739896: [static_transform_publisher_4YlDNmmHIB7F3qaw] [INFO] Spinning until stopped - publishing transform
septentrio-driver | [static_transform_publisher-3] translation: ('0.000000', '0.000000', '0.000000')
septentrio-driver | [static_transform_publisher-3] rotation: ('0.000000', '0.000000', '0.000000', '1.000000')
septentrio-driver | [static_transform_publisher-3] from 'imu' to 'gnss'
septentrio-driver | [septentrio_gnss_driver_node-1] 1723123269.200005791: [septentrio_gnss_driver] [INFO] Connecting to tcp://192.168.3.1:28784...
septentrio-driver | [septentrio_gnss_driver_node-1] 1723123269.202121285: [septentrio_gnss_driver] [INFO] Connected to 192.168.3.1:28784.
septentrio-driver | [septentrio_gnss_driver_node-1] 1723123269.221647101: [septentrio_gnss_driver] [INFO] The connection descriptor is IP10
septentrio-driver | [septentrio_gnss_driver_node-1] 1723123269.221851559: [septentrio_gnss_driver] [INFO] Setting up Rx.
septentrio-driver | [static_transform_publisher-4] 1723123269.245323948: [static_transform_publisher_kRdgEX7ZXWaM8xZQ] [INFO] Spinning until stopped - publishing transform
septentrio-driver | [static_transform_publisher-4] translation: ('0.000000', '0.000000', '0.000000')
septentrio-driver | [static_transform_publisher-4] rotation: ('0.000000', '0.000000', '0.000000', '1.000000')
septentrio-driver | [static_transform_publisher-4] from 'imu' to 'vsm'
septentrio-driver | [septentrio_gnss_driver_node-1] 1723123269.550120539: [septentrio_gnss_driver] [ERROR] Invalid command just sent to the Rx! The Rx's response contains 62 bytes and reads:
septentrio-driver | [septentrio_gnss_driver_node-1] $R? setAntennaOffset: Tabular argument 'Antenna' is invalid!
septentrio-driver | [septentrio_gnss_driver_node-1]
septentrio-driver | [septentrio_gnss_driver_node-1] 1723123269.739602975: [septentrio_gnss_driver] [WARN] Multi antenna requested but Rx does not support it.
septentrio-driver | [septentrio_gnss_driver_node-1] 1723123270.686877777: [septentrio_gnss_driver] [INFO] Setup complete.

septentrio-gnss / septentrio_gnss_driver Goto Github PK

septentrio_gnss_driver's People

Contributors

Stargazers

Watchers

Forkers

septentrio_gnss_driver's Issues

Issue description

Steps to reproduce the issue

What's the expected result?

What's the actual result?

Additional details

Version

Issue description

Steps to reproduce the issue

What's the expected result?

What's the actual result?

Additional details / screenshot

Version

Issue description

Steps to reproduce the issue

What's the expected result?

What's the actual result?

Additional details / screenshot

Version

Description of bug

Environment

To Reproduce

Expected behavior

Suspected cause of bug

Files

GNSS/INS Parameters

For both GNSS and INS Rxs

For GNSS Rx only

For INS Rx only

INS-Specific Parameters

Logger

GNSS/INS Parameters

For both GNSS and INS Rxs

For GNSS Rx only

For INS Rx only

INS-Specific Parameters

Logger

Configuration Settings for the Rover Rx

GNSS/INS Parameters

For both GNSS and INS Rxs

For GNSS Rx only

For INS Rx only

Recommend Projects

Recommend Topics

Recommend Org