Skip to content

Architecture

Rover Nexus links your robot software to the cloud through an on-robot agent and two message hops.

The three layers

  ┌────────────────────┐   local Zenoh    ┌──────────────┐       mTLS       ┌───────────────┐
  │  Robot software    │  Cap'n Proto     │  rover-agent │   (Cap'n Proto)  │  Rover Nexus  │
  │  (native, ROS 2,   │ <──────────────> │  (on robot)  │ <──────────────> │     cloud     │
  │   or copper-rs)    │                  │              │                  │               │
  └────────────────────┘                  └──────────────┘                  └───────────────┘
  1. Robot software: your controller (native, ROS 2, or copper-rs). It exchanges messages with the agent over a local Zenoh bus using Cap'n Proto serialization, or over a Unix domain socket carrying the same messages.
  2. rover-agent: runs on the robot's Linux host. It ingests local messages, maintains robot state, and relays to/from the cloud. It also serves local request/reply queries (features, field rules, settings).
  3. Rover Nexus cloud: the fleet backend. The agent connects to it over mTLS (also Cap'n Proto).

Local transport. The robot-software ↔ agent hop runs over local Zenoh by default, or a Unix domain socket on the same host, selected by agent configuration. Both carry byte-for-byte identical Cap'n Proto messages, so the rest of this picture is unchanged either way.

Message flow

  • Uplink (robot → cloud): robot software publishes telemetry, faults/events, objects, and mission feedback to local Zenoh. The agent serializes and relays them to the cloud (rate-limited per message type).
  • Downlink (cloud → robot): the cloud sends mission commands, teleop, mode/velocity commands, settings, and field rules. The agent receives them, persists assets it needs (missions, features, objects, settings), and republishes commands on the local hop for the robot software (or the ROS 2 Bridge or Copper Bridge) to act on.

The agent also bridges geometry between the cloud's WGS84 frame and your robot's local ENU frame in both directions. See Coordinate Frames.

Topic contract

At a glance, robot software publishes uplink messages under the local robot/** key space (e.g. robot/telemetry/motion) and subscribes to downlink commands on command. These local keys do not include the robot id; the agent adds the robot's identity when it relays to and from the cloud. Local robot-software topics also include queryables (request/reply) such as feature and field-rule get-bulk lookups and settings queries.

See Zenoh for the full topic-contract table and the queryables list. It is the canonical reference for the local contract.

ROS 2 robots

ROS 2 robots do not change this picture. rover_ros2_bridge translates ROS 2 (DDS) topics to and from the same Cap'n Proto messages over a Unix domain socket, so the agent still sees one local ingest path. See the ROS 2 Bridge.

copper-rs robots

copper-rs robots also leave this picture unchanged. rovernexus-cu-components provides NexusBridge, a Copper bridge component compiled into your graph. It maps Copper pins to and from the same Cap'n Proto messages over local Zenoh. See the Copper Bridge.

Persistence and scheduling

The agent keeps a local store of assets it needs to operate offline and recover state (missions, features/routes, objects, and settings), and includes a one-shot mission scheduler that fires scheduled missions when due.

Next steps