Start here: UNIVIP in diagramsLink to the section Start here: UNIVIP in diagrams

On this page

UNIVIP is a shared interface between a compatible uncrewed vehicle and a video management system (VMS). It brings the vehicle's video, location, health and events into the same operator workspace. Optional camera and vehicle controls use separate permissions.

This is an introduction to the v0.2 working draft. The draft defines aerial conformance tests; underwater, surface and ground domains remain reserved. The linked specification contains the exact requirements.

Choose a starting pointLink to the section Choose a starting point

To try the reference software first, run the simulator.

The three piecesLink to the section The three pieces

How a vehicle reaches a VMS

A UNIVIP Device adapts a vehicle's native interface. Video, telemetry and events go to the VMS. Authorized commands return through the device and the vehicle controller's checks.

View Mermaid source
flowchart TB
    accTitle: How a vehicle reaches a VMS
    accDescr: A UNIVIP Device adapts a vehicle's native interface. Video, telemetry and events go to the VMS. Authorized commands return through the device and the vehicle controller's checks.
    V["Vehicle and camera"] -->|Native interface| D["UNIVIP Device"]
    D -->|Video, telemetry and events| M["VMS / UNIVIP Client"]
    M -->|Authorized commands| D
    D -->|Controller checks apply| V

The Device is the software that speaks UNIVIP. It can run in vehicle or dock firmware, in a controller app, or in a gateway server. The diagram's device box describes a software role; it does not require an extra appliance.

The Client is the receiving software: a compatible VMS, command platform or recorder. An existing VMS needs UNIVIP support or an integration built against the protocol.

See Architecture and deployment modes for the three transport planes.

Choose what the operator can doLink to the section Choose what the operator can do

Profile In plain language Does it move the vehicle?
S — Surveillance and Streaming View video, follow position and health, receive events, preserve telemetry for replay No
C — Camera and Payload Control Everything in S, plus advertised camera and payload controls such as zoom or gimbal pointing No
N — Navigation and Vehicle Control Everything in S, plus separately authorized vehicle tasking Yes, within the advertised commands, permissions, leases and safety checks

C and N independently extend S. A vehicle can support S + N without supporting C. A device offering both camera and vehicle control claims both profiles. Profile names describe sets of requirements; they are not a claim that a particular product has passed conformance testing.

See the profile dependency diagram and feature matrix.

Connect, describe, then streamLink to the section Connect, describe, then stream

  1. Configure the endpoint. The operator gives the Device the Client's endpoint and credentials.
  2. Connect securely. The Device initiates the authenticated session. The Client does not need an unsolicited inbound connection to the vehicle.
  3. Introduce the device. The Device sends hello; the Client answers welcome. The Device checks the Client's identity and then publishes its capabilities.
  4. Show what is available. Telemetry and events begin. The Client negotiates the advertised video stream and offers only supported controls.

The connection sequence diagram shows the message order. Media streaming defines video negotiation and time synchronization.

Follow an exampleLink to the section Follow an example

The alarm inspection example walks through viewing a vehicle, receiving a low-battery event, pointing a camera and requesting return home. It includes a chart drawn from an example telemetry message.

Use Concepts and profiles for the vocabulary, or Build for the runnable setup and integration paths.

Generated from docs/start-here.md.