Architecture

​

Overview

Cyberwave is a platform infrastructure for physical AI. It connects robots, sensors, and actuators to their digital twins and provides a unified API and SDK to standardise integration across different hardware. It enables a digital-first workflow for building, testing, and deploying physical AI systems, streamlining delivery from cloud to edge and cutting the path from prototype to production.

​

System Architecture

​

System Components

​

Your Applications

This is where your code lives. Whether it’s a Python script on your laptop, an MCP-powered AI agent in your IDE, a backend service in the cloud, or automation in a CI pipeline, your application connects to Cyberwave Cloud via the REST API and Python SDK.

​

Cyberwave Cloud

The cloud layer is the central control plane of the Cyberwave platform. It provides the backend services and compute infrastructure required to manage robots, digital twins, simulations, and AI models at scale. Your applications and the edge runtime both connect to the cloud.

​

Cyberwave Edge

An edge node is a physical compute unit deployed at the periphery of the Cyberwave platform (e.g., industrial PC, embedded computer, Raspberry Pi, or similar hardware), typically co-located with one or more robots or connected devices. Edge nodes operate under strict latency, bandwidth, reliability, safety, and security constraints and are designed to function even under degraded or intermittent connectivity. For clarity: edge node refers to the physical host, and edge runtime refers to the software system executing on it. The edge runtime is a hybrid system:

• Edge Core: a central host-level service running on the node OS. It handles identity, authentication, device registration, and coordination with the cloud backend.
• Runtime Services: a set of isolated Docker containers running modular, replaceable, and vendor-isolated services (e.g., hardware drivers, inference engines, data pipelines).

This separation ensures a stable, trusted control plane while enabling flexible, swappable runtime services.

​

Robot Hardware

The physical layer consists of the robot’s hardware components:

• Sensors: cameras, LiDAR, IMUs, encoders, and other perception devices that stream data to the edge runtime.
• Actuators: motors, servos, grippers, and other effectors that receive commands from the edge runtime.
• Microcontroller: the low-level controller (e.g., Arduino, STM32) that interfaces directly with sensors and actuators over serial, I2C, SPI, or CAN bus.

​

Communication Protocols

​

Applications ↔ Cyberwave Cloud: REST API / WebSocket

Your application code communicates with the Cyberwave cloud over HTTPS REST APIs for all CRUD operations (twins, environments, workflows, assets, alerts) and WebSocket connections for real-time state updates. The Python SDK and MCP server both use these protocols under the hood. Live camera feeds use WebRTC instead, described in Video Streaming below.

​

Cyberwave Cloud ↔ Edge: MQTT / REST

The edge runtime maintains a persistent connection to the Cyberwave cloud via MQTT for real-time bidirectional messaging (telemetry, commands, state sync) and REST APIs for request-response operations (registration, pairing, config). This hybrid approach ensures low-latency streaming alongside reliable transactional operations.

​

Edge ↔ Robot Hardware: Serial / USB / ROS Topics

The edge runtime communicates with the physical robot over local interfaces: Serial (UART), USB, or ROS Topics, depending on the robot’s hardware architecture. The Cyberwave hardware driver abstracts these transport differences, exposing a unified interface to the rest of the edge stack.

​

Video Streaming (WebRTC)

Live camera feeds (teleoperation, monitoring, cameras panel) stream from the edge to the browser over WebRTC, while control commands and telemetry continue to travel over MQTT. WebRTC negotiates the most direct path available between the edge and your browser, and falls back to a relay through Cyberwave’s TURN service (turn.cyberwave.com) whenever a direct peer-to-peer connection isn’t possible, for example when the edge device sits behind a restrictive NAT or corporate firewall.

​

Connectivity requirements

Because WebRTC and TURN negotiate connections outbound, you typically don’t need to open any inbound ports on the edge network. What you do need is outbound access from the edge network (and from the operator’s browser/network) to the following:

​

Local Data Bus (Zenoh)

Alongside MQTT (used for edge ↔ cloud communication), the edge runtime uses Zenoh as a local, low-latency publish/subscribe data bus. Zenoh carries high-frequency traffic between the Edge Core and hardware drivers/workers running on the same edge node (sensor readings, joint states, inference outputs) without adding load to the cloud link. Only the data you explicitly forward is bridged out to Cyberwave Cloud over the existing MQTT connection.

​

Connectivity requirements

For a single-node deployment (the common case), Zenoh requires no firewall configuration at all. If you spread drivers across several machines on the same local network, allow TCP 7447 between those hosts.

---

​

Next Steps