Video & OSD Architecture

Executive Summary

The On-Screen Display (OSD) overlays flight data onto the FPV video feed. ArduPilot supports both legacy Analog OSDs (MAX7456 chips) and modern Digital OSDs (DJI, Walksnail, HDZero). It uses a unified "Panel" architecture, where you arrange items (Altitude, Battery, Horizon) on a grid, and the backend translates that grid to the specific hardware protocol.

Theory & Concepts

1. The Character Grid

Unlike a modern smartphone screen which draws pixels, OSDs are character-based.

• The Grid: Typically 30 columns x 16 rows.
• The Font: Icons (like a battery symbol) are just special characters in a custom font file (font.bin).
• Limitations: You cannot draw a smooth line or a circle. You can only place a pre-drawn character in a grid cell.

2. Analog Video (V-Blank)

Analog OSD chips (MAX7456) overlay white pixels onto the NTSC/PAL signal.

• SPI Bus: The flight controller sends the character map to the OSD chip over SPI.
• Timing: The chip must sync with the video signal's Vertical Blanking Interval (V-Blank) to update the screen without tearing.

Architecture (The Engineer's View)

1. The OSD Thread

Rendering text is slow. To prevent it from blocking the main 400Hz flight loop, AP_OSD runs in its own thread.

• Rate: 10Hz (approx 100ms per frame).
• Logic:
  1. Calculates values (e.g., "Alt: 100m").
  2. Writes string to the backend buffer.
  3. Calls flush() to send the buffer to the hardware.
  • Code Path: AP_OSD::osd_thread().

2. Backend Abstraction

• Analog: AP_OSD_MAX7456. Writes to SPI. Optimizes bandwidth by only updating "Dirty" characters (chars that changed since last frame).
• Digital: AP_OSD_MSP_DisplayPort. Wraps the grid commands into MAVLink/MSP serial packets for the DJI/Walksnail unit to render locally.

Key Parameters

Parameter	Default	Description
OSD_TYPE	1	1=MAX7456 (Analog), 5=MSP_DisplayPort (Digital).
OSD_CHAN	0	The specific screen to display (Screen 1, 2, 3, 4).

Source Code Reference

• Thread Runner: AP_OSD::osd_thread()

Client-Side Rendering (MAVLink HUD)

The architecture described above relies on the Flight Controller (STM32) to generate the video overlay. This consumes CPU cycles and limits graphical fidelity.

MAVLink HUD inverts this model:

1. Raw Data: The Flight Controller sends raw telemetry values (not video pixels) via MAVLink.
2. GPU Rendering: The Android device uses its powerful GPU to render smooth, high-fidelity instruments.
3. Display: The result is output via USB-C to Supported AR Glasses, creating an infinite-resolution overlay.