Oden Control Pipeline overview

Last validated: 2026-05-04

Oden Control Pipeline (OCP) moves operator intent to a vehicle and brings vehicle state back to the operator station. It is the control-data companion to Oden’s video path: OdenVR reads or receives operator input, OCP routes it to the connected Oden Streamer, and the vehicle-side integration turns those commands into vehicle-specific control.

OCP is useful when you want a teleoperation control path that already understands Oden vehicles, operator stations, feedback, faults, and latency measurement. It gives you a standard place to connect the vehicle controller, a standard place to connect operator-side UI or automation, and a shared fault model for deciding when the control signal should be considered unhealthy.

OCP does not replace your vehicle safety controller. Treat OCP as the transport and observability layer for control messages; the vehicle integration should still enforce vehicle-specific limits, interlocks, emergency stop behavior, and actuator safety.

What OCP does

OCP runs as a global plugin in both Oden applications:

OdenVR / Player

The operator side discovers the connected vehicle, reads gamepad input by default, accepts optional operator-side user data, sends control messages, receives feedback, and publishes data to web views, plugins, or the player-side TCP API.

Oden Streamer

The vehicle side receives control messages from the operator, exposes them to the vehicle integration over TCP, collects vehicle responses, reports receiver faults, and embeds latency timestamps into the outgoing video stream.

The default integration is intentionally small:

  • Connect vehicle-side code to the OCP TCP server on the Streamer.

  • Read framed JSON control messages containing optional controller input, telemetry, timestamp fields, and optional operator user data.

  • Send framed JSON responses containing the timestamp fields and optional vehicle user data.

  • Optionally connect operator-side software through a web view, a custom plugin, or the player-side TCP server.

When to use OCP

Use OCP when:

  • You are building a teleoperated vehicle or robot with Oden Streamer on the vehicle and OdenVR at the operator station.

  • The operator’s gamepad should be forwarded to the vehicle with health status and latency telemetry.

  • The vehicle needs to send custom state, position, or dashboard data back to the operator.

  • A web UI, Oden plugin, or external process needs to participate in the control path.

  • You need Oden-aware faults for lost input, lost feedback, missing cameras, unavailable vehicle integration, high latency, or slow Streamer frames.

Use another path, or put a narrower bridge in front of OCP, when:

  • Your vehicle controller needs a different real-time bus or hard real-time guarantees.

  • The operator input is not part of Oden and you only need ordinary application messaging.

  • Your safety case requires an independent certified control channel.

Data paths

OCP has two main paths. Most deployments need the vehicle-side path; operator-side integration is added only when you need custom UI, custom input handling, automation, or external software at the operator station.

Vehicle-side path

The vehicle-side path connects Oden Streamer to the vehicle controller.

OdenVR input
  -> OCP operator sender
  -> Oden com channel
  -> OCP Streamer receiver
  -> vehicle-side TCP server
  -> vehicle integration / ECU bridge
  -> vehicle controller

By default, the Streamer-side TCP server listens on 127.0.0.1:4000. Set ocp_tcp_allow_remote only when the TCP client must connect from another host. Each TCP message is length-prefixed with a 4-byte little-endian size followed by UTF-8 JSON; messages larger than 16 KB are dropped.

The Streamer sends an OcpControlMessage to the TCP client. It includes:

  • controller: gamepad/controller state, or null when gamepad forwarding is disabled or unavailable.

  • telemetry: current latency, fault boolean, and fault reason string.

  • ack_time and ack_time_mac: timestamp values that must be returned unmodified.

  • client_user_data: optional operator-side user data.

The vehicle integration responds with VehicleResponseMessage. It must copy ack_time and ack_time_mac back to OCP and may include vehicle_user_data. Vehicle user data is carried back to the operator side and can contain position plus any JSON payload your dashboard or application understands.

When OCP sees an active fault on the control path, it sends default controller values to the vehicle-side TCP client. Your vehicle integration should map that default command and the telemetry fault state to the vehicle’s safe behavior.

Operator-side path

The operator-side path is optional. Use it when the operator station needs to display vehicle data, send custom data to the vehicle, choose the active vehicle, or replace OCP’s default gamepad handling.

Vehicle feedback
  -> OCP operator sender
  -> web view / plugin shared data / player-side TCP
  -> operator UI or external application
  -> optional client user data
  -> OCP operator sender
  -> vehicle-side path

OCP supports three operator-side integration points:

Web view

Receives ocp_vehicle_user_data and sends ocp_client_user_data with the Oden JavaScript SDK. Timestamp handling is automatic for web views.

Custom Oden plugin

Reads vehicle_ocp shared data and publishes client_ocp shared data.

Player-side TCP

Exposes a local TCP server on 127.0.0.1:4001 by default. It uses the same 4-byte length prefix and JSON payload style as the vehicle-side TCP server.

Only one operator-side client data source may be active in a session. The first source to send client data becomes the locked source. If another source sends data after that, OCP stops all client data communication and requires a restart. This keeps timestamp echo and control-user-data ownership unambiguous.

Vehicle discovery and active control

On the operator side, OCP needs to know which remote Streamer represents each vehicle. With the Fleet plugin active, OCP uses the fleet vehicle-name-to-UUID mapping and supports multiple vehicles. Without Fleet, OCP falls back to the scene and only supports exactly one Remote Streamer.

For multiple vehicles, operator-side data should set active_vehicle. Only the active vehicle receives gamepad input. If no active vehicle is selected while multiple vehicles are connected, OCP marks vehicle control inactive for the non-selected paths.

Fault model

OCP faults are health signals for the control pipeline. They are self-recovering: when the underlying condition clears, the fault clears.

Operator-side faults include:

  • InputLost: no expected gamepad input is available.

  • NoFeedbackMessage: the operator has not received feedback from the Streamer for more than 1000 ms.

  • VehicleControlInactive: this vehicle is not currently selected for control.

Vehicle-side faults include:

  • VehicleNoResponse: no TCP client is connected to the vehicle-side OCP server.

  • NoControlMessage: control messages from the operator are missing for more than 1000 ms.

  • CameraLost: a monitored camera has not produced a valid frame within the drop-detector timeout. The default is 200 ms, and cameras with drop detection disabled are ignored.

  • StreamerSlow: the Streamer frame loop exceeded the slow-frame threshold, currently 500 ms.

  • HighLatency: measured round-trip latency is above latency_limit.

  • OperatorStationHasError: the operator side has reported a sender fault.

  • InvalidMac: latency timestamp validation failed.

  • ControlThreadChannelSlow: OCP’s internal control queue is not being serviced quickly enough.

The important design point is that faults flow with the control message. The operator can see vehicle-side faults, the vehicle side can see operator-side faults, and the vehicle integration receives a telemetry fault flag and reason string.

Settings to know first

The Oden Control Pipeline plugin exposes the same practical settings on Streamer and Player. Most deployments can keep the defaults.

Setting Default Use

tcp_port

4000

Vehicle-side TCP server port on the Streamer.

ocp_player_tcp_port

4001

Operator-side TCP server port on OdenVR / Player when an external operator-side TCP process is used.

ocp_tcp_allow_remote

unset

Binds OCP TCP servers to 0.0.0.0 instead of 127.0.0.1. Use only when another machine must connect directly to the TCP server and the network is trusted.

latency_limit

500

Streamer-side threshold in milliseconds for the HighLatency fault. Increase it only when the measured end-to-end control path is still acceptable for the vehicle.

Latency concepts

OCP tracks two related values:

Ping latency

A lightweight Oden com-channel ping from operator to vehicle and back. This is useful for network health.

Message round-trip latency

The safety-relevant OCP timestamp loop. The vehicle side creates an ack_time and ack_time_mac, the vehicle integration returns them to OCP, OCP embeds them into outgoing video metadata, the operator side extracts and echoes them back in the next control message, and the vehicle side validates the returned value before measuring elapsed time.

The default latency_limit is 500 ms. When the measured message round trip exceeds that limit, OCP raises HighLatency. If the timestamp or MAC is not passed through unmodified, latency measurement fails and OCP raises InvalidMac / "Latency Loop Not Closed" behavior.

Because the timestamp loop follows the real control and video path, it includes more than network transit time. It can include vehicle integration processing, video transport, operator-side handling, and the return control message.

Where to go next