Skip to content

Releases: hieutachi/rosbridge-mcp

v0.2.0 — Perception & actions

Choose a tag to compare

@hieutachi hieutachi released this 18 Aug 02:12

v0.2.0 — Perception & actions

The AI agent can now see through the robot's camera, understand the robot's coordinate frames, and drive long-running behaviors (navigation, arm motion) via ROS 2 actions — on top of the topic/service tools from v0.1. Everything below is implemented, tested (43 tests, CI green on Python 3.10 & 3.12), and matches the rosbridge v2 protocol spec.

Highlights

  • send_action_goal / cancel_action_goal — full ROS 2 action client over rosbridge's send_action_goal / cancel_action_goal ops: wait for the result (with the last feedback received), or fire-and-forget and cancel by goal_id. Detects rosbridge servers that predate action support and tells you to upgrade instead of hanging.
  • get_tf_tree — brief /tf + /tf_static subscription merged into a parent→child frame tree with static/dynamic provenance. Read-only.
  • get_camera_image — one CompressedImage (or raw Image) frame as base64 for vision-capable models, with a 4 MB safety limit. Read-only. This is the bridge for VLM / vision-language-action workflows: the model looks before it acts.
  • Readonly mode hardened — switched from a blocklist to a frozen allowlist of known read-only /rosapi services; the new action tools are blocked in readonly mode, the new perception tools work in it.

Fixed (all 5 issues from the v0.1 QA round)

  • #1 — Reconnect race: a stale listener no longer spuriously fails calls resent on the new connection.
  • #2 — rosbridge status messages are no longer dropped: publish_message reports rosbridge_warnings when rosbridge rejects the message instead of claiming clean success.
  • #3 — Readonly /rosapi access is now allowlist-based (security hardening).
  • #4get_topic_snapshot clamps count ≤ 100 / timeout ≤ 60 s and fails fast on mid-collection connection loss.
  • #5 — License audit notes certifi is MPL-2.0 (file-level copyleft, MIT-compatible).

Full details in CHANGELOG.md.

What this release needed / what the next one needs

This release took one maintainer working part-time, a mock-based test suite, and no special hardware — exactly what the roadmap predicted for v0.2. What exists today is real and verifiable: 11 tools, 43 automated tests in CI, per-scenario docs for 5 user paths, a readonly safety mode, and an audited zero-telemetry codebase.

The next stages need more than one part-time person (ROADMAP.md has the full breakdown):

  • v0.3 (deployment & auth): a security-minded reviewer for the rosbridge auth/TLS layer, and a small VM or self-hosted runner for Docker image builds.
  • v0.4 (fleets): access to 2+ robots or simulator instances, and a robotics lab willing to pilot and give design feedback.
  • v1.0 (stability): sustained maintainer time, one RTX-class GPU workstation for Isaac Sim validation, and optionally a low-cost robot (~$1–3k) for hardware-in-the-loop CI.

If you can help: star the repo, try it against your robot or simulator and open an issue with your ROS distro + rosbridge version, pick a roadmap item and send a PR, or reach out about sponsorship / lab partnership via github.com/hieutachi. No inflated claims here — just a working bridge between AI agents and ROS 2, and a clear list of what it takes to finish it.