home / skills / plurigrid / asi / kos-firmware

kos-firmware skill

/skills/kos-firmware

This skill helps you control Rust-based KOS firmware via Python clients, enabling actuator, IMU, and sim2real operations through gRPC.

npx playbooks add skill plurigrid/asi --skill kos-firmware

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
7.5 KB
---
name: kos-firmware
description: K-Scale Operating System - Rust-based robot firmware with gRPC services for actuator control, IMU, and sim2real transfer. Platform abstraction layer for hardware/simulation backends.
version: 1.0.0
category: robotics-firmware
author: K-Scale Labs
source: kscalelabs/kos
license: MIT
trit: 1
trit_label: PLUS
color: "#79ED91"
verified: false
featured: true
---

# KOS Firmware Skill

**Trit**: +1 (PLUS - generation/construction)
**Color**: #79ED91 (Bright Green)
**URI**: skill://kos-firmware#79ED91

## Overview

KOS (K-Scale Operating System) is a general-purpose, configurable framework for robot firmware. Written in Rust with gRPC services exposed to Python clients via pykos.

## Architecture

```
┌────────────────────────────────────────────────────────────────┐
│                     KOS ARCHITECTURE                            │
├────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │                    Python Client (pykos)                  │  │
│  │  KosClient.actuator.command_actuators(...)               │  │
│  │  KosClient.imu.get_imu_values()                          │  │
│  │  KosClient.sim.reset()                                   │  │
│  └──────────────────────────────────────────────────────────┘  │
│                            │ gRPC                               │
│                            ▼                                    │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │                   KOS Runtime Daemon                      │  │
│  │  ┌─────────────┬─────────────┬─────────────────────────┐ │  │
│  │  │ Actuator    │ IMU         │ Simulation              │ │  │
│  │  │ Service     │ Service     │ Service                 │ │  │
│  │  └─────────────┴─────────────┴─────────────────────────┘ │  │
│  └──────────────────────────────────────────────────────────┘  │
│                            │ HAL Traits                         │
│                            ▼                                    │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │              Platform Abstraction Layer                   │  │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐   │  │
│  │  │ KBot HAL    │  │ ZBot HAL    │  │ Stub (Testing)  │   │  │
│  │  │ (Hardware)  │  │ (Hardware)  │  │ (Simulation)    │   │  │
│  │  └─────────────┘  └─────────────┘  └─────────────────┘   │  │
│  └──────────────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────────────┘
```

## gRPC Services

### ActuatorService

```protobuf
service ActuatorService {
  rpc CommandActuators(CommandActuatorsRequest) returns (CommandActuatorsResponse);
  rpc ConfigureActuator(ConfigureActuatorRequest) returns (ActionResponse);
  rpc CalibrateActuator(CalibrateActuatorRequest) returns (ActionResponse);
  rpc GetActuatorsState(GetActuatorsStateRequest) returns (ActuatorStateResponse);
  rpc ParameterDump(ParameterDumpRequest) returns (ParameterDumpResponse);
}
```

### SimulationService (for sim2real)

```protobuf
service SimulationService {
  rpc Reset(ResetRequest) returns (ResetResponse);
  rpc SetPaused(SetPausedRequest) returns (ActionResponse);
  rpc Step(StepRequest) returns (StepResponse);
  rpc AddMarker(AddMarkerRequest) returns (ActionResponse);
  rpc SetParameters(SetParametersRequest) returns (ActionResponse);
}
```

## Python Client Usage

```python
from pykos import KosClient

async def control_robot():
    async with KosClient("localhost:50051") as client:
        # Get actuator states
        states = await client.actuator.get_actuators_state([1, 2, 3])
        
        # Command positions
        await client.actuator.command_actuators([
            {"actuator_id": 1, "position": 0.5},
            {"actuator_id": 2, "position": -0.3},
        ])
        
        # Configure actuator
        await client.actuator.configure_actuator(
            actuator_id=1,
            kp=100.0,
            kd=10.0,
            torque_enabled=True,
        )
        
        # Calibrate
        await client.actuator.calibrate(1)

# For simulation
async def sim_control():
    async with KosClient("localhost:50051") as client:
        await client.sim.reset()
        await client.sim.step(dt=0.002)
        await client.sim.add_marker(
            name="target",
            position=[1.0, 0.0, 0.5],
            color=[1.0, 0.0, 0.0],
        )
```

## Key Contributors

- **codekansas** (Ben Bolte): Core architecture, async client
- **nfreq**: PolicyService, calibration, parameter dump
- **WT-MM**: Markers, visualization
- **hatomist**: Acceleration, telemetry

## GF(3) Triads

This skill participates in balanced triads:

```
ksim-rl (-1) ⊗ kos-firmware (+1) ⊗ mujoco-scenes (0) = 0 ✓
kos-firmware (+1) ⊗ evla-vla (-1) ⊗ ktune-sim2real (0) = 0 ✓
```

## Related Skills

- `ksim-rl` (-1): RL training library
- `evla-vla` (-1): Vision-language-action models
- `kbot-humanoid` (-1): K-Bot robot configuration
- `zeroth-bot` (-1): Zeroth bot 3D-printed platform
- `mujoco-scenes` (0): Scene composition

## References

```bibtex
@misc{kos2024,
  title={KOS: K-Scale Operating System for Robot Firmware},
  author={K-Scale Labs},
  year={2024},
  url={https://github.com/kscalelabs/kos}
}
```


## SDF Interleaving

This skill connects to **Software Design for Flexibility** (Hanson & Sussman, 2021):

### Primary Chapter: 6. Layering

**Concepts**: layered data, metadata, provenance, units

### GF(3) Balanced Triad

```
kos-firmware (−) + SDF.Ch6 (+) + [balancer] (○) = 0
```

**Skill Trit**: -1 (MINUS - verification)

### Secondary Chapters

- Ch2: Domain-Specific Languages

### Connection Pattern

Layering adds metadata. This skill tracks provenance or annotations.

Overview

This skill describes KOS (K-Scale Operating System), a Rust-based robot firmware runtime exposing gRPC services for actuators, IMU, and simulation. It provides a platform abstraction layer so the same runtime can target hardware HALs or simulation stubs. Python clients interact via pykos to command actuators, read sensors, and run sim2real workflows.

How this skill works

The runtime daemon implements modular gRPC services (Actuator, IMU, Simulation) and forwards high-level RPCs to HAL trait implementations for different platforms. A Python async client (pykos) opens a gRPC channel to call methods like CommandActuators, GetActuatorsState, and Simulation Reset/Step. The platform layer swaps concrete HALs (hardware or stub) so control code and tests use the same interfaces for sim2real transfer.

When to use it

  • Building firmware that must run both on real robots and in simulation without changing control code
  • Exposing low-latency actuator and IMU control over a network to Python controllers
  • Automating calibration, parameter dumps, and actuator configuration remotely
  • Running sim2real experiments where simulation reset/step/markers are needed
  • Testing control logic with hardware-in-the-loop or stubbed HALs for CI

Best practices

  • Keep control loops in the Python client concise and push hardware specifics to HAL implementations
  • Use ConfigureActuator and ParameterDump for repeatable calibration and provenance
  • Run simulation flows through the SimulationService to mirror real-device sequences
  • Prefer async pykos clients to avoid blocking the runtime daemon and to scale multiple streams
  • Version and record HAL and parameter sets alongside experiment metadata for sim2real reproducibility

Example use cases

  • Remote commanding of a multi-actuator arm from a Python control process using CommandActuators and GetActuatorsState
  • Automated actuator calibration and parameter export before deployment to hardware
  • Running closed-loop simulations with Reset, Step, and AddMarker to prototype trajectories
  • CI tests that swap the hardware HAL for a stub to validate safety limits and message formats
  • Sim2real experiments where simulation parameters are tuned then applied to the hardware HAL

FAQ

Can I run the same client code against hardware and simulation?

Yes. The platform abstraction layer exposes the same gRPC interface; swapping HAL implementations lets the same pykos client code target hardware or a simulation stub.

How do I perform actuator calibration?

Use the CalibrateActuator RPC exposed by the ActuatorService; common flows also use ConfigureActuator and ParameterDump to store calibrated settings.