Skip to content
R2Kernel™ Runtime Kernel for Robotics 1.0.0rc10
R2Kernel™ Runtime Kernel for Robotics 1.0.0rc10

    Capabilities (Legacy Compatibility)

    New R2Kernel platform manifests do not need a separate capability.* layer. Apps require api.* contracts, compounds declaratively export selected APIs from required component.* bundles, and the runtime resolves those exports to the implementing component.

    The material below documents the legacy contract family retained for existing manifests. Do not use it for new platform or tutorial definitions.

    Capabilities are app-facing robot contracts. They describe what an application may ask a robot to do without exposing controller, gateway, device-channel, or vendor topology.

    Each capability.* spec points to one backing api.* contract. Official R2Kernel capabilities currently use the api.capability.* namespace. The API owns the concrete endpoints and message types. The capability adds semantic constraints that an app and provider must share.

    Capability IDs always include an authority as their first namespace segment: capability.<authority>.<domain>.<name>.vN. The r2kernel authority is reserved for contracts published in the official dictionary. Vendors and packages use their own stable authority, for example capability.acme.fire.suppression.v1 or capability.example.cleaning.trash_disposal.v1. An authority identifies who owns the semantics. It does not make that capability portable by itself.

    Legacy Boundary

    • an app requires capability.*
    • a component normally provides the standard capability.* surface associated with its robotics function
    • a platform-specific component provides specialized capability adapters
    • the backing api.* contract defines the callable surface
    • component and gateway contracts remain available for platform composition, but apps bind to the capability interface selected by the robot manifest
    • vendor and package-specific capabilities use their own authority and package spec root. They do not enter the official dictionary automatically

    Official Capabilities

    Capability Meaning Backing API
    capability.r2kernel.mobility.body_motion.v1 bounded body-frame motion and stop behavior api.capability.mobility.body_motion.v1
    capability.r2kernel.manipulation.reach.v1 extend, shrink, and stow a platform manipulator api.capability.manipulation.reach.v1
    capability.r2kernel.manipulation.gripper.control.v1 open, close, and observe a gripper api.capability.manipulation.gripper.control.v1
    capability.r2kernel.perception.object_detection.v1 query semantic object detections api.capability.perception.object_detection.v1
    capability.r2kernel.navigation.goal.v1 execute and cancel framed goal or path navigation api.capability.navigation.goal.v1

    body_motion uses periodic Control because continuous motion needs period, deadline, validity, and late-command rejection. Reach and gripper requests use Procedures because they are bounded semantic actions. Goal navigation uses Operations because progress, cancellation, and terminal state are part of its application-facing contract.

    Legacy Platform Declaration

    The robot manifest maps each declared capability to a concrete provider.

    capabilities:
  mobility.body_motion:
    capability: capability.r2kernel.mobility.body_motion.v1
    implementation:
      kind: interface_binding
      subsystem: component.mobile
      interface: body_motion

    interface_binding selects the public component interface that provides the complete capability contract. Runtime traffic goes directly to that provider. Platform-specific behavior remains a component even when it wraps only one gateway channel.

    The runtime continues to read legacy compound_subsystem capability mappings for migration compatibility. Within the legacy model, a component interface_binding identifies the implementation. New platform manifests use compound API exports as described above.

    An application owns task sequencing. A radar-cleaning app can call perception, navigation, reach, gripper, and burn capabilities in order, including its own retry and fault policy. The compound does not hide that sequence inside a second application-like state machine.

    Cleaner Tutorial Migration

    The current cleaner tutorial uses api.r2kernel.actuation.trigger.v1 from component.r2kernel.trigger_actuator.v1, exported as trash_disposal by its compound. The old capability.tutorial.robot_cleaner.* package specs were removed. Use the current platform guide for new examples; the legacy mapping above is not the cleaner's current manifest.