|
| 1 | +--- |
| 2 | +title: "How robots talk: building distributed robots with gRPC and WebRTC" |
| 3 | +date: 2025-04-30 |
| 4 | +author: |
| 5 | + name: Joyce Lin |
| 6 | + position: Viam |
| 7 | + link: https://www.linkedin.com/in/joyce-lin/ |
| 8 | + guest: true |
| 9 | +--- |
| 10 | + |
| 11 | +If you're building any kind of distributed machine, like robots, drones, or IoT devices, two questions come up fast: |
| 12 | + |
| 13 | +- How do you send structured commands and data efficiently? |
| 14 | +- How do you keep communication resilient when you have an unreliable network? |
| 15 | + |
| 16 | +In this article, I’ll share the approach we use at [Viam](https://www.viam.com/), an open-source robotics platform that combines gRPC for structured RPCs and WebRTC for peer-to-peer streaming. Even if you're not building robots, the same architectural ideas can help you design more scalable and adaptable systems. |
| 17 | + |
| 18 | +## Bridging the gap between lab-grade robotics and real-world systems |
| 19 | + |
| 20 | +[ROS](https://en.wikipedia.org/wiki/Robot_Operating_System) (Robot Operating System) has long been the go-to framework for building and prototyping robotics systems, especially in research and academia. It works well on trusted, local networks because that’s what it was designed for. |
| 21 | + |
| 22 | +But today's robots don’t stay on tightly-regulated lab benches. They're deployed on factory floors, out at sea, or in remote fields, where network conditions are unpredictable and reliability matters. |
| 23 | + |
| 24 | +ROS doesn’t handle network communication out of the box. If you need to talk to a robot over the internet, you’re on your own to architect the solution. Modern robotics requires more than local LAN protocols. It needs cloud-ready, peer-to-peer, resilient communication stacks. |
| 25 | + |
| 26 | +Rather than relying on a distributed messaging stack like MQTT or relaying commands through the cloud, Viam uses gRPC and WebRTC to power [its robotics platform](https://docs.viam.com/#platform). Used together, these protocols offer a modern alternative that complements ROS’s strengths. gRPC provides structured, language-agnostic APIs with fast, efficient Protobuf serialization. And WebRTC adds low-latency, peer-to-peer connections, which is ideal for streaming sensor data or real-time video between machines. |
| 27 | + |
| 28 | +Some robot builders are also layering gRPC interfaces on top of ROS, blending ROS’s rich ecosystem with the modern transport and scalability of gRPC. |
| 29 | + |
| 30 | +## Why gRPC makes sense for robots |
| 31 | + |
| 32 | +Modern robots are no longer single-purpose machines in fixed environments. They're mobile, multi-part systems that need to collaborate with sensors, perception services, and control loops, often in real time. |
| 33 | + |
| 34 | +gRPC supports these needs in several key ways: |
| 35 | + |
| 36 | +- **Low-latency, real-time control**: gRPC enables continuous, bidirectional streams, allowing systems to send real-time pose updates to a robotic arm, while simultaneously receiving telemetry, without additional round-trip delays. |
| 37 | +- **Cross-platform, multi-language consistency**: gRPC automatically generates client libraries (stubs) for languages like Python, Go, C++, and others, making it easier to bridge different devices, SDKs, and environments with a consistent interface. |
| 38 | +- **Lightweight and efficient serialization**: gRPC also helps in bandwidth-constrained environments or on embedded devices, enabled by Protobuf’s lightweight binary encoding. |
| 39 | +- **Security benefits**: gRPC is designed with end-to-end encryption (TLS by default) and authentication capabilities baked in, ensuring secure communication between machine parts, whether across local networks or the public internet, without requiring developers to bolt on separate security layers. |
| 40 | +- **Service abstraction for machine parts**: With gRPC and Protobuf, every part of a robot, from motors to cameras to sensors, can be modeled as a standardized, language-agnostic service. |
| 41 | +  |
| 42 | + |
| 43 | +In [Viam’s public API](https://github.com/viamrobotics/api), each robot component is defined as a gRPC service using Protobuf. Components like arms, cameras, and sensors expose typed methods that can be called remotely. Here's an excerpt from the [`arm.proto`](https://github.com/viamrobotics/api/blob/main/proto/viam/component/arm/v1/arm.proto) file that defines basic movement and pose retrieval methods for a robotic arm: |
| 44 | + |
| 45 | +```proto |
| 46 | +// An ArmService services all arms associated with a robot |
| 47 | +service ArmService { |
| 48 | + rpc MoveToPosition (MoveToPositionRequest) returns (MoveToPositionResponse); |
| 49 | + rpc GetEndPosition (GetEndPositionRequest) returns (GetEndPositionResponse); |
| 50 | + rpc GetJointPositions(GetJointPositionsRequest) returns (GetJointPositionsResponse); |
| 51 | +} |
| 52 | +``` |
| 53 | + |
| 54 | +These proto services can then generate [SDKs](https://docs.viam.com/dev/reference/sdks/) to help you work with your machines. This example uses the Python SDK to move an arm. Under the hood, gRPC handles encoding the command into a Protobuf message and sending it over HTTP/2 (or WebRTC, depending on the environment). |
| 55 | + |
| 56 | +```python |
| 57 | +from viam.components.arm import ArmClient |
| 58 | + |
| 59 | +arm = ArmClient.from_robot(robot=robot, name="my-arm") |
| 60 | + |
| 61 | +# Move the arm to a target 3D position |
| 62 | +arm.move_to_position(x=0.1, y=0.2, z=0.3, orientation=None, world_state=None) |
| 63 | +``` |
| 64 | + |
| 65 | +## Why WebRTC is also part of the picture |
| 66 | + |
| 67 | +At first glance, gRPC and WebRTC might seem redundant. Both can stream data and send structured messages. But they solve very different challenges in robotics. |
| 68 | + |
| 69 | +WebRTC excels at direct, peer-to-peer connections, which is essential when: |
| 70 | + |
| 71 | +- Devices are on local networks or constrained by NAT/firewalls |
| 72 | +- You want to bypass a central relay or cloud server |
| 73 | +- You’re streaming high-bandwidth sensor data (like real-time video or LIDAR) between machines |
| 74 | + |
| 75 | +Viam uses gRPC for orchestration and WebRTC as the underlying transport, combining them for fast, structured messaging with minimal routing overhead. |
| 76 | + |
| 77 | +## Flexible transport layers with gRPC |
| 78 | + |
| 79 | +While WebRTC enables peer-to-peer communication in distributed machines, gRPC also offers flexibility to swap underlying transport layers. |
| 80 | + |
| 81 | +Here is [an example gRPC server that runs over WebRTC and other transport protocols](https://github.com/viamrobotics/goutils/tree/main/rpc/examples/echo). Viam also uses Unix domain sockets (UDS) for local messaging between the `viam-server` and internal modules, Bluetooth for provisioning machines or proxying network traffic, and serial ports for embedded peripherals. |
| 82 | + |
| 83 | +Because gRPC defines a consistent interface at the API layer, we can change the transport depending on the environment or device without rewriting client logic, a huge strength when building systems that span cloud, local, and constrained networks. |
| 84 | + |
| 85 | +## A real-world example: coordinating a claw game |
| 86 | + |
| 87 | +Picture a remote-controlled claw machine, like the ones you'd find in an arcade. It has two main components: a camera and a robotic arm. A user interface, such as a [web app](https://docs.viam.com/dev/reference/sdks/#frontend-sdks) or [mobile app](https://docs.viam.com/dev/reference/sdks/#mobile-sdk), sends control commands and receives a live video stream to help guide the claw to its prize. |
| 88 | + |
| 89 | + |
| 90 | + |
| 91 | +Here's how gRPC and WebRTC work together behind the scenes: |
| 92 | + |
| 93 | +- **Initialization**: The system establishes control channels using gRPC over HTTP/2. Each component registers its services (e.g. `ArmService`, `CameraService`). |
| 94 | +- **Connection**: gRPC coordinates the exchange of peer metadata and signaling to set up a WebRTC session between the SDK and machine parts. |
| 95 | +- **Real-time operation**: WebRTC now handles the media and data streams directly between peers. Commands are sent using gRPC method calls, routed over the WebRTC transport. Video and sensor streams flow the other way. |
| 96 | + |
| 97 | + |
| 98 | + |
| 99 | +This dual-protocol approach allows real-time interaction, smooth streaming, and resilient fallback behavior, even in unpredictable network conditions. |
| 100 | + |
| 101 | +## Why this pattern matters for the broader community |
| 102 | + |
| 103 | +The combination of gRPC’s structure and WebRTC’s flexibility opens the door to a new class of distributed systems, not just in robotics, but anywhere you need: |
| 104 | + |
| 105 | +- Real-time, bi-directional communication between loosely-coupled systems |
| 106 | +- Typed, versioned APIs that span languages and devices |
| 107 | +- Transport-agnostic flexibility, with the option to go peer-to-peer when needed |
| 108 | + |
| 109 | +gRPC structures the conversation. WebRTC carries it across the network. |
| 110 | + |
| 111 | +## Viam for real-time robot control |
| 112 | + |
| 113 | +gRPC has evolved far beyond simple request/response APIs. Across many industries beyond robotics, the way machines communicate is more critical than ever. gRPC and WebRTC aren’t just faster protocols, they’re influential building blocks for the next generation of distributed, resilient, and intelligent machines. |
| 114 | + |
| 115 | +If you’re building systems that need to talk to each other across devices, environments, and networks, it might be time to explore a more scalable and adaptable communication layer. |
| 116 | + |
| 117 | +While you could engineer a similar stack on your own, [Viam](https://www.viam.com/) offers these capabilities out of the box. The on-machine functionality is open-source and free to operate, with optional cloud services available on a usage-based model when you scale to fleets. |
| 118 | + |
| 119 | +_Technical review by [Nick Hehr](https://www.linkedin.com/in/nick-hehr/) (Viam)_ |
0 commit comments