This repository hosts a ROS Melodic and Noetic driver (i.e. for Linux only) - written in C++ - that works with mosaic and AsteRx - two of Septentrio's cutting-edge GNSS/INS receiver families - and beyond. Since Noetic will only be supported until 2025, we plan to make ROSaic compatible with ROS2.
DOPin order to publish
Please let the maintainers know of your success or failure in using the driver with other devices so we can update this page appropriately.
master branch for this driver functions on both ROS Melodic (Ubuntu 18.04) and Noetic (Ubuntu 20.04). It is thus necessary to install the ROS version that has been designed for your Linux distro.
The serial and TCP/IP communication interface of the ROS driver is established by means of the Boost C++ library. In the unlikely event that the below installation instructions fail to install Boost on the fly, please install the Boost libraries via<br>
sudo apt install libboost-all-dev.
Compatiblity with PCAP captures are incorporated through pcap libraries. Install the necessary headers via<br>
sudo apt install libpcap-dev.
The binary release is now available for Melodic and Noetic. To install the binary package on Melodic for instance, simply run
sudo apt-get install ros-melodic-septentrio-gnss-driver. </details>
Build from Source
Alternatively, the package can also be built from source using
catkin_tools, where the latter can be installed using the command
sudo apt-get install python-catkin-tools for Melodic or
sudo apt-get install python3-catkin-tools for Noetic. The typical
catkin_tools workflow should suffice:
Notes Before Usage
true. Note that in the GNSS case
gpsfixaccounts for 3 additional streams (
MeasEpochblocks), for instance.
config/rover.yamlfile according to your needs. The
launch/rover.launchneed not be modified. Specify the communication parameters, the ROS messages to be published, the frequency at which the latter should happen etc.:
In order to launch ROSaic, one must specify all
arg fields of the
rover.launch file which have no associated default values, i.e. for now only the
param_file_name field. Hence, the launch command reads
roslaunch septentrio_gnss_driver rover.launch param_file_name:=rover.
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 position can be changed by specifying the lever arm's
z parameters in the
config.yaml file under the
Compensate for IMU Orientation
config.yamlfile under the
The following is a list of ROSaic parameters found in the
device: location of device connection
serial:xxxformat for serial connections, where xxx is the device node, e.g.
file_name:path/to/file.sbfformat for publishing from an SBF log
file_name:path/to/file.pcapformat for publishing from PCAP capture.
roslaunch septentrio...might be useful to specify that the node should be started using the executable's directory as its working-directory.
tcp://host:portformat for TCP/IP connections
28784should 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.
serial: specifications for serial communication
serial/baudrate: serial baud rate to be used in a serial connection
serial/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 HW flow control enabled or not
offto disable UART HW flow control,
RTS|CTSto enable it
receiver_type: This parameter is to select the type of the Septentrio receiver
gnss, then ROS can only output data related to GNSS receivers.
ins, then ROS can only output data related to INS receivers.
frame_id: name of the ROS tf frame for the Rx, placed in the header of all published messages
tf_prefixif 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
/topicis the topic into which the message is being published.
datum: datum that (ellipsoidal) height should be referenced to in all published ROS messages
poi_to_arp: offsets of the main GNSS antenna reference point (ARP) with respect to the point of interest (POI = marker)
delta_uare the offsets in the East, North and Up (ENU) directions respectively, expressed in meters.
poi_to_aux1_arp: same for Aux1 antenna </details>
ant_type: type of your main GNSS antenna
lstAntennaInfo, Overview. This is the list of antennas for which the receiver can compensate for phase center variation.
ant_typedoes 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.
ant_serial_nr: serial number of your main GNSS antenna
ant_aux1_serial_nr: same for Aux1 antenna </details>
leap_seconds: number of leap seconds that have been inserted up until the point of ROSaic usage
use_GNSS_timeto true and uncomment a paragraph in the
UTCtoUnix()function definition found in the file
septentrio_gnss_driver/src/septentrio_gnss_driver/parsers/parsing_utilities.cppand enter the year, month and date to be simulated. </details>
polling_period/pvt: desired period in milliseconds between the polling of two consecutive
PosCovCartesianblocks and - if published - between the publishing of two of the corresponding ROS messages (e.g.
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
500(2 Hz) </details>
trueif the ROS message headers' unix epoch time field shall be constructed from the TOW (in the SBF case) and UTC (in the NMEA case) data,
falseif those times shall be constructed by the driver via the time(NULL) function found in the
ntrip_settings: determines NTRIP connection parameters
rx_has_internetto true, and
rx_has_internetto false, but
Data Linkfrom Septentrio's RxTools is installed on the computer.
ntrip_settings/mode, specifies the type of the NTRIP connection and must be one of
Clientmode, the receiver receives data from the NTRIP caster. When selecting the
Client-Sapcordamode, the receiver receives data from the Sapcorda NTRIP service and no further settings are required, i.e. all other nested parameters are ignored. Note that the latter mode only works in Europe and North America. Set mode to
offto disable all correction services.
ntrip_settings/casteris the hostname or IP address of the NTRIP caster to connect to. To send data to the built-in NTRIP caster, use "localhost" for this parameter.
ntrip_settings/mountpointare the IP port number, the user name, the password and the mount point, respectively, to be used when connecting to the NTRIP caster. The receiver encrypts the password so that it cannot be read back with the command "getNtripSettings". The
ntrip_settings/versionargument specifies which version of the NTRIP protocol to use (
send_ggaspecifies whether or not to send NMEA GGA messages to the NTRIP caster, and at which rate. It must be one of
automode, the receiver automatically sends GGA messages if requested by the caster.
rx_has_internetspecifies whether the Rx has internet access or not. Note that an Ethernet cable is the only way to enable internet access on mosaic receivers (and most others) at the moment. In case internet is available, NTRIP will be configured with a simple command
snts, ...that ROSaic sends to the receiver.
rtcm_versionspecifies the type of RTCM data transmitted to ROSaic by the NTRIP caster, either
RTCMv3. It depends on the mountpoint.
rx_input_corrections_tcpspecifies the port number of the IP server (IPS1) connection that ROSaic establishes on the receiver. Note that ROSaic will send GGA messages on this connection, such that in the
Data Linkapplication of
RxToolsone just needs to set up a TCP client to the host name as found in the ROSaic parameter
devicewith the port as found in
rx_input_corrections_tcp. 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.
rx_input_corrections_serialanalogously determines the port on which corrections could be serially forwarded to the Rx via
off, empty, empty, empty, empty, empty,
ins_spatial_config: Spatial configuration of INS/IMU
att_offset: Angular offset between two antenna (Main and Aux) and vehicle heading
heading: The perpendicular axis can be compensated for by adjusting the
pitch: Vertical offset can be compensated for by adjusting the
imu_orientation: IMU sensor orientation
theta_zare 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:
X axismarked on the receiver pointing to the front of the vehicle.
poi_to_imu: The lever arm from the IMU reference point to a user-defined POI
delta_zrefer to the vehicle reference frame
ant_lever_arm: The lever arm from the IMU reference point to the main GNSS antenna
zrefer to the vehicle reference frame
vel_sensor_lever_arm: The lever arm from the IMU reference point to the velocity sensor
vsm_zrefer to the vehicle reference frame
ins_initial_heading: How the receiver obtains the initial INS/GNSS integrated heading during the alignment phase
auto, the initial integrated heading is determined from GNSS measurements.
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.
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)
ins_use_poi: Whether or not to use the POI defined in
insnavgeodROS topic) is calculated will be the POI as defined above, otherwise it'll be the main GNSS antenna.
Parameters Configuring (Non-)Publishing of ROS Messages <details>
NMEA/SBF Messages to be Published
septentrio_gnss_driver/GPGGA.msgmessages into the topic
septentrio_gnss_driver/GPRMC.msgmessages into the topic
septentrio_gnss_driver/GPGSA.msgmessages into the topic
septentrio_gnss_driver/GPGSV.msgmessages into the topic
septentrio_gnss_driver/PVTCartesian.msgmessages into the topic
septentrio_gnss_driver/PVTGeodetic.msgmessages into the topic
septentrio_gnss_driver/PosCovCartesian.msgmessages into the topic
septentrio_gnss_driver/PosCovGeodetic.msgmessages into the topic
septentrio_gnss_driver/VelCovGeodetic.msgmessages into the topic
septentrio_gnss_driver/AttEuler.msgmessages into the topic
septentrio_gnss_driver/AttCovEuler.msgmessages into the topic
sensor_msgs/TimeReference.msgmessages into the topic
sensor_msgs/NavSatFix.msgmessages into the topic
gps_common/GPSFix.msgmessages into the topic
geometry_msgs/PoseWithCovarianceStamped.msgmessages into the topic
diagnostic_msgs/DiagnosticArray.msgmessages into the topic
septentrio_gnss_driver/INSNavCart.msgmessage into the topic
septentrio_gnss_driver/INSNavGeod.msgmessage into the topic
septentrio_gnss_driver/ExtSensorMeas.msgmessage into the topic
septentrio_gnss_driver/IMUSetup.msgmessage into the topic
septentrio_gnss_driver/VelSensorSetup.msgsmessage into the topic
septentrio_gnss_driver/ExtEventINSNavCart.msgsmessage into the topic
septentrio_gnss_driver/ExtEventINSNavGeod.msgsmessage into the topic
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
Available ROS Topics
/gpgga: publishes custom ROS message
septentrio_gnss_driver/Gpgga.msg- equivalent to
nmea_msgs/Gpgga.msg- converted from the NMEA sentence GGA
/gprmc: publishes custom ROS message
septentrio_gnss_driver/Gprmc.msg- equivalent to
nmea_msgs/Gprmc.msg- converted from the NMEA sentence RMC
/gpgsa: publishes custom ROS message
septentrio_gnss_driver/Gpgsa.msg- equivalent to
nmea_msgs/Gpgsa.msg- converted from the NMEA sentence GSA
/gpgsv: publishes custom ROS message
septentrio_gnss_driver/Gpgsv.msg- equivalent to
nmea_msgs/Gpgsv.msg- converted from the NMEA sentence GSV
/pvtcartesian: publishes custom ROS message
septentrio_gnss_driver/PVTCartesian.msg, corresponding to the SBF block
PVTCartesian(GNSS case) or
/pvtgeodetic: publishes custom ROS message
septentrio_gnss_driver/PVTGeodetic.msg, corresponding to the SBF block
PVTGeodetic(GNSS case) or
/poscovcartesian: publishes custom ROS message
septentrio_gnss_driver/PosCovCartesian.msg, corresponding to SBF block
PosCovCartesian(GNSS case) or
/poscovgeodetic: publishes custom ROS message
septentrio_gnss_driver/PosCovGeodetic.msg, corresponding to SBF block
PosCovGeodetic(GNSS case) or
/velcovgeodetic: publishes custom ROS message
septentrio_gnss_driver/VelCovGeodetic.msg, corresponding to SBF block
/atteuler: publishes custom ROS message
septentrio_gnss_driver/AttEuler.msg, corresponding to SBF block
AttEuler(GNSS case) or
/attcoveuler: publishes custom ROS message
septentrio_gnss_driver/AttCovEuler.msg, corresponding to the SBF block
AttCovEuler(GNSS case) or
/gpst(for GPS Time): publishes generic ROS message
sensor_msgs/TimeReference.msg, converted from the
PVTGeodetic(GNSS case) or
INSNavGeod(INS case) block's GPS time information, stored in its header, or - if
use_gnss_timeis set to
false- from the systems's wall-clock time
/navsatfix: publishes generic ROS message
sensor_msgs/NavSatFix.msg, converted from the SBF blocks
PosCovGeodetic(GNSS case) or
/gpsfix: publishes generic ROS message
gps_common/GPSFix.msg, which is much more detailed than
sensor_msgs/NavSatFix.msg, converted from the SBF blocks
DOP(GNSS case) or
/pose: publishes generic ROS message
geometry_msgs/PoseWithCovarianceStamped.msg, converted from the SBF blocks
AttCovEuler(GNSS case) or
setAntennaLocation, ...) !local! NED frame. Thus the orientation is !not! given with respect to the same frame as the position is given in. The cross-covariances are hence set to 0.
robot_localizationpackage can accept the ROS message
/insnavcart: publishes custom ROS message
septentrio_gnss_driver/INSNavCart.msg, corresponding to SBF block
/insnavgeod: publishes custom ROS message
septentrio_gnss_driver/INSNavGeod.msg, corresponding to SBF block
/extsensormeas: publishes custom ROS message
septentrio_gnss_driver/ExtSensorMeas.msg, corresponding to SBF block
/imusetup: publishes custom ROS message
septentrio_gnss_driver/IMUSetup.msg, corresponding to SBF block
/velsensorsetup: publishes custom ROS message
septentrio_gnss_driver/VelSensorSetup.msgcorresponding to SBF block
/exteventinsnavcart: publishes custom ROS message
septentrio_gnss_driver/ExtEventINSNavCart.msg, corresponding to SBF block
/exteventinsnavgeod: publishes custom ROS message
septentrio_gnss_driver/ExtEventINSNavGeod.msg, corresponding to SBF block
/diagnostics: accepts generic ROS message
diagnostic_msgs/DiagnosticArray.msg, converted from the SBF blocks
host:portspecification, the driver could automatically search and establish a connection on the specified port.
/measepoch: It could accept the custom ROS message
septentrio_gnss_driver/MeasEpoch.msg, corresponding to the SBF block
MeasEpoch(raw GNSS data).
/twist: It could accept the generic ROS message
geometry_msgs/TwistWithCovarianceStamped.msg, converted from the SBF blocks
PosCovGeodeticand others or via standardized NMEA sentences (cf. the NMEA driver).
Data Link. </details>
Steps to Follow
Is there an SBF or NMEA message that is not being addressed while being important to your application? If yes, follow these steps:
.msgfile to the
septentrio_gnss_driver/PVTGeodetic.h) that gets compiler-generated from the
.msgfile constructed in step 3.
NMEA_ID_Enumenumeration in the
rx_message.hppfile with a new entry.
RxIDMapmap in the
rx_message.cppfile with a new pair.
io_comm_rx::RxMessage classin the
rx_message.hppfile. It should be modeled on the existing
evPVTGeodeticcase, e.g. one needs a static counter variable declaration.
septentrio_gnss_driver/src/septentrio_gnss_driver/parsers/nmea_parsersfolder and one such as
publish/..ROSaic parameter in the
septentrio_gnss_driver/config/rover.yamlfile, create a global boolean variable
septentrio_gnss_driver/src/septentrio_gnss_driver/node/rosaic_node.cppfile, insert the publishing callback function to the C++ "multimap"
IO.handlers_.callbackmap_- which is already storing all the others - in the
rosaic_node::ROSaicNode::defineMessages()method in the same file and add an
extern bool publish_...;line to the
septentrio_gnss_driver/CMakeLists.txtfile by adding a new entry to the