Skip to content
Back to catalogue

Verified intelligence · Expert-reviewed from public records, platform data, primary sources, and private research beyond AI search.

INFRACross-industryGLOBAL

AI infrastructure for robot operating systems after ROS

Commercial robot platforms can standardize deployment, telemetry and evidence above ROS 2, but production value depends on accepted physical output, integration labour, replayable incidents, OT security and body-specific approval.

The colophon

Landscape reviewed
2026-06-05
Latest revision
2026-06-05
Kinetics
Kinetics: watchfulImpact 0.87 · momentum 0.80 · vector 0.706 balls · 30 px/s

Robot buyers now approve the operating envelope, not the platform label: body, planner, controller and evidence boundaries decide scale. Release cadence, platform resource models and OEM control interfaces can move approval boundaries before annual refresh.

Known unknowns
Public evidence still lacks comparable production telemetry, integration-labour denominators, retest failure records, controller incidents and accepted physical-output records across platforms.

Contents

  1. Executive summary
  2. What changed
  3. Decision spine
  4. Deployment economics
  5. Scenario economics
  6. Operating evidence economics
  7. Body-class approval expansion
  8. Runtime controls and private eval
  9. Public evidence and private evals
  10. Viam platform test
  11. ROS domain engines
  12. Observability and evidence
  13. OEM authority
  14. Interoperability boundary
  15. Development and simulation layers
  16. Buy, build or stay close to ROS
  17. Implementation proof cases
  18. Adverse scenario controls
  19. Operating model
  20. Known unknowns
  21. Watch and reapproval triggers
  22. Platform and stack directory
  23. Source ledger
  24. Glossary

Executive summary

The operating system is the evidence boundary. Robot operating systems after ROS should be judged by what they refuse to hide. The useful commercial layer above ROS 2 governs resources, modules, configuration, deployment and rollback 14. Motion calls need their own evidence because they touch physical output 5. Telemetry and data export need field records that can survive support and incident review 737.

One public example is Viam: it documents typed hardware components 2, modules and fragments 34, and motion and data services 57. Treat it as a test case for the solution type, not as the whole market.

The hard boundary is still below the platform. ROS 2 distribution and RMW choices remain approval objects 89. Nav2 behaviour trees and ros2_control command interfaces need the same treatment 1012. MoveIt planning scenes and OEM controller modes also have to stay visible 1622.

Use the accepted physical output as the production unit. That unit should connect the configured body, motion service and planner limits 56 to controller state 10, OEM authority 22, replayable telemetry 1837, industrial safety evidence 32 and controller security records 34. Approval should separate platform and fleet deployment, ROS runtime, navigation and manipulation, OEM authority and operating evidence before scale.

Executive decision: move the work system up while keeping safety proof body-specific

LayerCan abstractMust exposeBuying move
Platform and fleet deploymentResources, configs and deployment state 1, modules 3, fragments 4, and data capture 7.Resolved config 1, module version 3, device state and log export 7, and rollback or config-rollout proof 14.Treat commercial operating-layer platforms as the evidence plane; use Viam as one documented example 14. Require equivalent rollout and rollback proof from integration-layer alternatives 40.
ROS 2 runtimeDistribution support, RMW vendor choice, dependency lane and messaging-middleware assumptions 89.Distribution, RMW, dependency and cross-distro assumptions 89.Approve a supported ROS lane, not just ROS compatibility.
Navigation and manipulationReusable mission calls over Nav2 structures 1213 and task templates over MoveIt planning scenes 1516.Nav2 plugins 13, MoveIt planning scene 16, controller interface and failure mode 1031.Keep planner evidence in the approval file.
OEM controller authorityController-resource status and selected command wrappers 2022.Write access, remote-control mode, safety function and controller authority 2022.Negotiate controller evidence before scale.
Operating evidence and economicsReplayable incident packets 37, accepted-output ledgers 38, integration connectors 40, and fleet-control software examples 4546.Accepted output and rejected work 38, integration hours 40, and recovery time with exportable logs 37.Price the next body, site and controller approval before funding broad standardization.

Source scope is public vendor, ROS-domain and OEM documentation checked on June 5, 2026; private body tests still decide acceptance.

Approve the operating envelope before the platform label

The decision path forces the buyer to clear body, controller, evidence and operating economics before scale.

  1. Can the platform expose resolved configuration, module versions and rollback evidence? 14

    No

    Keep the platform in pilot status; fleet rollout would hide the change file.

    Yes

    Move to runtime and controller boundaries.

    Next: Runtime boundary

  2. Can ROS runtime 8, planner and control boundaries 10, and OEM controller boundaries 22 be tested on the buyer body?

    No

    Approve only the lab workflow; production behaviour is still unproven.

    Yes

    Move to evidence export and operating economics.

    Next: Evidence and economics

  3. Can the buyer reconstruct incidents 37 and price accepted output, integration time and exception burden 3840?

    No

    Block scale until logs, accepted-output ledger and support records exist.

    Yes

    Approve a narrow operating envelope with named reapproval triggers.

Approval starts by assigning owners to the platform layer, ROS runtime, motion and control lane, and OEM boundary before scale.

What changed

The market is selling operating layers because ROS solved only part of the buyer problem. ROS made robot software shareable; operations now need governance. ROS 2 remains central because it provides libraries, tools, packages and middleware choices. The current public release table lists Lyrical Luth as a May 2026 LTS release supported until May 2031 8.

That still leaves the buyer with production questions ROS does not answer alone: which configuration is live, which model can command which actuator, which logs prove a failure, which OEM interface owns safety and which change forces reapproval.

Commercial platforms are entering that gap. Viam packages resource APIs, modules and fragments 14. Motion and data services add physical-output and evidence workflows 57. Foxglove packages observability and replay 18. Nav2, MoveIt and ros2_control carry the navigation, manipulation and controller semantics that wrappers must respect 1012.

The market is therefore not moving away from ROS so much as moving around it. The operating layer is useful when it makes ROS and OEM complexity auditable.

Abstraction is valuable only when the lower layer remains inspectable

SignalWhat changedProcurement effect
ROS 2 LTS and RMW choiceDistribution support, middleware and cross-distribution assumptions are explicit approval variables 89.Contract for a supported runtime lane.
Viam resource modelHardware components can share typed APIs while modules and fragments manage variation 24.Ask for resolved config, module version and dependency export.
Nav2 and MoveIt as enginesNavigation and manipulation expose plugin, scene, action and controller decisions 1215.Keep planner settings and failure records outside the UI.
Foxglove and MCAPLogs, ROS bags and message definitions become replayable evidence 1718.Make record-and-replay part of acceptance.

The same platform can be a useful operating layer in one row and an unsafe hiding place in another.

Decision spine

Approve owner lanes and economics before comparing platform features. The early decision is the approved robot stack, not the vendor list. Start with owner lanes. Platform configuration, ROS runtime, motion and control, OEM authority, observability and site operations each need a named owner and a stop condition.

Then price the retest burden. A robot operating layer is attractive only if the next body, site, controller change or incident replay becomes cheaper to approve.

Owner lanes come before platform selection

LaneOwnerApproval evidenceScale gate
Commercial platformRobotics platform leadResolved config, module versions, fragment tag, deployment status and rollback proof.No unreviewed module, fragment or device-class rollout.
ROS runtimeROS engineering ownerDistribution, RMW, QoS, domain, dependency and cross-distribution policy.No unsupported distro, untested RMW or mixed runtime lane.
Planning and controlAutonomy and controls ownerNav2, MoveIt, ros2_control, controller limits, scene assumptions and private eval.No planner, scene, hardware-interface or controller change without retest.
OEM authoritySafety and OT ownerEnabled services, remote-command mode, diagnostics, credentials and safety regression.No hidden controller authority or remote-write path.
Evidence replayRobOps and data ownerLogs, MCAP or bags, message definitions, incident link and export test.No scale approval if a field incident cannot be reconstructed.

A platform pilot should fail if any lower-layer owner cannot explain the evidence it needs to approve.

Once the owner lanes are named, the next question is whether each added body, site or controller change becomes cheaper to approve.

That retest burden should become body-specific approval paths before platform features enter the buying discussion.

Glossary

Terms used in this report

TermPlain meaning
RouteThe approved path from work to accepted output: source set, data boundary, model or vendor channel, tools, reviewer, evidence record and reapproval trigger.
APIApplication programming interface: a governed software connection used by an app or workflow to call a model or service.
SDKSoftware development kit: packaged code and tools developers use to connect a product to an API or service.
JSONJavaScript Object Notation: a structured text format commonly used for machine-readable API output.

Definitions are reader aids, not separate evidence claims.

MCP PREVIEW INVENTORY

What the locked report contains

Commercial robot platforms can standardize deployment, telemetry and evidence above ROS 2, but production value depends on accepted physical output, integration labour, replayable incidents, OT security and body-specific approval.

Schema endpoints

  • Sample object: /api/v1/reports/RPT_01KZJRBAFTERROSOS26/sample
  • Inventory object: /api/v1/reports/RPT_01KZJRBAFTERROSOS26/inventory
  • Schema contract: /api/v1/reports/RPT_01KZJRBAFTERROSOS26/schema

Coverage fields

  • Category: INFRA
  • Sector: Cross-industry
  • Region: GLOBAL
  • Topics: robotics, robot operating systems, ROS 2, Viam, Nav2, MoveIt, Foxglove, OEM SDKs, robot fleet operations

Schema contract

  • Contract: colophon.report_document v2026-05-28
  • Payload schemas: document, summary, sample, inventory, full_report
  • Required top-level fields: title, subtitle, abstract, category, sector, region, topics, sources, evidence, claims, colophon, body
  • Integrity rules: evidence.sourceId must reference sources[].id claim.evidenceIds[] must reference evidence[].id evidence.claimIds[] must reference claims[].id section and block evidence references must resolve colophon.kinetics.speed must match the momentum band for the business impact x momentum model

Data-point inventory

  • vendor_or_actor_ledger: entity names; product categories; source references; confidence notes
  • buyer_decision_fields: pricing signals; deployment constraints; risk flags; monitoring fields
  • evidence_index: source class; access date; claim linkage; verification status

Section inventory

  1. 1. Executive summaryPreview

    decision-ready conclusions; major findings; confidence caveats

  2. 2. What changedPreview

    structured findings; supporting evidence; buyer-use fields

  3. 3. Decision spinePreview

    selection criteria; tradeoff map; recommended buyer actions

  4. 4. Deployment economicsLocked

    structured findings; supporting evidence; buyer-use fields

  5. 5. Scenario economicsLocked

    structured findings; supporting evidence; buyer-use fields

  6. 6. Operating evidence economicsLocked

    claim support; known gaps; verification notes; 81 evidence objects

  7. 7. Body-class approval expansionLocked

    structured findings; supporting evidence; buyer-use fields

  8. 8. Runtime controls and private evalLocked

    structured findings; supporting evidence; buyer-use fields

  9. 9. Public evidence and private evalsLocked

    claim support; known gaps; verification notes; 81 evidence objects

  10. 10. Viam platform testLocked

    structured findings; supporting evidence; buyer-use fields

  11. 11. ROS domain enginesLocked

    structured findings; supporting evidence; buyer-use fields

  12. 12. Observability and evidenceLocked

    claim support; known gaps; verification notes; 81 evidence objects

  13. 13. OEM authorityLocked

    structured findings; supporting evidence; buyer-use fields

  14. 14. Interoperability boundaryLocked

    structured findings; supporting evidence; buyer-use fields

  15. 15. Development and simulation layersLocked

    structured findings; supporting evidence; buyer-use fields

  16. 16. Buy, build or stay close to ROSLocked

    structured findings; supporting evidence; buyer-use fields

  17. 17. Implementation proof casesLocked

    structured findings; supporting evidence; buyer-use fields

  18. 18. Adverse scenario controlsLocked

    structured findings; supporting evidence; buyer-use fields

  19. 19. Operating modelLocked

    structured findings; supporting evidence; buyer-use fields

  20. 20. Known unknownsLocked

    structured findings; supporting evidence; buyer-use fields

  21. 21. Watch and reapproval triggersLocked

    structured findings; supporting evidence; buyer-use fields

  22. 22. Platform and stack directoryLocked

    structured findings; supporting evidence; buyer-use fields

  23. 23. Source ledgerLocked

    normalized entity rows; source ledger; evidence-to-claim mapping

  24. 24. GlossaryPreview

    structured findings; supporting evidence; buyer-use fields

Relevance signals

  • Confidence score: 0.84
  • Source classes: vendor_docs, open_source_governance, developer_docs, oem_docs, open_source_project, technical_specification, operator_case_study, customer_case_study, standard, security_advisory, standard_update, government_guidance, security_framework, benchmark, research_paper, vendor_case_study, regulation
  • Known unknowns: Public evidence still lacks comparable production telemetry, integration-labour denominators, retest failure records, controller incidents and accepted physical-output records across platforms.
  • Watch signals:

Locked continuation

Purchase or subscribe to unlock the full findings, evidence ledger, and buyer-ready recommendations.

HumanAgent