ROS / ROS2 + AI Agent: Connecting Your Robot to ASI Biont via MQTT and WebSocket

Why connect a ROS 2 robot to an AI agent?

ROS 2 is the de facto standard for building robots: navigation, manipulation, sensing, and fleet coordination are already solved with packages like Nav2, MoveIt 2, and the ROS 2 navigation stack. But ROS 2 remains a developer tool. When you want to give a robot to an operator, a warehouse manager, or a homeowner, they do not want to run ros2 topic pub, parse YAML files, or debug DDS discovery. They want to type "go to shelf B12, pick the box, and bring it to the dock" in a chat window and have the robot execute the task.

That is exactly the gap ASI Biont fills. ASI Biont is an AI agent that connects to industrial and robotics hardware through standard protocols — MQTT, Modbus/TCP, HTTP, WebSocket, OPC-UA, and more — and translates natural language into structured commands. For ROS 2, the fastest and cleanest path is an MQTT bridge: ROS 2 nodes publish telemetry to MQTT topics, and ASI Biont publishes high-level goals back. The robot stays in its ROS 2 ecosystem; the AI agent handles dialogue, task decomposition, and integration with external services such as Telegram or existing warehouse APIs.

This article is a practical integration guide, not a device review. By the end, you will have a working pattern for connecting a ROS 2 robot to ASI Biont, with code examples you can adapt to your own robot.

Architecture: MQTT bridge + WebSocket telemetry

ROS 2 already uses DDS under the hood, but most AI agents and cloud services do not speak DDS. Trying to implement DDS on the agent side is overkill. MQTT is the right intermediary because it is lightweight, has a pub/sub model that maps naturally to ROS 2 topics, and is supported by every major programming language.

A typical ASI Biont integration looks like this:

WebSocket is used when you need low-latency bidirectional streaming, for example live sensor values or a video-like stream of laser scan data. MQTT is sufficient for most command-and-telemetry traffic; WebSocket is a useful complement when your robot exposes an HTTP/WebSocket API already.

Why choose MQTT for ROS 2 integration?

There are several ways to connect a robot to an AI agent. The table below compares the options in the context of ASI Biont:

The key insight is that you do not need to expose every ROS 2 topic. You expose a small contract: input topics for goals and output topics for state. The AI agent becomes the task planner, and ROS 2 continues to handle real-time control.

Code example 1: ROS 2 MQTT command subscriber

This ROS 2 node subscribes to an MQTT topic named robot/cmd_vel, receives a JSON payload, and publishes a Twist message to /cmd_vel. The robot's Nav2 stack will execute it.

import json
import rclpy
from rclpy.node import Node
from geometry_msgs.msg import Twist
import paho.mqtt.client as mqtt

class MqttCommandBridge(Node):
    def __init__(self):
        super().__init__('mqtt_command_bridge')
        self.publisher_ = self.create_publisher(Twist, '/cmd_vel', 10)

        self.client = mqtt.Client()
        self.client.on_connect = self.on_connect
        self.client.on_message = self.on_message

        # Replace with your MQTT broker address, e.g. the ASI Biont MQTT bridge
        self.client.connect('192.168.1.100', 1883, 60)
        self.client.loop_start()

    def on_connect(self, client, userdata, flags, rc):
        self.get_logger().info('Connected to MQTT broker')
        client.subscribe('robot/cmd_vel')

    def on_message(self, client, userdata, msg):
        data = json.loads(msg.payload.decode())

        twist = Twist()
        twist.linear.x = float(data.get('linear', 0.0))
        twist.angular.z = float(data.get('angular', 0.0))

        self.publisher_.publish(twist)
        self.get_logger().info(f'Publishing: linear={twist.linear.x}, angular={twist.angular.z}')

def main():
    rclpy.init()
    node = MqttCommandBridge()
    try:
        rclpy.spin(node)
    except KeyboardInterrupt:
        pass
    finally:
        node.destroy_node()
        rclpy.shutdown()

if __name__ == '__main__':
    main()

To use this with ASI Biont, you tell the agent: "The robot subscribes to MQTT topic robot/cmd_vel and expects {linear, angular} values. Send a command, and confirm delivery." The agent will respond with a JSON command on the same topic, and your robot will move.

Code example 2: Publishing telemetry back to ASI Biont

Telemetry is the foundation of the AI agent's situational awareness. The following node subscribes to /odom and publishes x, y, and yaw to an MQTT topic:

import json
import math
import rclpy
from rclpy.node import Node
from nav_msgs.msg import Odometry
import paho.mqtt.publish as publish

class TelemetryBridge(Node):
    def __init__(self):
        super().__init__('telemetry_bridge')
        self.subscription = self.create_subscription(
            Odometry,
            '/odom',
            self.on_odom,
            10
        )

    def on_odom(self, msg):
        position = msg.pose.pose.position
        orientation = msg.pose.pose.orientation

        # Convert quaternion to yaw (simplified)
        siny_cosp = 2.0 * (orientation.w * orientation.z + orientation.x * orientation.y)
        cosy_cosp = 1.0 - 2.0 * (orientation.y * orientation.y + orientation.z * orientation.z)
        yaw = math.atan2(siny_cosp, cosy_cosp)

        payload = json.dumps({
            'x': position.x,
            'y': position.y,
            'yaw': yaw,
            'frame_id': msg.header.frame_id
        })

        # Publish to the ASI Biont MQTT topic
        publish.single(
            'robot/odom',
            payload,
            hostname='192.168.1.100',
            port=1883
        )

def main():
    rclpy.init()
    node = TelemetryBridge()
    try:
        rclpy.spin(node)
    except KeyboardInterrupt:
        pass
    finally:
        node.destroy_node()
        rclpy.shutdown()

if __name__ == '__main__':
    main()

Once telemetry flows, ASI Biont can answer questions like "Where is the robot now?", "Is it moving toward the target?", or "What is the battery level?" — and notify you via Telegram or another chat endpoint using standard HTTP calls to api.telegram.org, not custom functions.

Natural language robot control: from words to actions

With the MQTT bridge in place, the workflow becomes:

1. Operator message in ASI Biont chat: "Navigate to waypoint A1, then return to charging station."
2. Agent planning: ASI Biont decomposes the request into a sequence — move to A1, publish goal pose to MQTT topic robot/goal_pose, wait for status, then navigate back.
3. ROS 2 execution: Your bridge node receives the goal, converts it to a PoseStamped message, and sends it to Nav2's /goal_pose topic or the action server.
4. Feedback loop: ROS 2 publishes status to robot/status; ASI Biont reports "Reached A1, now returning to the charger."

For manipulation, the same pattern applies to MoveIt 2. Toggle a gripper: publish to robot/gripper with payload "{\"command\": \"close\"}". A ROS 2 node calls the MoveIt action server. The AI agent does not need to know MoveIt's API; the bridge translates a clean JSON contract into ROS actions.

Real-world scenarios

These scenarios do not require a custom backend. The robot stays fully in the ROS 2 ecosystem; ASI Biont handles the outside world — user interaction, enterprise APIs, and multi-step reasoning.

How ASI Biont connects to any ROS 2 device without a custom SDK

A critical architectural decision is that ASI Biont does not maintain a hardcoded list of supported robots. Instead, it uses a universal execute_python mode: you describe the parameters — IP address of the MQTT broker, topic names, message format, baud rate for serial devices, or API key — and the AI agent writes a Python integration script on the fly using paho-mqtt, pyserial, paramiko, pymodbus, aiohttp, or opcua-asyncio. The script runs in a sandboxed Python environment and handles the protocol-level details.

This has important implications for ROS 2 users:

• You do not need to wait for the ASI Biont team to "add support" for your controller, gripper, or lidar brand.
• You do not fill out forms in a management panel. You simply describe the device in chat: "Our robot publishes odometry on MQTT at 10 Hz to topic robot/odom, and we want the AI to send navigation goals to robot/goal_pose."
• The AI creates the integration in seconds, tests it, and explains how to run the ROS 2 bridge node.

The entire integration happens through dialogue. If you need a different serialization, protocol, or data rate, you ask the AI to change it — no pull request required.

Telemetry, commands, and the control loop

For reliable control, separate your topics into three groups:

A common mistake is to stream raw point clouds or full laser scans through MQTT. MQTT can handle it, but it consumes bandwidth and makes the agent slower to respond. Publish processed information instead: a bounding box, a distance to goal, or a status enum. If you must stream raw data, use WebSocket and keep MQTT for commands and discrete telemetry.

Security and reliability considerations

ROS 0 is often deployed on unauthenticated DDS domains; exposing it directly to an AI agent is risky. Use MQTT with TLS and a username/password, or run a local broker that both ASI Biont and the robot bridge connect to. The robot bridge should validate every message — the AI agent is powerful, but a malformed goal can send a robot into a wall. Follow the safety requirements from the official ROS 2 documentation (docs.ros.org) and the Nav2 safety guidelines (docs.nav2.org).

QoS matters too. In ROS 2, topics have QoS policies; your bridge should subscribe with QoSProfile(depth=10) or a matching reliability policy, otherwise messages silently drop. The official ROS 2 QoS documentation explains the trade-offs in detail.

Why ASI Biont saves you weeks of integration work

Writing an MQTT bridge for ROS 2 is maybe a day of work. Writing the full task layer — natural language parsing, multi-step planning, error recovery, user notification, fleet coordination — is months of work. ASI Biont brings the latter out of the box. The AI agent reads telemetry, decides what needs attention, and asks the robot to act. When engineers want to query a robot's behavior, they do not dig through logs; they ask the agent in plain English.

The time saving is real. With ASI Biont's execute_python capability, what used to require a dedicated integration engineer can be done in a conversation. You describe your ROS 2 topics, the AI generates the bridge and the monitoring logic, and you spend the rest of your time refining the robot's actual behavior rather than writing glue code.

Conclusion

Connecting a ROS 2 robot to an AI agent does not require ditching ROS or rewriting your navigation stack. A thin MQTT bridge is enough to give an AI agent access to your robot's sensors and actuators. ASI Biont handles the natural language, planning, and integration with messaging services like Telegram, so operators can control a robot with the same ease as sending a chat message.

Try it today: describe your ROS 2 robot to ASI Biont on asibiont.com, and let it wire up the MQTT bridge, telemetry monitoring, and command parsing automatically. Your robot will start taking orders in plain English — without a single line of AI infrastructure code written by hand.

References

• ROS 2 Documentation: https://docs.ros.org
• Nav2 Navigation Stack: https://docs.nav2.org
• MoveIt 2 Manipulation: https://moveit.picknik.ai
• OASIS MQTT 3.1.1 Specification: https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
• ROS 2 QoS Policies: https://docs.ros.org/en/humble/Concepts/About-Quality-of-Service-Settings.html