Skip to content
Librux Runtime Kernel for Robotics development
Librux Runtime Kernel for Robotics development

    Librux in 3 Minutes

    Librux is easiest to understand as a runtime kernel for software-defined robots.

    Librux models the robot before it models a process. Each deployment describes one robot composition, a reusable platform plus an application, made concrete by deployment data.

    Robot = Platform + Application + Deployment

    The runtime owns the concerns around that definition, including validation, launch, spec-defined communication, federation, timing state, diagnostics, and resource admission.

    flowchart TB ROBOT["Robot"] PLATFORM["Platform<br/>what the robot is"] APP["Application<br/>what the robot should do"] DEPLOY["Deployment<br/>what runs and how it connects"] RUNTIME["Librux Runtime"] SPEC["Librux Spec"] subgraph PIECES["Executable Pieces"] G1["gateways"] C1["components"] C2["compounds"] A1["applications"] end PLATFORM --> ROBOT APP --> ROBOT ROBOT --> DEPLOY DEPLOY --> RUNTIME RUNTIME --> PIECES SPEC -.-> PIECES

    The Core Objects

    Robot
    The top-level Librux composition unit. A robot is one platform, one application selection, and the deployment data that binds concrete runtime pieces together.
    Platform
    The app-less definition of what the robot is and what it can provide. It is compound internally. Deeper pages break it into parts, slots, API contracts, compound subsystems, and robot capabilities.
    Application
    The top-level app for one robot. It declares the platform capabilities it needs and may constrain optional platform compatibility labels.
    Deployment
    The concrete composition. It chooses the packages to run, records launch modes and host placement, and connects gateway, component, compound, and application pieces.
    Subsystem
    The executable and contract-bearing unit inside a robot composition. After the robot, application, and deployment model is clear, subsystems are the concrete gateway, component, compound, or application pieces that run.
    Managed Package
    The deployable execution unit that wraps one subsystem. A package declares the entrypoint, arguments, environment, resource claims, and optionally a static package frontend.
    Librux Runtime
    The host runtime that validates deployments, launches managed packages, admits requested resources before start, carries time-stamped packets, and routes communication locally or across federation.
    Librux Spec
    The public contract vocabulary implemented by subsystems and robot capabilities. It defines message schemas, API contracts, components, and communication surfaces.
    Time-Stamped Packet
    The packet exchanged between subsystems with timing metadata attached by the runtime. Librux uses this timing context to support local and cross-host execution semantics.

    Terminology rule. Use subsystem for the runtime unit that registers, launches, communicates, and is validated by Librux. The word component appears in two controlled places. In role: component, it means a subsystem role for a replaceable robot function between gateways and compound or application layers. In public contract IDs such as component.*, it means the compatibility contract or API bundle exposed by that role. Do not use component as a generic synonym for subsystem. API contracts use domain namespaces such as api.motion.*, api.locomotion.*, and api.io.*.

    Federation

    When one robot spans machines, each host keeps its own managed packages and subsystems. Federation connects the Librux runtimes on those hosts, then each runtime routes the time-stamped packet to its local subsystems. Federation is host composition for one robot, not the primary model for a fleet.

    flowchart LR subgraph H1["Host A"] LA["Librux Runtime"] subgraph PA["Managed Package A"] A1["Subsystem A"] end A1 -->|"local Time-Stamped Packet"| LA end subgraph H2["Host B"] LB["Librux Runtime"] subgraph PB["Managed Package B"] B1["Subsystem B"] end LB -->|"local delivery"| B1 end LA <-->|"federated Time-Stamped Packet"| LB

    Subsystem code still thinks in terms of the same robot deployment and spec-defined communication model. Librux owns the cross-host route and local delivery.

    The Practical Rule

    Use Librux when the robot system needs the following.

    • a robot definition that separates platform, application, and deployment
    • a stable subsystem model from local development to multi-host deployment
    • explicit contracts instead of ad-hoc message shapes
    • control-owned remote routing instead of per-subsystem socket wiring
    • managed launch and resource admission for product deployments
    • timing state that is visible and accepted before one-way cross-host timing is trusted

    Continue next with Robot, Application, And Deployment or the deeper Design Philosophy.