ROSaic Deep Dive: Integrating Septentrio GNSS/INS Receivers with ROS 1 & ROS 2

Integrating a professional GNSS receiver into a ROS-based robot or autonomous system usually looks simple on paper and turns out to be messy in practice: binary protocols, axis-convention mismatches, differential correction plumbing, and receiver-state observability all surface as integration work. Septentrio’s official driver — ROSaic (septentrio_gnss_driver) — was built to remove exactly that friction. This guide walks through how the driver works under the hood, what it takes to configure GNSS/INS receivers for ROS 1 and ROS 2, and how the integration effort compares with rolling your own.

1. The Integration Gap ROSaic Closes

A flight controller (PX4, ArduPilot, Pixhawk) talks to GNSS receivers through basic NMEA/UBX sentences — enough to keep a vehicle flying, but not enough for serious autonomy. The SBF binary format, fine-grained RTK status, AIM+ interference-mitigation state, and multi-source differential inputs stay locked inside the receiver unless something on the onboard computer decodes them. ROS, running on a companion computer (Raspberry Pi, NVIDIA Jetson, NUC), is that something: it handles sensor processing, perception, planning, and fusion, while the flight controller handles real-time stabilization. ROSaic sits exactly in this gap — it converts receiver-native data into the standard ROS messages that fusion stacks like robot_localization consume directly.

2. Which Receivers Speak ROSaic

The driver targets Septentrio’s two main receiver families. The mosaic line — mosaic-X5 (multi-frequency, multi-constellation RTK), mosaic-G5 (cost-optimized), and mosaic-H (dual-antenna heading) — covers compact, low-power module integration. The AsteRx line — AsteRx-m3 Pro+, AsteRx-SB Pro+, AsteRx-SBi3 Pro, and related models — adds board and enclosed-receiver form factors, including GNSS/INS variants with dual-antenna heading. All of them bring the same underlying capabilities: centimeter-level RTK across GPS / Galileo / GLONASS / BeiDou / QZSS / NavIC, AIM+ interference mitigation with OSNMA signal authentication, and IMU-fused GNSS/INS output (position, velocity, attitude). The resilience claims are backed by the 2025 Jammertest, where receivers held centimeter accuracy through roughly 100 jamming scenarios and raised correct spoofing alarms.

3. Inside the Driver: Architecture in Brief

ROSaic is a single C++ repository maintained by Septentrio on GitHub that covers both ROS generations — ROS 1 (Melodic, Noetic) and ROS 2 (Foxy through Galactic, Humble, Iron, Jazzy, Kilted, Lyrical, Rolling, and later). Receivers attach over serial, TCP, UDP, or USB (RNDIS and TCP/IP). Data arrives in SBF binary plus selected ASCII/NMEA messages and is exposed as sensor_msgs/NavSatFix, gps_common/GPSFix, and — for INS models — nav_msgs/Odometry.

Three implementation details matter most in practice:

• Native SBF decoding. The driver parses PVTGeodetic, PosCovGeodetic, ChannelStatus, MeasEpoch, AttEuler, AttCovEuler, VelCovGeodetic, DOP, and related blocks, so RTK status, signal health, and attitude data never have to pass through a lossy NMEA translation.
• Built-in NED→ENU conversion. Septentrio outputs in the NED convention; ROS expects ENU. The driver resolves the axis mismatch internally, with an explicit convention selector for INS models (use_ros_axis_orientation).
• Observability. AIM+ and OSNMA anti-jamming / anti-spoofing status is published to ROS topics, turning receiver state into something you can monitor, log, and alert on.

Development workflow is covered too: launch files and parameter directories ship with the package, PCAP files can be replayed offline, and installation works either as a binary package (recommended for mainstream distros) or from source for custom builds.

4. Compatibility Matrix

5. GNSS/INS Setup: The YAML Walkthrough

INS models (AsteRx-i3 D Pro(+), AsteRx SBi3 Pro(+), AsteRx RBi3 Pro(+)) need a few configuration decisions beyond a standard GNSS-only setup. Per Septentrio’s official integration guide, these live in the driver’s YAML file:

• receiver_type: ins — switches the driver into INS receiver mode.
• use_ros_axis_orientation — pick NED or ENU to match your robot’s frame convention.
• ins_spatial_config — the geometry block: IMU orientation angles (imu_orientation theta X/Y/Z), plus the three lever-arm offsets: poi_lever_arm (point of interest), ant_lever_arm (GNSS antenna reference point to IMU), and vsm_lever_arm (velocity sensor to IMU).
• ins_initial_heading — auto (derived from GNSS motion, default) or stored (reuse the previously saved heading).
• ins_std_dev_mask — the acceptance threshold for attitude and position uncertainty; effectively the quality gate of the INS solution.
• ins_use_poi — which point the navigation solution reports (configured POI or primary antenna); must be on when TF publishing is enabled (default true).
• ins_vsm — velocity sensor measurement input for tighter INS accuracy; velocity can come from ROS (Odometry/Twist), a TCP/IP device, or serial.

These parameters are not cosmetic: they define the spatial relationship between the IMU, antennas, and vehicle origin, and errors here propagate directly into fused position and attitude output.

Once running, INS receivers publish topics backed by the INSNavGeod, INSNavCart, ExtSensorMeas, IMUSetup, and VelSensorSetup SBF blocks. Verification is standard ROS workflow — ros2 topic list to enumerate, ros2 topic echo <topic> to inspect — and the bundled PlotJuggler integration renders acceleration, trajectory, and attitude streams in real time.

6. Integration Cost: Official Driver vs. Building Your Own

The honest way to evaluate a driver is against the alternative. For a typical outdoor inspection robot running ROS 2 Humble with robot_localization doing GNSS/IMU fusion, the comparison looks like this:

Timelines are engineering estimates — actual results depend on team experience and project complexity.

The value story reduces to four levers: time (configuration replaces driver development), risk (an upstream maintainer owns compatibility), capability (multi-source RTK, AIM+ reporting, and frame conversion all ship in the box), and ecosystem fit (standard messages drop straight into robot_localization and other fusion frameworks).

7. Beyond ROS: the Flight Controller Route

ROSaic is not the only integration path. mosaic-series receivers also work directly with Pixhawk, ArduPilot, and PX4 Autopilot, and Septentrio’s mosaicHAT reference design (mosaic-X5 + Raspberry Pi) plus the Robotics Interface Board (RIB) simplify hardware bring-up. Teams can therefore start on the flight-controller route and move to a full ROS stack later — or run both, with the receiver serving either side without changes. Eview’s mosaic-X5 based receivers and OEM GNSS boards inherit this whole ecosystem, as do our anti-jamming GNSS solutions for autonomy applications.

8. FAQ

Is the Septentrio ROS driver open source?

Yes — septentrio_gnss_driver is maintained in the open on Septentrio’s GitHub under the ROSaic brand, free to use, and actively updated across ROS 1 and ROS 2 releases.

Do I need a GNSS/INS receiver to benefit from ROSaic?

No. GNSS-only models (mosaic-X5, mosaic-G5, AsteRx m3 Pro+) publish NavSatFix and GPSFix. INS models additionally publish Odometry with full attitude, but everything else — SBF parsing, NED→ENU, multi-source RTK, AIM+ status — works identically either way.

Why does the driver need to convert NED to ENU?

Septentrio receivers follow the NED (North-East-Down) convention, while ROS frames use ENU (East-North-Up). Without conversion, fused position and orientation would be subtly wrong. ROSaic handles this internally, and INS models expose an explicit convention selector.

How do I configure lever arms for an INS receiver?

In the driver YAML, under ins_spatial_config: set imu_orientation for mounting angles and the three lever-arm offsets — poi_lever_arm, ant_lever_arm (antenna to IMU), and vsm_lever_arm (velocity sensor to IMU). These physical offsets directly affect fusion accuracy.

Can I develop against ROSaic without hardware?

Yes — the driver supports PCAP replay, so you can capture receiver data once and exercise the full pipeline offline, which is a practical way to validate message output and fusion behavior before hardware is on the bench.

How long does a typical ROSaic integration take?

For a standard setup, integration is usually verified within days — install the driver, set the receiver type and connection parameters, and launch. Custom INS spatial configuration or unusual fusion setups add time but rarely reach the weeks-to-months scale of a self-developed driver.

9. Sources & References

Author: Eview GNSS Technical Team · Published: 2026-08-26 · Source document: Septentrio GNSS 接入 ROS 技术指南 终稿 v1.1 · External references as listed above.

10. Related Reading

• Septentrio GNSS + ROS Integration: Official ROSaic Driver, Compatibility & Technical Advantages — UAV-operator-focused version on uav-gnss.com
• Septentrio GNSS 接收机如何无缝接入 ROS：官方驱动、兼容性与技术优势详解（中文版） — Chinese version on gnss-imu.com

11. More on AIM+ Anti-Jamming

• Jammertest 2025 Results: AIM+ Anti-Jamming GNSS Holds Centimeter Accuracy Through 100+ Interference Scenarios (gnss-solutions.com)
• Jammertest 2025: AIM+ Anti-Jamming GNSS Keeps UAVs on Mission Through 100+ Interference Scenarios (uav-gnss.com)
• Jammertest 2025 抗干扰实测结果（中文版） (gnss-imu.com)