Glossary

Fictionlab > Glossary > MQTT

MQTT

MQTT – definition

MQTT is a lightweight publish/subscribe messaging protocol designed for communication over IP networks with constrained bandwidth, intermittent connectivity, or limited device resources. It uses a broker-based architecture: publishers send messages to named topics, the broker distributes them, and subscribers receive messages for the topics they have subscribed to. MQTT does not require a direct connection between the publisher and subscriber.

In mobile robotics, MQTT is commonly used as an integration layer between a UGV, remote monitoring software, edge gateways, cloud services, and non-ROS devices. It is not a replacement for ROS 2 middleware inside a robot. ROS 2 normally uses DDS through its RMW abstraction for node-to-node communication. MQTT is more suitable when telemetry, events, commands, or selected ROS data must cross network boundaries or reach systems that do not implement ROS 2.

For Leo Rover and Raph Rover deployments, MQTT can expose battery state, GNSS fixes, mission status, diagnostic events, or environmental sensor readings to external applications. A separate bridge node should translate between ROS 2 topics and MQTT topics while preserving message semantics, timestamps, units, and command safety rules.

MQTT protocol versions and communication model

MQTT is standardized by OASIS. MQTT Version 3.1.1 was approved as an OASIS Standard in 2014 and later published as ISO/IEC 20922:2016. MQTT Version 5.0 was approved by OASIS in 2019. MQTT 5.0 adds features such as reason codes, message expiry intervals, topic aliases, shared subscriptions, user properties, and request/response correlation fields.

Element Function in a UGV system Example
Broker Accepts client connections, filters messages by topic, and forwards publications. Broker running on an on-site edge computer.
Publisher Sends a message to a topic without knowing which clients consume it. ROS 2 bridge publishing rover battery telemetry.
Subscriber Receives messages matching a topic filter. Dashboard subscribed to rover status topics.
Topic UTF-8 hierarchical identifier used for message routing. fictionlab/leo-01/telemetry/battery
Payload Application-defined message body. JSON, CBOR, Protobuf, or serialized ROS data.

MQTT topics are not ROS 2 topic names, even though both use a topic-oriented model. MQTT topic levels are separated with /. The + wildcard matches one level, while # matches multiple remaining levels. Wildcard subscriptions should be limited in operational robot networks because they can expose unintended telemetry or command channels.

Quality of Service, retained messages, and session state

MQTT defines three Quality of Service (QoS) levels. The selected level controls broker-client delivery behavior. It does not validate sensor values, guarantee real-time execution, or make a robot command safe.

  • QoS 0 – at most once: the message is sent once with no acknowledgment or retransmission and may be lost. It is suitable for high-rate, non-critical telemetry where newer data supersedes older data.
  • QoS 1 – at least once: the receiver acknowledges delivery. Duplicate messages are possible and consumers must be idempotent.
  • QoS 2 – exactly once: a four-step protocol handshake ensures exactly-once delivery on each client-broker hop. It creates more protocol overhead than QoS 0 or QoS 1.

A retained MQTT message is stored by the broker and delivered to future subscribers whose topic filter matches that topic. Retained messages are useful for slowly changing state, such as a rover’s current operating mode or software version. They are unsafe for movement commands unless the bridge explicitly rejects stale, retained, or expired command messages.

For UGV control, command payloads should include an identifier, timestamp, source, validity period, and explicit stop behavior. A bridge must reject old commands after reconnection. MQTT Last Will and Testament messages can publish an offline status when a client disconnects unexpectedly, but they are not a substitute for hardware emergency-stop circuits or onboard safety logic.

MQTT and ROS 2 integration

ROS 2 communication is based on DDS concepts such as publishers, subscriptions, services, actions, and QoS policies. ROS 2 QoS settings and MQTT QoS levels are different mechanisms. ROS 2 reliability can be RELIABLE or BEST_EFFORT, while MQTT defines QoS 0, 1, and 2 delivery procedures. A bridge must configure both sides independently.

A typical integration uses a ROS 2 node that subscribes to local robot data, converts it into a defined external schema, and publishes it to MQTT. The reverse path subscribes to approved MQTT command topics and publishes validated ROS 2 messages. Do not expose unrestricted geometry_msgs/msg/Twist control over a public or shared broker.

mqtt_bridge:
  broker_uri: "mqtts://edge-broker.example.net"
  robot_id: "leo-01"

  ros_to_mqtt:
    - ros_topic: "/battery_state"
      ros_type: "sensor_msgs/msg/BatteryState"
      mqtt_topic: "fictionlab/leo-01/telemetry/battery"
      mqtt_qos: 1
      retained: false

  mqtt_to_ros:
    - mqtt_topic: "fictionlab/leo-01/command/mission"
      ros_topic: "/mission_command"
      ros_type: "std_msgs/msg/String"
      mqtt_qos: 1
      reject_retained: true
      require_timestamp: true

The payload format should be documented. JSON is readable and convenient for dashboards, but it has greater size and parsing overhead than binary encodings. For measurements, include SI units and frame identifiers where relevant. For example, GNSS data should state whether coordinates are WGS 84 latitude/longitude, local ENU coordinates, or a map-frame pose.

Use on Leo Rover and Raph Rover

Leo Rover runs ROS 2 natively on its built-in Raspberry Pi compute unit with ROS 2 Humble or a newer distribution. MQTT can connect the rover to a laboratory broker through Wi-Fi or Ethernet infrastructure while keeping navigation, motor control, and local perception inside the ROS 2 graph. Leo Rover has differential drive, so externally supplied velocity commands must be constrained by the local controller and navigation stack.

Raph Rover can use the same pattern when a larger platform carries additional sensors or payload computers. MQTT is useful for forwarding selected data from payload subsystems, such as a GNSS receiver, inspection camera gateway, or agricultural sensor module. High-bandwidth camera streams and raw LiDAR point clouds are generally poor candidates for MQTT telemetry. Publish derived results instead, such as object detections, occupancy metrics, health status, or references to recorded data.

Security and operational limitations

MQTT has no inherent semantic authorization for robot actions. Transport encryption, client authentication, topic-level access control, and network segmentation must be configured by the broker and client deployment. Use TLS certificates where the broker is outside a physically controlled network. Separate telemetry topics from command topics and grant each client only the permissions it needs.

MQTT is not deterministic real-time middleware. Broker load, Wi-Fi roaming, retransmissions, and Internet latency can delay messages. It should not be the only path for collision avoidance, motor watchdogs, emergency stop functions, or local autonomous navigation. Those functions belong on the rover and should continue operating safely after broker disconnection.

Normative references and standards

The following sources define the protocol and the ROS 2 concepts relevant to an MQTT bridge.

See also