Drone autonomy and GNSS-denied navigation

Navigation when GNSS is not there

A standard autopilot relies on GNSS for position. Under a tree canopy, inside a shed, near steel structures, beneath a bridge or where there is interference, that position becomes noisy or disappears. The drone then needs another way to know where it is and how fast it is moving.

We feed other sources into the autopilot's state estimator: EKF2 in PX4 and EKF3 in ArduPilot. Both accept external position and velocity estimates, so a companion computer can supply them. The sources we use:

• Visual-inertial odometry (VIO). A camera and an IMU track features between frames to estimate motion. It works well in textured scenes and drifts slowly with distance.
• Visual or lidar SLAM. The drone builds a map as it flies and corrects drift when it recognises a place it has seen before.
• Optical flow with a rangefinder. A downward camera measures ground motion and a rangefinder gives height. It is light and simple, and suits low, slow flight over textured ground.
• Known landmarks. Fiducial markers or surveyed features give an absolute fix for landing and docking.

Each source fails in its own way. VIO struggles over still water and in poor light. Lidar struggles in open paddocks with nothing to measure against. We choose sensors for the environment, monitor estimator health in flight and define what the aircraft does when confidence drops.

Path planning and obstacle avoidance

Planning runs at two levels. A global planner works out the route: a coverage pattern for a survey, or the shortest safe path through a known map using search methods such as A* or sampling methods such as RRT* in cluttered space. A local planner reacts to what the sensors see in the moment, using a depth camera or lidar to slow, stop or steer around obstacles the map did not include.

We plan in three dimensions with margins for the aircraft's size, the wind and its stopping distance, and we smooth the path so the drone can fly it without sharp corners that waste battery.

Integration: MAVLink, ROS 2 and companion computers

Autonomy software usually runs on a companion computer next to the flight controller, such as an NVIDIA Jetson or another Linux board. It talks to the autopilot over MAVLink, the standard messaging protocol for drones, or through the uXRCE-DDS bridge that connects PX4 to ROS 2. The flight controller stays responsible for stable flight. The companion computer supplies navigation, planning and perception. If it stops responding, the autopilot falls back to a configured safe behaviour such as hold, return or land.

We build on PX4 and ArduPilot because both are open, well documented and widely used. That keeps you free to change airframes or suppliers later.

Simulation before flight

Every behaviour is tested in software-in-the-loop simulation, in Gazebo worlds built to resemble the site, before it goes near an aircraft. Hardware-in-the-loop tests then run the real flight controller and companion computer against the simulator. Only then do we fly, starting in a controlled area with a pilot ready to take over, and widening the test envelope one step at a time.

Regulation and safety

In Australia, drone operations are regulated by the Civil Aviation Safety Authority (CASA). Drones flown for business must be registered, and the operator needs an RPA operator accreditation or a remote pilot licence, depending on the aircraft and the job. Flights beyond visual line of sight or near controlled aerodromes need further approvals.

Neuralis designs and develops the autonomy software and the systems around it. Flights are carried out by appropriately licensed operators under CASA rules, and we write test plans that fit inside the approvals the operator holds.

Questions