// the find
ika-rwth-aachen/mqtt_client
ROS 2 C++ Node for bi-directionally bridging messages between ROS and MQTT
A ROS 2 component node that bridges topics in both directions between ROS and an MQTT broker. It sends arbitrary ROS message types as serialized payloads, as JSON, or as bare primitives for non-ROS MQTT clients. It is aimed at robotics and vehicle teams who need a broker in the middle, and it ships as an apt package that lists ROS 2 humble through rolling as supported.
Topics are handled as serialized payloads through rclcpp generic pub/sub, so any message type bridges without a per-type adapter. Adding a topic is a YAML edit, not a code change. Bridges can also be added at runtime through the new_ros2mqtt_bridge and new_mqtt2ros_bridge services, which matters when the topic set is not known at launch. QoS is configurable on both sides (ROS reliability and durability, MQTT QoS and retained), and the latency mode injects a timestamp and publishes the measured delta as a Float64 topic.
JSON mode does not deduce types, so every JSON bridge needs a hand-written ros_type, and the JSON has to match that type field for field. The README does not say what happens on a mismatch. The MQTT-to-ROS primitive probe tries bool, int, float, then string in that order, so a numeric payload's ROS type depends on the probe rather than on what the sender meant. The fixed-type config variants in the repo are the workaround, but the default is a footgun. Buffering while disconnected needs a non-empty client ID, buffer size defaults to 0, and clean_session defaults to true, so out of the box anything published during a broker outage is lost; the demo log warns about the empty-ID case. Broker passwords and TLS key passwords sit in plaintext YAML, and the README gives no guidance on secret handling beyond the TLS options.