ROSaic = ROS + mosaic

Overview

This repository hosts drivers for ROS 1 (Melodic and Noetic) and ROS 2 (Foxy, Galactic, Humble, Iron, Rolling, and beyond) - written in C++ - that work with mosaic and AsteRx - two of Septentrio's cutting-edge GNSS and GNSS/INS receiver families - and beyond. Both ROS 1 and ROS 2 are supported within one repository.

Main Features:

• Supports Septentrio's single antenna GNSS, dual antenna GNSS and INS receivers
• Supports serial, TCP/IP and USB connections, the latter being compatible with both serial (RNDIS) and TCP/IP protocols
• Supports several ASCII (including key NMEA ones) messages and SBF (Septentrio Binary Format) blocks
• Reports status of AIM+ (Advanced Interference Mitigation including OSNMA) anti-jamming and anti-spoofing.
• Can publish nav_msgs/Odometry message for INS receivers
• Can blend SBF blocks PVTGeodetic, PosCovGeodetic, ChannelStatus, MeasEpoch, AttEuler, AttCovEuler, VelCovGeodetic and DOP in order to publish gps_common/GPSFix and sensor_msgs/NavSatFix messages
• Supports optional axis convention conversion since Septentrio follows the NED convention, whereas ROS is ENU.
• Easy configuration of multiple RTK corrections simultaneously (via NTRIP, TCP/IP stream, or serial)
• Can play back PCAP capture logs for testing purposes
• Tested with the mosaic-X5, mosaic-H, AsteRx-m3 Pro+, AsteRx-SB Pro+ and the AsteRx-SBi3 Pro receiver
• Easy to add support for more log types

Please let the maintainers know of your success or failure in using the driver with other devices so we can update this page appropriately.

Usage

Important notes

Dependencies

Installation via apt

Build from source

Inertial Navigation System (INS): Basics

• An Inertial Navigation System (INS) is a device which takes the rotation and acceleration solutions as obtained from its Inertial Measurement Unit (IMU) and combines those with position and velocity information from the GNSS module. Compared to a GNSS system with 7D or 8D (dual-antenna systems) phase space solutions, the combined, Kalman-filtered 9D phase space solution (3 for position, 3 for velocity, 3 for orientation) of an INS is more accurate, more precise and more stable against GNSS outages.

• The IMU is typically made up of a 3-axis accelerometer, a 3-axis gyroscope and sometimes a 3-axis magnetometer and measures the system's angular rate and acceleration.

  Measure and Compensate for IMU-Antenna Lever Arm

  + The IMU-antenna lever-arm is the relative position between the IMU reference point and the GNSS Antenna Reference Point (ARP), measured in the vehicle frame. + In case of AsteRx SBi3, the IMU reference point is clearly marked on the top panel of the receiver. It is important to compensate for the effect of the lever arm, otherwise the receiver may not be able to calculate an accurate INS position. + The IMU/antenna position can be changed by specifying the lever arm's `x`,`y`and `z` parameters in the `config.yaml` file under the `ins_spatial_config.ant_lever_arm` parameter. 
  Compensate for IMU Orientation

  + It is important to take into consideration the mounting direction of the IMU in the body frame of the vehicle. For e.g. when the receiver is installed horizontally with the front panel facing the direction of travel, we must compensate for the IMU’s orientation to make sure the IMU reference frame is aligned with the vehicle reference frame. The IMU position and orientation is printed on the top panel, cf. image below. + The IMU's orientation can be changed by specifying the orientation angles `theta_x`,`theta_y`and `theta_z` in the `config.yaml` file under `ins_spatial_config.imu_orientation` + The below image illustrates the orientation of the IMU reference frame with the associated IMU orientation for the depicted installation. Note that for `use_ros_axis_orientation: true` sensor_default is the top left position. 

• These Steps should be followed to configure the receiver in INS integration mode:

  • Specify receiver_type: INS
  • Specify the orientation of the IMU sensor with respect to your vehicle, using the ins_spatial_config.imu_orientation parameter.
  • Specify the IMU-antenna lever arm in the vehicle reference frame. This is the vector starting from the IMU reference point to the ARP of the main GNSS antenna. This can be done by means of the ins_spatial_config.ant_lever_arm parameter.
  • Specify ins_spatial_config.vsm_lever_arm if measurements of a velocity sensor is available.
  • Alternatively the lever arms may be specified via tf. Set get_spatial_config_from_tfto true in this case.
  • If the point of interest is neither the IMU nor the ARP of the main GNSS antenna, the vector between the IMU and the point of interest can be provided with the ins_solution/poi_lever_arm parameter.

• For further more information about Septentrio receivers, visit Septentrio support resources or check out the user manual and reference guide of the AsteRx SBi3 receiver.

ROSaic Parameters

The following is a list of ROSaic parameters found in the config/rover.yaml file. Note, that in the following nested parameters are depicted in ROS 2 style, i.e., using a . as delimiter, whereas in ROS 1 the delimiter is a /.

• Parameters Configuring Communication Ports and Processing of GNSS and INS Data

  Connectivity Specs

  + `device`: location of main device connection. This interface will be used for setup communication and VSM data for INS. Incoming data streams of SBF blocks and NMEA sentences are recevied either via this interface or a static IP server for TCP and/or UDP. The former will be utilized if section `stream_device.tcp` and `stream_device.udp` are not configured. + `serial:xxx` format for serial connections,where xxx is the device node, e.g. `serial:/dev/ttyS0`. If using serial over USB, it is recommended to specify the port by ID as the Rx may get a different ttyXXX on reconnection, e.g. `serial:/dev/serial/by-id/usb-Septentrio_Septentrio_USB_Device_xyz`. + `file_name:path/to/file.sbf` format for publishing from an SBF log. When reading from a file, `use_gnss_time` is automatically set to true, since constructing the time stamps from ROS time would not match the data. If the sbf log does not contain `ReceiverTime`, parameter`leap_seconds` must be set manually. + `file_name:path/to/file.pcap` format for publishing from PCAP capture. When reading from a file, `use_gnss_time` is automatically set to true, since constructing the time stamps from ROS time would not match the data. If the pcap log does not contain `ReceiverTime`, parameter`leap_seconds` must be set manually. + Regarding the file path, ROS_HOME=\`pwd\` in front of `roslaunch septentrio...` might be useful to specify that the node should be started using the executable's directory as its working-directory. + `tcp://host:port` format for TCP/IP connections + `28784` should be used as the default (command) port for TCP/IP connections. If another port is specified, the receiver needs to be (re-)configured via the Web Interface before ROSaic can be used. + An RNDIS IP interface is provided via USB, assigning the address `192.168.3.1` to the receiver. This should work on most modern Linux distributions. To verify successful connection, open a web browser to access the web interface of the receiver using the IP address `192.168.3.1`. + default: `tcp://192.168.3.1:28784 ` + `serial`: specifications for serial communication + `baudrate`: serial baud rate to be used in a serial connection. Ensure the provided rate is sufficient for the chosen SBF blocks. For example, activating MeasEpoch (also necessary for /gpsfix) may require up to almost 400 kBit/s. + `rx_serial_port`: determines to which (virtual) serial port of the Rx we want to get connected to, e.g. USB1 or COM1 + `hw_flow_control`: specifies whether the serial (the Rx's COM ports, not USB1 or USB2) connection to the Rx should have UART hardware flow control enabled or not + `off` to disable UART hardware flow control, `RTS|CTS` to enable it + default: `921600`, `USB1`, `off` + `stream_device`: If left unconfigured, by default `device` is utilized for the data streams. Within `stream_device` static IP servers may be defined instead. In config mode (`configure_rx` set to `true`), TCP will be prioritized over UDP. If Rx is pre-configured, both may be set simultaneously. + `tcp`: specifications for static TCP server of SBF blocks and NMEA sentences. + `ip_server`: IP server of Rx to be used, e.g. “IPS1”. + `port`: UDP destination port. + `udp`: specifications for low latency UDP reception of SBF blocks and NMEA sentences. + `ip_server`: IP server of Rx to be used, e.g. “IPS1”. + `port`: UDP destination port. + `unicast_ip`: Set to computer's IP to use unicast (optional). If not set multicast will be used. + `login`: credentials for user authentication to perform actions not allowed to anonymous users. Leave empty for anonymous access. + `user`: user name + `password`: password + `custom_commands_file`: path to a file containing custom commands to be sent to the Rx. The file shall contain one command per line. Be **very** careful using this command, since commands are sent to the Rx without further checks.
  OSNMA

  + `osnma`: Configuration of the Open Service Navigation Message Authentication (OSNMA) feature. + `mode`: Three operating modes are supported: `off` where OSNMA authentication is disabled, `loose` where satellites are included in the PVT if they are successfully authenticated or if their authentication status is unknown, and `strict` where only successfully-authenticated satellites are included in the PVT. In case of `strict` synchronization via NTP is mandatory. + default: off + `ntp_server`: In `strict` mode, OSNMA authentication requires the availability of external time information. In `loose` mode, this is optional but recommended for enhanced security. The receiver can connect to an NTP time server for this purpose. Options are `default` to let the receiver choose an NTP server or specify one like `pool.ntp.org` for example. + default: "" + `keep_open`: Wether OSNMA shall be kept active on driver shutdown. + default: true
  Receiver Configuration

  + configure_rx: Wether to configure the Rx according to the config file. If set to `false`, the Rx has to be configured via the web interface and the settings must be saved. On the driver side communication has to set accordingly to serial, TCP or UDP (TCP and UDP may even be used simultaneously in this case). For TCP communication it is recommended to use a static TCP server (`stream_device.tcp.ip_server` and `stream_device.tcp.port`), since dynamic connections (`device` is tcp) are not guaranteed to have the same id on reconnection. It should also be ensured that obligatory SBF blocks are activated (as of now: ReceiverTime if `use_gnss_time` is set to `true`; `PVTGeodetic`or `PVTCartesian` if latency compensation for PVT related blocks shall be used). Further, if ROS messages compiled from multiple SBF blocks, it should be ensured that all necessary blocks are activated with matching periods, details can be found in section [ROS Topic Publications](#ros-topic-publications). The messages that shall be published still have to be set to `true` in the *NMEA/SBF Messages to be Published* section. Also, parameters concerning the connection and node setup are still relevant (sections: *Connectivity Specs*, *receiver type*, *Frame IDs*, *UTM Zone Locking*, *Time Systems*, *Logger*). + default: true
  Receiver Type

  + `receiver_type`: This parameter is to select the type of the Septentrio receiver + `gnss` for GNSS receivers. + `ins` for INS receivers. + default: `gnss` + `multi_antenna`: Whether or not the Rx has multiple antennas. + default: `false`
  Frame IDs

  + `frame_id`: name of the ROS tf frame for the Rx, placed in the header of published GNSS messages. It corresponds to the frame of the main antenna. + In ROS, the [tf package](https://wiki.ros.org/tf) lets you keep track of multiple coordinate frames over time. The frame ID will be resolved by [`tf_prefix`](http://wiki.ros.org/geometry/CoordinateFrameConventions) if defined. If a ROS message has a header (all of those we publish do), the frame ID can be found via `rostopic echo /topic`, where `/topic` is the topic into which the message is being published. + default: `gnss` + `imu_frame_id`: name of the ROS tf frame for the IMU, placed in the header of published IMU message + default: `imu` + `poi_frame_id`: name of the ROS tf frame for the POI, placed in the child frame_id of localization if `ins_use_poi` is set to `true`. + default: `base_link` + `vsm_frame_id`: name of the ROS tf frame for the velocity sensor. + default: `vsm` + `aux1_frame_id`: name of the ROS tf frame for the aux1 antenna. + default: `aux1` + `vehicle_frame_id`: name of the ROS tf frame for the vehicle. Default is the same as `poi_frame_id` but may be set otherwise. + default: `base_link` + `local_frame_id`: name of the ROS tf frame for the local frame. + default: `odom` + `insert_local_frame`: Wether to insert a local frame to published tf according to [ROS REP 105](https://www.ros.org/reps/rep-0105.html#relationship-between-frames). The transform from the local frame specified by `local_frame_id` to the vehicle frame specified by `vehicle_frame_id` has to be provided, e.g. by odometry. Insertion of the local frame means the transform between local frame and global frame is published instead of transform between vehicle frame and global frame. + default: `false` + `get_spatial_config_from_tf`: wether to get the spatial config via tf with the above mentioned frame ids. This will override spatial settings of the config file. For receiver type `ins` with `multi_antenna` set to `true` all frames have to be provided, with `multi_antenna` set to `false`, `aux1_frame_id` is not necessary. For type `gnss` with dual-antenna setup only `frame_id`, `aux1_frame_id`, and `poi_frame_id` are needed. For single-antenna `gnss` no frames are needed. Keep in mind that tf has a tree structure. Thus, `poi_frame_id` is the base for all mentioned frames. + default: `false` + `use_ros_axis_orientation` Wether to use ROS axis orientations according to [ROS REP 103](https://www.ros.org/reps/rep-0103.html#axis-orientation) for body related frames and geographic frames. Body frame directions affect INS lever arms and IMU orientation setup parameters. Geographic frame directions affect orientation Euler angles for INS+GNSS and attitude of dual-antenna GNSS. If `use_ros_axis_orientation` is set to `true`, the driver converts between the NED convention (Septentrio: yaw = 0 is north, positive clockwise), and ENU convention (ROS: yaw = 0 is east, positive counterclockwise). There is no conversion when setting this parameter to `false` and the angles will be consistent with the web GUI in this case. + If set to `false` Septentrios definition is used, i.e., front-right-down body related frames and NED (north-east-down) for orientation frames. + If set to `true` ROS definition is used, i.e., front-left-up body related frames and ENU (east-north-up) for orientation frames. + default: `true`
  UTM zone locking

  + `lock_utm_zone`: wether the UTM zone of the initial localization is locked, i.e., this zone is kept even if a zone transition would occur. + default: `true`
  Datum

  + `datum`: With this command, the datum the coordinates should refer to is selected. With setting it to `Default`, the datum depends on the positioning mode, e.g. `WGS84` for standalone positioning. + Since the standardized GGA message does only provide the orthometric height (= MSL height = distance from Earth's surface to geoid) and the geoid undulation (distance from geoid to ellipsoid) for which non-WGS84 datums cannot be specified, it does not affect the GGA message. + default: `Default`
  POI-ARP Offset

  + `poi_to_arp`: offsets of the main GNSS antenna reference point (ARP) with respect to the point of interest (POI = marker). Use for static receivers only. + The parameters `delta_e`, `delta_n` and `delta_u` are the offsets in the East, North and Up (ENU) directions respectively, expressed in meters. + All absolute positions reported by the receiver are POI positions, obtained by subtracting this offset from the ARP. The purpose is to take into account the fact that the antenna may not be located directly on the surveying POI. + default: `0.0`, `0.0` and `0.0`
  Antenna Attitude Offset

  + `att_offset`: Angular offset between two antennas (Main and Aux) and vehicle frame + `heading`: The perpendicular (azimuth) axis can be compensated for by adjusting the `heading` parameter + `pitch`: Vertical (elevation) offset can be compensated for by adjusting the `pitch` parameter + default: `0.0`, `0.0` (degrees)
  Antenna Specs

  + `ant_type`: type of your main GNSS antenna + For best positional accuracy, it is recommended to select a type from the list returned by the command `lstAntennaInfo, Overview`. This is the list of antennas for which the receiver can compensate for phase center variation. + By default and if `ant_type` does not match any entry in the list returned by `lstAntennaInfo, Overview`, the receiver will assume that the phase center variation is zero at all elevations and frequency bands, and the position will not be as accurate. + default: `Unknown` + `ant_serial_nr`: serial number of your main GNSS antenna + `ant_aux1_type` and `ant_aux1_serial_nr`: same for Aux1 antenna
  Leap Seconds

  + `leap_seconds`: Leap seconds are automatically gathered from the receiver via the SBF block `ReceiverTime`. If a log file is used for simulation and this block was not recorded, the number of leap seconds that have been inserted up until the point of ROSaic usage can be set by this parameter. + At the time of writing the code (2020), the GPS time, which is unaffected by leap seconds, was ahead of UTC time by 18 leap seconds. Adapt the `leap_seconds` parameter accordingly as soon as the next leap second is inserted into the UTC time or in case you are using ROSaic for the purpose of simulations.
  Polling Periods

  + `polling_period.pvt`: desired period in milliseconds between the polling of two consecutive `PVTGeodetic`, `PosCovGeodetic`, `PVTCartesian` and `PosCovCartesian` blocks and - if published - between the publishing of two of the corresponding ROS messages (e.g. `septentrio_gnss_driver/PVTGeodetic.msg`). Consult firmware manual for allowed periods. If the period is set to a lower value than the receiver is capable of, it will be published with the next higher period. If set to `0`, the SBF blocks are output at their natural renewal rate (`OnChange`). + Clearly, the publishing of composite ROS messages such as [`sensor_msgs/NavSatFix.msg`](https://docs.ros2.org/foxy/api/sensor_msgs/msg/NavSatFix.html) or [`gps_msgs/GPSFix.msg`](https://github.com/swri-robotics/gps_umd/blob/ros2-devel/gps_msgs/msg/GPSFix.msg) is triggered by the SBF block that arrives last among the blocks of the current epoch. + default: `500` (2 Hz) + `polling_period.rest`: desired period in milliseconds between the polling of all other SBF blocks and NMEA sentences not addressed by the previous parameter, and - if published - between the publishing of all other ROS messages + default: `500` (2 Hz)
  Time Systems

  + `use_gnss_time`: `true` if the ROS message headers' unix epoch time field shall be constructed from the TOW/WNC (in the SBF case) and UTC (in the NMEA case) data, `false` if those times shall be taken by the driver from ROS time. If `use_gnss_time` is set to `true`, it is **imperative** that the ROS system is synchronized to an NTP time server or PTP clock either via internet or ideally via the Septentrio receiver since the latter serves as a Stratum 1 time server not dependent on an internet connection. If this is not followed, the time stamps may drift apart! + default: `false` + `ntp_server`: Wether the NTP server shall be activated. + default: `false` + `ptp_server_clock`: Wether the PTP server slcok hall be activated. + default: `false` + `latency_compensation`: Rx reports processing latency in PVT and INS blocks. If set to `true`this latency is subtracted from ROS timestamps in related blocks (i.e., `use_gnss_time` set to `false`). Related blocks are INS, PVT, Covariances, and BaseVectors. In case of `use_gnss_time` set to `true`, the latency is already compensated within the RX and included in the reported timestamps. + default: `false`
  RTK corrections

  + `rtk_settings`: determines RTK connection parameters + There are multiple possibilities to feed RTK corrections to the Rx. They may be set simultaneously and the Rx will choose the nearest source. + a) `ntrip_#` if the Rx has internet access and is able to receieve NTRIP streams from a caster. Up to three NTRIP connections are possible. + b) `ip_server_#` if corrections are to be receieved via TCP/IP for example over `Data Link` from Septentrio's RxTools is installed on a computer. Up to five IP server connections are possible. + c) `serial_#` if corrections are to be receieved via a serial port for example over radio link from a local RTK base or over `Data Link` from Septentrio's RxTools installed on a computer. Up to five serial connections are possible. + `ntrip_#`: for receiving corretions from an NTRIP caster (`#` is from 1 ... 3). + `id`: NTRIP connection `NTR1`, `NTR2`, or `NTR3`. + default: "" + `caster`: is the hostname or IP address of the NTRIP caster to connect to. + default: "" + `caster_port`: IP port of the NTRIP caster. + default: 2021 + `username`: user name for the NTRIP caster. + default: "" + `pasword`: password for the NTRIP caster. The receiver encrypts the password so that it cannot be read back with the command "getNtripSettings". + default: "" + `mountpoint`: mount point of the NTRP caster to be used. + default: "" + `version`: argument specifies which version of the NTRIP protocol to use (`v1` or `v2`). + default: "v2" + `tls`: determines wether to use TLS. + default: false + `fingerprint`: fingerprint to be used if the certificate is self-signed. If the caster’s certificate is known by a publicly-trusted certification authority, fingerprint should be left empty. + default: "" + `rtk_standard`: determines the RTK standard, options are `auto`, `RTCMv2`, `RTCMv3`, or `CMRv2`. + default: "auto" + `send_gga`: specifies whether or not to send NMEA GGA messages to the NTRIP caster, and at which rate. It must be one of `auto`, `off`, `sec1`, `sec5`, `sec10` or `sec60`. In `auto` mode, the receiver automatically sends GGA messages if requested by the caster. + default: "auto" + `keep_open`: determines wether this connection shall be kept open. If set to `true` the Rx will still be able to receive RTK corrections to improve precision after driver is shut down. + default: true + `ip_server_#`: for receiving corretions via TCP/IP (`#` is from 1 ... 5). + `id`: specifies the IP server `IPS1`, `IPS2`, `IPS3`, `IPS4`, or `IPS5`. Note that ROSaic will send GGA messages on this connection if `send_gga` is set, such that in the `Data Link` application of `RxTools` one just needs to set up a TCP client to the host name as found in the ROSaic parameter `device` with the port as found in `port`. If the latter connection were connection 1 on `Data Link`, then connection 2 would set up an NTRIP client connecting to the NTRIP caster as specified in the above parameters in order to forward the corrections from connection 2 to connection 1. + default: "" + `port`: its port number of the connection that ROSaic establishes on the receiver. When selecting a port number, make sure to avoid conflicts with other services. + default: 0 + `rtk_standard`: determines the RTK standard, options are `auto`, `RTCMv2`, `RTCMv3`, or `CMRv2`. + default: "" + `send_gga`: specifies whether or not to send NMEA GGA messages to the NTRIP caster, and at which rate. It must be one of `auto`, `off`, `sec1`, `sec5`, `sec10` or `sec60`. In `auto` mode, the receiver sends with `sec1`. + default: "auto" + `keep_open`: determines wether this connection shall be kept open. If set to `true` the Rx will still be able to receive RTK corrections to improve precision after driver is shut down. + default: true + `serial_#`: for receiving corretions via serial connection (`#` is from 1 ... 5). + `port`: Serial connection `COM1`, `COM2`, `COM3`, `USB1`, or `USB2` on which corrections could be forwarded to the Rx from a serially connected radio link modem or via `Data Link` for example. + default: "" + `baud_rate`: sets the baud rate of this port for genuine serial ports, i.e., not relevant for USB connection. + default: 115200 + `rtk_standard`: determines the RTK standard, options are `auto`, `RTCMv2`, `RTCMv3`, or `CMRv2`. + default: "auto" + `send_gga`: specifies whether or not to send NMEA GGA messages to the NTRIP caster, and at which rate. It must be one of `auto`, `off`, `sec1`, `sec5`, `sec10` or `sec60`. In `auto` mode, the receiver sends with `sec1`. + default: "auto" + `keep_open`: determines wether this connection shall be kept open. If set to `true` the Rx will still be able to receive RTK corrections to improve precision after driver is shut down. + default: true
  INS Specs

  + `ins_spatial_config`: Spatial configuration of INS/IMU. Coordinates according to vehicle related frame directions chosen by `use_ros_axis_orientation` (front-left-up if `true` and front-right-down if `false`). + `imu_orientation`: IMU sensor orientation + Parameters `theta_x`, `theta_y` and `theta_z` are used to determine the sensor orientation with respect to the vehicle frame. Positive angles correspond to a right-handed (clockwise) rotation of the IMU with respect to its nominal orientation (see below). The order of the rotations is as follows: `theta_z` first, then `theta_y`, then `theta_x`. + The nominal orientation is where the IMU is upside down and with the `X axis` marked on the receiver pointing to the front of the vehicle. By contrast, for `use_ros_axis_orientation: true`, nominal orientation is where the `Z axis` of the IMU is pointing upwards and also with the `X axis` marked on the receiver pointing to the front of the vehicle. + default: `0.0`, `0.0`, `0.0` (degrees) + `poi_lever_arm`: The lever arm from the IMU reference point to a user-defined POI + Parameters `delta_x`,`delta_y` and `delta_z` refer to the vehicle reference frame + default: `0.0`, `0.0`, `0.0` (meters) + `ant_lever_arm`: The lever arm from the IMU reference point to the main GNSS antenna + The parameters `x`,`y` and `z` refer to the vehicle reference frame + default: `0.0`, `0.0`, `0.0` (meters) + `vsm_lever_arm`: The lever arm from the IMU reference point to the velocity sensor + The parameters `vsm_x`,`vsm_y` and `vsm_z` refer to the vehicle reference frame + default: `0.0`, `0.0`, `0.0` (meters) + `ins_initial_heading`: How the receiver obtains the initial INS/GNSS integrated heading during the alignment phase + In case it is `auto`, the initial integrated heading is determined from GNSS measurements. + In case it is `stored`, the last known heading when the vehicle stopped before switching off the receiver is used as initial heading. Use if vehicle does not move when the receiver is switched off. + default: `auto` + `ins_std_dev_mask`: Maximum accepted error + `att_std_dev`: Configures an output limit on standard deviation of the attitude angles (max error accepted: 5 degrees) + `pos_std_dev`: Configures an output limit on standard deviation of the position (max error accepted: 100 meters) + default: `5` degrees, `10` meters + `ins_use_poi`: Whether or not to use the POI defined in `ins_spatial_config.poi_lever_arm` + If true, the point at which the INS navigation solution (e.g. in `insnavgeod` ROS topic) is calculated will be the POI as defined above (`poi_frame_id`), otherwise it'll be the main GNSS antenna (`frame_id`). Has to be set to `true` if tf shall be published. + default: `true` + `ins_vsm`: Configuration of the velocity sensor measurements. IP server may be used to receive velocity information from ROS or from an external device. Serial connection may be used to receive velocity information from an external device only. + `ros`: VSM info received from ROS msgs + `source`: Specifies which ROS message type shall be used, options are `odometry` or `twist`. Accordingly, a subscriber is established of the type [`nav_msgs/Odometry.msg`](https://docs.ros2.org/foxy/api/nav_msgs/msg/Odometry.html) or [`geometry_msgs/TwistWithCovarianceStamped.msg`](https://docs.ros2.org/foxy/api/geometry_msgs/msg/TwistWithCovarianceStamped.html) listening on the topics `odometry_vsm` or `twist_vsm` respectively. Only linear velocities are evaluated. Measurements have to be with respect to the frame aligned with the vehicle and defined by `ins_spatial_config.vsm_lever_arm` or tf-frame `vsm_frame_id`, see also comment in [`nav_msgs/Odometry.msg`](https://docs.ros2.org/foxy/api/nav_msgs/msg/Odometry.html) that twist should be specified in `child_frame_id`. + default: "" + `config`: Defines which measurements belonging to the respective axes are forwarded to the INS. In addition, non-holonomic constraints may be introduced for directions known to be restricted in movement. For example, a vehicle with Ackermann steering is limited in its sidewards and upwards movement. So, even if only motion in x-direction may be measured, zero-velocities for y and z may be sent. Only has to be set if `ins_vsm.ros.source`is set to `odometry` or `twist`. + default: [] + `variances_by_parameter`: Wether variances shall be entered by parameter `ins_vsm.ros.variances` or the values from inside the ROS messages are used. Only has to be set if `ins_vsm.source`is set to `odometry` or `twist`. + default: false + `variances`: Variances of the respective axes. Only have to be set if `ins_vsm.variances_by_parameter` is set to `true`. Values must be > 0.0, else measurements cannot not be used. + default: [] + `ip_server`: + `id`: IP server to receive the VSM info (e.g. `IPS1`). If a TCP stream device (`device.stream_device.tcp`) is set up, this device may be used here, i.e, `id` my be set to the same. + default: "IPS5" + `port`: TCP port to receive the VSM info. When selecting a port number, make sure to avoid conflicts with other services. + default: 24786 + `keep_open` determines wether this connections to receive VSM shall be kept open on driver shutdown. If set to `true` the Rx will still be able to use external VSM info to improve its localization. + default: `true` + `serial`: + `port`: Serial port to receive the VSM info. + default: "" + `baud_rate`: Baud rate of the serial port to receive the VSM info. + default: 115200 + `keep_open` determines wether this connections to receive VSM shall be kept open on driver shutdown. If set to `true` the Rx will still be able to use external VSM info to improve its localization. + default: `true`
  Logger

  + `activate_debug_log`: `true` if ROS logger level shall be set to debug.

• Parameters Configuring (Non-)Publishing of ROS Messages

  NMEA/SBF Messages to be Published

  + `publish.auto_publish`: `true` to automatically publish messages for which SBF blocks and NMEA sentences are available. Only applicable if `conigure_rx` is `false`. If `tf_ecef` shall be published, this must be explicitily set to true, else tf in UTM is published if available. + `publish.publish_only_valid`: `true` to publish SBF blocks only if timestamp (TOW) is valid. + `publish.gpgga`: `true` to publish `nmea_msgs/GPGGA.msg` messages into the topic `/gpgga` + `publish.gprmc`: `true` to publish `nmea_msgs/GPRMC.msg` messages into the topic `/gprmc` + `publish.gpgsa`: `true` to publish `nmea_msgs/GPGSA.msg` messages into the topic `/gpgsa` + `publish.gpgsv`: `true` to publish `nmea_msgs/GPGSV.msg` messages into the topic `/gpgsv` + `publish.measepoch`: `true` to publish `septentrio_gnss_driver/MeasEpoch.msg` messages into the topic `/measepoch` + `publish.galauthstatus`: `true` to publish `septentrio_gnss_driver/GALAuthStatus.msg` messages into the topic `/galauthstatus` and corresponding `/diganostics` + `publish.aimplusstatus`: `true` to publish `septentrio_gnss_driver/RFStatus.msg` messages into the topic `/rfstatus`, `septentrio_gnss_driver/AIMPlusStatus.msg` messages into `/aimplusstatus` and corresponding `/diganostics`. Some information is only available with active OSNMA. + `publish.pvtcartesian`: `true` to publish `septentrio_gnss_driver/PVTCartesian.msg` messages into the topic `/pvtcartesian` + `publish.pvtgeodetic`: `true` to publish `septentrio_gnss_driver/PVTGeodetic.msg` messages into the topic `/pvtgeodetic` + `publish.basevectorcart`: `true` to publish `septentrio_gnss_driver/BaseVectorCart.msg` messages into the topic `/basevectorcart` + `publish.basevectorgeod`: `true` to publish `septentrio_gnss_driver/BaseVectorGeod.msg` messages into the topic `/basevectorgeod` + `publish.poscovcartesian`: `true` to publish `septentrio_gnss_driver/PosCovCartesian.msg` messages into the topic `/poscovcartesian` + `publish.poscovgeodetic`: `true` to publish `septentrio_gnss_driver/PosCovGeodetic.msg` messages into the topic `/poscovgeodetic` + `publish.velcovcartesian`: `true` to publish `septentrio_gnss_driver/VelCovCartesian.msg` messages into the topic `/velcovcartesian` + `publish.velcovgeodetic`: `true` to publish `septentrio_gnss_driver/VelCovGeodetic.msg` messages into the topic `/velcovgeodetic` + `publish.atteuler`: `true` to publish `septentrio_gnss_driver/AttEuler.msg` messages into the topic `/atteuler` + `publish.attcoveuler`: `true` to publish `septentrio_gnss_driver/AttCovEuler.msg` messages into the topic `/attcoveuler` + `publish.gpst`: `true` to publish `sensor_msgs/TimeReference.msg` messages into the topic `/gpst` + `publish.navsatfix`: `true` to publish `sensor_msgs/NavSatFix.msg` messages into the topic `/navsatfix` + `publish.gpsfix`: `true` to publish `gps_msgs/GPSFix.msg` messages into the topic `/gpsfix` + `publish.pose`: `true` to publish `geometry_msgs/PoseWithCovarianceStamped.msg` messages into the topic `/pose` + `publish.twist`: `true` to publish `geometry_msgs/TwistWithCovarianceStamped.msg` messages into the topics `/twist` and `/twist_ins` respectively + `publish.diagnostics`: `true` to publish `diagnostic_msgs/DiagnosticArray.msg` messages into the topic `/diagnostics` + `publish.insnavcart`: `true` to publish `septentrio_gnss_driver/INSNavCart.msg` message into the topic`/insnavcart` + `publish.insnavgeod`: `true` to publish `septentrio_gnss_driver/INSNavGeod.msg` message into the topic`/insnavgeod` + `publish.extsensormeas`: `true` to publish `septentrio_gnss_driver/ExtSensorMeas.msg` message into the topic`/extsensormeas` + `publish.imusetup`: `true` to publish `septentrio_gnss_driver/IMUSetup.msg` message into the topic`/imusetup` + `publish.velsensorsetup`: `true` to publish `septentrio_gnss_driver/VelSensorSetup.msgs` message into the topic`/velsensorsetup` + `publish.exteventinsnavcart`: `true` to publish `septentrio_gnss_driver/ExtEventINSNavCart.msgs` message into the topic`/exteventinsnavcart` + `publish.exteventinsnavgeod`: `true` to publish `septentrio_gnss_driver/ExtEventINSNavGeod.msgs` message into the topic`/exteventinsnavgeod` + `publish.imu`: `true` to publish `sensor_msgs/Imu.msg` message into the topic`/imu` + `publish.localization`: `true` to publish `nav_msgs/Odometry.msg` message into the topic`/localization` + `publish.tf`: `true` to broadcast tf of localization. `ins_use_poi` must also be set to true to publish tf. Note that only one of `publish.tf` or `publish.tf_ecef` may be `true`. + `publish.localization_ecef`: `true` to publish `nav_msgs/Odometry.msg` message into the topic`/localization` related to ECEF frame. + `publish.tf_ecef`: `true` to broadcast tf of localization related to ECEF frame. `ins_use_poi` must also be set to true to publish tf. Note that only one of `publish.tf` or `publish.tf_ecef` may be `true`.

ROS Topic Publications

A selection of NMEA sentences, the majority being standardized sentences, and proprietary SBF blocks is translated into ROS messages, partly generic and partly custom, and can be published at the discretion of the user into the following ROS topics. All published ROS messages, even custom ones, start with a ROS generic header std_msgs/Header.msg, which includes the receiver time stamp as well as the frame ID, the latter being specified in the ROS parameter frame_id.

Suggestions for Improvements

Adding New SBF Blocks or NMEA Sentences