ROS 2 vs Viam

Agent access

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

   weight 2 · round to Viam
   ROS 2—none0/10

   No evidence of an llms.txt file, agent-oriented documentation format, or any mention of AI agent-targeted docs; the evidence pack only covers standard human-oriented ROS 2 documentation and community discussion.

   ⚑ 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 Viam
   ROS 2~partialclaimed5/10

   ROS 2 documents a headless-capable install (ROS-Base 'Bare Bones' with no GUI tools) plus a full CLI toolset (ros2 command, topic pub, bag record/play) that can be scripted for automation, supporting non-interactive/CI-style operation. However there's no explicit documentation of CI pipelines, Docker images, or automated test harnesses for ROS 2 itself. Missing for 10: explicit CI/automation docs or examples, containerized/headless deployment guidance, and independent evidence of running ROS 2 in a CI pipeline.

   • [claimed-docs] “ROS-Base Install (Bare Bones): Communication libraries, message packages, command line tools. No GUI tools.”
   • [claimed-docs] “ROS 2 includes a suite of command-line tools for introspecting a ROS 2 system.”
   • [claimed-docs] “The main entry point for the tools is the command ros2, which itself has various sub-commands for introspecting and working with nodes, topi…”
   • [claimed-docs] “$ ros2 topic pub /chatter std_msgs/msg/String "data: Hello world"”
   • [claimed-docs] “bag: Record/play a rosbag”
   • [claimed-docs] “ROS 2 runs a background daemon process that maintains information about the ROS graph to provide faster responses to queries, such as the li…”

   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
   ROS 2—none0/10

   ROS 2 is a robotics middleware/framework, not an AI agent — publishing an official MCP server is a plausible ecosystem capability, but no evidence in the pack mentions MCP, agent connectivity, or any AI-agent integration server. Missing for 10: any mention of an official MCP server, MCP protocol support, or agent-facing API for ROS 2.

   ⚑ 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 drawn
   ROS 2✓fullclaimed8/10

   ROS 2 ships an official, extensively documented `ros2` CLI with sub-commands for nodes, topics, services, bags, security, etc., making it fully scriptable and usable by any automated/agentic caller. Missing for 10: explicit documentation or examples targeting AI-agent/automated usage patterns, and independent hands-on confirmation of CLI reliability for such workflows.

   • [claimed-docs] “ROS 2 includes a suite of command-line tools for introspecting a ROS 2 system.”
   • [claimed-docs] “Command-line introspection tools using an extensible framework”
   • [claimed-docs] “The main entry point for the tools is the command ros2, which itself has various sub-commands for introspecting and working with nodes, topi…”
   • [claimed-docs] “ros2 topic pub /chatter std_msgs/msg/String "data: Hello world"”
   • [claimed-docs] “bag: Record/play a rosbag”
   • [claimed-docs] “ROS 2 runs a background daemon process that maintains information about the ROS graph to provide faster responses to queries, such as the li…”
   • [claimed-docs] “$ ros2 topic pub /chatter std_msgs/msg/String "data: Hello world"”

   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
   ROS 2✓fullcommunity7/10

   ROS 2 exposes a well-documented public API surface — client libraries in multiple languages (rclpy/rclcpp) for nodes, topics, services, actions, parameters, plus an extensible CLI (`ros2 topic`, `ros2 service`, `ros2 bag`, etc.) and Python APIs for bag recording — all of which let an external program or agent drive the system programmatically. Missing for 10: no explicit mention of AI-agent-specific SDKs, and community commentary flags friction/complexity in actually using these APIs in practice (dependency hell, steep learning curve), so real-world ease for an AI-native driver is unproven.

   • [claimed-docs] “Client libraries come in a variety of programming languages so that users may write ROS 2 code in the language that is best-suited for their…”
   • [claimed-docs] “ROS 2 includes a suite of command-line tools for introspecting a ROS 2 system.”
   • [claimed-docs] “$ ros2 topic pub /chatter std_msgs/msg/String "data: Hello world"”
   • [claimed-docs] “Topics: For continuous data streams. Services: For synchronous request/response interactions. Actions: For long-running tasks with feedback”
   • [claimed-docs] “It also provides a Python API for reading from and writing to a bag from your own source code.”
   • [claimed-docs] “Set/retrieve parameters”
   • [claimed-docs] “The main entry point for the tools is the command ros2, which itself has various sub-commands for introspecting and working with nodes, topi…”
   • [community] “I've been a ROS 1 (and now 2) user since 2010... ROS gives you some important things 'for free' if you cooperate with its ecosystem conventi…”
   • [community] “I'm really struggling in learning ROS in a systematic way. The tutorials are all over the place and somehow unorganized IMO. When trying to …”

   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 userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   ROS 2~partialclaimed4/10

   ROS 2's security framework (sros2/DDS-Security) lets you create a keystore and define per-participant 'security enclaves' that encapsulate a distinct authentication/authorization policy, which maps loosely onto the idea of scoped, least-privilege credentials issued to individual nodes/agents. However this is a general robotics middleware security feature, not an API-credential system designed for AI agents, and there's no documented workflow for dynamically issuing/revoking scoped tokens to an 'agent' persona. Missing for 10: agent-oriented credential issuance workflow, dynamic/temporary scoped tokens, any AI-agent-specific access control examples, and independent evidence of least-privilege enforcement in practice.

   • [claimed-docs] “ROS 2 includes the ability to secure communications among nodes within the ROS 2 computational graph.”
   • [claimed-docs] “A security enclave encapsulates a single policy for protecting ROS communications.”
   • [claimed-docs] “The `sros2` package provides the tools and instructions to use ROS 2 on top of DDS-Security.”
   • [claimed-docs] “DDS-Security support”
   • [claimed-docs] “Built-in ROS 2 security features enable control over communications throughout the ROS graph. This not only allows for encrypting data in tr…”
   • [claimed-docs] “ros2 security create_keystore demo_keystore”

   proof ↗⚑ flag

   Viam~partialclaimed4/10

   Viam's Fleet API/CLI documentation mentions the ability to 'manage permissions and authorization' at the org/location/machine level (viam-docs-20/34/43), and machine credentials are auto-injected for hosted apps (viam-docs-52), implying some access-control primitives exist. However, there is no explicit documentation of issuing scoped or least-privilege API keys/tokens specifically for AI agents, nor any agent-specific credential-scoping workflow beyond generic 'permissions and authorization' management. Missing for 10: explicit API key/token scoping mechanism, agent-specific credential issuance docs, and any least-privilege role examples tied to agent use.

   • [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…”
   • [claimed-docs] “A web app hosted by Viam at `{name}_{namespace}.viamapplications.com`. Auth and machine credentials are injected automatically.”
   • [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.”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Viam
   ROS 2✓fullclaimed7/10

   ROS 2 ships official client libraries (rclcpp, rclpy, etc.) that expose the core ROS 2 functionality, letting developers build in the language best suited to their application, and this is the backbone of any ROS 2 application development (ros2-docs-7, ros2-docs-35, ros2-docs-36, ros2-docs-21). This constitutes an official SDK story that any AI-native builder could target when writing perception/planning nodes. Missing for 10: explicit AI-agent-oriented SDK features or examples (e.g., LLM/agent integration guides), broader language coverage beyond C++/Python emphasis, and independent hands-on corroboration of SDK ergonomics.

   • [claimed-docs] “Client libraries come in a variety of programming languages so that users may write ROS 2 code in the language that is best-suited for their…”
   • [claimed-docs] “Client libraries come in a variety of programming languages so that users may write ROS 2 code in the language that is best-suited for their…”
   • [claimed-docs] “client libraries expose to users the core functionality that makes ROS "ROS"”
   • [claimed-docs] “you might prefer to write visualization tools in Python because it makes prototyping iterations faster, while for parts of your system that …”

   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

Agentic features

1. ai-native userSet up automations that run autonomously in the background

   weight 2 · round drawn
   ROS 2~partialclaimed6/10

   ROS 2 provides the core building blocks for autonomous background execution — a launch system to coordinate multiple nodes, managed node lifecycles, a background daemon process maintaining graph state, and actions for long-running tasks with feedback/cancellation — which together let a robotics system run continuously and autonomously once configured. However, this is generic robotics middleware automation, not anything framed around AI-agent-triggered or AI-native workflow automation specifically. Missing for 10: explicit support for AI-driven/agentic triggering or scheduling of automations, independent hands-on evidence of long-running unattended deployments succeeding, and any AI-specific orchestration tooling.

   • [claimed-docs] “Launch system for coordinating multiple nodes”
   • [claimed-docs] “Support for nodes with managed lifecycles”
   • [claimed-docs] “ROS 2 runs a background daemon process that maintains information about the ROS graph to provide faster responses to queries, such as the li…”
   • [claimed-docs] “Actions allow clients to send goals, receive feedback during the execution, cancel if needed, and return a result if availabl”
   • [claimed-docs] “Multiple executors (at level of callback groups) in same node”

   proof ↗⚑ flag

   Viam~partialclaimed6/10

   Viam supports logic modules that react to sensor data, coordinate components, run continuous processes, and schedule actions autonomously (viam-docs-17, viam-docs-38, viam-docs-46), plus scheduled data sync and cloud automation triggers (viam-docs-7, viam-docs-9). This is genuine background automation for physical/robotic systems, but it's not framed as an AI-agent-orchestrated automation builder — it's code-based module logic requiring developer setup rather than a no-code 'set up automation' AI-native workflow. missing for 10: a dedicated no-code automation/trigger builder UI, evidence of AI-native natural-language automation setup, and independent verification that these automations run reliably unattended in production long-term.

   • [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.”
   • [claimed-docs] “Data queues locally during network outages and in low-bandwidth environments, and syncs when connectivity returns. Viam handles restarts and…”
   • [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] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”

   proof ↗⚑ flag

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

   weight 2 · round to Viam
   ROS 2—none0/10

   ROS 2's interfaces are CLI-based (ros2 command with sub-commands) and programmatic client libraries, not natural-language control; no evidence of NL command parsing, LLM integration, or agentic natural-language interface 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
   ROS 2—none0/10

   The evidence pack shows standard reStructuredText documentation, tutorials, and CLI examples, but nothing describing an interactive API reference (e.g., a searchable/browsable API explorer with runnable/executable code examples in-browser). No mention of interactive docs, sandboxed code execution, or API playgrounds.

   ⚑ 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
   ROS 2—none0/10

   ROS 2 defines interfaces via .msg/.srv/.action IDL files and provides CLI introspection tools, but no evidence in the pack shows a downloadable machine-readable API spec in OpenAPI or equivalent format for AI-native consumption. missing for 10: any OpenAPI/JSON-schema export, machine-readable spec endpoint, or documented spec-generation tool.

   ⚑ 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 ROS 2
   ROS 2~partialclaimed5/10

   ROS 2 supports Gazebo simulation (ros2-docs-16) and rosbag recording/playback (ros2-docs-17, ros2-docs-23, ros2-docs-39) which together enable testing against simulated/recorded data instead of live production systems, and separate ROS domains/DDS partitioning could isolate test traffic. However there is no explicit first-party guidance framing a dedicated 'sandbox vs production' workflow or environment isolation for AI-native testing. missing for 10: explicit sandbox/staging environment documentation, guidance on isolating test data from production ROS graphs, AI-agent-specific test harness integration, independent corroboration of safe sandbox testing practice.

   • [claimed-docs] “Launch a Simulation with Gazebo and ROS 2”
   • [claimed-docs] “It also provides a Python API for reading from and writing to a bag from your own source code.”
   • [claimed-docs] “This allows you to subscribe to a topic and save the received data to a bag at the same time as performing any other processing of your choi…”
   • [claimed-docs] “bag: Record/play a rosbag”

   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
   ROS 2—none0/10

   No evidence in the pack references API versioning policy, deprecation guidelines, or backward-compatibility guarantees for ROS 2 APIs/interfaces; the docs cover features, tools, and QoS but not a documented deprecation/versioning policy. missing for 10: documented API versioning scheme, formal deprecation policy/timeline, compatibility guarantees across releases.

   ⚑ 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 userPerform bulk operations across many items at once

   weight 2 · round to Viam
   ROS 2~partialclaimed3/10

   ROS 2's launch system lets you coordinate and start many nodes at once, and its CLI/introspection framework can operate across the whole graph (nodes, topics, services), which gives a loose analog to bulk operations, but there's no dedicated batch/bulk API (e.g., batch topic remap, bulk parameter set across nodes, mass import/export) described in the docs. Missing for 10: explicit bulk/batch operation tooling (e.g., scripted mass parameter updates, bulk topic/service operations), any evidence of an AI-native workflow performing such operations, and independent confirmation of this use case.

   • [claimed-docs] “Launch system for coordinating multiple nodes”
   • [claimed-docs] “Command-line introspection tools using an extensible framework”
   • [claimed-docs] “The main entry point for the tools is the command ros2, which itself has various sub-commands for introspecting and working with nodes, topi…”
   • [claimed-docs] “Set/retrieve parameters”

   proof ↗⚑ flag

   Viam~partialclaimed6/10

   Viam's CLI supports bulk data operations — exporting, querying, deleting, and tagging 'all data that matches a given filter' — and Fleet Management APIs let users manage many machines/organizations at once (OTA updates, permissions, fragments) rather than one-by-one. This covers bulk operations on data records and fleet-wide updates, but the evidence doesn't show a general-purpose batch API for bulk manipulating arbitrary resources (e.g., configuring many components/machines in one call) or independent confirmation of these bulk features working at scale. Missing for 10: independent/hands-on verification of bulk operations, explicit batch API for machine/component configuration beyond data tagging, and scale/performance evidence for large fleets.

   • [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] “viam data query tabular sql --org-id=<org-id> --sql=<query> [--destination=<output path>]”
   • [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…”
   • [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”

   proof ↗⚑ flag

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

   weight 3 · round to Viam
   ROS 2~partialclaimed4/10

   ROS 2's pub/sub, services, and actions model is inherently event-driven — subscribing to a topic or lifecycle event triggers a callback/action, which is a form of automatic reaction to events (ros2-docs-10, ros2-docs-24, ros2-docs-5). However, there is no evidence of a declarative 'rules engine' or AI-native trigger-condition-action system; this capability exists only as a byproduct of general-purpose programming against the pub/sub API, not as a built-in automation-rule feature. Missing for 10: a documented rules/automation-definition interface (e.g. declarative if-event-then-action config), AI-native tooling to define such rules without writing node code, and independent evidence of this pattern being used for automation purposes.

   • [claimed-docs] “Topics: For continuous data streams. Services: For synchronous request/response interactions. Actions: For long-running tasks with feedback”
   • [claimed-docs] “Actions allow clients to send goals, receive feedback during the execution, cancel if needed, and return a result if availabl”
   • [claimed-docs] “Support for nodes with managed lifecycles”
   • [claimed-docs] “Launch system for coordinating multiple nodes”

   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
   ROS 2~partialclaimed6/10

   ROS 2's core architecture—standard message packages, topics/services/actions interfaces, and multi-language client libraries—is exactly the mechanism that lets drivers for different sensors/actuators publish/subscribe to the same standardized interface, enabling swap-in-place hardware. However, the evidence pack never explicitly documents a 'hardware abstraction layer' concept, driver ecosystem practices, or a concrete example of swapping a sensor/actuator without app changes. Missing for 10: explicit hardware-abstraction/driver-interface documentation, named sensor/actuator driver packages demonstrating swap-ability, and independent hands-on confirmation that application code needs no changes when hardware is swapped.

   • [claimed-docs] “Topics: For continuous data streams. Services: For synchronous request/response interactions. Actions: For long-running tasks with feedback”
   • [claimed-docs] “The topic interface is meant for continuous data streams, for example, streaming sensor data or the status of your robot.”
   • [claimed-docs] “The service interface is meant for synchronous request/response interactions, for example, when you want to send a query requesting the conf…”
   • [claimed-docs] “Client libraries come in a variety of programming languages so that users may write ROS 2 code in the language that is best-suited for their…”
   • [claimed-docs] “Client libraries come in a variety of programming languages so that users may write ROS 2 code in the language that is best-suited for their…”
   • [claimed-docs] “ROS-Base Install (Bare Bones): Communication libraries, message packages, command line tools. No GUI tools.”
   • [claimed-docs] “client libraries expose to users the core functionality that makes ROS "ROS"”

   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
   ROS 2!disputedcontradicted5/10

   ROS 2 docs show strong building blocks for hardware bring-up (launch system for coordinating nodes, CLI tools for introspection/pub-sub, multi-language client libraries, parameters, lifecycle nodes, drivers ecosystem implied by ros2-gh-1) that in principle let an engineer wire up a robot quickly. However, independent hands-on community reports concretely contradict the 'hours not weeks' claim: reports of dependency hell, a convoluted build system, disorganized tutorials causing 'weird errors,' and even advice to budget a full 'Epic: Migrate off of ROS' once shipping — while one commenter admits it's fast only for hobbyist/prototype use, not production bring-up. Missing for 10: a first-party quantified bring-up example (e.g., time-to-first-motion tutorial) and independent corroboration that real hardware bring-up is fast, not just prototyping.

   • [claimed-docs] “Launch system for coordinating multiple nodes”
   • [claimed-docs] “Client libraries come in a variety of programming languages so that users may write ROS 2 code in the language that is best-suited for their…”
   • [claimed-docs] “ROS 2 includes a suite of command-line tools for introspecting a ROS 2 system.”
   • [github] “The Robot Operating System (ROS) is a set of software libraries and tools that help you build robot applications. From drivers to state-of-t…”
   • [community] “If you are a hobbyist, academic or garage startup, absolutely use ROS. It will take you from nothing to something faster than anything. But,…”
   • [community] “ROS is, in my opinion, dying on the industry front. It is a dependency hell; resource-heavy on embedded systems; too slow for real-time, hig…”
   • [community] “I'd love to use something other than ROS2, if for no other reason than to get rid of the dependency hell and the convoluted build system. Bu…”
   • [community] “I usually feel the same when starting something new... Installing/building ROS, the package boilerplate, etc... But then again I often end u…”
   • [community] “I'm really struggling in learning ROS in a systematic way. The tutorials are all over the place and somehow unorganized IMO. When trying to …”

   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
   ROS 2~partialcommunity4/10

   Community comments confirm a broad ecosystem of pre-built ROS drivers/nodes exists that developers rely on ('a lot of nodes and drivers out there', 'data bagging, visualization, teleop, and sim... for free'), and docs show packages are distributed via apt-installable debs (Desktop/ROS-Base installs), implying a package ecosystem. However there is no first-party documentation in the pack describing an actual registry/index (e.g. ROS Index, rosdep, ros-<distro>-* apt packages) or concrete examples of pulling hardware-specific packages. Missing for 10: explicit registry/package-manager documentation, examples of installing a specific hardware driver or behavior package, and independent corroboration beyond passing community remarks.

   • [community] “I'd love to use something other than ROS2, if for no other reason than to get rid of the dependency hell and the convoluted build system. Bu…”
   • [community] “I've been a ROS 1 (and now 2) user since 2010... ROS gives you some important things 'for free' if you cooperate with its ecosystem conventi…”
   • [community] “I usually feel the same when starting something new... Installing/building ROS, the package boilerplate, etc... But then again I often end u…”
   • [claimed-docs] “Desktop Install (Recommended): ROS, RViz, demos, tutorials.”
   • [claimed-docs] “ROS-Base Install (Bare Bones): Communication libraries, message packages, command line tools. No GUI tools.”

   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
   ROS 2~partialcommunity4/10

   Evidence confirms ROS 2 ships standard message packages and a large driver/node ecosystem in general terms (ros2-docs-44 'message packages'; ros2-comm-7 'a lot of nodes and drivers out there for ROS already'; ros2-comm-16 on standardized robotics datatypes), but there is no explicit documentation of specific camera, lidar, IMU, or GPS driver packages or sensor_msgs/standard sensor message types. missing for 10: explicit docs listing camera/lidar/IMU/GPS driver packages, sensor_msgs or NavSat message specifics, first-party hardware integration guides.

   • [claimed-docs] “ROS-Base Install (Bare Bones): Communication libraries, message packages, command line tools. No GUI tools.”
   • [community] “I'd love to use something other than ROS2, if for no other reason than to get rid of the dependency hell and the convoluted build system. Bu…”
   • [community] “ROS is popular because it's like a big collection of .proto or .thrift files for complex robotics datatypes that everyone agrees to use in t…”

   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. developerCapture sensor and telemetry data on-robot and sync it to the cloud with bandwidth-aware policies

   weight 3 · round to Viam
   ROS 2~partialclaimed3/10

   ROS 2 provides strong on-robot data capture via rosbag (record/play, Python API for custom recording) and configurable QoS policies for tuning network reliability, but there is no evidence of any built-in cloud-sync mechanism or bandwidth-aware upload policy — bags are local artifacts and QoS applies to live DDS pub/sub between nodes, not to offloading recorded data to a cloud backend. Missing for 10: cloud upload/sync capability, bandwidth-aware transfer policies, any first-party cloud integration or partner tooling for telemetry sync.

   • [claimed-docs] “It also provides a Python API for reading from and writing to a bag from your own source code.”
   • [claimed-docs] “This allows you to subscribe to a topic and save the received data to a bag at the same time as performing any other processing of your choi…”
   • [claimed-docs] “bag: Record/play a rosbag”
   • [claimed-docs] “ROS 2 offers a rich variety of Quality of Service (QoS) policies that allow you to tune communication between nodes.”
   • [claimed-docs] “With the right set of Quality of Service policies, ROS 2 can be as reliable as TCP or as best-effort as UDP, with many, many possible states…”

   proof ↗⚑ flag

   Viam✓fullcommunity8/10

   Viam's docs explicitly describe on-device data capture with a built-in data manager that queues locally during outages/low-bandwidth conditions and syncs automatically when connectivity returns, handling storage constraints and restarts (viam-docs-7, viam-docs-28, viam-docs-51). Independent community evidence corroborates offline-first behavior (cached configs, working reboots without internet) (viam-comm-1), and CLI/query tooling for the synced tabular/binary data is documented (viam-docs-11, viam-docs-23, viam-docs-33). missing for 10: granular bandwidth-throttling/scheduling policy configuration details (e.g., rate limits, sync frequency tuning) beyond generic 'low-bandwidth' handling, and independent hands-on benchmarking of sync behavior under constrained bandwidth

   • [claimed-docs] “Data queues locally during network outages and in low-bandwidth environments, and syncs when connectivity returns. Viam handles restarts and…”
   • [claimed-docs] “Data Management: Collect, store, and query sensor data and telemetry”
   • [claimed-docs] “Data capture means the built-in data manager can capture this type’s output to the Viam cloud.”
   • [community] “Internet access is optional/intermittent for Viam robots: if connectivity is lost, the robot operates fine until the TLS cert expires (30+ d…”
   • [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…”

   proof ↗⚑ flag

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

   weight 2 · round to Viam
   ROS 2~partialclaimed5/10

   ROS 2 provides rosbag2 with a Python API for reading and writing recorded data (ros2-docs-17, ros2-docs-23) and CLI tools for recording/playing bags (ros2-docs-39), enabling offline analysis of collected data programmatically. However, no evidence documents a SQL query interface or export mechanism, despite rosbag2's known SQLite backend not being mentioned in this pack. Missing for 10: explicit SQL querying/export documentation, examples of offline analysis workflows, and independent corroboration of API usability for this purpose.

   • [claimed-docs] “It also provides a Python API for reading from and writing to a bag from your own source code.”
   • [claimed-docs] “This allows you to subscribe to a topic and save the received data to a bag at the same time as performing any other processing of your choi…”
   • [claimed-docs] “bag: Record/play a rosbag”
   • [claimed-docs] “Topic statistics are built-in measurements that help you understand how messages behave when a subscription receives them.”

   proof ↗⚑ 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

Data ml

1. developerFeed collected robot data into model training and deploy the improved model back to the fleet

   weight 2 · round to Viam
   ROS 2~partialclaimed3/10

   ROS 2 provides rosbag recording/playback (ros2-docs-17, ros2-docs-23) which supports collecting robot data for later use, but there is no evidence of any built-in or documented pathway for feeding that data into model training or deploying updated models back to a robot fleet. missing for 10: model-training integration, fleet-wide model deployment/update mechanism, MLOps tooling, and any end-to-end example connecting bag data to a training loop and redeployment.

   • [claimed-docs] “It also provides a Python API for reading from and writing to a bag from your own source code.”
   • [claimed-docs] “This allows you to subscribe to a topic and save the received data to a bag at the same time as performing any other processing of your choi…”

   proof ↗⚑ flag

   Viam✓fullclaimed8/10

   Docs explicitly describe the full loop: capturing data to the cloud, creating/annotating datasets and training ML models (or bringing your own), then pushing trained models to the cloud where machines pull and run inference automatically with versioning/staging/rollback and canary testing, backed by OTA updates for ML models on the fleet. This directly matches the story of feeding data into training and deploying improved models fleet-wide. Missing for 10: independent/hands-on verification of the training-to-deployment loop working in practice and more detail on training architecture options beyond marketing copy.

   • [claimed-docs] “Data queues locally during network outages and in low-bandwidth environments, and syncs when connectivity returns. Viam handles restarts and…”
   • [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] “Cloud-managed fleet monitoring and alerting; OTA updates for software and ML models; Canary testing and rollbacks for safe versioning”
   • [claimed-docs] “Canary testing and rollbacks for safe versioning”
   • [claimed-docs] “OTA updates for software and ML models”
   • [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 drawn
   ROS 2—none0/10

   The evidence pack shows ROS 2 can launch simulations (Gazebo) and record/playback data via rosbag, but contains no documentation or evidence of automated testing frameworks (e.g., colcon test, launch_testing), CI pipeline integration, or simulation-based regression testing workflows. Without concrete evidence of a CI-oriented test harness or regression-testing tooling, the story is unevidenced even though the axis clearly applies to a robotics middleware/deployment story.

   • [claimed-docs] “Launch a Simulation with Gazebo and ROS 2”
   • [claimed-docs] “It also provides a Python API for reading from and writing to a bag from your own source code.”
   • [claimed-docs] “This allows you to subscribe to a topic and save the received data to a bag at the same time as performing any other processing of your choi…”

   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

Fleet

1. ops leadGet alerts on robot faults, battery, and connectivity so issues are caught before customers notice

   weight 2 · round to Viam
   ROS 2—none0/10

   ROS 2 docs describe core middleware capabilities (topics, services, QoS, security, CLI introspection, bag recording) but there is no evidence of any built-in alerting, notification, or ops-dashboard system that would notify an ops lead about robot faults, battery levels, or connectivity issues proactively. Diagnostics-like data could theoretically be built on top of topics, but no such alerting feature or fleet-ops tooling is documented.

   ⚑ flag

   Viam~partialclaimed6/10

   Viam explicitly markets 'Cloud-managed fleet monitoring and alerting' and machine health status APIs (GetMachineStatus reporting unhealthy/configuring resources), plus a generic pattern where 'a temperature sensor crosses a threshold and a notification fires,' which supports fault/threshold-based alerting. However, there's no explicit documentation of dedicated battery-level or connectivity-loss alert configuration, nor any hands-on/community confirmation that these alerts actually fire reliably in practice. Missing for 10: explicit battery/connectivity-specific alert setup docs, and independent evidence that alerting reliably catches issues before customers notice.

   • [claimed-docs] “Cloud-managed fleet monitoring and alerting”
   • [claimed-docs] “Cloud-managed fleet monitoring and alerting; OTA updates for software and ML models; Canary testing and rollbacks for safe versioning”
   • [claimed-docs] “A camera detects an object, and a motor responds. A temperature sensor crosses a threshold, and a notification fires.”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [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…”

   proof ↗⚑ flag

2. ops leadPush configuration changes across many robots at once with per-group targeting

   weight 2 · round to Viam
   ROS 2—none0/10

   ROS 2's documented features cover per-node parameters, launch systems for coordinating multiple nodes on one robot, and CLI introspection tools, but there is no evidence of a fleet-wide configuration push mechanism with per-group targeting across many robots — that is a higher-level fleet-management capability (e.g., separate tools like open-rmf) not shown here.

   • [claimed-docs] “Launch system for coordinating multiple nodes”
   • [claimed-docs] “Set/retrieve parameters”
   • [claimed-docs] “The main entry point for the tools is the command ros2, which itself has various sub-commands for introspecting and working with nodes, topi…”

   proof ↗⚑ flag

   Viam~partialclaimed5/10

   Viam's Fleet Management API lets you manage organizations, locations, and machines and 'create and manage fragments' — fragments are Viam's mechanism for defining shared config that can be applied across multiple machines, and locations/organizations provide a grouping structure for targeting. However, no evidence explicitly describes a workflow for pushing a config change to a defined subset/group of robots at once or shows a UI/CLI command for group-scoped rollout beyond generic OTA update mentions. missing for 10: explicit documentation of per-group/segment targeting UI or CLI command, evidence of bulk config push confirmation/rollback across a named group, independent/hands-on confirmation of fragment-based fleet-wide 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…”
   • [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] “OTA updates for software and ML models”

   proof ↗⚑ flag

3. ops leadMonitor the health, location, and status of a whole robot fleet from one dashboard

   weight 3 · round to Viam
   ROS 2—none0/10

   ROS 2 evidence covers single-robot/graph introspection (CLI tools, RViz via desktop install, topic/service introspection) but nothing about a unified dashboard aggregating health, location, and status across a whole fleet of robots — fleet-level monitoring is typically built by third-party layers on top of ROS 2, not documented here.

   • [claimed-docs] “ROS 2 includes a suite of command-line tools for introspecting a ROS 2 system.”
   • [claimed-docs] “The main entry point for the tools is the command ros2, which itself has various sub-commands for introspecting and working with nodes, topi…”
   • [claimed-docs] “Desktop Install (Recommended): ROS, RViz, demos, tutorials.”
   • [claimed-docs] “ROS 2 runs a background daemon process that maintains information about the ROS graph to provide faster responses to queries, such as the li…”

   proof ↗⚑ flag

   Viam✓fullclaimed8/10

   Viam explicitly offers cloud-managed fleet monitoring/alerting, remote monitoring, access control, and OTA updates, plus a fleet management API to manage organizations, locations, and machines, and configuration to connect and monitor machines 'from anywhere.' This covers health (GetMachineStatus, alerting), status, and centralized dashboard-style fleet management across locations. Missing for 10: explicit mention of a unified 'location' map/view or independent hands-on confirmation of the dashboard UI beyond vendor docs.

   • [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] “Cloud-managed fleet monitoring and alerting”
   • [claimed-docs] “create and manage organizations, locations, and individual machines; manage permissions and authorization; create and manage fragments”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [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

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

   weight 2 · round to Viam
   ROS 2~partialclaimed5/10

   ROS 2's architecture is fundamentally API/CLI-first: docs show that features like bag recording (ros2 bag CLI and equivalent Python API [ros2-docs-17],[ros2-docs-23]), security keystore creation (CLI [ros2-docs-42]), and topic pub/sub ([ros2-docs-9],[ros2-docs-38]) are all backed by client-library APIs, and the CLI tools themselves are described as an 'extensible framework' built on the same graph introspection layer as the daemon ([ros2-docs-30],[ros2-docs-52]). However there is no explicit documentation claiming full parity between GUI tools (e.g., RViz, which is only mentioned as part of the Desktop install [ros2-docs-51]) and the client-library APIs, nor any statement that everything visualizable/configurable in RViz can be replicated purely via API. Missing for 10: explicit API/GUI parity claim, documentation of RViz-equivalent functionality via API, and independent confirmation that AI-native/headless workflows can fully replace GUI-based configuration.

   • [claimed-docs] “ROS 2 includes a suite of command-line tools for introspecting a ROS 2 system.”
   • [claimed-docs] “$ ros2 topic pub /chatter std_msgs/msg/String "data: Hello world"”
   • [claimed-docs] “It also provides a Python API for reading from and writing to a bag from your own source code.”
   • [claimed-docs] “This allows you to subscribe to a topic and save the received data to a bag at the same time as performing any other processing of your choi…”
   • [claimed-docs] “Command-line introspection tools using an extensible framework”
   • [claimed-docs] “The main entry point for the tools is the command ros2, which itself has various sub-commands for introspecting and working with nodes, topi…”
   • [claimed-docs] “ros2 security create_keystore demo_keystore”
   • [claimed-docs] “Desktop Install (Recommended): ROS, RViz, demos, tutorials.”
   • [claimed-docs] “ROS 2 runs a background daemon process that maintains information about the ROS graph to provide faster responses to queries, such as the li…”

   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 userExport all of my data in open formats and leave

   weight 3 · round drawn
   ROS 2~partialclaimed6/10

   ROS 2 is fully open-source with rosbag recording/playback and a Python API for reading/writing bag data, meaning all system data lives in inspectable, non-proprietary formats accessible via CLI or code, and there's no vendor SaaS lock-in to 'leave' from since it runs locally. However, the evidence never explicitly addresses bulk data export, format standardization/versioning guarantees, or migration tooling framed as 'export and leave'. Missing for 10: explicit documentation on bag format portability/interoperability guarantees, an explicit statement on no lock-in or data export completeness, and independent confirmation that recorded data is fully portable across tools/versions.

   • [claimed-docs] “It also provides a Python API for reading from and writing to a bag from your own source code.”
   • [claimed-docs] “This allows you to subscribe to a topic and save the received data to a bag at the same time as performing any other processing of your choi…”
   • [claimed-docs] “bag: Record/play a rosbag”
   • [github] “The Robot Operating System (ROS) is a set of software libraries and tools that help you build robot applications. From drivers to state-of-t…”

   proof ↗⚑ flag

   Viam~partialcommunity6/10

   Viam's CLI documents exporting data in 'a variety of formats' and querying tabular/binary data via SQL or MQL, and the core RDK is confirmed open source (gRPC-based, self-hostable, robots can run offline/on their own server), supporting a genuine 'leave' path. However, the docs don't spell out full-fidelity export of configs/models/permissions or a formal migration guide, and a community comment flags uncertainty about how much of the platform (beyond RDK) is truly open, which tempers confidence without constituting a concrete contradiction. Missing for 10: comprehensive documentation of exporting all data types/configs (not just sensor data) in open formats, and independent verification of successful full platform migration/exit.

   • [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”
   • [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…”
   • [community] “Internet access is optional/intermittent for Viam robots: if connectivity is lost, the robot operates fine until the TLS cert expires (30+ d…”

   proof ↗⚑ flag

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

   weight 2 · round to ROS 2
   ROS 2✓fullclaimed8/10

   ROS 2 is hosted publicly on GitHub (github.com/ros2/ros2) as an open-source project, consistent with its well-known Apache 2.0 licensing, and the docs/source are openly accessible for inspection. Missing for 10: explicit license file citation and independent confirmation of license terms beyond the GitHub repo listing.

   • [github] “The Robot Operating System (ROS) is a set of software libraries and tools that help you build robot applications. From drivers to state-of-t…”

   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

4. ai-native userSelf-host the core product

   weight 3 · round to ROS 2
   ROS 2✓fullcommunity8/10

   ROS 2 is a fully open-source framework distributed via apt/source with no cloud dependency, installable and run entirely on user-owned infrastructure (ROS-Base and Desktop install options, CLI tools, client libraries). Community evidence confirms it is widely self-hosted in production and research despite operational complaints. missing for 10: no explicit first-party 'self-hosting' guide or containerized deployment reference architecture, and no independent audit confirming zero external calls.

   • [claimed-docs] “ROS-Base Install (Bare Bones): Communication libraries, message packages, command line tools. No GUI tools.”
   • [claimed-docs] “Desktop Install (Recommended): ROS, RViz, demos, tutorials.”
   • [claimed-docs] “The default middleware that ROS 2 uses is `Fast DDS`, but the middleware (RMW) can be replaced at runtime.”
   • [github] “The Robot Operating System (ROS) is a set of software libraries and tools that help you build robot applications. From drivers to state-of-t…”
   • [community] “I've been a ROS 1 (and now 2) user since 2010... ROS gives you some important things 'for free' if you cooperate with its ecosystem conventi…”
   • [community] “I still remember the time before ROS, 20 years ago, when each robotics team had to designate a sub-team just for building and maintaining th…”

   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

1. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   ROS 2—none0/10

   The evidence pack contains no mention of telemetry, usage tracking, or any opt-out mechanism for ROS 2; documentation covers middleware, QoS, CLI tools, and security but nothing about data collection practices. Since telemetry controls are a plausible axis for any software toolchain and no evidence confirms or denies its presence, this is 'none' rather than 'na'.

   ⚑ flag

   Viam—none0/10

   No evidence in the pack addresses telemetry/usage-tracking opt-out settings or privacy controls for Viam's platform or CLI; docs focus on device data capture/cloud sync, not vendor telemetry about usage of the product itself.

   ⚑ flag

Safety

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

   weight 1 · round to Viam
   ROS 2~partialclaimed4/10

   ROS 2's SROS2 security layer provides per-node 'security enclaves' with DDS-Security authentication and permissions policies that can restrict which participants may publish, subscribe, or call services — a mechanism that could be used to gate who can command/configure/view a robot's topics and services (ros2-docs-12,13,15,29,40,42,49). However, this is a low-level, certificate-based node/participant authorization system, not a role-based access model for human operators (no user/role management UI, no built-in 'ops vs viewer' role concept), and no community evidence corroborates real-world use for this purpose. Missing for 10: explicit human-role/permission management (RBAC for ops users), UI/dashboard for granting per-robot view/command rights, and independent hands-on validation of the security enclave workflow.

   • [claimed-docs] “ROS 2 includes the ability to secure communications among nodes within the ROS 2 computational graph.”
   • [claimed-docs] “A security enclave encapsulates a single policy for protecting ROS communications.”
   • [claimed-docs] “The `sros2` package provides the tools and instructions to use ROS 2 on top of DDS-Security.”
   • [claimed-docs] “DDS-Security support”
   • [claimed-docs] “Built-in ROS 2 security features enable control over communications throughout the ROS graph. This not only allows for encrypting data in tr…”
   • [claimed-docs] “ros2 security create_keystore demo_keystore”
   • [claimed-docs] “Built-in ROS 2 security features enable control over communications throughout the ROS graph. This not only allows for encrypting data in tr…”

   proof ↗⚑ 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 to ROS 2
   ROS 2~partialclaimed5/10

   ROS 2 documents managed lifecycle nodes (ros2-docs-5), which are the standard building block for implementing safety-interlock/state-transition patterns like emergency stop, plus QoS tuning (ros2-docs-14/22/41) and preliminary real-time support (ros2-docs-32) that engineers rely on for safety-critical control loops. However, there is no explicit documented emergency-stop tutorial, reference pattern, or safety-certification guidance in the evidence. Missing for 10: dedicated emergency-stop/safety-interlock tutorial or design guide, explicit safety-certification or functional-safety documentation, and independent confirmation that lifecycle nodes are used successfully for e-stop in production.

   • [claimed-docs] “Support for nodes with managed lifecycles”
   • [claimed-docs] “ROS 2 can be as reliable as TCP or as best-effort as UDP, with many, many possible states in between.”
   • [claimed-docs] “ROS 2 offers a rich variety of Quality of Service (QoS) policies that allow you to tune communication between nodes.”
   • [claimed-docs] “Preliminary support for real-time code”
   • [claimed-docs] “ROS 2 can be as reliable as TCP or as best-effort as UDP, with many, many possible states in between”

   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

3. ops leadMy robots keep operating and buffer data locally when cloud connectivity drops, then recover cleanly

   weight 2 · round to Viam
   ROS 2~partialclaimed3/10

   ROS 2's QoS policies (reliable/best-effort spanning TCP-to-UDP behavior) are explicitly designed to handle non-ideal networks, and rosbag tooling lets nodes record/buffer data locally, which are adjacent capabilities to 'operate offline and buffer data.' However, there is no documented feature specifically addressing cloud-connectivity loss detection, local buffering during an outage, or a clean reconnection/sync-recovery workflow — the evidence is about node-to-node DDS network resilience, not cloud uplink resilience. missing for 10: explicit cloud-connectivity-loss handling, local buffering-for-cloud-sync mechanism, and documented clean-recovery-on-reconnect behavior.

   • [claimed-docs] “Quality of service settings for handling non-ideal networks”
   • [claimed-docs] “ROS 2 can be as reliable as TCP or as best-effort as UDP, with many, many possible states in between.”
   • [claimed-docs] “ROS 2 can be as reliable as TCP or as best-effort as UDP, with many, many possible states in between”
   • [claimed-docs] “With the right set of Quality of Service policies, ROS 2 can be as reliable as TCP or as best-effort as UDP, with many, many possible states…”
   • [claimed-docs] “It also provides a Python API for reading from and writing to a bag from your own source code.”
   • [claimed-docs] “This allows you to subscribe to a topic and save the received data to a bag at the same time as performing any other processing of your choi…”

   proof ↗⚑ flag

   Viam✓fullcommunity8/10

   Docs explicitly state data queues locally during outages/low-bandwidth and syncs when connectivity returns, with automatic handling of restarts and storage constraints (viam-docs-7), and independent community testimony confirms robots keep operating offline (cached configs, works even through full reboot without internet, TLS cert grace period of 30+ days) (viam-comm-1). This directly matches the ops story of continued operation plus buffered local data and clean recovery. missing for 10: no first-party documentation detailing exact buffer size/retention limits or a hands-on failure/recovery test log beyond the anecdotal HN report.

   • [claimed-docs] “Data queues locally during network outages and in low-bandwidth environments, and syncs when connectivity returns. Viam handles restarts and…”
   • [community] “Internet access is optional/intermittent for Viam robots: if connectivity is lost, the robot operates fine until the TLS cert expires (30+ d…”

   proof ↗⚑ 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
   ROS 2~partialclaimed5/10

   ROS 2 provides DDS-Security with per-node 'security enclaves' encapsulating a single policy (scoped permissions) plus keystore/authentication tooling (ros2-docs-12,13,15,40,42,49), and its client libraries (rclcpp/rclpy) plus topics/services/actions let a program (including an AI agent) command a robot end-to-end via a real API/SDK (ros2-docs-7,10,24,35,36). However, there is no documentation of an AI-agent-oriented credential model (e.g., token/OAuth-style scoped API keys), no explicit workflow for an agent authenticating and issuing end-to-end commands, and no independent evidence of this being used by AI agents in practice. missing for 10: agent-specific scoped credential/token issuance workflow, explicit AI-agent authentication example, independent/hands-on validation of an agent driving a real robot end-to-end via this security model.

   • [claimed-docs] “ROS 2 includes the ability to secure communications among nodes within the ROS 2 computational graph.”
   • [claimed-docs] “A security enclave encapsulates a single policy for protecting ROS communications.”
   • [claimed-docs] “The `sros2` package provides the tools and instructions to use ROS 2 on top of DDS-Security.”
   • [claimed-docs] “Built-in ROS 2 security features enable control over communications throughout the ROS graph. This not only allows for encrypting data in tr…”
   • [claimed-docs] “ros2 security create_keystore demo_keystore”
   • [claimed-docs] “Built-in ROS 2 security features enable control over communications throughout the ROS graph. This not only allows for encrypting data in tr…”
   • [claimed-docs] “Client libraries come in a variety of programming languages so that users may write ROS 2 code in the language that is best-suited for their…”
   • [claimed-docs] “Topics: For continuous data streams. Services: For synchronous request/response interactions. Actions: For long-running tasks with feedback”
   • [claimed-docs] “Actions allow clients to send goals, receive feedback during the execution, cancel if needed, and return a result if availabl”
   • [claimed-docs] “Client libraries come in a variety of programming languages so that users may write ROS 2 code in the language that is best-suited for their…”
   • [claimed-docs] “client libraries expose to users the core functionality that makes ROS "ROS"”

   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
   ROS 2—none0/10

   The evidence pack covers ROS 2's core middleware, client libraries, CLI tools, QoS, security, and simulation features, but contains no mention of VLA models, robotics foundation models, or any supported tooling/integration path (e.g., official packages, tutorials, or SDKs) for incorporating such AI models into the autonomy stack. Missing for 10: any documentation or examples of VLA/foundation-model integration, official model-serving nodes, or partner tooling (e.g., NVIDIA Isaac, Hugging Face robotics integrations) referenced by ROS 2 itself.

   ⚑ 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
   ROS 2~partialclaimed5/10

   ROS 2 docs confirm official client libraries in multiple languages, but only explicitly evidence C++ and Python (rclcpp/rclpy) as officially verified APIs, with no mention of official TypeScript or Go SDKs covering the full ROS 2 surface (nodes, topics, services, actions, QoS, security, etc.). Community remarks confirm long-standing use of C++/Python but do not corroborate TypeScript/Go as first-party. Missing for 10: official TypeScript SDK, official Go SDK, evidence that all four languages have full-surface parity and 'typed' guarantees.

   • [claimed-docs] “Client libraries come in a variety of programming languages so that users may write ROS 2 code in the language that is best-suited for their…”
   • [claimed-docs] “This verifies both the C++ and Python APIs are working properly.”
   • [claimed-docs] “you might prefer to write visualization tools in Python because it makes prototyping iterations faster, while for parts of your system that …”
   • [claimed-docs] “Client libraries come in a variety of programming languages so that users may write ROS 2 code in the language that is best-suited for their…”
   • [claimed-docs] “client libraries expose to users the core functionality that makes ROS "ROS"”

   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 ROS 2
   ROS 2~partialclaimed3/10

   ROS 2 docs reference a tutorial for launching a Gazebo simulation with ROS 2, indicating an integration path exists, but there is no detail on physics fidelity, sensor model realism, or independent corroboration of simulation quality. missing for 10: documentation of physics engine accuracy, sensor plugin catalog (cameras, lidar, IMU), community/hands-on validation of sim-to-real fidelity.

   • [claimed-docs] “Launch a Simulation with Gazebo and ROS 2”

   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 ROS 2
   ROS 2✓fullcommunity7/10

   ROS 2's architecture (topics/services/actions abstraction, pub/sub) lets nodes interact with either real hardware drivers or simulated ones (e.g., Gazebo) using the identical ROS API, and the docs explicitly walk through launching a Gazebo simulation alongside ROS 2 nodes, plus a community user notes ROS gives you sim 'for free' as part of its ecosystem. Missing for 10: an explicit vendor statement that the same node code requires zero changes to move from sim to real robot, and independent hands-on corroboration/case study confirming no-rewrite in practice.

   • [claimed-docs] “Launch a Simulation with Gazebo and ROS 2”
   • [claimed-docs] “Publish/subscribe over topics”
   • [claimed-docs] “Topics: For continuous data streams. Services: For synchronous request/response interactions. Actions: For long-running tasks with feedback”
   • [claimed-docs] “Inter- and intra-process communication using the same API”
   • [community] “I've been a ROS 1 (and now 2) user since 2010... ROS gives you some important things 'for free' if you cooperate with its ecosystem conventi…”

   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. ops leadRoute autonomy failures to a human intervention queue where an operator resolves and hands back control

   weight 1 · round drawn
   ROS 2—none0/10

   ROS 2 provides low-level building blocks (actions with feedback/cancel, lifecycle-managed nodes, topics) that could underpin a human-intervention workflow, but the evidence pack shows no actual feature for detecting autonomy failures, routing them to an operator queue, or handing control back after resolution — that is an application-layer capability ROS 2 does not ship out of the box. Missing for 10: any documentation of a fault-detection/escalation mechanism, an intervention-queue or ticketing construct, or operator handback protocol.

   • [claimed-docs] “Actions allow clients to send goals, receive feedback during the execution, cancel if needed, and return a result if availabl”
   • [claimed-docs] “Support for nodes with managed lifecycles”
   • [claimed-docs] “Topics: For continuous data streams. Services: For synchronous request/response interactions. Actions: For long-running tasks with feedback”

   proof ↗⚑ flag

   Viam—none0/10

   Viam documents fleet monitoring, alerting, remote control/teleoperation via web interface, and OTA updates, but nothing describes an automated routing of autonomy failures to a human intervention queue with resolve-and-handback workflow. Missing for 10: any documented intervention-queue mechanism, failure-triggered escalation to a human operator, or handback-to-autonomy control flow.

   • [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] “Cloud-managed fleet monitoring and alerting”

   proof ↗⚑ flag

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

   weight 2 · round to ROS 2
   ROS 2✓fullcommunity8/10

   ROS 2 provides a comprehensive suite of CLI introspection tools (ros2 topic, ros2 node, ros2 service, ros2 bag) plus a daemon for graph state, topic statistics, service introspection, and rosbag recording/playback for logs, all of which support remote debugging of live topics and state on deployed robots. This is corroborated by direct docs on command-line tools, topic statistics, and bag recording, and community comments confirm CLI tools/bags/viewers are valued 'for free' benefits of using ROS's ecosystem conventions. Missing for 10: explicit first-party or independent evidence of remote/networked debugging over real deployments (e.g., cross-machine domain setup docs) and no hands-on account specifically describing remote robot debugging via these tools.

   • [claimed-docs] “ROS 2 includes a suite of command-line tools for introspecting a ROS 2 system.”
   • [claimed-docs] “Command-line introspection tools using an extensible framework”
   • [claimed-docs] “The main entry point for the tools is the command ros2, which itself has various sub-commands for introspecting and working with nodes, topi…”
   • [claimed-docs] “ROS 2 runs a background daemon process that maintains information about the ROS graph to provide faster responses to queries, such as the li…”
   • [claimed-docs] “Topic statistics are built-in measurements that help you understand how messages behave when a subscription receives them.”
   • [claimed-docs] “It also provides a Python API for reading from and writing to a bag from your own source code.”
   • [claimed-docs] “This allows you to subscribe to a topic and save the received data to a bag at the same time as performing any other processing of your choi…”
   • [claimed-docs] “bag: Record/play a rosbag”
   • [claimed-docs] “Service Introspection”
   • [community] “I've been a ROS 1 (and now 2) user since 2010... ROS gives you some important things 'for free' if you cooperate with its ecosystem conventi…”
   • [community] “I usually feel the same when starting something new... Installing/building ROS, the package boilerplate, etc... But then again I often end u…”

   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

3. ops leadTeleoperate a remote robot with live video and responsive control over real-world networks

   weight 3 · round to Viam
   ROS 2~partialcommunity5/10

   ROS 2's QoS policies (reliable/best-effort tuning for non-ideal networks), pub/sub topics for continuous sensor/video streams, and actions for long-running feedback-driven tasks provide the underlying building blocks for teleoperation, and a community user explicitly notes ROS gives teleop 'for free' via its ecosystem conventions [ros2-comm-9]. However, there is no first-party documentation of a video-streaming pipeline, latency benchmarks over real-world/lossy networks, or a dedicated teleop stack/tooling in this evidence pack. missing for 10: dedicated video transport/compression tooling (e.g., image_transport/web video), real-network latency/responsiveness benchmarks, explicit teleoperation reference architecture or case study.

   • [claimed-docs] “Quality of service settings for handling non-ideal networks”
   • [claimed-docs] “ROS 2 can be as reliable as TCP or as best-effort as UDP, with many, many possible states in between.”
   • [claimed-docs] “ROS 2 offers a rich variety of Quality of Service (QoS) policies that allow you to tune communication between nodes.”
   • [claimed-docs] “Actions allow clients to send goals, receive feedback during the execution, cancel if needed, and return a result if availabl”
   • [claimed-docs] “The topic interface is meant for continuous data streams, for example, streaming sensor data or the status of your robot.”
   • [community] “I've been a ROS 1 (and now 2) user since 2010... ROS gives you some important things 'for free' if you cooperate with its ecosystem conventi…”

   proof ↗⚑ flag

   Viam~partialcommunity7/10

   Viam documents live camera streaming, keyboard/teleop controls from a web interface, and NAT traversal for connecting to machines behind firewalls without VPN/port-forwarding, which directly supports remote teleoperation with live video (viam-docs-4, viam-docs-6, viam-docs-42, viam-docs-44). However, there is no evidence quantifying latency/responsiveness over real-world (e.g., cellular, high-latency) networks, and community commentary focuses on offline resilience rather than teleop performance. Missing for 10: independent benchmarks or hands-on reports of control responsiveness/latency over real networks, and explicit teleoperation-specific case studies beyond generic 'drive with keyboard' docs.

   • [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] “Drive bases with keyboard controls, move arms to specific positions, or test components directly from Viam's web interface. Debug without de…”
   • [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] “Viam treats your hardware like cloud infrastructure—connect from anywhere, no VPN required.”
   • [claimed-docs] “Connect your first machine to the Viam platform so you can configure, control, and monitor it from anywhere.”
   • [community] “Internet access is optional/intermittent for Viam robots: if connectivity is lost, the robot operates fine until the TLS cert expires (30+ d…”

   proof ↗⚑ flag