Documentation

Connect a robot fleet remotely: ROS 2, AGVs and AMRs

A robot fleet rarely gets deployed on a friendly network: AMRs at customer sites behind a 4G carrier’s CGNAT, AGVs on a segmented industrial Wi-Fi, drones on sites with no IT at all. Remote robot access — supervising, updating, pulling telemetry — then becomes a project of its own. VIGIL-MESH puts every robot on the same logical local network as your engineering workstations: ROS 2 discovers across sites, the console shows the fleet in real time, and an SSH terminal opens right in the browser.

The field: robots unreachable by construction

A robot in production is almost never reachable from the outside. It sits behind a carrier’s 4G — hence CGNAT, no public address —, on a factory’s segmented industrial Wi-Fi, or on a customer network where nobody will open a port for you.

The AMR at the customer site

Shipped with its 4G router, it lives behind CGNAT: no inbound connection is possible — port forwarding does not even exist there —, and the customer’s IT will not touch its firewall.

The AGV in the factory

The industrial Wi-Fi is segmented into VLANs, filtered or cut off from the internet; the robotics team has no control over the factory network.

The drone, the construction machine

Temporary sites, 4G/5G or Starlink uplinks, zero IT infrastructure on location — and yet telemetry and video to bring back.

ROS 2 and DDS need multicast: the mesh carries it

DDS, the middleware under ROS 2, discovers its participants over UDP multicast: no multicast, no discovery — and no discovery, no graph. That is what makes multi-site ROS 2 so painful over a classic VPN: multicast does not cross. VIGIL-MESH replicates IP multicast across the mesh: DDS discovery works between sites as on a LAN, and the ROS 2 nodes at headquarters see the topics of a robot deployed on the other side of the country.

How multicast works inside the mesh (groups, scope, storm control) is detailed in Advanced multicast.
The full robotics picture — end-to-end datagrams, real-time priorities, MAVLink — is on the Robotics and ROS 2 page.

Managing the fleet: enroll at the factory, supervise, intervene

A fleet cannot be managed robot by robot, by hand. Key-based enrollment fits into production: the key is baked into the disk image at the factory, and every robot joins the network on its first connected boot — no on-site operation.

Enrollment wizard of the console: generating an enrollment key to bake into the robots’ disk image. — The enrollment wizard generates the key the factory bakes into the image: the robot joins the network on first boot.

Real-time topology in the console: which robots are online, from which site, over which path.
Real-time telemetry and video: end-to-end datagrams, with no TCP head-of-line blocking on the data path.
Updates and debugging through an SSH terminal in the browser, without a VPN or a bastion — see SSH terminal in the browser.
Identity-based ACLs: the support team reaches every robot, the robot only reaches what it needs, and the end customer’s network stays out of reach.
The agent runs on NVIDIA Jetson, Linux, Windows and Android; the supervision workstation can be nothing more than a browser (WASM).

SSH terminal of the console: connecting to a machine of the network from the browser. — An SSH terminal opens on the robot from the console — to read a log, restart a ROS 2 node or push an update.

Concrete case: the AMR deployed at the customer site is unreachable

The AMR ships to the customer with its 4G router. The mobile carrier does CGNAT: no public address, no inbound connection possible — port forwarding does not even exist. On the customer side, IT will open neither a port nor a VPN into its network.

The result: at the first incident, a technician has to travel on site for a problem that ten minutes of SSH would solve — and the fleet grows faster than the support team.

Teleoperation: what you should know

For teleoperation, the mesh establishes a direct path as soon as possible and only adds one layer of encryption to the network trip; until the direct path is up, traffic goes through a blind vigie relay. Real-time datagrams are strictly prioritized over service flows.

Frequently asked questions

Do I need a SIM card with a public IP for each robot?

No. The robot makes all its connections outward: a consumer 4G SIM behind CGNAT is enough. That is precisely the case the mesh is designed to traverse.

Does ROS 2 discovery really work between two sites?

IP multicast is replicated across the mesh, so DDS discovery crosses as on a LAN. Formal ROS 2 validation is on the roadmap — we do not claim it as demonstrated yet.

What latency should I expect for teleoperation?

We do not promise a figure: on a direct path, the mesh adds one layer of encryption to the network trip, and the real latency mostly depends on the robot’s radio link (4G, industrial Wi-Fi). Measure on your own link before any critical use.

How do I enroll fifty robots without clicking fifty times?

With an enrollment key baked into the disk image at the factory: every robot joins the network on its first connected boot. The key is managed from the console, and every machine’s arrival is visible there.

Which platforms on the robot side?

Linux and NVIDIA Jetson on the robot side; Windows, Android and the browser (WASM) for supervision. The teleoperation workstation can be nothing more than a browser tab.