Robots are declared as systems
Components, sensors, actuators, tasks, behaviours, rates, deadlines, and data dependencies live together in a readable TypeScript definition.
← Back to selected work
Selected work / HefaOS
A typed path from robot definition to runtime.
HefaOS is an early open source framework. Its design pairs TypeScript definitions of hardware, tasks, and behaviours with a C++ runtime intended to enforce timing and hardware constraints.
DEFINE / COMPILE / RUNTypeScript definitions.
C++ execution.
C++ execution.
- Type
- Open source framework
- Authoring
- TypeScript + TSX
- Runtime
- Modern C++
- Status
- Early architecture
01 / Why it exists
Robot projects rebuild the same foundation.
A robot project needs drivers, state management, scheduling, message transport, deployment, simulation, model runtimes, and safety boundaries. Teams often assemble these pieces again for each machine.
Existing frameworks provide many of those pieces. HefaOS explores a narrower path from a typed robot definition to explicit task graphs, target configuration, and deterministic execution.
02 / The model
TypeScript definitions with C++ execution.
The architecture separates how a robot is described from how it executes. TypeScript provides the vocabulary. The compiler checks and lowers it. C++ deals with timing, hardware, and the consequences.
The compiler makes constraints concrete
The intended compiler validates the graph and emits the configuration and bindings required by the runtime. Invalid timing should fail before a motor develops an opinion.
The runtime owns execution
A C++ core is designed to run explicit task graphs with bounded state, direct hardware access, and deterministic scheduling.
Hardware and simulation share a boundary
A common abstraction layer is intended to connect the same robot definition to Linux hardware, test doubles, or simulation while keeping backend differences visible.
03 / The intended loop
From robot definition to target runtime.
The intended workflow keeps definition, validation, and execution in one repository.
- 01
Define the machine
Keep joints, sensors, actuators, limits, frames, and target hardware together as named, typed components.
- 02
State the work and its timing
Tasks declare periods, deadlines, priority, inputs, and outputs. Timing requirements stay in source and can be checked before deployment.
- 03
Compile and inspect the graph
Validate dependencies and target capabilities, then produce artefacts the runtime can execute and a human can examine.
- 04
Move from simulation to hardware
Run the same system against simulated and physical backends while preserving the configuration and capability differences between them.
04 / Why I am building it
A readable API must preserve runtime constraints.
I wanted a robotics stack that software engineers can read without hiding timing, hardware, or failure modes.
A readable API makes a robot easier to describe, but it cannot relax the system’s timing requirements. A task with a one millisecond deadline remains a one millisecond task after compilation.
HefaOS keeps the authoring model and runtime model separate, with the compiler connecting them. This gives hardware, scheduling, behaviours, and generated artefacts defined places in the system.
05 / Current truth
The specification is ahead of the implementation.
HefaOS is public at an early stage. The OS, SDK, and development infrastructure specifications describe the design in detail. The repository contains the package structure, build system, CI, development environment, and a declarative robot arm example.
Large parts of the runtime, hardware layer, AI backends, compiler, and tests are still scaffolding. No production timing results are available yet. The repository documents the intended architecture and provides a starting structure for the implementation.
- Public and open source under the MIT licence
- C++ runtime and TypeScript SDK architecture
- Hardware, simulation, and AI boundaries specified
- Implementation and benchmarks still in progress
Explore the project