GodwitNavSOLUTIONS

Autonomy

A research drone designed to fly on if its computer fails.

We are building an autonomous UAS platform to carry our methods from paper onto real aircraft. It is at an early stage: the software foundation runs in simulation, and hardware bring-up of the first airframe has begun. It has not flown.

One design rule

The drone must always be flyable and safe with the companion computer dead.

That is a requirement the design is built around, not yet a demonstrated result. ArduPilot on the flight controller owns everything safety-critical: stabilization, failsafes, geofence, and return-to-launch. The NVIDIA Jetson is advisory. It plans, perceives, logs, and sends commands through MAVLink guided mode, but it never bypasses a flight-controller failsafe.

Powering the Jetson off in flight is an exit test for milestone M2 and has not been run yet.

Platform architecture A Jetson Orin Nano companion computer running ROS 2 exchanges guided-mode commands and telemetry with a Pixhawk 6C flight controller running ArduPilot over MAVLink. The RC receiver and Remote ID connect to the flight controller, which drives the motors. The design intent is that flight control continues if the Jetson fails; this has not yet been flight-tested. Jetson Orin Nano Companion computer · advisory ROS 2 Humble mission state machine health watchdog telemetry and logging perception (later milestones) Pixhawk 6C Flight controller · authority ArduPilot stabilization failsafes and geofence return-to-launch manual RC flight guided commands telemetry MAVLink / MAVROS RC receiver Remote ID If the Jetson fails flight control stays with ArduPilot. Design intent; flight test planned for M2.
Intended architecture, drawn from the project’s design documents. The airframe is a Holybro X500 V2.

Milestones

One new capability per milestone, and each one flies before the next begins. Where the platform actually stands:

  1. M0
    Foundations

    ArduPilot software-in-the-loop simulation in Docker, ROS 2 and MAVROS on the workstation and the Jetson, and a waypoint mission flown in simulation. Continuous integration builds the code, runs the tests, and flies the simulated mission on every change.

    Complete
  2. M1
    Airframe and manual flight

    Most components are received, and hardware bring-up began in late August 2026 with the RC receiver and Remote ID. Exit criteria: ten uneventful battery cycles on RC only, a tuned parameter file, and failsafes validated on the bench and in flight. It has not flown yet.

    In progress
  3. M2
    Autonomous GPS mission

    The Jetson commands and monitors a full outdoor waypoint mission, including a test where it is powered off mid-flight and the flight controller must return home unaffected.

    Planned
  4. M3
    GPS-denied position hold

    Optical flow and a downward rangefinder fused into the flight controller’s estimator, with a controlled in-flight transition when GPS is lost.

    Planned
  5. M4
    Obstacle detection

    A depth camera on the Jetson that brakes the aircraft before an obstacle, then simple bypass.

    Planned
  6. M5
    Indoor autonomy

    Visual-inertial odometry feeding the flight controller for guided flight without GPS.

    Planned
  7. M6
    Mission products and hardening

    An end-to-end demonstration mission, MAVLink signing and other security hardening, and requirements traceability.

    Planned

What came before

Closed

The platform follows an earlier prototype: a custom flight controller on an ESP32-S3 with its own sensor fusion (a complementary filter for attitude, a Kalman filter for altitude from barometer and IMU), a time-of-flight rangefinder, and a parametric 3D-printed frame. It never reached stable free flight, and we closed it in favor of proven flight-control software. What it taught us went straight into the new design:

  • Motor and battery current corrupts an onboard magnetometer, so the compass now sits on a GPS mast away from power wiring.
  • Axis alignment between the IMU and magnetometer is easy to get plausibly wrong; heading is now checked for tilt-invariance.
  • Prop wash and sunlight both corrupt barometric altitude.
  • Some I²C sensors stall the bus, so UART sensors are preferred where available.
  • Gyro bias drifts with temperature, so it is estimated in flight rather than only at boot.

The magnetometer calibration tooling from that project was carried forward into the new platform.

Interested in this work?

We are open to teaming on autonomy and deconfliction research where our analytic methods and verification discipline are useful.

Email info@godwitnavsolutions.com