Skip to content
R2Kernel Runtime Kernel for Robotics v1.0.0rc1
R2Kernel Runtime Kernel for Robotics v1.0.0rc1

    Capabilities

    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.tutorial.robot_cleaner.trash_disposal.v1. An authority identifies who owns the semantics. It does not make that capability portable by itself.

    Boundary

    • an app requires capability.*
    • a compound subsystem normally provides capability.*
    • the backing api.* contract defines the callable surface
    • lower-level component.* and gateway api.* interfaces remain behind the compound provider
    • 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

    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. Longer behaviors may use Operations when feedback and cancellation are part of the contract.

    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: compound_subsystem
      subsystem: compound.cleaner
      interface: mobility
      contract: capability.r2kernel.mobility.body_motion.v1

    compound_subsystem is the normal implementation when behavior coordinates several lower-level interfaces, applies safety checks, or owns state. A direct_binding may expose exactly one public Control, Procedure, or Operation when that narrow low-level outlet is intentional.

    Package-Local Example

    Trash collection and incineration are specific to the cleaner tutorial. They live under capability.tutorial.robot_cleaner.* in the tutorial package spec root. The official dictionary does not standardize this behavior.

    This separation preserves both goals. Portable applications can target official capabilities, while specialized products can define precise private behavior without weakening gateway and component conformance.