As a leader in high-precision GNSS positioning technology, Septentrio provides robust and flexible integration support for the open-source autopilot ecosystem. Whether for the ArduPilot or PX4 platforms, Septentrio’s AsteRx, Mosaic-go, and Mosaic-G5 series receivers offer seamless integration solutions, meeting diverse needs from basic positioning to high-end orientation. The integration of Septentrio GNSS receivers with open-source flight controllers bridges the gap between high-precision GNSS technology and autopilots. It enables developers and manufacturers to rapidly build professional drone systems with positioning and orientation capabilities based on mature, reliable open-source flight control platforms, accelerating application deployment in fields such as surveying, inspection, and precision agriculture. Choosing Septentrio means selecting a proven, high-performance navigation core for your drone.
Q&A
What are the main configuration differences between ArduPilot and PX4 when integrating Septentrio?
The hardware connections and the core SBF protocol are the same for both. The differences lie in configuration: ArduPilot requires manually searching for and setting specific parameters like GPS_TYPE2 in Mission Planner, while PX4 offers a more guided interface in QGroundControl to directly select the SBF protocol. For using dual-antenna heading, both recommend flashing a custom firmware, but the specific parameter paths for enabling heading fusion differ.
What are the two most critical settings in a dual-antenna configuration?
On the receiver side, the SBF data stream must be configured to add and output the AuxAntPositions and AttCovEuler attitude messages. On the flight controller side, the protocol for the corresponding GPS port must be set to an SBF mode that supports heading, and the antenna lever arm offsets must be accurately configured. Finally, verify that heading data is active in the ground station.
Under what circumstances must custom firmware be used?
Custom firmware is mandatory when utilizing dual antennas to obtain GNSS heading information. This is because official stable firmware typically lacks the code to parse critical attitude messages (like AttCovEuler). If using only single-antenna positioning, official firmware may be sufficient.
How do different Septentrio modules affect flight controller performance?
Key differences lie in performance metrics: Newer modules (e.g., Mosaic-G5) with multi-frequency, multi-constellation support shorten RTK convergence time and enhance anti-jamming capabilities. Higher PVT/attitude output rates and lower latency help the flight controller’s filter improve state estimation accuracy. For dual-antenna modules, the heading accuracy and frequency directly determine the stability of directional control.
Septentrio High-Precision GNSS Technology Empowers Drone Flight Control Systems
The deep integration of Septentrio high-precision GNSS receivers with open-source flight controllers provides drone systems with navigation solutions that surpass traditional positioning. Through native support for the efficient SBF protocol, our technology not only achieves centimeter-level RTK positioning but also delivers highly reliable heading information via dual-antenna orientation, completely solving the problem of attitude perception in magnetically interfered environments. Whether on the ArduPilot or PX4 platform, users can rapidly integrate through standardized interfaces and customized firmware, gaining faster convergence, stronger anti-jamming capabilities, and more stable control performance. From precision surveying to autonomous inspection, from agricultural spreading to facility monitoring, Septentrio, with its industrial-grade reliability and all-weather operation capability, provides drones with a true “smart eye.” It makes every flight precise and reliable, turning complex tasks into simple and efficient operations. Choosing Septentrio means injecting the core competitiveness of high-precision navigation into your drone system.

Common Issues to Note When Integrating GNSS with Flight Control Platforms
Protocol and Data Interface
-Protocol Matching: Verify that the flight controller firmware supports the output protocol of the GNSS receiver (e.g., NMEA 0183, UBX, SBF). High-precision positioning often requires proprietary binary protocols (like Septentrio SBF), which may necessitate flashing custom firmware or confirming compatibility with official firmware versions.
-Data Completeness: Ensure the receiver outputs the required message types and frequencies for the flight controller. For example, dual-antenna orientation requires attitude messages (e.g., AttCovEuler), and RTK requires raw observation messages (e.g., RAWX).
-Baud Rate Configuration: The flight controller serial port baud rate must match the receiver’s output baud rate (commonly 115200 or higher); otherwise, data loss will occur.
Hardware Connection and Electrical
-Power and Level Compatibility: Confirm the receiver’s operating voltage (e.g., 3.3V/5V) matches the power supply capability of the flight controller interface, avoiding damage from voltage mismatch. Ensure RS232/TTL logic levels are compatible with the flight controller UART.
-Cabling and Connectors: Use shielded cables to reduce interference and ensure connectors are secure. Standard Pixhawk GPS interfaces typically use JST-GH connectors; pay attention to pinout definitions (e.g., swapping TX/RX will cause communication failure).
-Antenna System:
Use anti-multipath antennas and keep them away from interference sources (e.g., motors, ESCs).
For dual-antenna systems, ensure antenna spacing (typically >30cm) and installation baseline orientation meet receiver requirements.
Ensure antenna port impedance matching (e.g., 50Ω).
Flight Controller Parameter Configuration
GPS Protocol Selection: Correctly set the GPS port protocol in the flight controller ground station (e.g., “Septentrio SBF” in Mission Planner/QGC).
Lever Arm Compensation: Accurately measure and input the offset (X/Y/Z) of the GNSS antenna phase center relative to the flight controller’s IMU center. Failure to do so results in systematic errors in fused position.
Attitude Fusion Settings:
When using dual-antenna heading, enable the GNSS yaw source in the EKF parameters (e.g., EK3_SRC1_YAW in ArduPilot, EKF2_GPS_CTRL in PX4).
Redundancy and Failover: For multi-GNSS systems, set primary/secondary priorities and health check parameters (e.g., GPS_AUTO_SWITCH).
Performance Optimization and Calibration
Installation Location: Antennas should be placed away from propellers and metal structures, ideally at the highest point on the airframe with an open sky view.
Receiver Configuration: Use receiver tools (e.g., web interface) to optimize output frequency, enable multi-frequency/multi-constellation, set elevation mask angle, etc., balancing data rate with accuracy.
System Delay Calibration: If using a PPS pulse for synchronization, calibrate signal transmission delays. High-dynamic scenarios may require configuring dynamic platform models (e.g., vehicle, UAV mode).
Interference Protection: Common electromagnetic interference on drones (ESCs, video transmitters) can affect GNSS reception. Consider adding ferrite cores, shielding, or physical isolation if necessary.
Testing and Verification
Data Stream Monitoring: Use the ground station to check GPS status (satellite count, HDOP, fix type) and confirm valid position and heading output.
Static Accuracy Test: Verify positioning fixed accuracy (RTK Fixed state) and heading stability in an open area.
Dynamic Consistency Test: Compare GNSS velocity/heading with IMU estimated values to check if lever arm parameters are correct.
Failure Safety Test: Simulate signal obstruction or interference to verify the flight controller’s normal failover or alerting.
Firmware and Documentation
Firmware Version: Pay attention to updates in flight controller firmware changelogs regarding GNSS protocol improvements or bug fixes. For high-precision applications, recommended stable versions or manufacturer-recommended firmware are advisable.
Documentation Reference: Carefully read the integration documentation for both the GNSS receiver and flight controller, noting constraints for specific models (e.g., Septentrio requires saving configuration to non-volatile memory).

Core Characteristics of the Two Mainstream Open-Source Flight Control Platforms: PX4 and ArduPilot
Core Characteristics of PX4
Modular Architecture Design:
Based on a microkernel real-time operating system (NuttX RTOS), offering strong system response determinism.
Uses uORB (micro Object Request Broker) message bus for inter-module communication, enabling high decoupling.
Core functions implemented by independent threads/modules (e.g., attitude estimation, position control, navigation), facilitating debugging and feature customization.
Standardized Hardware Support:
-Strict Hardware Compatibility List (FMU standard), ensuring reliable hardware-software collaboration.
-Pixhawk series hardware reference design provides unified hardware ecosystem.
-Supports sensor hot-plugging and automatic calibration.
Modern Development Toolchain:
-Deep integration with QGroundControl, offering an intuitive guided configuration interface.
-Comprehensive simulation environment support (Gazebo, jMAVSim, etc.), supporting Hardware-in-the-Loop (HITL) and Software-in-the-Loop (SITL) simulation.
-Uses modern CMake build system, supports development in IDEs like VSCode.
Safety Design:
-Built-in fault detection and recovery mechanisms (e.g., sensor failure protection, communication loss handling).
-Supports dual-IMU redundancy and failover.
-Detailed flight log recording for incident analysis.
Core Characteristics of ArduPilot
Versatile Platform Coverage:
-Single codebase supports over 100 vehicle types (Copter, Plane, Rover, Sub, Antenna Tracker, etc.).
-Cross-platform capability (Linux, ChibiOS, ESP32, etc.), not dependent on specific hardware operating systems.
-Diverse ground station software options (Mission Planner, MAVProxy, QGC, etc.).
Massive Parameterized Configuration:
-Over 3000 tunable parameters, providing extreme control fine-tuning capability.
-File-based parameter storage system, facilitating configuration backup and migration.
-Supports Lua scripting extension for executing custom logic during flight.
Community-Driven and Experience Accumulation:
-Over 15 years of continuous development, code validated by massive real-world flight hours.
-Large user community providing rich vehicle configuration templates and tuning experience.
-Mature optimized configurations for specific applications (agriculture, surveying, racing, etc.).
Powerful Mission Planning Capability:
-Mission Planner ground station offers professional-grade waypoint mission editor.
-Supports complex automated missions (auto takeoff/landing, survey grids, area searches, etc.).
-Detailed data logging and analysis tools (Dataflash log analysis).
Main Advantages of the Two Mainstream Open-Source Flight Control Platforms: PX4 and ArduPilot
Main Advantages of PX4
-“Out-of-the-box” and Standardization: Strict hardware compatibility list combined with QGC’s guided setup allows users to quickly configure and fly standard airframes, offering an experience closer to consumer products.
-Advanced Architecture, Suitable for Development: Its clean modular architecture and uORB communication mechanism are ideal for researchers and companies conducting secondary development and algorithm integration (e.g., visual navigation, new sensor fusion).
-Powerful Simulation Support: Excellent integration with simulation environments like Gazebo, providing high-fidelity HITL and SITL simulation, greatly facilitating early-stage development and testing.
-Business Application Friendly: Its rigorous architecture and foundation-backed development process are favored by developers seeking productization and compliance for industrial and commercial applications.
Main Advantages of ArduPilot
-Unparalleled Functional Breadth: Supports over 100 vehicle types, from fixed-wing, multirotors, helicopters to unmanned boats, ROVs, rovers, etc., making it the most feature-complete open-source autopilot project.
-Extreme Tunability and Community Wisdom: Possesses a vast number of tunable parameters, accumulating countless user tuning experiences in various extreme scenarios. For non-standard, special-purpose vehicles, or unique missions, desired performance can almost always be achieved through tuning.
-Time-Tested Stability and Reliability: Over 15 years of development history, with code refined through massive real-world flight hours, demonstrating exceptional reliability in complex environments and long-endurance missions.
-Powerful Automated Mission Capability: Its Mission Planner ground station is very powerful for complex waypoint mission planning, scripting (e.g., Lua Scripting), data logging, and analysis.
Typical Application Domain Recommendations for PX4 and ArduPilot
Scenarios Favoring PX4
-Academic Research & New Algorithm Development: Requires a clean architecture for integrating custom state estimation or control algorithms.
-Rapid Prototyping & Productization Development: Companies wanting to quickly develop stable, reproducible drone products based on a standardized platform.
-Standard Multirotor/VTOL Fixed-Wing Applications: Performing standardized tasks like inspection, surveying, and logistics, prioritizing deployment efficiency.
Scenarios Favoring ArduPilot
-Non-Standard or Special-Purpose Vehicles: Such as hybrid aircraft, complex helicopters, giant multirotors, sailboats, ROVs, etc.
-Professional Surveying & Agriculture Applications: Require complex survey grids, spraying patterns, and rely on community-accumulated tuning data for specific vehicle types.
-Long-Range Autonomous Flight & Exploration Missions: Such as solar-powered UAVs, polar expeditions, where long-term system reliability and robustness in extreme environments are paramount.
-Experienced RC Enthusiasts & Tinkerers: Enjoy the process of “taming” various unique aircraft through deep tuning and rely on community support to solve problems.
Summary
Both PX4 and ArduPilot are excellent mainstream open-source flight control platforms that have jointly driven the prosperity of the drone open-source ecosystem. An apt analogy: PX4 is like “iOS”: It offers a more standardized, smooth, and developer-friendly experience, suitable for efficient work and innovation within a clear framework. It’s the preferred choice for commercialization, research, and standard applications. ArduPilot is like “Android”: Extremely feature-rich and highly customizable, with the largest ecosystem, capable of adapting to almost any “device,” but requiring more setup and knowledge. It’s the tool of choice for special-purpose applications, extreme challenges, and seasoned users. The final choice should be based on specific project requirements, team technical background, and long-term maintenance plans.

