Hi PX4 community,
I would like to share some technical thoughts from our recent work on an integrated UAV control architecture for autonomous flight in GNSS-denied and GNSS-unstable environments.
At ROBOSN, we have been working on UAV systems that need to operate in places where GNSS alone is not reliable enough, such as underground garages, warehouses, indoor spaces, caves, and indoor-to-outdoor transition areas. In these scenarios, the architecture has to coordinate perception, localization, planning, and low-level flight control as one complete autonomy stack.
This post is not intended as a product announcement. The focus is on architecture choices, integration challenges, and engineering trade-offs that may also be useful to PX4 developers working on autonomous systems.
1. Why flight-control-centered architectures become insufficient
For many conventional UAV platforms, the flight controller is the center of the system. It receives IMU, barometer, compass, GNSS, RC input, and sometimes external vision or range data, then executes attitude and position control. This works well for many outdoor missions.
The situation changes when the aircraft must fly where GNSS is unavailable, unstable, or affected by multipath interference. At that point, the system is no longer only a flight-control problem. It becomes a full-stack autonomy problem.
A GNSS-denied UAV may need to run several mission-critical capabilities at the same time:
· visual-inertial or LiDAR-inertial localization;
· real-time SLAM or map-based positioning;
· obstacle perception and environmental understanding;
· point-cloud map management;
· target detection or recognition;
· path planning and mission-level decision logic;
· safe handover between indoor and outdoor positioning sources;
· stable communication between onboard computers and the flight controller.
The flight controller still needs to remain deterministic and reliable, but the perception, localization, and planning modules around it also become mission-critical. This is why the overall system architecture matters as much as the flight controller itself.
2. A layered autonomy architecture
In our current architecture, we separate the UAV system into several logical layers instead of treating the aircraft as one large black box.
The application layer is responsible for user applications, third-party mission logic, and payload applications.
The planning and control layer handles mission orchestration, navigation scheduling, control coordination, safety management, and status monitoring.
The perception layer focuses on visual detection, recognition, tracking, and environmental understanding.
The localization and mapping layer handles visual, LiDAR, IMU, GNSS, and INS fused positioning and map building.
The flight-control layer handles low-level attitude, velocity, position control, and actuator output.
The operating-system and service layer provides Linux-based services, networking, logging, payload communication, and system management.
This separation gives each layer a clear responsibility. PX4 or PX4-based firmware can remain the low-level control foundation, while higher-level autonomy modules run outside the flight controller on onboard compute units. This makes debugging and system expansion much cleaner.
3. GNSS-denied positioning requires multi-source fusion
One of the core challenges is positioning continuity. In GNSS-denied environments, the UAV cannot depend on satellite positioning. Even when GNSS is partially available, multipath or unstable signal quality may cause position jumps.
Instead of replacing GNSS with a single alternative sensor, we use a fused positioning approach. The system combines several sources:
· vision data;
· LiDAR data;
· IMU data;
· RTK or GNSS when available;
· INS data;
· front and rear perception cameras;
· environmental map data.
Different operating scenarios require different sensor emphasis.
In an underground garage, GNSS is unavailable and lighting may be weak, so LiDAR, IMU, and vision become more important.
In a warehouse, repetitive shelves and narrow aisles can create perception ambiguity, so LiDAR, vision, and map constraints need to work together.
In an office building, the aircraft may need precise indoor hovering and stable low-speed motion, so vision, LiDAR, and IMU consistency are critical.
In a cave, the environment may have no GNSS and limited light, so LiDAR geometry and IMU propagation are often more reliable than visual texture.
During indoor-to-outdoor transition, the key issue is not only positioning accuracy but also estimator continuity. The system should not generate sudden jumps when GNSS quality changes or when the UAV moves between positioning regimes.
4. Sensor synchronization is a system-level problem
Multi-sensor positioning depends heavily on time synchronization. If vision, LiDAR, IMU, GNSS, and flight-control data are not aligned properly, the fused positioning output may become unstable, especially during aggressive motion or in complex environments.
For autonomous UAVs, timestamp accuracy directly affects mapping quality, estimator stability, and control reliability. A small synchronization error may appear later as localization drift, delayed setpoint tracking, unstable hovering, or inconsistent control behavior.
In our design, hardware-level coordination is used for key sensors such as cameras, LiDAR, IMU, and GNSS / RTK. Software-level synchronization is useful, but for high-dynamic UAV operation it may not always be sufficient.
This is a topic where PX4 community discussion would be very valuable: what synchronization strategies have proven most reliable in real field deployment, especially for visual positioning and LiDAR-based navigation?
5. Why perception compute and planning compute should be separated
Many UAV prototypes run SLAM, perception, planning, communication, and mission logic on the same onboard computer. This is convenient during early development, but it can create reliability problems in real missions.
Several workload spikes are common:
· SLAM may consume heavy CPU resources when the environment becomes complex;
· point-cloud processing may become unstable as the map grows;
· AI recognition may create sudden GPU or CPU load;
· network or video-streaming tasks may affect scheduling;
· logging and data recording may increase I/O pressure.
If planning and mission-control logic share the same compute resources with heavy perception workloads, the autonomy stack becomes less predictable. For this reason, we use a separated compute model.
The perception and positioning computer handles SLAM, fused localization, environmental mapping, and object recognition.
The decision and planning computer handles mission logic, route planning, control commands, and safety decisions.
The flight-control computer handles low-level control, attitude stabilization, and actuator control.
The actuation unit executes motor and actuator outputs.
The main design principle is simple: heavy perception workloads should not interfere with planning and low-level flight-control reliability. This is especially important when the UAV needs to map, recognize, and navigate autonomously at the same time.
6. PX4 as the low-level control foundation
In this type of architecture, PX4-related firmware works best as the reliable low-level control foundation. The autonomy stack should not try to replace the flight controller. Instead, it should send high-level control intentions to the flight-control layer.
Depending on the application, these commands may be position setpoints, velocity setpoints, attitude setpoints, mission commands, or a hybrid control strategy.
This division is practical because:
· PX4 handles real-time control and actuator output;
· the onboard autonomy stack handles perception, mapping, localization, and planning;
· the ground station handles configuration, monitoring, debugging, and log analysis;
· application developers can build mission logic through higher-level interfaces.
This also makes debugging more structured. When a problem occurs, developers can check one layer at a time:
· Is the positioning output stable?
· Is the coordinate frame correct?
· Is the planning command reasonable?
· Is PX4 receiving the correct setpoints?
· Is the aircraft responding correctly at the control level?
· Are timestamps, transforms, and estimator outputs consistent?
This layered debugging method is usually more efficient than trying to diagnose the entire UAV as a single black-box system.
7. Development workflow for an integrated autonomous UAV
A practical development workflow usually includes five stages.
First, aircraft integration. The airframe is connected with the flight-control computer, onboard computers, vision and LiDAR sensors, GNSS / INS, image and data link, payload interface, and network interface. The goal is to verify electrical connections, communication links, and basic sensor availability.
Second, basic configuration. Developers configure the PX4-related firmware, SLAM or fused positioning module, ground station, sensor calibration, coordinate frames, and communication links. For GNSS-denied systems, coordinate-frame consistency is especially important. A small mistake may lead to unstable hovering or incorrect navigation behavior.
Third, application development. After the base system is stable, developers can build application logic around the autonomy loop: perceive, assess, decide, and execute.
Fourth, joint debugging. This stage usually takes the most time. Developers need to inspect flight logs, onboard computer logs, SLAM output, sensor timestamps, network latency, MAVLink communication, position setpoints, velocity setpoints, failsafe logic, and ground-station feedback.
Fifth, deployment and validation. Before field deployment, the system must be tested repeatedly for hovering stability, positioning continuity, indoor flight, indoor-to-outdoor transition, mapping quality, mission execution, communication reliability, failsafe behavior, payload compatibility, and long-duration stability.
For OEM or industrial UAV applications, a single demo flight is not enough. The system needs to remain stable under repeated real-world operation.
8. Web-based tools for map and system management
For GNSS-denied UAV deployment, map and positioning management can become a practical bottleneck. Field engineers may need to upload map packages, manage point-cloud maps, check positioning status, monitor sensor data, diagnose localization quality, and configure mapping parameters.
A web-based tool can reduce deployment complexity, especially for engineers who do not need to modify the full autonomy stack. This does not replace QGroundControl. It is better understood as an additional interface for managing the perception and positioning subsystem.
9. Open questions for the PX4 community
We are still exploring the best architecture for PX4-based or PX4-compatible autonomous UAV systems. I would appreciate feedback on the following questions:
1. What is the best practice for sending high-level autonomy commands to PX4 in GNSS-denied flight: position setpoints, velocity setpoints, attitude setpoints, or a hybrid approach?
2. How do developers usually handle coordinate-frame consistency between SLAM output and PX4 estimators?
3. For LiDAR, vision, IMU, and GNSS fusion, what synchronization methods have proven most reliable in field deployment?
4. Should perception and planning run on physically separated compute units, or is a single high-performance onboard computer usually enough?
5. How should indoor-to-outdoor positioning transition be handled to avoid sudden jumps in estimator output?
6. What logging and debugging tools are most useful for PX4-based autonomous systems?
7. For OEM UAV development, which parts of the autonomy stack should remain open and configurable, and which parts should be pre-integrated?
10. Reference implementation from ROBOSN
As one implementation of this architecture, ROBOSN has developed an integrated control system called FlyCore. It integrates perception, positioning, planning, and flight control into one hardware and software platform. It includes visual / LiDAR fused positioning, PX4-based low-level control, onboard planning, point-cloud map management, and application-level development interfaces.
The purpose is to reduce repeated integration work for OEMs and UAV developers, especially when building aircraft for GNSS-denied autonomous flight. However, the main intention of this post is to discuss the architecture and engineering trade-offs behind this type of system, not only the product itself.
Any feedback from PX4 developers, researchers, OEM teams, and system integrators would be very valuable.
Thanks for reading. Looking forward to your technical suggestions.