Why HORUS?

HORUS is a robotics framework built for teams that need speed, determinism, and simplicity — without the complexity of traditional middleware stacks.

The Problem with Traditional Robotics Middleware

Most robotics frameworks were designed in the 2000s-2010s for multi-machine, networked robot systems. They use serialization, network protocols, and discovery mechanisms that add overhead — even when all your components run on the same machine.

The result:

• 50-100 μs per message (DDS/ROS2) — fine for 10Hz planning, painful for 1kHz control
• Non-deterministic callback ordering — debugging race conditions in safety-critical code
• 3+ config files per package — CMakeLists.txt, package.xml, launch files, colcon workspace
• Weeks of setup — DDS tuning, QoS profiles, executor configuration

Most robots don't need this. A warehouse AGV, surgical robot, drone, or research platform runs all its control software on a single computer. The network layer is pure overhead.

What HORUS Does Differently

1. Shared Memory IPC — 575x Faster

HORUS topics use shared memory, not network protocols. No serialization, no copying, no middleware layer.

This isn't a synthetic benchmark — these are real robotics message types at real payload sizes. The speedup matters most for control loops above 100Hz where every microsecond counts.

2. Deterministic Execution — No Race Conditions

HORUS runs nodes in a guaranteed order every tick:

scheduler.add(SafetyMonitor::new()?).order(0).build()?;  // Always first
scheduler.add(SensorReader::new()?).order(1).build()?;    // Always second
scheduler.add(Controller::new()?).order(2).build()?;      // Always third
scheduler.add(Actuator::new()?).order(3).build()?;        // Always last

No callback scheduling surprises. No mutex deadlocks. The safety monitor always runs before the actuator — every tick, guaranteed.

3. Auto-Detected Real-Time

Set a rate or budget, and HORUS automatically enables RT features:

scheduler.add(MotorNode::new()?)
    .order(0)
    .rate(1000.hz())     // 1kHz → auto-enables RT
    .budget(200.us())    // 200μs budget per tick
    .on_miss(Miss::Skip) // Skip tick if budget exceeded
    .build()?;

No DDS QoS tuning. No PREEMPT_RT kernel patches. No rmw configuration files. Just declare your timing requirements and HORUS handles the rest.

4. Single-File Config

Everything in one horus.toml:

[package]
name = "warehouse-robot"
version = "1.0.0"

[dependencies]
nalgebra = "0.32"
opencv = { version = "0.92", source = "system" }

[scripts]
start = "horus run --release"
test = "horus test --parallel"

No CMakeLists.txt. No package.xml. No colcon workspace. No launch files for simple cases.

5. Built-in Safety

HORUS has safety features built into the scheduler — not bolted on:

• Watchdog: Detects frozen nodes and triggers recovery
• Deadline enforcement: .budget() and .deadline() are first-class
• Graduated degradation: Ok → Warning → Expired → Critical (not binary crash/no-crash)
• Safe state: Every node can implement enter_safe_state() (stop motors, close valves)
• Emergency stop: <100 μs response time

6. Rust + Python — Your Choice

// Rust: Maximum performance, compile-time safety
struct Controller { cmd: Topic<f32> }
impl Node for Controller {
    fn tick(&mut self) { self.cmd.send(compute_velocity()); }
}

# Python: Fast prototyping, ML integration
def controller_tick(node):
    node.send("cmd", compute_velocity())

Same framework, same topics, same scheduler. Mix Rust and Python nodes in the same application. Use Python for prototyping, Rust for production — or both simultaneously.

Who Uses HORUS

HORUS is designed for:

• Research labs prototyping new robot behaviors (Python quick iteration)
• Startups building production robots (Rust safety + performance)
• Control engineers who need deterministic timing (auto-RT, deadline enforcement)
• Teams migrating from ROS2 who want simpler tooling without sacrificing capability
• Solo developers who want to build a robot without weeks of framework setup

What HORUS Is NOT (Yet)

Being honest about current limitations:

• Not multi-machine — HORUS is single-machine. For fleet management or distributed robots, use ROS2 for the network layer and HORUS for on-robot control
• No RViz equivalent — horus monitor shows nodes, topics, and metrics, but not 3D visualization
• Smaller ecosystem — ROS2 has thousands of packages. HORUS has a growing registry but can't match 15 years of community contributions
• No ROS2 bag compatibility — HORUS has its own recording format

These are active development areas. The core framework is production-ready; the ecosystem is growing.

Get Started

Ready to try HORUS?

• Installation — 5 minutes to install
• Quick Start — 10 minutes to your first robot
• HORUS vs ROS2 — Detailed technical comparison
• Benchmarks — Full performance data

# Install and build your first robot in under 15 minutes
curl -fsSL https://horusrobotics.dev/install.sh | sh
horus new my-robot
cd my-robot && horus run