Gazebo vs Viam

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Viam
   Gazebo—none0/10

   Direct probes show no llms.txt (404), no markdown-alt docs, and no OpenAPI spec, indicating no agent-oriented documentation format is provided; no evidence of any agent-discoverable docs endpoint.

   • [probe] “PROBE llms.txt: HTTP 404 at https://gazebosim.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://gazebosim.org/docs/latest/getstarted/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gazebosim.org/openapi.json, https://gazebosim.org/swagger.json, https://gazebosim.org/api/op…”

   proof ↗⚑ flag

   Viam✓fullprobed8/10

   Probe confirms llms.txt is live at https://docs.viam.com/llms.txt (HTTP 200) with a structured summary, and Viam also documents an explicit agent-oriented doc page (use-viam-from-an-agent) describing how an AI agent with a shell or SDK can operate a machine. missing for 10: no independent/community corroboration that agents actually consume llms.txt successfully, and no evidence of broader agent-oriented doc index beyond the single page.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.viam.com/llms.txt # Viam > Viam is a platform for building, operating, and managing robots and oth…”
   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [claimed-docs] “Plan motion through the motion service rather than commanding joints or poses directly. `Move` takes a goal pose in any frame, plus obstacle…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Gazebo
   Gazebo✓fullclaimed8/10

   Gazebo explicitly supports headless server-only operation via the -s flag and even offers a dedicated lightweight server-only package (gz-sim-server) without GUI/Qt dependencies, plus CLI tools and TCP/IP transport for remote/automated control, all of which are well suited to CI pipelines. Missing for 10: explicit first-party CI/CD example (e.g., GitHub Actions workflow) or independent report confirming headless CI usage in practice.

   • [claimed-docs] “Gazebo Sim can also be run headless, i.e. without the GUI, by using the -s (server only) flag.”
   • [claimed-docs] “the gz-sim10-server package provides a lightweight alternative. It installs only the Gazebo simulation server (gz-sim-server) without any GU…”
   • [claimed-docs] “It installs only the Gazebo simulation server (`gz-sim-server`) without any GUI or Qt dependencies, resulting in a significantly smaller ins…”
   • [github] “Command line tools: Extensive command line tools for increased simulation introspection and control.”
   • [github] “TCP/IP Transport: Run simulation on remote servers and interface to Gazebo Sim through socket-based message passing using Gazebo Transport.”

   proof ↗⚑ flag

   Viam~partialprobed6/10

   Viam has a documented CLI that can call any machine API method with JSON in/out, supports SQL queries for data, and explicitly documents agent/headless usage patterns (shell or SDK operating a machine like a person or program), which supports CI/automation workflows. However, evidence lacks explicit CI/CD pipeline integration examples, headless installation/authentication flows for automation contexts, or exit-code/scripting conventions typical of CI tooling. missing for 10: CI pipeline examples/integration guides, non-interactive auth/service-account setup for headless CLI use, independent confirmation of CI usage in the wild.

   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out; no code to write.”
   • [claimed-docs] “viam data query tabular sql --org-id=<org-id> --sql=<query> [--destination=<output path>]”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [probe] “official CLI documented at https://docs.viam.com/cli/reference/”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round drawn
   Gazebo—none0/10

   Gazebo is a robotics simulator, not an AI agent, so it is a plausible candidate to expose an official MCP server for agent integration, but no evidence in the pack mentions MCP, agent connectivity, or any AI-agent integration protocol at all.

   ⚑ flag

   Viam—none0/10

   Viam is a robotics platform (not itself an agent), so publishing an official MCP server is a fair question, but the evidence only shows agent access via CLI/SDK/shell (viam-docs-12, viam-docs-13, viam-docs-31, viam-docs-32) with no mention of the Model Context Protocol or an MCP server offering anywhere in docs or probes.

   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.viam.com/llms.txt # Viam > Viam is a platform for building, operating, and managing robots and oth…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.viam.com/openapi.json, https://docs.viam.com/swagger.json, https://docs.viam.com/api/op…”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Viam
   Gazebo✓fullclaimed7/10

   Gazebo ships an official `gz` CLI with documented commands (e.g. `gz sim shapes.sdf`), headless/server-only mode (`-s` flag) and server-only packages that are ideal for scripted/automated (agentic) invocation without a GUI, plus GitHub docs calling out 'extensive command line tools for increased simulation introspection and control'. Missing for 10: explicit framing of the CLI for AI-agent orchestration use-cases and independent (non-vendor) corroboration of CLI usage in automated pipelines.

   • [claimed-docs] “gz sim shapes.sdf”
   • [claimed-docs] “Gazebo Sim can also be run headless, i.e. without the GUI, by using the -s (server only) flag.”
   • [claimed-docs] “Gazebo Sim can also be run headless, i.e. without the GUI, by using the `-s` (server only) flag.”
   • [claimed-docs] “the gz-sim10-server package provides a lightweight alternative. It installs only the Gazebo simulation server (gz-sim-server) without any GU…”
   • [github] “Command line tools: Extensive command line tools for increased simulation introspection and control.”
   • [github] “Extensive command line tools for increased simulation introspection and control.”

   proof ↗⚑ flag

   Viam✓fullprobed8/10

   Viam ships an official documented CLI (docs.viam.com/cli/reference) supporting data queries, resource control, fleet/org management, and JSON-in/JSON-out API calls that an AI agent can drive directly, with a dedicated guide on using Viam from an agent via shell/SDK. This is agent-friendly and well-documented but lacks independent hands-on corroboration of the CLI itself. Missing for 10: independent/community verification of CLI usage, more detail on agent-specific CLI workflows beyond the single doc page.

   • [claimed-docs] “viam data query tabular sql --org-id=<org-id> --sql=<query> [--destination=<output path>]”
   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out; no code to write.”
   • [claimed-docs] “With it, you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all…”
   • [probe] “official CLI documented at https://docs.viam.com/cli/reference/”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Viam
   Gazebo~partialprobed5/10

   Gazebo exposes documented, non-GUI ways to drive the simulator programmatically: a headless server mode (-s flag), gz-transport for socket-based TCP/IP message passing to remote-control simulations, extensive CLI tools for introspection/control, and C++ library APIs (gz-math, sdformat, gz-transport) for building custom integrations/plugins. However, probes for a modern machine-readable API spec (OpenAPI/swagger) and an llms.txt all returned 404, and there is no evidence of a REST/HTTP API or AI-specific SDK. missing for 10: OpenAPI/swagger spec or any public HTTP API, explicit AI-agent-oriented API docs or llms.txt, independent confirmation that an AI agent can drive Gazebo via gz-transport.

   • [claimed-docs] “Gazebo Sim can also be run headless, i.e. without the GUI, by using the `-s` (server only) flag.”
   • [github] “TCP/IP Transport: Run simulation on remote servers and interface to Gazebo Sim through socket-based message passing using Gazebo Transport.”
   • [github] “Extensive command line tools for increased simulation introspection and control.”
   • [claimed-docs] “those who use individual Gazebo libraries (like `gz-math`, `sdformat`, or `gz-transport`) directly in their own C++ applications”
   • [probe] “PROBE llms.txt: HTTP 404 at https://gazebosim.org/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gazebosim.org/openapi.json, https://gazebosim.org/swagger.json, https://gazebosim.org/api/op…”

   proof ↗⚑ flag

   Viam✓fullprobed8/10

   Viam publishes a dedicated doc page explicitly stating 'An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can,' backed by CLI/API references (JSON in/out for any API method), fleet API docs, and multi-language SDKs, directly satisfying the AI-native documented public API story. Missing for 10: standard machine-readable OpenAPI spec discoverable (probe found 404s at all candidate openapi.json paths), independent third-party hands-on verification of agent API usage.

   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out; no code to write.”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [claimed-docs] “Plan motion through the motion service rather than commanding joints or poses directly. `Move` takes a goal pose in any frame, plus obstacle…”
   • [claimed-docs] “With it you can create and manage organizations, locations, and individual machines, manage permissions and authorization, create and manage…”
   • [claimed-docs] “viam data query tabular sql --org-id=<org-id> --sql=<query> [--destination=<output path>]”
   • [github] “Multiple SDKs are available for writing client applications that interface with the Viam RDK.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.viam.com/openapi.json, https://docs.viam.com/swagger.json, https://docs.viam.com/api/op…”
   • [probe] “official CLI documented at https://docs.viam.com/cli/reference/”

   proof ↗⚑ flag

6. ai-native userBuild against official SDKs

   weight 2 · round to Viam
   Gazebo~partialprobed6/10

   Gazebo documents genuine official SDKs/libraries (gz-math, gz-transport, sdformat) and a plugin API for building custom C++ applications/plugins, with a dedicated 'Developers' docs section (gazebo-docs-1/8/14/16). However, evidence shows only C++-centric libraries with no Python or other language SDK bindings, no AI-agent-oriented SDK, and probes show no llms.txt or OpenAPI spec, suggesting no AI-native tooling layer. Missing for 10: language bindings beyond C++/plugins, an AI-agent-specific SDK or API spec, independent developer corroboration of SDK usability.

   • [claimed-docs] “Developers: For those who use individual Gazebo libraries (like gz-math, sdformat, or gz-transport) directly in their own C++ applications, …”
   • [claimed-docs] “those who use individual Gazebo libraries (like `gz-math`, `sdformat`, or `gz-transport`) directly in their own C++ applications”
   • [claimed-docs] “For those who use individual Gazebo libraries (like gz-math, sdformat, or gz-transport) directly in their own C++ applications, or those who…”
   • [github] “Plugins: Develop custom plugins for robot, sensor, and environment control.”
   • [claimed-docs] “If your package directly depends on a Gazebo library, instead of relying only on ros_gz, refer to this documentation to learn how to use the…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://gazebosim.org/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gazebosim.org/openapi.json, https://gazebosim.org/swagger.json, https://gazebosim.org/api/op…”

   proof ↗⚑ flag

   Viam✓fullclaimed8/10

   Viam documents official SDKs in Python, Go, C++, TypeScript, and Flutter for building client applications and control logic, with consistent APIs across components (e.g., GetImage) and explicit support for AI agents using an SDK or shell to operate machines. This is corroborated by the GitHub RDK repo listing multiple SDKs. Missing for 10: independent hands-on developer reviews of SDK ergonomics/quality and more detail on SDK completeness/parity across languages.

   • [claimed-docs] “Write your control logic in Python or Go, get lower-level control with C++, or build a client application with Typescript or Flutter.”
   • [claimed-docs] “Every camera component in Viam exposes the same GetImage() method regardless of brand. Same for motors, sensors, arms, and other components.”
   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [github] “Multiple SDKs are available for writing client applications that interface with the Viam RDK.”
   • [claimed-docs] “Once it exists, the hardware behaves like any built-in component. Data capture, test panels, and the SDKs work automatically.”

   proof ↗⚑ flag

7. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Gazebo—none0/10

   No evidence of webhook subscription support; Gazebo uses TCP/IP transport, plugins, and CLI tools for integration, but nothing in the evidence pack mentions webhooks or event push notifications.

   ⚑ flag

   Viam—none0/10

   The evidence pack mentions fleet monitoring, alerting, and data sync, but nowhere describes a webhook subscription mechanism for events. Webhooks are a plausible feature for an IoT/robotics platform, so absence of evidence means 'none' rather than 'na'.

   ⚑ flag

Agentic features

1. ai-native userOperate the product with natural-language commands

   weight 2 · round to Viam
   Gazebo—none0/10

   Gazebo is a robotics simulator controlled via CLI tools, SDF files, and C++ plugins; no evidence of any natural-language command interface, LLM integration, or agentic control layer is present in the evidence pack.

   ⚑ flag

   Viam~partialclaimed6/10

   Viam has a dedicated 'use Viam from an agent' doc explicitly describing AI agents operating machines via shell/SDK/CLI with JSON in/out (viam-docs-12, viam-docs-13, viam-docs-30, viam-docs-31), which is strong evidence of agentic operability, but this is API/CLI-driven control rather than a built-in natural-language command interface—an agent must translate NL to API calls itself. Missing for 10: explicit natural-language parsing/command interface within Viam itself, and independent/hands-on confirmation of an AI agent successfully operating a machine via plain-language instructions.

   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out; no code to write.”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [claimed-docs] “Plan motion through the motion service rather than commanding joints or poses directly. `Move` takes a goal pose in any frame, plus obstacle…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Gazebo—none0/10

   No evidence of an interactive API reference or runnable examples; probes for llms.txt, markdown docs, and OpenAPI specs all returned 404, and the docs are static C++ library documentation without interactive tooling.

   • [probe] “PROBE llms.txt: HTTP 404 at https://gazebosim.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://gazebosim.org/docs/latest/getstarted/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gazebosim.org/openapi.json, https://gazebosim.org/swagger.json, https://gazebosim.org/api/op…”

   proof ↗⚑ flag

   Viam—none0/10

   No evidence of an interactive, runnable API reference (like a Swagger/OpenAPI explorer or executable code sandbox); a direct probe for OpenAPI/Swagger endpoints returned 404s, and docs only show static CLI/SDK reference pages and a llms.txt file, not a runnable API explorer.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.viam.com/openapi.json, https://docs.viam.com/swagger.json, https://docs.viam.com/api/op…”
   • [claimed-docs] “viam data query tabular sql --org-id=<org-id> --sql=<query> [--destination=<output path>]”
   • [probe] “official CLI documented at https://docs.viam.com/cli/reference/”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Gazebo—none0/10

   Gazebo is a robotics simulator, not an HTTP API service, and probes explicitly show no OpenAPI/swagger endpoints or llms.txt exist. No evidence of any machine-readable API spec being offered.

   • [probe] “PROBE openapi: all candidate paths 404 (https://gazebosim.org/openapi.json, https://gazebosim.org/swagger.json, https://gazebosim.org/api/op…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://gazebosim.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://gazebosim.org/docs/latest/getstarted/.md”

   proof ↗⚑ flag

   Viam—none0/10

   Viam's APIs are built on gRPC/protobuf (viam-comm-3) and documented via CLI/SDK references, but a direct probe for OpenAPI/swagger endpoints returned 404 on all candidate paths, and no evidence pack item mentions a downloadable OpenAPI spec or equivalent machine-readable API description.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.viam.com/openapi.json, https://docs.viam.com/swagger.json, https://docs.viam.com/api/op…”
   • [community] “The whole system is built on gRPC and everything is open source aside from the cloud app itself; you can run your own server and have multip…”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out.”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Gazebo
   Gazebo✓fullclaimed7/10

   Gazebo is fundamentally a robot/environment simulator that lets users test robots, sensors, and physics in a virtual sandbox instead of on real (production) hardware — it can run headless or on remote servers via TCP/IP transport, and supports numerous pre-built simulation models via Gazebo Fuel, letting an AI-native user iterate safely without touching production systems. Missing for 10: explicit framing around isolating from 'production data' (e.g., data provenance, reset/snapshot guarantees) and no first-party mention of AI/agent-specific sandbox workflows.

   • [claimed-docs] “Gazebo Sim can also be run headless, i.e. without the GUI, by using the -s (server only) flag.”
   • [claimed-docs] “the gz-sim10-server package provides a lightweight alternative. It installs only the Gazebo simulation server (gz-sim-server) without any GU…”
   • [github] “Simulation models: Access numerous robots including PR2, Pioneer2 DX, iRobot Create, and TurtleBot, and construct environments using other p…”
   • [github] “TCP/IP Transport: Run simulation on remote servers and interface to Gazebo Sim through socket-based message passing using Gazebo Transport.”
   • [github] “Dynamics simulation: Access multiple high-performance physics engines through Gazebo Physics.”

   proof ↗⚑ flag

   Viam~partialclaimed4/10

   Viam offers 'test panels' and browser-based controls to 'debug without deploying code' and mentions 'canary testing and rollbacks for safe versioning', which suggest some isolated testing capability, but there is no explicit sandbox environment or data isolation from production described. missing for 10: dedicated sandbox/staging environment concept, explicit guarantee that test data doesn't touch production datasets, and any first-party or community confirmation of production/sandbox separation.

   • [claimed-docs] “Drive bases with keyboard controls, move arms to specific positions, or test components directly from Viam's web interface. Debug without de…”
   • [claimed-docs] “Once it exists, the hardware behaves like any built-in component. Data capture, test panels, and the SDKs work automatically.”
   • [claimed-docs] “Canary testing and rollbacks for safe versioning”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Gazebo—none0/10

   No evidence of a versioned API policy or documented deprecation schedule; ROS/Gazebo version compatibility docs mention supporting multiple versions but don't describe an API deprecation policy, and API probes (openapi, llms.txt) all 404. Missing for 10: any explicit versioning/deprecation policy documentation, API changelogs, or stability guarantees for AI/agentic consumers.

   • [claimed-docs] “This document provides guidance on using different versions of ROS in combination with different versions of Gazebo.”
   • [claimed-docs] “This document provides guidance on using different versions of ROS in combination with different versions of Gazebo. We recommend reading it…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gazebosim.org/openapi.json, https://gazebosim.org/swagger.json, https://gazebosim.org/api/op…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://gazebosim.org/llms.txt”

   proof ↗⚑ flag

   Viam—none0/10

   The evidence pack shows SDK/CLI/API surface documentation but no mention of API versioning scheme (e.g., v1/v2 endpoints) or any documented deprecation policy for APIs; references to 'versioning' only concern ML model deployment, not API contracts.

   ⚑ flag

1. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Viam
   Gazebo—none0/10

   Gazebo's evidence shows a plugin architecture for developers to extend robot/sensor/environment behavior in C++, but there is no documented rule-based trigger-action automation system for AI-native/non-developer users to define event-driven rules declaratively.

   • [github] “Plugins: Develop custom plugins for robot, sensor, and environment control.”
   • [github] “Develop custom plugins for robot, sensor, and environment control.”
   • [claimed-docs] “Users: For those who primarily run Gazebo using standard tools (like gz sim), edit SDFormat files, use existing plugins, and interact with r…”

   proof ↗⚑ flag

   Viam~partialclaimed6/10

   Viam supports event-driven automation via logic modules that react to sensor thresholds and coordinate components (e.g., 'A temperature sensor crosses a threshold, and a notification fires' and 'React to sensor data: trigger an alert or an actuator when a reading crosses a threshold'), which requires writing a custom module rather than a built-in no-code rules engine. missing for 10: a declarative/no-code rules-builder UI, scheduling/cron-style trigger config in the app, and independent/hands-on confirmation that this event-action pattern works reliably in production.

   • [claimed-docs] “Use a logic module when you need your machine to: React to sensor data... Coordinate multiple components... Run continuous processes... Sche…”
   • [claimed-docs] “React to sensor data: trigger an alert or an actuator when a reading crosses a threshold. Coordinate multiple components: read from a camera…”
   • [claimed-docs] “A camera detects an object, and a motor responds. A temperature sensor crosses a threshold, and a notification fires.”

   proof ↗⚑ flag

Bring up

1. robotics engineerSwap sensors and actuators behind stable hardware-abstraction interfaces without rewriting application code

   weight 3 · round to Viam
   Gazebo~partialclaimed5/10

   Gazebo's plugin architecture lets robot, sensor, environment, and physics-engine components be swapped as plugins (gazebo-gh-1/7, gazebo-gh-2, gazebo-docs-15), and simulated hardware is accessed via SDF/gz-transport rather than hard-coded app logic, which supports a hardware-abstraction-like workflow. However, the evidence never explicitly discusses interface stability guarantees or confirms application code is untouched when swapping sensors/actuators. Missing for 10: explicit documentation of stable/versioned sensor-actuator interface contracts, and case evidence that application code needed zero changes across a hardware swap.

   • [github] “Plugins: Develop custom plugins for robot, sensor, and environment control.”
   • [github] “Develop custom plugins for robot, sensor, and environment control.”
   • [github] “Dynamics simulation: Access multiple high-performance physics engines through Gazebo Physics.”
   • [claimed-docs] “A plugin based interface to physics engines, such as ODE, Bullet, and DART.”
   • [github] “Simulation models: Access numerous robots including PR2, Pioneer2 DX, iRobot Create, and TurtleBot, and construct environments using other p…”

   proof ↗⚑ flag

   Viam✓fullcommunity9/10

   Viam's docs explicitly describe standardized component APIs (e.g., GetImage() for all cameras) so swapping hardware doesn't require code changes, backed by a Registry of drivers for common hardware and a module system for unsupported hardware that then 'behaves like any built-in component.' This is corroborated by community evidence confirming the architecture is real (gRPC-based, open-source RDK) and by explicit doc statements ('If you change a camera or motor in your config, your code keeps working'). Missing for 10: independent hands-on verification from a robotics engineer swapping real hardware in production (only vendor docs and general community architecture confirmation, not a specific swap case study).

   • [claimed-docs] “Every camera component in Viam exposes the same GetImage() method regardless of brand. Same for motors, sensors, arms, and other components.”
   • [claimed-docs] “If you change a camera or motor in your config, your code keeps working.”
   • [claimed-docs] “Every camera component in Viam exposes the same GetImage() method regardless of brand... you can swap hardware without rewriting your code.”
   • [claimed-docs] “Viam’s Registry provides drivers for your hardware, so you don’t need to implement one yourself.”
   • [claimed-docs] “Search for the model that matches your hardware. Search by manufacturer or hardware type (for example, `webcam`, `viam:raspberry-pi:rpi5`, `…”
   • [claimed-docs] “When no existing model supports your hardware, you write a driver module to add one. Once it exists, the hardware behaves like any built-in …”
   • [claimed-docs] “Once it exists, the hardware behaves like any built-in component. Data capture, test panels, and the SDKs work automatically.”
   • [claimed-docs] “A driver module teaches Viam how to talk to a specific piece of hardware.”
   • [community] “The whole system is built on gRPC and everything is open source aside from the cloud app itself; you can run your own server and have multip…”

   proof ↗⚑ flag

2. robotics engineerBring up a new robot — drivers, configuration, first motion — in hours rather than weeks

   weight 3 · round to Viam
   Gazebo~partialclaimed5/10

   Gazebo provides reusable robot/sensor plugins, Fuel-hosted models (PR2, TurtleBot, etc.), SDF snippet copy-paste, and CLI tools that could speed up assembling a simulated robot and getting first motion quickly, but there is no first-party or independent evidence of an actual hours-vs-weeks bring-up workflow, driver integration, or hardware configuration case study. missing for 10: quantified bring-up time claims, driver/hardware configuration workflow evidence, independent case study or hands-on report of a new robot going from zero to first motion

   • [github] “Simulation models: Access numerous robots including PR2, Pioneer2 DX, iRobot Create, and TurtleBot, and construct environments using other p…”
   • [github] “Develop custom plugins for robot, sensor, and environment control.”
   • [claimed-docs] “click on the <> icon in the model description page... to copy an SDF snippet into your clipboard. This snippet can be pasted directly into y…”
   • [github] “Extensive command line tools for increased simulation introspection and control.”
   • [claimed-docs] “Users: For those who primarily run Gazebo using standard tools (like gz sim), edit SDFormat files, use existing plugins, and interact with r…”

   proof ↗⚑ flag

   Viam✓fullcommunity8/10

   Viam's docs describe a first-machine wizard, a hardware Registry that auto-pulls drivers, no-code web test panels to drive motors/arms immediately, and a motion-planning service for first motion — directly matching the 'drivers, config, first motion in hours' story. Community evidence (HN thread) corroborates the architecture (gRPC, open-source RDK, local caching) but raises general skepticism about production fit for industrial use rather than concretely refuting bring-up speed. Missing for 10: independent hands-on timing benchmarks proving 'hours not weeks' and a case where an engineer contradicts the ease-of-bring-up claim.

   • [claimed-docs] “Connect your first machine to the Viam platform so you can configure, control, and monitor it from anywhere. You'll create a machine in the …”
   • [claimed-docs] “Click Add machine, enter a name (for example, my-first-machine), and click Add machine again... A wizard dialog will open with the heading I…”
   • [claimed-docs] “Search for the model that matches your hardware. Search by manufacturer or hardware type (for example, `webcam`, `viam:raspberry-pi:rpi5`, `…”
   • [claimed-docs] “Drive bases with keyboard controls, move arms to specific positions, or test components directly from Viam's web interface. Debug without de…”
   • [claimed-docs] “Viam’s Registry provides drivers for your hardware, so you don’t need to implement one yourself. Specify your hardware model and connection …”
   • [claimed-docs] “Viam's motion service plans a collision-free path and executes it, using a frame system you describe and obstacles you declare.”
   • [community] “The whole system is built on gRPC and everything is open source aside from the cloud app itself; you can run your own server and have multip…”
   • [community] “Critique: 'as someone who has been building robots full time for 7 years, I am struggling to guess which real world application use cases yo…”

   proof ↗⚑ flag

Ecosystem modules

1. developerPull reusable packages or modules from a registry or ecosystem for common hardware and behaviors

   weight 1 · round to Viam
   Gazebo✓fullclaimed6/10

   Gazebo Fuel is documented as a registry/ecosystem from which developers can pull ready-made robot models (PR2, TurtleBot, etc.) and physically accurate environment models, and the docs show copying SDF snippets directly from a model's Fuel page into a project; plugins extend hardware/behavior reuse further. missing for 10: no evidence of versioning/dependency management, search/discovery tooling details, or independent hands-on corroboration of the Fuel registry experience.

   • [github] “Simulation models: Access numerous robots including PR2, Pioneer2 DX, iRobot Create, and TurtleBot, and construct environments using other p…”
   • [github] “Access numerous robots including PR2, Pioneer2 DX, iRobot Create, and TurtleBot, and construct environments using other physically accurate …”
   • [claimed-docs] “click on the <> icon in the model description page... to copy an SDF snippet into your clipboard. This snippet can be pasted directly into y…”
   • [github] “Plugins: Develop custom plugins for robot, sensor, and environment control.”
   • [github] “Develop custom plugins for robot, sensor, and environment control.”

   proof ↗⚑ flag

   Viam✓fullclaimed8/10

   Viam has a Registry providing pre-built drivers/modules for common hardware (cameras, motors, arms, sensors) that viam-server pulls automatically based on config, plus 'pre-built modules or build your own' for reusable behaviors, and searchable models by manufacturer/type. This is well-documented first-party but lacks independent hands-on corroboration of registry breadth/quality. Missing for 10: independent/community verification of registry module quality and coverage, and any registry browsing UI/API evidence beyond docs claims.

   • [claimed-docs] “Viam's Registry provides drivers for your hardware, so you don't need to implement one yourself.”
   • [claimed-docs] “Viam’s Registry provides drivers for your hardware, so you don’t need to implement one yourself.”
   • [claimed-docs] “Viam’s Registry provides drivers for your hardware, so you don’t need to implement one yourself. Specify your hardware model and connection …”
   • [claimed-docs] “Modular Components: Pre-built modules or build your own in any language”
   • [claimed-docs] “Search for the model that matches your hardware. Search by manufacturer or hardware type (for example, `webcam`, `viam:raspberry-pi:rpi5`, `…”
   • [claimed-docs] “When no existing model supports your hardware, you write a driver module to add one. Once it exists, the hardware behaves like any built-in …”
   • [claimed-docs] “A driver module teaches Viam how to talk to a specific piece of hardware.”
   • [github] “Multiple SDKs are available for writing client applications that interface with the Viam RDK.”

   proof ↗⚑ flag

Sensors

1. robotics engineerIntegrate cameras, lidars, IMUs, and GPS with ready-made drivers and standard message types

   weight 2 · round to Viam
   Gazebo~partialclaimed4/10

   Evidence confirms Gazebo supports sensor/robot plugins generally (gazebo-gh-7) and ROS integration via ros_gz (gazebo-docs-9, gazebo-docs-13, gazebo-docs-18), implying standard message compatibility, but no evidence specifically names ready-made camera, lidar, IMU, or GPS driver plugins or standard message types used. missing for 10: explicit documentation of built-in sensor plugin types (camera/lidar/IMU/GPS), confirmation of standard ROS/Gazebo message schemas for each, and hands-on verification of sensor bring-up.

   • [github] “Develop custom plugins for robot, sensor, and environment control.”
   • [claimed-docs] “This document provides guidance on using different versions of ROS in combination with different versions of Gazebo.”
   • [claimed-docs] “This document provides guidance on using different versions of ROS in combination with different versions of Gazebo. We recommend reading it…”
   • [claimed-docs] “The following command will install the correct version of Gazebo and ros_gz for your ROS installation on a Linux system.”

   proof ↗⚑ flag

   Viam✓fullclaimed8/10

   Viam's Registry provides a searchable catalog of pre-built driver modules for cameras, arms, sensors, and other hardware (explicitly matching by manufacturer/type e.g. webcam, rpi5, xArm6), with standard component APIs like GetImage() ensuring uniform message types across brands, and modules for unsupported hardware can be added easily. Docs and SDK repo corroborate multi-language SDK support and automatic driver initialization from config. Missing for 10: explicit named lidar/IMU/GPS driver examples in the Registry and independent hands-on validation of driver quality/breadth beyond vendor docs.

   • [claimed-docs] “Every camera component in Viam exposes the same GetImage() method regardless of brand. Same for motors, sensors, arms, and other components.”
   • [claimed-docs] “Viam's Registry provides drivers for your hardware, so you don't need to implement one yourself.”
   • [claimed-docs] “Viam’s Registry provides drivers for your hardware, so you don’t need to implement one yourself. Specify your hardware model and connection …”
   • [claimed-docs] “Search for the model that matches your hardware. Search by manufacturer or hardware type (for example, `webcam`, `viam:raspberry-pi:rpi5`, `…”
   • [claimed-docs] “When no existing model supports your hardware, you write a driver module to add one. Once it exists, the hardware behaves like any built-in …”
   • [claimed-docs] “Every camera component in Viam exposes the same GetImage() method regardless of brand... you can swap hardware without rewriting your code.”
   • [claimed-docs] “A driver module teaches Viam how to talk to a specific piece of hardware.”
   • [github] “Multiple SDKs are available for writing client applications that interface with the Viam RDK.”

   proof ↗⚑ flag

Data

1. developerQuery and export collected robot data through an API or SQL for offline analysis

   weight 2 · round to Viam
   Gazebo—none0/10

   No evidence of any SQL database, data export tool, or query API for offline analysis of collected robot/simulation data; evidence only covers transport messaging, plugins, and CLI simulation control, and API probes for OpenAPI/docs endpoints returned 404.

   ⚑ flag

   Viam✓fullclaimed8/10

   Viam's CLI explicitly supports SQL and MQL querying of tabular/binary data with export to a destination path, plus data management APIs and SDKs for programmatic access, directly satisfying the story. missing for 10: independent/hands-on confirmation of SQL export workflow and details on API-based (non-CLI) query mechanics beyond docs.

   • [claimed-docs] “viam data query tabular sql --org-id=<org-id> --sql=<query> [--destination=<output path>]”
   • [claimed-docs] “With it, you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all…”
   • [claimed-docs] “you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all data tha…”
   • [claimed-docs] “query tabular or binary data with SQL or MQL, delete data, add or remove tags from all data that matches a given filter”
   • [claimed-docs] “Data Management: Collect, store, and query sensor data and telemetry”

   proof ↗⚑ flag

Deploy

1. developerRun automated tests of robot software in CI, including simulation-based regression tests

   weight 2 · round to Gazebo
   Gazebo~partialclaimed4/10

   Gazebo supports headless server-only execution and CLI-driven simulation control, which are prerequisites for CI-based regression testing, but there is no evidence of a documented CI integration, test harness, or automated regression-test framework/examples. missing for 10: CI pipeline examples (e.g. GitHub Actions), automated test/assertion framework for simulation regression, documented headless test workflows, third-party corroboration of CI usage.

   • [claimed-docs] “Gazebo Sim can also be run headless, i.e. without the GUI, by using the -s (server only) flag.”
   • [claimed-docs] “the gz-sim10-server package provides a lightweight alternative. It installs only the Gazebo simulation server (gz-sim-server) without any GU…”
   • [github] “Command line tools: Extensive command line tools for increased simulation introspection and control.”
   • [github] “TCP/IP Transport: Run simulation on remote servers and interface to Gazebo Sim through socket-based message passing using Gazebo Transport.”

   proof ↗⚑ flag

   Viam—none0/10

   No evidence describes CI integration, automated test pipelines, or simulation-based regression testing for robot software; docs only mention manual web-based test panels and debugging tools, which is a different capability.

   • [claimed-docs] “Drive bases with keyboard controls, move arms to specific positions, or test components directly from Viam's web interface. Debug without de…”
   • [claimed-docs] “Once it exists, the hardware behaves like any built-in component. Data capture, test panels, and the SDKs work automatically.”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Viam
   Gazebo~partialclaimed5/10

   Gazebo can run fully headless via the `-s` server flag and exposes CLI tools plus gz-transport for programmatic introspection/control, suggesting most simulation functionality is scriptable outside the GUI. However, there is no explicit documentation claiming full feature parity between the GUI (which is plugin-based and includes visualization-only components) and the API/CLI surface. Missing for 10: an explicit statement or evidence that every GUI capability (especially visualization/plugin-specific GUI features) is exposed via API/CLI, and any third-party confirmation of parity.

   • [claimed-docs] “Gazebo Sim can also be run headless, i.e. without the GUI, by using the -s (server only) flag.”
   • [claimed-docs] “the GUI can be run independently using the -g (gui only) flag. On start, the GUI will attempt to connect to a server instance.”
   • [claimed-docs] “Gazebo Sim can also be run headless, i.e. without the GUI, by using the `-s` (server only) flag.”
   • [github] “Command line tools: Extensive command line tools for increased simulation introspection and control.”
   • [github] “Run simulation on remote servers and interface to Gazebo Sim through socket-based message passing using Gazebo Transport.”
   • [claimed-docs] “A framework for graphical user interfaces centered around QT. Each component in Gazebo GUI is an independent plugin”

   proof ↗⚑ flag

   Viam✓fullprobed8/10

   Viam explicitly documents that AI agents can operate machines identically to UI/human users: 'An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can' and 'The CLI can call any API method a machine serves, with JSON in and JSON out; no code to write.' Fleet management, data query/export, motion planning, and component control are all exposed via CLI/SDK/API (viam-docs-11, 13, 20, 23, 30-34), mirroring UI capabilities like test panels and driving components (viam-docs-6). Missing for 10: a discoverable OpenAPI spec (probe found 404s across candidate paths) and independent/hands-on confirmation that every UI action (e.g., dataset annotation workflows) has a full API equivalent.

   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out; no code to write.”
   • [claimed-docs] “With it you can create and manage organizations, locations, and individual machines, manage permissions and authorization, create and manage…”
   • [claimed-docs] “create and manage organizations, locations, and individual machines; manage permissions and authorization; create and manage fragments”
   • [claimed-docs] “viam data query tabular sql --org-id=<org-id> --sql=<query> [--destination=<output path>]”
   • [claimed-docs] “With it, you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all…”
   • [claimed-docs] “you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all data tha…”
   • [claimed-docs] “Drive bases with keyboard controls, move arms to specific positions, or test components directly from Viam's web interface. Debug without de…”
   • [claimed-docs] “Plan motion through the motion service rather than commanding joints or poses directly. `Move` takes a goal pose in any frame, plus obstacle…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.viam.com/openapi.json, https://docs.viam.com/swagger.json, https://docs.viam.com/api/op…”

   proof ↗⚑ flag

2. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   Gazebo~partialclaimed5/10

   Evidence confirms the source code is publicly hosted on GitHub (github.com/gazebosim/gz-sim) with docs describing internals, implying open availability, but no citation explicitly states an open-source license (e.g., Apache-2.0) or links a LICENSE file. Missing for 10: explicit license text/citation, confirmation of license type, and any independent verification of licensing terms.

   • [github] “Plugins: Develop custom plugins for robot, sensor, and environment control.”
   • [github] “Graphical interface: Create, introspect and interact with your simulations through plugin-based graphical interfaces powered by Gazebo GUI.”
   • [claimed-docs] “Developers: For those who use individual Gazebo libraries (like gz-math, sdformat, or gz-transport) directly in their own C++ applications, …”

   proof ↗⚑ flag

   Viam~partialcommunity5/10

   A Hacker News community comment states the core RDK is open source on GitHub (github.com/viamrobotics/rdk) while the cloud app itself is closed, which is corroborated by a GitHub reference. However, no first-party documentation confirms an explicit open-source license, and another commenter expresses uncertainty about how much of the codebase is genuinely open, indicating the openness story is only partially substantiated. missing for 10: explicit license file/name in first-party docs, clarity on which components (SDKs, modules, app) are covered vs proprietary, and confirmation the readable source is complete rather than partial.

   • [community] “The whole system is built on gRPC and everything is open source aside from the cloud app itself; you can run your own server and have multip…”
   • [community] “User concern: 'I see there is a lot on Github but I'm a bit unsure how much is actually Open Source... I'd be concerned to use one in produc…”
   • [github] “Multiple SDKs are available for writing client applications that interface with the Viam RDK.”

   proof ↗⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round to Gazebo
   Gazebo✓fullclaimed8/10

   Gazebo is open-source, self-installable software with documented server-only installs (gz-sim10-server package, headless -s flag) and remote TCP/IP transport for running simulation on remote servers, enabling full self-hosting of the core simulation engine. missing for 10: no explicit containerized/docker self-hosting guide or independent third-party confirmation of a full self-hosted deployment at scale.

   • [claimed-docs] “Gazebo Sim can also be run headless, i.e. without the GUI, by using the -s (server only) flag.”
   • [claimed-docs] “the gz-sim10-server package provides a lightweight alternative. It installs only the Gazebo simulation server (gz-sim-server) without any GU…”
   • [claimed-docs] “Gazebo Sim can also be run headless, i.e. without the GUI, by using the `-s` (server only) flag.”
   • [claimed-docs] “It installs only the Gazebo simulation server (`gz-sim-server`) without any GUI or Qt dependencies, resulting in a significantly smaller ins…”
   • [github] “TCP/IP Transport: Run simulation on remote servers and interface to Gazebo Sim through socket-based message passing using Gazebo Transport.”
   • [github] “Run simulation on remote servers and interface to Gazebo Sim through socket-based message passing using Gazebo Transport.”

   proof ↗⚑ flag

   Viam~partialcommunity6/10

   viam-server (the core robot software / RDK) is open source and runs locally on the user's own compute device, and community evidence confirms it can operate fully offline/self-hosted with robots talking to each other without outside communication, but the management 'cloud app' itself remains a proprietary hosted service not shown to be self-hostable, and a community commenter voices uncertainty about how much is genuinely open source. Missing for 10: first-party documentation for self-hosting the full fleet-management/app layer, and resolution of community doubts about open-source scope and production robustness.

   • [community] “The whole system is built on gRPC and everything is open source aside from the cloud app itself; you can run your own server and have multip…”
   • [community] “Internet access is optional/intermittent for Viam robots: if connectivity is lost, the robot operates fine until the TLS cert expires (30+ d…”
   • [community] “User concern: 'I see there is a lot on Github but I'm a bit unsure how much is actually Open Source... I'd be concerned to use one in produc…”
   • [claimed-docs] “Connect your first machine to the Viam platform so you can configure, control, and monitor it from anywhere. You'll create a machine in the …”
   • [claimed-docs] “Click Add machine, enter a name (for example, my-first-machine), and click Add machine again... A wizard dialog will open with the heading I…”

   proof ↗⚑ flag

Safety

1. ops leadControl with roles and permissions who is allowed to command, configure, or view each robot

   weight 1 · round to Viam
   Gazebo—none0/10

   No evidence of any role-based access control, user permissions, or authentication system in Gazebo; it is a robotics simulator with no mention of RBAC or multi-user access governance.

   ⚑ flag

   Viam~partialclaimed5/10

   Viam's Fleet Management docs explicitly mention 'access control' and the Fleet API reference states you can 'manage permissions and authorization' for organizations, locations, and machines, supporting role-based access control at a high level. However, the evidence never details specific role types (e.g., viewer vs operator vs admin) or how granularly permissions map to command/configure/view actions per robot. missing for 10: granular role definitions, documentation of specific permission scopes (command vs configure vs view), independent/hands-on confirmation of RBAC enforcement.

   • [claimed-docs] “Fleet Management: Remote monitoring, access control, and OTA updates”
   • [claimed-docs] “With it you can create and manage organizations, locations, and individual machines, manage permissions and authorization, create and manage…”
   • [claimed-docs] “create and manage organizations, locations, and individual machines; manage permissions and authorization; create and manage fragments”
   • [claimed-docs] “With it you can create and manage organizations, locations, and individual machines; manage permissions and authorization; create and manage…”

   proof ↗⚑ flag

2. robotics engineerImplement emergency-stop and safety-interlock patterns the platform documents and supports

   weight 3 · round drawn
   Gazebo—none0/10

   While Gazebo supports custom plugins for robot/sensor/environment control and command-line introspection tools that could theoretically be used to build safety logic, none of the evidence mentions emergency-stop, safety-interlock, or any documented safety pattern/support specifically. missing for 10: any documentation or example referencing e-stop or safety-interlock patterns, guidance on implementing safety-critical control logic, or built-in safety plugin APIs.

   • [github] “Plugins: Develop custom plugins for robot, sensor, and environment control.”
   • [github] “Develop custom plugins for robot, sensor, and environment control.”
   • [github] “Extensive command line tools for increased simulation introspection and control.”
   • [claimed-docs] “Developers: For those who use individual Gazebo libraries (like gz-math, sdformat, or gz-transport) directly in their own C++ applications, …”

   proof ↗⚑ flag

   Viam—none0/10

   The evidence shows general capabilities like motion planning with obstacle avoidance (viam-docs-14/22/39) and logic modules that can react to sensor thresholds (viam-docs-17/38/46), which could theoretically be used to build custom safety logic, but there is no documentation of an emergency-stop primitive, safety-interlock pattern, safety-rated I/O, or any dedicated safety/E-stop API or guide anywhere in the pack.

   ⚑ flag

Sdk agentic

1. ai-native userHave an AI agent authenticate with scoped credentials and command a real robot end-to-end through the platform's API or SDK

   weight 3 · round to Viam
   Gazebo—none0/10

   Evidence describes Gazebo as a physics simulator with C++/plugin APIs, transport messaging, and CLI tools for simulated robots, but there is no mention of authentication, scoped credentials, or any mechanism for an AI agent to command a real (non-simulated) robot end-to-end via an API/SDK. Probes for API/auth surfaces (llms.txt, openapi.json) also returned 404s.

   • [github] “TCP/IP Transport: Run simulation on remote servers and interface to Gazebo Sim through socket-based message passing using Gazebo Transport.”
   • [github] “Run simulation on remote servers and interface to Gazebo Sim through socket-based message passing using Gazebo Transport.”
   • [github] “Simulation models: Access numerous robots including PR2, Pioneer2 DX, iRobot Create, and TurtleBot, and construct environments using other p…”
   • [github] “Access numerous robots including PR2, Pioneer2 DX, iRobot Create, and TurtleBot, and construct environments using other physically accurate …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gazebosim.org/openapi.json, https://gazebosim.org/swagger.json, https://gazebosim.org/api/op…”

   proof ↗⚑ flag

   Viam✓fullclaimed8/10

   Viam has a dedicated doc page explicitly framing this exact story—'An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can'—and details how an agent lists resources/status, drives motion via the motion service, and calls any API method via CLI or SDK with JSON in/out. Fleet/auth docs show permission and authorization management at org/location/machine granularity, supporting scoped credentials, and the platform provides multi-language SDKs (Python, Go, C++, TypeScript, Flutter) plus a CLI for end-to-end control. Missing for 10: a concrete walkthrough of creating/scoping an API key specifically for an agent, and independent/hands-on corroboration beyond first-party docs.

   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [claimed-docs] “Plan motion through the motion service rather than commanding joints or poses directly. `Move` takes a goal pose in any frame, plus obstacle…”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out; no code to write.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out.”
   • [claimed-docs] “With it you can create and manage organizations, locations, and individual machines, manage permissions and authorization, create and manage…”
   • [claimed-docs] “create and manage organizations, locations, and individual machines; manage permissions and authorization; create and manage fragments”
   • [claimed-docs] “Write your control logic in Python or Go, get lower-level control with C++, or build a client application with Typescript or Flutter.”
   • [github] “Multiple SDKs are available for writing client applications that interface with the Viam RDK.”

   proof ↗⚑ flag

2. ai-native userIntegrate vision-language-action or robotics foundation models into my robot's autonomy stack through supported tooling

   weight 2 · round to Viam
   Gazebo—none0/10

   Evidence covers Gazebo's general plugin architecture, transport, physics engines, and ROS integration, but there is no mention of VLA models, robotics foundation models, or any supported tooling/SDK for integrating such models into an autonomy stack. Nothing in the pack ties Gazebo to AI/foundation-model integration workflows.

   ⚑ flag

   Viam~partialclaimed4/10

   Viam documents generic ML model training/deployment ('bring your own model', push trained models to cloud for local inference) and a motion-planning service that could host custom control logic, which together could support integrating a VLA or robotics foundation model — but no evidence specifically mentions VLA, foundation models, or dedicated tooling/integrations for such models. Missing for 10: explicit VLA/foundation-model support, documented integration examples, prebuilt model-hub connectors, or partner/third-party corroboration of foundation-model deployment on Viam.

   • [claimed-docs] “Create and annotate datasets, and train ML models in your chosen architecture, all through the cloud. Or bring your own model.”
   • [claimed-docs] “Push trained models to the cloud. Machines pull them automatically and run inference locally. Version, stage, and roll back models just like…”
   • [claimed-docs] “Viam's motion service plans a collision-free path and executes it, using a frame system you describe and obstacles you declare.”
   • [claimed-docs] “Viam’s motion service plans a collision-free path and executes it, using a frame system you describe and obstacles you declare.”
   • [claimed-docs] “Built-in motion and vision”

   proof ↗⚑ flag

Sdks

1. developerBuild against official, typed SDKs in multiple languages (Python, TypeScript, Go, C++) that cover the platform's full surface

   weight 3 · round to Viam
   Gazebo—none0/10

   Evidence shows Gazebo is primarily a C++ library/simulator with plugin APIs, ROS integration, and CLI tools, but there is no mention of official typed SDKs in Python, TypeScript, or Go, nor any unified multi-language SDK covering the platform surface. Missing for 10: Python/TypeScript/Go SDK docs, typed client libraries, and evidence of full API-surface coverage across languages.

   • [claimed-docs] “Developers: For those who use individual Gazebo libraries (like gz-math, sdformat, or gz-transport) directly in their own C++ applications, …”
   • [claimed-docs] “If your package directly depends on a Gazebo library, instead of relying only on ros_gz, refer to this documentation to learn how to use the…”
   • [github] “Plugins: Develop custom plugins for robot, sensor, and environment control.”

   proof ↗⚑ flag

   Viam✓fullprobed7/10

   Viam's docs explicitly state that developers can write control logic in Python, Go, C++, and TypeScript (plus Flutter), and GitHub confirms multiple official SDKs exist for the RDK, directly matching the story's language list. However, there's no independent verification of full API-surface parity across all SDKs or detailed typed-API documentation per language beyond marketing copy. Missing for 10: independent hands-on corroboration of SDK completeness/parity, and detailed reference docs showing full API coverage per language.

   • [claimed-docs] “Write your control logic in Python or Go, get lower-level control with C++, or build a client application with Typescript or Flutter.”
   • [github] “Multiple SDKs are available for writing client applications that interface with the Viam RDK.”
   • [claimed-docs] “Every camera component in Viam exposes the same GetImage() method regardless of brand... you can swap hardware without rewriting your code.”
   • [probe] “official CLI documented at https://docs.viam.com/cli/reference/”

   proof ↗⚑ flag

Sim

1. robotics engineerSimulate my robot and its environment with realistic physics and sensor models before touching hardware

   weight 3 · round to Gazebo
   Gazebo✓fullclaimed7/10

   Gazebo's core purpose is physics-and-sensor simulation: docs/GitHub evidence confirms multiple physics engines (ODE, Bullet, DART), plugin-based sensor and robot control, access to physically accurate robot/environment models via Fuel, and SDF-based world/robot description before hardware deployment. Missing for 10: independent/hands-on validation of sensor model realism (e.g. lidar/camera noise fidelity) and no third-party benchmark or case study corroborating physics accuracy claims beyond vendor docs.

   • [github] “Dynamics simulation: Access multiple high-performance physics engines through Gazebo Physics.”
   • [claimed-docs] “A plugin based interface to physics engines, such as ODE, Bullet, and DART.”
   • [github] “Plugins: Develop custom plugins for robot, sensor, and environment control.”
   • [github] “Simulation models: Access numerous robots including PR2, Pioneer2 DX, iRobot Create, and TurtleBot, and construct environments using other p…”
   • [github] “Graphical interface: Create, introspect and interact with your simulations through plugin-based graphical interfaces powered by Gazebo GUI.”
   • [claimed-docs] “click on the <> icon in the model description page... to copy an SDF snippet into your clipboard. This snippet can be pasted directly into y…”

   proof ↗⚑ flag

   Viam—none0/10

   No evidence anywhere in the pack mentions simulation, physics engines, digital twins, or sensor-model simulation; the documented capability set (real hardware drivers, motion planning against physical machines, fleet management, data capture) is entirely about operating and managing real hardware, not simulating it before deployment. missing for 10: any mention of a simulator/physics engine, virtual sensor models, or a documented sim-to-real workflow.

   ⚑ flag

2. robotics engineerRun the same robot code against simulation and the real robot without a rewrite

   weight 2 · round to Gazebo
   Gazebo~partialclaimed5/10

   Gazebo's plugin/transport architecture and ROS integration (ros_gz, TCP/IP transport, command-line/introspection tools) suggest that robot control code communicating via standard ROS topics/services could target both simulated and real robots, but no evidence explicitly describes a sim-to-real code-reuse workflow or hardware-in-the-loop testing. missing for 10: explicit documentation or case study of running identical control code against simulated and physical robots, no independent corroboration of a no-rewrite workflow.

   • [github] “TCP/IP Transport: Run simulation on remote servers and interface to Gazebo Sim through socket-based message passing using Gazebo Transport.”
   • [github] “Run simulation on remote servers and interface to Gazebo Sim through socket-based message passing using Gazebo Transport.”
   • [claimed-docs] “If your package directly depends on a Gazebo library, instead of relying only on ros_gz, refer to this documentation to learn how to use the…”
   • [claimed-docs] “This document provides guidance on using different versions of ROS in combination with different versions of Gazebo.”
   • [github] “Develop custom plugins for robot, sensor, and environment control.”

   proof ↗⚑ flag

   Viam—none0/10

   Viam's evidence shows strong hardware abstraction (same API across camera/motor brands, swap hardware without rewriting code) and driver registry, which is architecturally adjacent to sim-to-real, but there is no mention anywhere of a simulation environment, simulated components, digital twin, or explicit sim-to-real workflow. The axis is fair for a robotics platform, but no evidence demonstrates Viam actually supports running the same code against a simulated robot.

   ⚑ flag

Teleop

1. robotics engineerInspect live topics, logs, and state on a deployed robot remotely to debug issues

   weight 2 · round to Viam
   Gazebo~partialclaimed5/10

   Gazebo provides remote TCP/IP transport (gz-transport) for interfacing with simulations over the network, a headless server mode, and extensive CLI tools for 'simulation introspection and control', which could plausibly extend to inspecting topics/state on a running (simulated or transport-connected) robot. However, none of the evidence explicitly addresses inspecting logs or state on a physically deployed robot, or dedicated remote debugging/monitoring dashboards. Missing for 10: log inspection tooling, explicit remote/robot (non-simulated) debugging workflow, and independent hands-on confirmation of remote monitoring in production robot deployments.

   • [github] “TCP/IP Transport: Run simulation on remote servers and interface to Gazebo Sim through socket-based message passing using Gazebo Transport.”
   • [github] “Run simulation on remote servers and interface to Gazebo Sim through socket-based message passing using Gazebo Transport.”
   • [github] “Extensive command line tools for increased simulation introspection and control.”
   • [github] “Command line tools: Extensive command line tools for increased simulation introspection and control.”
   • [claimed-docs] “Gazebo Sim can also be run headless, i.e. without the GUI, by using the -s (server only) flag.”
   • [claimed-docs] “Gazebo Sim can also be run headless, i.e. without the GUI, by using the `-s` (server only) flag.”
   • [github] “Graphical interface: Create, introspect and interact with your simulations through plugin-based graphical interfaces powered by Gazebo GUI.”

   proof ↗⚑ flag

   Viam✓fullclaimed7/10

   Viam docs show real-time remote visibility into machine state, sensor data, and camera feeds from the browser (viam-docs-5, viam-docs-6), machine status/resource health via GetMachineStatus (viam-docs-31), and cloud-managed fleet monitoring/alerting (viam-docs-10, viam-docs-26). NAT traversal (viam-docs-4) supports remote access to deployed robots without networking hassle. missing for 10: explicit documentation of a dedicated 'logs' viewer/log streaming feature (only alerting/monitoring and state inspection are directly evidenced, not log tailing specifically), and independent hands-on confirmation of the debugging workflow in production.

   • [claimed-docs] “Write code in your local IDE and execute it against hardware in the field. Stream camera feeds, read sensor data, and visualize machine stat…”
   • [claimed-docs] “Drive bases with keyboard controls, move arms to specific positions, or test components directly from Viam's web interface. Debug without de…”
   • [claimed-docs] “Fleet Management: Remote monitoring, access control, and OTA updates”
   • [claimed-docs] “Cloud-managed fleet monitoring and alerting; OTA updates for software and ML models; Canary testing and rollbacks for safe versioning”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [claimed-docs] “Built-in NAT traversal means you connect to any machine through firewalls and routers. No port forwarding, no networking configuration, no "…”
   • [claimed-docs] “Connect your first machine to the Viam platform so you can configure, control, and monitor it from anywhere. You'll create a machine in the …”

   proof ↗⚑ flag