​

HDMI Kiosk Mode

Plug a monitor and a gamepad into the ground station SBC. The agent launches Chromium in kiosk mode, rendering the Mission Control HUD route at full screen. You get video, telemetry overlays, and stick control without a laptop, phone, or internet connection.

​

What you need

• Micro-HDMI to HDMI cable (Pi 4B uses micro-HDMI)
• Any HDMI monitor or display (7” field monitors work well)
• USB or Bluetooth gamepad (Logitech F310, Xbox, PS4, PS5, 8BitDo)

The agent serves the cockpit itself, on its own HTTP surface. Nothing else needs installing for the panel to work.

​

How it works

When a display is connected, the kiosk path comes up. The DRM node is not assumed to be card0: the service scans every card for a connected connector, because on a Pi 4 the render node and the display are different cards, and it waits for one to appear rather than checking once (the driver probes asynchronously, so a one-shot check loses the boot race).

1. The agent serves the cockpit at http://localhost:8080/cockpit/ — a light single-page app served by the agent’s own front. The kiosk waits for that URL to answer before launching, so the panel never lands on an error page it will not retry from.
2. ados-kiosk launches Chromium pointed at it, either inside the cage Wayland compositor (when the board has no desktop, the appliance case) or as a fullscreen window inside a running desktop session (cage needs the DRM master, which a running compositor already holds).
3. Chromium renders it fullscreen, with no address bar, no tabs, no browser chrome. Its profile and cache are kept in a RAM-backed directory with a bounded cache, so a panel running for months does not wear out the card.

The display chain runs locally on the SBC. No network traffic, no external server. Video from the radio link flows through MediaMTX (ados-mediamtx-gs) on localhost. Telemetry comes from the local MAVLink WebSocket.

​

The cockpit layout

The cockpit is a flight view designed for a small fullscreen panel:

• Full-frame video background (WebRTC from the local MediaMTX)
• Top bar: link RSSI, flight mode, battery percentage, altitude, speed, GPS satellite count
• Bottom bar: crosshair, artificial horizon, heading tape
• Corner alerts: failsafe indicators, home distance, connection health
• No menus, no maps, no multi-drone fleet views

This is the pilot-in-command view. For mission planning and fleet management, use a laptop connected over WiFi or USB.

​

Performance on Pi 4B

​

Gamepad input

The Web Gamepad API in Chromium handles controller mapping. USB gamepads work immediately. Bluetooth gamepads need to be paired first. To pair a Bluetooth gamepad:

1. Put the controller in pairing mode
2. Use the OLED menu: navigate to Network > Bluetooth > Scan
3. Select the controller from the list
4. Press B3 (Select) to confirm

Or pair through the setup webapp Display page from your phone. Once paired, the gamepad sends stick inputs at 50 Hz through the existing MANUAL_CONTROL MAVLink message path. The same code that handles gamepad input in the browser on your laptop handles it here.

​

Pilot-in-command (PIC)

When the kiosk starts and a gamepad is connected, the kiosk automatically claims PIC. If a laptop or phone also connects, they are observers until PIC is explicitly transferred. PIC transfer is done through:

• The ground-station panel in Mission Control on a connected laptop (click “Take Control”)
• The OLED menu (B3 long-press to release PIC)

If the kiosk client disconnects (monitor unplugged, gamepad dies), PIC auto-transfers to the next connected client with an active gamepad. If no client has a gamepad, the agent sends failsafe intent to the flight controller (hover or RTL, depending on FC configuration).

​

Display settings

You can configure HDMI output from three places:

• OLED menu: Display > HDMI Resolution
• Setup webapp: Display page
• Mission Control: ground-station panel > Physical UI tab

Available settings:

• Resolution (auto-detect, 720p, 1080p)
• Refresh rate (30 Hz, 60 Hz)
• OLED brightness and auto-dim

​

Booting into kiosk

The kiosk service uses cage as a minimal Wayland compositor. cage is designed for single-application kiosk use. It starts only when:

1. A display output is detected (/dev/dri/card0 exists)
2. The ground-station profile is active
3. The local Mission Control build is available

If any of these conditions are not met, the kiosk service does not start. The OLED and WiFi AP still work normally.

​

Graceful degradation

​

What is next

• Physical UI for the OLED and button system
• WiFi AP to add laptop observers while flying on HDMI
• Setup and Pairing for the first-time walkthrough