Hi everyone,

The question I want to discuss is direct: can a team with limited UAV development experience build a drone in about three months that can fly autonomously in GPS/GNSS-denied environments?

My current view is that it is possible, but only if the project is not treated as building everything from scratch. The key is to use a clear layered architecture: keep PX4 or the flight-control unit responsible for deterministic flight execution, and move perception, mapping, AI recognition, planning, and mission logic to the companion-computing side. FlyCore is the practical implementation case I worked with to test this idea.

1. Why flight control alone is not enough

A flight controller is very good at deterministic and safety-critical tasks: attitude estimation, stabilization, motor output, basic navigation, and failsafe handling. This layer needs predictable timing more than raw computing power.

Autonomous inspection, GNSS-denied flight, mapping, obstacle avoidance, and target recognition add a different type of workload: camera and LiDAR processing, SLAM, AI inference, path planning, and mission logic. These tasks are heavier, less deterministic, and often depend on multiple high-bandwidth sensors.

So the core conflict is simple: low-level control needs millisecond-level response, while perception and AI planning need flexible high-performance computing. Mixing both too tightly can make the system harder to debug and less predictable.

2. The layered approach used in this case

In the FlyCore implementation, the autonomy stack is divided into three layers. The goal is not to replace the flight controller, but to let each layer do the work it is best suited for.

Perception layer

Processes camera, LiDAR, IMU, GNSS/RTK and other sensor data. Runs localization, mapping, SLAM and object-recognition modules.

Decision / planning layer

Uses perception results to generate path plans, task decisions, trajectories, or setpoints.

Execution / flight-control layer

Keeps real-time flight control stable. Tracks setpoints or trajectories and handles low-level control and safety logic.

The practical rule is: PX4 or the flight-control unit should receive clean and bounded commands, not raw perception outputs. For example, the autonomy side can output position setpoints, velocity setpoints, trajectory references, or mission-level commands after filtering and safety checks.

3. Notes for PX4-based integration

For a PX4-based UAV, my preferred structure is to keep PX4 as the deterministic execution layer and place perception, mapping, recognition, and planning on the companion computer. This keeps the flight-control loop clean while still allowing advanced autonomy on the upper layer.

The companion side should also check its own output before sending commands to PX4. If localization confidence drops, if perception is delayed, or if the planner output becomes unstable, the system should stop sending aggressive commands and move into a safer mode. PX4 should still remain the final safety boundary.

4. Engineering details that matter in real flight

· Computing-power decoupling: keep real-time control on the flight-control side; keep AI inference, SLAM, and planning on higher-compute modules.

· Multi-sensor consistency: adding more sensors is not enough. Camera, LiDAR, IMU, and GNSS/RTK data must be aligned well enough for localization and planning.

· Clock synchronization: even a small timing offset can create map distortion, localization drift, obstacle-position errors, or delayed control response.

· Modular software: node-based perception and planning modules make it easier to replace algorithms, log data, replay tests, and move from simulation to real flight.

In this implementation, Prometheus is used for autonomous UAV planning and control logic, SpireCV for visual-recognition workflows, and SpireMS as a lightweight messaging layer. The exact tools are less important than the engineering principle: the autonomy stack should be modular, observable, and easy to test.

5. Validation direction

The most useful tests are not only open-area flights. For autonomy, the real pressure comes from GNSS-denied or partially observable environments: indoor spaces, narrow corridors, low-light areas, occlusion, dense forest-like scenes, and night operation.

For these scenarios, I would focus on four measurements: localization stability, perception-to-control latency, setpoint or trajectory quality, and failsafe behavior when localization or planning confidence drops

6. Questions for the PX4 community

I would be interested in hearing how other developers evaluate this three-month goal and handle these issues in real PX4 projects:

· Is three months realistic for building a GPS/GNSS-denied autonomous UAV if the team has limited UAV development experience but uses an integrated autonomy platform?

· For autonomous flight, do you prefer position setpoints, velocity setpoints, trajectory references, or mission-level commands?

· How do you measure perception-to-control latency in real flights?

· What synchronization method do you prefer when combining camera, LiDAR, IMU, and GNSS/RTK?

· If the companion computer loses localization confidence, should it enter a degraded autonomy mode first, or should PX4 immediately take over through failsafe logic?

· For GNSS-denied inspection, do you rely more on VIO, LIO, multi-sensor fusion, or another approach?

7. Conclusion

So, can this be done in three months? Based on this case, my answer is: it can be possible, but only when the system boundary is clear and the team avoids rebuilding every layer from zero.

FlyCore is one implementation case of this layered idea. The broader lesson is that a GPS/GNSS-denied autonomous UAV should be built as an integrated stack: deterministic flight control, reliable perception and localization, bounded planning outputs, and clear failsafe logic. I would like to hear how the PX4 community judges this approach and what architecture you would choose for the same three-month target.

Related Demonstration Videos

This is our recently filmed video showing the complete process of building a drone from scratch using FlyCore. Feel free to take a look if you are interested.

AI-Assisted Development of a GNSS-Denied UAV — Part 1

This three-part video series shows how AI-assisted development was used with FlyCore to rapidly build an intelligent UAV capable of stable flight in GPS/GNSS-denied environments.

AI-Assisted Development of a GNSS-Denied UAV — Part 2

The second part continues the development and testing process of the FlyCore-based autonomous UAV.

AI-Assisted Development of a GNSS-Denied UAV — Part 3

The final part presents the completed development process and flight performance in a GPS/GNSS-denied environment.

AI-Assisted FUEL Implementation on FlyCore — Part 1

This video shows how AI was used to reproduce and deploy the FUEL exploration algorithm on FlyCore, accelerating the development of an autonomous exploration UAV.

AI-Assisted FUEL Implementation on FlyCore — Part 2

This video continues the implementation and testing process, demonstrating a fast workflow for building an autonomous exploration UAV with FlyCore and the FUEL algorithm.

Contact
Email：lixinyuan@amovlab.com

Website：www.amovlab.top

WhatsApp：+86 13088068247

FlyCore Link: https://www.amovlab.top/products/flycore-uav-control-system