Challenge 4: UAV GNSS-Denied Navigation

1. Problem statement

A multicopter must fly a mission indoors or in an urban canyon with no usable GNSS. The deliverable is a sensor, compute and estimation architecture, a calibration and synchronisation plan, a failsafe design and a validation plan with flight-test evidence.

2. Constraints

• Weight, power and vibration limit the sensors and the computer; the flight time budget includes them.
• The flight controller owns stabilisation; the companion computer supplies pose or velocity estimates and must not be able to crash the aircraft by failing.
• Time synchronisation between camera, LiDAR, IMU and flight controller is measured, not assumed.
• The failsafe for loss of the estimate (hold, land, return) is defined and tested.
• Propeller vibration must be isolated from the IMU and the camera.
• Flight tests follow a written plan with abort criteria and a safety pilot.

3. Architecture

camera ─┐
LiDAR ──┼─▶ VIO / LIO on the companion computer ─▶ pose and velocity ─▶ flight controller (EKF) ─▶ motors
IMU ────┘                                                                ▲
                                                  health monitor ─▶ failsafe (hold, land, return)

4. Implementation stages

1. Requirements and ODD. Environment, light, structure, speeds, mission length (defining the operational design domain).
2. Estimator choice. Compare VIO and LIO for your ODD (comparing vio and lio, vio or lidar slam choosing by environment and payload).
3. Sensors and compute. Select from the sensor guides and size the computer (estimating sensor data throughput and memory, allocating workloads to cpu and gpu).
4. IMU and noise. Configure the IMU and obtain noise parameters (configuring an imu for vio, obtaining imu noise parameters).
5. Calibration and time. Camera–IMU and LiDAR–IMU calibration and time offsets (diagnosing camera imu calibration and time offset, validating lidar imu calibration, hardware vs software time synchronization).
6. Initialisation and recovery. Excitation, divergence detection and recovery (initialization failure and recovery).
7. Failure handling. Failure detection, watchdogs and safe states (sensor and localization failure detection, implementing watchdogs and health monitoring).
8. Validation. Drift against a reference, failsafe drills and a flight-test plan (preparing a field test).

5. Validation criteria

• Drift over closed-loop flights is below the requirement in the ODD’s worst lighting and structure.
• Injected failures (covered camera, disconnected LiDAR, IMU dropout) produce the defined failsafe every time in simulation first, then in flight.
• Time offsets are measured and stay within tolerance across power cycles.
• A flight-test plan with a safety pilot and abort criteria exists before the first flight.

6. Engineering trade-offs

• VIO vs LIO: light and power against geometry and weight.
• Companion computer vs onboard flight controller processing: compute against isolation.
• More redundancy (two IMUs, two estimators) against weight and complexity.
• Conservative failsafe (land immediately) against mission completion.

References

• Tools and guides for this challenge are linked in the stages; their sources are cited on those pages. This challenge is a design task: flight regulations and flight-controller specifics (for example PX4 or ArduPilot interfaces) are not covered by sources read for this site and must be taken from their own documentation.