Bounded work
Critical threads, IRQ work, and background services are separated so the data plane has a deliberate priority model.
olixOS™ / Real-time robotics runtime
From interrupt to insight. On time.
A purpose-built Linux runtime that governs how sensor data enters the system, moves through memory, receives a timestamp, meets a deadline, and becomes a ROS 2/DDS sample.
PREEMPT_RT
Copy-minimized HAL
PTP + TSN ready
Native ROS 2 / DDS
olixos / trace / cycle_2048CAPTURING
t0+250 µs+500 µs+750 µsdeadline
IRQwake
DMAring buffer fill
RT workeracquire + validate
HALbuffer view
ROS execpublish callback
DDSwrite
DEADLINE BOUNDARY
KERNELPREEMPT_RT
SCHEDULERpriority aware
BUFFERDMA-backed
OUTPUTsource-timed DDS
The operating premise
Linux, shaped around the control loop.
olixOS is not a desktop distribution placed inside a robot. It is a controlled embedded runtime: kernel, drivers, timing, middleware, and diagnostics are configured as one execution environment.
Stable data paths
DMA-backed acquisition and a copy-minimized HAL reduce avoidable movement between the driver and processing layers.
One time domain
PTP-aware synchronization, monotonic time, and source timestamps preserve when a measurement happened—not merely when it arrived.
Robot-native I/O
ROS 2 nodes, executors, and DDS policies are part of the runtime contract, not an integration layer added after bring-up.
Real-time core
Control latency at the source.
PREEMPT_RT changes the kernel's execution model; olixOS adds platform-specific thread priorities, affinity, IRQ placement, and service budgets around it.
KERNEL / THREADED IRQ
Make interrupt work schedulable.
With PREEMPT_RT, most interrupt handlers execute in kernel threads. olixOS can assign explicit priority and affinity so acquisition work participates in the same scheduling model as the rest of the real-time pipeline.
EVENThardware IRQ
RT DOMAINIRQ thread
SCHEDULEpriority policy
RESULTbounded handoff
CONTROLthread priority
PLACEMENTCPU affinity
OBSERVEwake-up latency
I/O architecture
A shorter path from wire to topic.
The operating system owns the complete path. Every transition has a defined buffer, clock, thread context, and failure signal.
Peripheral
Electrical or network sample arrives.
Interrupt
Minimal handler signals work.
Ring buffer
Hardware writes into owned memory.
Typed sample
Stable access without needless copies.
Processing
Validate, calibrate, transform.
ROS executor
Callback owns publish scheduling.
Data writer
QoS policy governs transport.
Zero-copy where ownership is controlled.
The HAL can expose DMA-backed views to the processing layer. Boundaries that require serialization or ownership transfer remain explicit and measurable.
Timestamp at acquisition.
Source time travels with the sample through calibration, processing, and publication so downstream consumers can reason about age and alignment.
Time fabric
Synchronize the robot, not just the clock display.
olixOS treats time as data infrastructure: PTP-aware discipline, source timestamps, clock-domain mapping, and TSN-ready transport preserve event order across distributed devices.
PTP DOMAIN / 0offset +0.8 µs
GM TIME
SENSORCOMPUTENETWORK
IEEE 1588 PTP
Linux PTP services relate local clocks to the selected grandmaster and expose offset state to diagnostics.
Hardware-assisted timestamps
Where the platform exposes them, timestamps are captured close to the physical ingress point.
Source-time semantics
The measurement keeps its acquisition time across HAL, processing, ROS messages, and DDS transport.
TSN-ready scheduling
Traffic classes and time-aware infrastructure can separate critical sensor streams from best-effort management traffic.
ROS 2 / DDS runtime
Communication is part of the schedule.
Topics alone do not define behavior. Executors decide when callbacks run; DDS QoS decides how samples are retained, delivered, and declared unhealthy.
DDS_QOS_PROFILEsensor_stream_v1
Fresh data over accumulated history.
A bounded queue and best-effort delivery can be appropriate when the next sample replaces the last. Deadline and liveliness status still make missing producers visible.
RELIABILITYbest effort
Delivery contract
HISTORYkeep last
Queue behavior
DEPTHsmall + bounded
Memory and freshness
DEADLINEstream period
Expected cadence
LIVELINESSautomatic
Producer health
DURABILITYvolatile
Late-join behavior
Callback control
Callback groups and executor placement prevent low-priority work from obscuring critical data handling.
Native graph
Nodes, topics, parameters, services, and diagnostics appear directly in the ROS 2 graph.
DDS / RTPS
Standard wire behavior keeps device data accessible to robot computers without a proprietary gateway.
Adaptive QoS
Runtime profiles match the semantic needs of streams, events, and persistent state.
Runtime observability
Determinism should leave a trace.
Latency, missed deadlines, clock offset, queue pressure, IRQ placement, and DDS status become operational signals—not lab-only measurements.
olixos / telemetry / liveSTREAMING
12:40:18clockptp0 state=SLAVE offset=+0.8usOK
12:40:18irq/42cpu=2 priority=88 wake=34usOK
12:40:18dma0ring=17/128 overruns=0OK
12:40:18executorcallback=publish_sensor age=112usOK
12:40:18ddsdeadline_miss=0 liveliness=aliveOK
12:40:17kernelrt_throttle=0 migrations=0OK
12:40:17thermalzone0=52.4C policy=nominalOK
12:40:17healthpipeline=ready sequence=284192OK
$ olixctl trace --follow
Illustrative live view
Illustrative live view
Illustrative live view
Illustrative live view
Lifecycle + control
Keep the data plane quiet.
Real-time acquisition and management services have different jobs. olixOS isolates their responsibilities while keeping configuration, health, and software state accessible.
Do the time-critical work.
IRQ threads, DMA completion, calibration, transforms, ROS executor work, and publication run within a defined scheduling and affinity plan.
Priority-controlled threadsPreallocated buffersSource-time propagationDeadline telemetry
Configure without disturbing.
Parameters, health reporting, Web UI access, logging, and update workflows remain observable but are kept outside the critical sensor path.
Versioned configurationRuntime diagnosticsSecure update integrationService supervision
Boot
Start from a known software and device state.
Hardware
Initialize buses, IRQs, DMA, clocks, and drivers.
Policy
Set affinity, priority, memory, and QoS profiles.
ROS lifecycle
Configure and activate nodes in dependency order.
Operate
Publish health, timing, and data-path status.
Deployment surface
Use the runtime at the layer you own.
olixOS can arrive as part of an Olive device, anchor a custom embedded platform, or contribute selected real-time runtime components to an existing robot architecture.
Olive hardware + olixOS
The shortest route to a sensor that powers on as a ROS 2 node with a coordinated kernel, driver, timing, and middleware stack.
- Integrated BSP and HAL
- Validated device interfaces
- Native diagnostics and updates
Custom board support
Adapt the same architectural rules—real-time scheduling, DMA ownership, time, ROS 2, and observability—to a specific embedded target.
- Driver and IRQ mapping
- Affinity and priority plan
- Clock and transport integration
Selected components
Bring targeted execution, telemetry, DDS policy, or lifecycle patterns into an existing Linux-based robot stack.
- QoS and executor profiles
- Health and timing telemetry
- Managed service boundaries
Build on a controlled runtime
Make every sample accountable.
Define the deadline, the clock, the memory path, the ROS 2 execution model, and the failure signal before the robot reaches production.
Discuss your runtime
olixOS™ / EMBEDDED REAL-TIME LINUX
