Drone and robotic automation and research

The autonomy stack

An autonomy stack is a set of layers that fail independently, so we design each with its own contract: drivers and hardware abstraction; perception from cameras, lidar, radar and depth sensors with hardware-triggered time synchronisation; state estimation; mapping; global and local planning; control; behaviour logic, typically behaviour trees; and mission or fleet management on top.

We build on ROS 2, which runs over DDS. Quality-of-service settings matter more than most teams expect: best-effort, shallow-history topics for high-rate sensor data over wireless links, reliable transport for commands and state, and intra-process zero-copy for large point clouds. Hard real-time loops stay on the flight controller or a microcontroller running micro-ROS, never on a general-purpose executor.

Aerial platforms: PX4, ArduPilot and MAVLink

The flight controller owns stabilisation and failsafes. A companion computer such as an NVIDIA Jetson supplies navigation, perception and planning through MAVLink or the uXRCE-DDS bridge that connects PX4 to ROS 2. Offboard control is always bounded by autopilot-side protections: geofences, link-loss and companion-loss actions, battery reserves and return or land behaviours that are configured and tested, not left at defaults. ArduPilot gives the same pattern with its EKF3 estimator and a wide range of vehicle types.

GNSS-denied navigation

Under canopy, indoors, near steel structures or under jamming, GNSS position degrades or disappears. We feed alternative sources into the estimator:

• Visual-inertial odometry. Feature tracking fused with IMU preintegration gives low-drift relative motion in textured scenes.
• Visual and lidar SLAM. Factor-graph smoothing with loop closure corrects accumulated drift when the vehicle recognises a place it has seen.
• Optical flow and rangefinders. Light and simple, for low, slow flight over textured ground.
• Absolute fixes. Fiducial markers, surveyed features or terrain matching against an elevation model to bound drift over long missions.

Each source has a known failure mode: VIO over still water or in darkness, lidar in open paddocks with nothing to range against. Estimator health is monitored in flight, with a defined degraded mode when confidence drops.

Perception

Perception turns sensor data into the map the planner trusts: obstacle detection and semantic segmentation, monocular or stereo depth, and volumetric occupancy maps updated in real time. Radar is fused where dust, smoke or spray blind cameras and lidar. Calibration is treated as an engineering deliverable, covering intrinsics, extrinsics and time offsets between sensors, because a few milliseconds of misalignment at speed moves an obstacle by centimetres. Models are quantised for the onboard compute, as described on our sovereign AI page.

Path planning and control

Global planners find routes: A* and D* Lite on grids, sampling-based RRT* in cluttered or high-dimensional spaces, state-lattice planners that respect a ground vehicle's turning radius, and coverage patterns for survey. Trajectory generation then produces something the vehicle can actually fly or drive, such as minimum-snap polynomials for multirotors. Model predictive control tracks the trajectory while enforcing actuator limits and obstacle constraints over a receding horizon, and safety filters based on control barrier functions can override any command that would breach a safety margin.

Swarm and multi-agent coordination

Several vehicles on one task need to divide it, share what they learn and stay out of each other's way. We use market-based and consensus-based task allocation so assignments survive the loss of any single agent, decentralised mapping with map merging when agents meet, and deconfliction in space and time. Planning is communication-aware: agents keep within range of the mesh, or plan rendezvous to exchange data when they cannot, using the radio design on our long-range comms page. The fleet degrades gracefully as agents drop out rather than failing as a whole.

Ground robots and manipulation

For wheeled and tracked UGVs we build on Nav2, with traversability estimated from lidar elevation maps, slip estimation on loose ground and recovery behaviours when the robot gets stuck. Manipulation uses MoveIt 2 for motion planning, grasp planning from depth data, visual servoing for final alignment and force-torque control for contact tasks. Agricultural and industrial settings add mud, glare and people, so speed limits, protective stops and safe zones are designed in from the start. See our agritech page for farm applications and our mining page for teleremote and autonomy retrofits on mobile plant and drone survey of pits and stockpiles.

Sim-to-real

Every behaviour is developed in simulation first, in Gazebo or NVIDIA Isaac Sim, with domain randomisation of lighting, textures and sensor noise so models do not overfit to a clean virtual world. System identification fits the vehicle's real dynamics into the simulator. Software-in-the-loop comes first, then hardware-in-the-loop with the real flight controller and companion computer, then staged field trials from a controlled area outward. Every run is logged in MCAP, and recorded logs become regression tests that run on each code change.

Research collaborations

Neuralis is a registered Research Service Provider under Australia's R&D Tax Incentive, and much robotics work is experimental by nature: the outcome cannot be known in advance and has to be found by systematic trial. We welcome research collaborations with companies, universities and government on navigation without GNSS, multi-agent autonomy, edge perception and sim-to-real transfer. Whether a given project qualifies for the incentive is a matter for the R&D entity and its adviser.

Regulation and safety

Questions