Mesh network

Mesh network – definition

A mesh network is a communication network in which nodes can relay traffic for other nodes. Unlike a star topology, where every device depends on one access point or central router, a mesh topology can provide several paths between a mobile robot, a base station, and other networked devices.

In mobile robotics, a mesh network is used to maintain data exchange when a UGV operates beyond the direct range of a single wireless access point or when obstacles attenuate the radio signal. A node may act as an endpoint, a relay, or both. The network can select or update routes when a link becomes unavailable.

For Leo Rover and Raph Rover deployments, a mesh network is primarily a field communication layer. It can carry ROS 2 traffic, telemetry, remote-operation video, map updates, and diagnostics between the rover and an operator station. It does not provide autonomy by itself. Navigation, perception, localization, and safety logic must continue to operate correctly when connectivity is degraded or lost.

Mesh topology in UGV communication systems

A practical UGV mesh usually contains mobile nodes on vehicles and fixed relay nodes positioned in the operating area. Fixed nodes can be installed at elevated locations, building entrances, corridor junctions, or field checkpoints. The rover node connects to its onboard computer through Ethernet or Wi-Fi.

Common communication roles include the following:

UGV node – a radio device installed on Leo Rover or Raph Rover and connected to the onboard compute unit.
Relay node – a stationary or mobile node that forwards packets between nodes with no direct radio path.
Gateway node – a node connecting the mesh segment to a wired LAN, VPN, Internet connection, or ROS 2 development workstation.
Operator node – a workstation running RViz, Foxglove, teleoperation tools, rosbag2 recording, or diagnostic utilities.

A mesh network should be distinguished from a Wi-Fi range extender. A basic extender repeats a signal to one upstream access point. A mesh implementation maintains peer links and routing information between multiple participating nodes. IEEE 802.11 mesh functionality was originally specified in IEEE 802.11s and is incorporated into IEEE Std 802.11-2020.

Mesh networking and ROS 2

ROS 2 does not define a mesh protocol. ROS 2 uses DDS-based middleware, while routing between radio nodes is handled by the operating system and the network infrastructure. DDS discovery and ROS 2 topic transport therefore depend on IP connectivity, multicast behavior, firewall rules, and Quality of Service settings.

A multi-hop mesh can affect ROS 2 communication in several ways. Each additional wireless hop adds latency, consumes airtime, and may increase packet loss. This is especially relevant for high-bandwidth streams such as images, point clouds, and compressed video. A control topic such as /cmd_vel has very different requirements from a LiDAR point cloud or a camera stream.

ROS 2 data type	Typical message type	Network consideration
Velocity command	`geometry_msgs/msg/Twist`	Low bandwidth, but requires low latency and defined fail-safe behavior.
Robot state	`nav_msgs/msg/Odometry`, `sensor_msgs/msg/Imu`	Usually low bandwidth. Useful for monitoring and remote visualization.
Laser scan	`sensor_msgs/msg/LaserScan`	Can be transmitted for visualization, but local navigation should not depend on a remote connection.
Point cloud	`sensor_msgs/msg/PointCloud2`	Potentially high bandwidth. Filtering, downsampling, or local recording may be required.
Camera image	`sensor_msgs/msg/Image`	Use transport compression where appropriate. Raw images can saturate a multi-hop wireless link.

The ROS 2 documentation describes QoS policies including reliability, durability, history, deadline, lifespan, and liveliness. These policies should be selected per topic rather than applied globally. The official reference is the ROS 2 QoS documentation.

Key parameters for a robotic mesh network

Mesh performance must be evaluated under rover motion and expected environmental conditions. A radio link that works while the robot is stationary may fail when the vehicle moves behind vegetation, reinforced concrete, machinery, terrain features, or metallic structures.

End-to-end latency – the delay between the operator node and the rover application. Measure it for command, telemetry, and video paths separately.
Packet loss – lost packets can affect DDS best-effort topics, video streams, and discovery traffic.
Jitter – variation in packet delay. High jitter can make teleoperation and time-sensitive visualization difficult.
Throughput – usable application-layer bandwidth, not only the radio link rate reported by the device.
Hop count – the number of relay links between rover and gateway. More hops generally reduce available capacity.
RSSI and signal-to-noise ratio – radio-level indicators that should be logged together with packet loss and latency.
Roaming or route convergence time – the time needed to establish a new usable path after movement or a link failure.

Basic ROS 2 and Linux diagnostics can be used to verify communication before a field test.

# Check ROS 2 nodes visible in the selected domain
ros2 node list

# Inspect publishers, subscribers and QoS compatibility
ros2 topic info -v /scan

# Measure IP reachability to a gateway or rover
ping -c 20 <robot-ip-address>

# Inspect Wi-Fi link information on Linux
iw dev wlan0 link

Integration on Leo Rover and Raph Rover

Leo Rover uses an onboard Raspberry Pi compute unit and supports ROS 2 Humble or later. A mesh radio can be connected through Ethernet or USB, depending on the selected network hardware and available power budget. The radio should be treated as a separate subsystem with documented addressing, firmware version, antenna placement, and startup behavior. Leo Rover technical integration details should be verified against the Leo Rover documentation.

On Leo Rover, autonomy-critical components should run locally. This includes motor control, odometry, local costmaps, obstacle processing, and safety handling. A mesh connection can expose diagnostics, RViz visualization, remote teleoperation, and selected sensor topics, but it should not be the only path required for safe stopping or collision avoidance.

Raph Rover can be used where a larger payload permits additional networking hardware, higher-gain antennas, dedicated edge compute, or a protected relay enclosure. The same design rule applies: rover mobility and local safety functions must not depend on continuous connectivity to an external mesh gateway.

Standards and protocol considerations

IEEE 802.11 mesh networking applies to Wi-Fi-based mesh systems. Low-power sensor meshes may instead use technologies based on IEEE 802.15.4, including systems built with Zigbee, Thread, or proprietary industrial protocols. IEEE Std 802.15.4-2020 defines the low-rate wireless personal area network physical and MAC layers.

For ROS 2, network interoperability also depends on the selected DDS implementation. ROS 2 distributions may use different default DDS vendors and configurations. Multicast discovery may not traverse routed mesh segments or VLAN boundaries without explicit configuration. In such deployments, engineers can use unicast peer configuration, discovery servers, VPN overlays, or DDS routing tools, depending on the middleware and security architecture.

ROS 2 security mechanisms are specified through the DDS Security model and exposed through SROS 2 documentation. Encryption and authentication can protect traffic, but they also add configuration complexity and should be validated under realistic mesh bandwidth and latency conditions.