Goals & Vision

What is HORUS Trying to Achieve?

HORUS aims to become the de facto standard for real-time robotics communication by providing an ultra-low latency, memory-safe, and developer-friendly framework that bridges the gap between research prototyping and production deployment.

Core Objectives

Sub-Microsecond Communication: Achieve ~75ns median latency for small control messages (16B CmdVel) and sub-microsecond latency for larger sensor messages, enabling real-time control loops at 1kHz+ frequencies

Zero Compromise Performance: Deliver sub-200ns message passing — roughly 30x lower latency than ROS 2's published REP 2014 reference for default DDS — without sacrificing safety or ease of use

Memory Safety by Default: Leverage Rust's type system to eliminate entire classes of bugs common in C++ robotics frameworks

Unified High-Level Workflow: Single command for build, run, and deployment across Rust, Python, and C++ with minimal configuration (simple horus.toml vs complex ROS XML)

Dependency Isolation: Solve dependency hell with portable, isolated environments and reproducible builds

Developer Experience First: From prototype to production without friction - auto-detect, auto-install, just run

Problems HORUS Solves

High IPC Latency in Traditional Frameworks

Problem: Traditional middleware introduces 50-500µs of latency, which is too slow for high-frequency control loops required in modern robotics.

HORUS Solution:

Shared memory architecture with zero-copy semantics
~75ns median (135ns p99) for CmdVel (16B messages), with the shared-memory backend selected automatically per topic
~210ns median (283ns p99) for LaserScan (1.5KB messages)
Sub-microsecond latency for typical robotics messages, benchmarked over an 8B-64KB size sweep

Impact: Enables 1kHz+ control loops for precise manipulation, high-speed drones, and real-time sensor fusion.

Memory Safety Issues

Problem: C++ frameworks are prone to memory leaks, use-after-free, data races, and segmentation faults that cause robot crashes in production.

HORUS Solution:

Written in Rust with safe user-facing APIs (unsafe is encapsulated in performance-critical core internals with SAFETY comments)
Pool-backed RAII types and POD message structures prevent common memory bugs
Compile-time guarantees for thread safety and memory safety

Impact: Drastically reduces debugging time and increases system reliability in production environments.

Dependency Hell and "Works On My Machine"

Problem: Managing dependencies across teams is a nightmare. Different Python versions, missing system libraries, incompatible package versions - research code rarely runs on production machines without hours of debugging.

HORUS Solution:

horus.lock pins exact dependency versions for reproducible builds (horus lock)
Portable environments that work identically across machines
Isolated dependency resolution prevents version conflicts
Package registry with automatic dependency installation

Impact: Share code with reproducible environments. Onboard new developers quickly. Production deployments match development environments when using the same configuration.

Complex Build and Runtime Management

Problem: Different build systems for different languages. Manual dependency installation. Configuration files everywhere. Switching between Rust and Python requires completely different workflows.

HORUS Solution:

Single unified command: horus run for everything
Auto-detection: Automatically detects project language and type
Auto-install: Missing dependencies? Installed automatically
Minimal configuration: Simple horus.toml (no makefiles, no build scripts, no setup.py)
Multi-language support: Same workflow for Rust, Python, and C++

Impact: Developers focus on robotics, not build systems. Instant iteration cycles. No more "how do I run this?"

Poor Developer Experience

Problem: Traditional frameworks have steep learning curves, require extensive boilerplate, and lack integrated monitoring.

HORUS Solution:

Simple tick() method with init() and shutdown() lifecycle
Minimal boilerplate with the Node trait
Built-in logging with automatic pub/sub tracking
Real-time monitor plugin (horus install horus-monitor) with CPU, memory, and message flow tracking
Interactive CLI with smart templates and package search

Impact: Developers can focus on robot logic instead of framework complexity.

Reinventing the Wheel Every Project

Problem: Robotics teams waste countless hours rewriting the same components - IMU drivers, PID controllers, path planners, sensor filters. Every project starts from scratch because sharing code across teams and organizations is too difficult.

HORUS Solution:

Built-in message library: horus_types (universal IPC types) and horus_robotics (standard robotics messages), both re-exported through horus::prelude
Standard messages: Imu, LaserScan, CmdVel, Image, PointCloud, and more — ready to use
Easy customization: Override just the tick() method to customize behavior
Registry for sharing: Publish and reuse custom nodes across teams
Community ecosystem: Growing library of production-ready components

Real-World Impact:

Instead of writing yet another message serializer, use the built-in message types in Python:

from horus import Node, Scheduler, Imu, CmdVel

def sensor_tick(node):
    if node.has_msg("imu.data"):
        imu: Imu = node.recv("imu.data")
        # Standard fields, ready to read — no custom parsing needed
        if abs(imu.accel_z) > 12.0:
            node.send("cmd_vel", CmdVel.zero())  # emergency stop

sensor = Node(name="sensor", subs=["imu.data"], pubs=["cmd_vel"], tick=sensor_tick, order=0)
scheduler = Scheduler()
scheduler.add(sensor)
scheduler.run()

Or use the same standard messages from Rust:

use horus::prelude::*;

// Use pre-built message types for common robotics data
let imu_topic: Topic<Imu> = Topic::new("imu.data")?;
let scan_topic: Topic<LaserScan> = Topic::new("lidar.scan")?;
let cmd_topic: Topic<CmdVel> = Topic::new("cmd_vel")?;

Impact: Transform robotics from "build everything from scratch" to "compose from proven components". Teams ship faster, researchers focus on novel algorithms instead of infrastructure, and knowledge compounds across the community through the built-in message library (horus_types, horus_robotics) and the registry.

Problem: Useful nodes stay locked inside the team that wrote them - there is no common way to package, publish, or discover robotics components across organizations.

HORUS Solution: Built your own IMU driver for a specific sensor? Share it with the community through the HORUS Registry:

# Publish your package to the registry
horus publish

# Others can discover it
horus search imu-driver

# And install it in one command
horus install your-imu-driver

The Registry enables:

Discover packages: Search the registry for community-contributed nodes
One-command install: horus install sensor-fusion - no manual setup
Semantic versioning: Reliable dependency management with automatic updates
Category filtering: horus search <query> --category lidar|camera|imu|motor|... narrows results
GitHub authentication: Secure publishing with your GitHub account
Signed packages: ed25519 publisher signatures verified at install (horus auth trust-publisher)

Real example - Cross-team collaboration:

# Team A builds and publishes a SLAM node
cd my-slam-package
horus publish
#  Published slam-cartographer v1.0.0 successfully!

# Team B discovers and uses it weeks later
horus search slam
# Found 1 plugins matching 'slam':
#
#   slam-cartographer v1.0.0 [REGISTRY]
#     SLAM using cartographer
horus install slam-cartographer

Then use it directly in their code:

use slam_cartographer::CartographerNode;

scheduler.add(CartographerNode::new()?).order(2).done();

Impact: Knowledge compounds across the entire robotics community. Build something useful once, share it globally. The registry becomes the npm/cargo/PyPI for robotics - proven components available to everyone.

Lack of Multi-Language Support

Problem: Switching between languages in robotics often requires multiple communication frameworks or language-specific bindings with performance penalties.

HORUS Solution:

Native support for Rust, Python, and C++
Unified workflow across all languages
Python bindings via PyO3 with shared memory access for near-native performance
Same horus run command works for Rust, Python, and C++ projects

Impact: Teams can use the best language for each component without performance penalties or workflow friction.

Cons HORUS Avoids

Network Overhead: Shared memory eliminates network serialization overhead and achieves deterministic latency.

Configuration Complexity: No XML files, no complex workspaces. Just horus new, write code, and horus run.

Debugging Black Holes: Automatic logging and performance metrics, plus the first-party horus-monitor plugin (horus install horus-monitor), eliminate the need for external debugging tools.

Unsafe Code: Safe user-facing APIs; unsafe stays confined to audited core internals with SAFETY comments. Memory safety is not optional in HORUS.

Version Conflicts: Isolated environments prevent dependency version conflicts across projects.

Build System Hell: One unified build system for all languages. Auto-detect, auto-install, minimal config (just horus.toml).

Robotics Scenarios That Benefit from HORUS

High-Speed Manipulation

Use Case: Pick-and-place robots, surgical robots, assembly line automation
Why HORUS: Sub-microsecond latency enables 1kHz+ control loops for precise trajectory following
Performance: ~75ns median (135ns p99) CmdVel latency for real-time control

Drone Control & Stabilization

Use Case: Quadcopters, racing drones, delivery drones
Why HORUS: Fast IMU processing (~121ns median for 304B IMU messages) enables real-time attitude control
Performance: sub-200ns end-to-end message passing, measured; roughly 30x lower latency than ROS 2's published DDS reference. HORUS's own numbers are measured by all_paths_latency; the ROS 2 figure is quoted from REP 2014, not measured here.

Collaborative Robots (Cobots)

Use Case: Human-robot interaction, force-torque control, safe operation
Why HORUS: Low latency force feedback and memory safety prevent dangerous failures
Performance: Priority-based scheduling ensures safety-critical tasks run first

Autonomous Vehicles

Use Case: Self-driving cars, mobile robots, warehouse robots
Why HORUS: Fast laser scan processing (~210ns median for 1.5KB scans) enables real-time obstacle detection
Performance: Sub-microsecond latency for typical robotics messages, benchmarked over an 8B-64KB size sweep

Industrial Automation

Use Case: Production lines, quality control, machine vision
Why HORUS: Deterministic latency and memory safety meet industrial reliability requirements
Performance: Predictable performance for 24/7 operation

Research Prototyping

Use Case: University labs, robotics research, algorithm development
Why HORUS: Simple API, built-in monitoring, fast iteration cycles, and portable environments
Performance: Transition from prototype to production without rewriting code

Teleoperation & Haptics

Use Case: Remote surgery, VR robotics, haptic feedback systems
Why HORUS: Ultra-low latency eliminates perceptible lag in feedback loops
Performance: ~75-210ns message passing (16B-1.5KB messages) enables sub-millisecond end-to-end latency

Multi-Robot Systems

Use Case: Swarm robotics, warehouse fleets, distributed sensing
Why HORUS: Registry enables instant code sharing across robot fleets, isolated environments prevent conflicts
Isolation: Per-project .horus build directories isolate dependencies between robot types
Reusability: Share swarm coordination nodes, formation controllers, and multi-agent algorithms through the registry

When NOT to Use HORUS

While HORUS excels in many scenarios, it may not be the best choice for:

Internet-scale distributed systems: HORUS is optimized for single-machine shared memory IPC, not WAN/internet communication
Legacy framework integration: If you need tight integration with existing ecosystems
Non-real-time applications: If you don't need sub-millisecond latency, simpler solutions may suffice
Pure simulation: Use standalone simulators for pure simulation needs

The HORUS Vision

HORUS provides:

Accessible real-time robotics for researchers and hobbyists, not just large companies
Memory safety by default, eliminating entire classes of production failures
Modern developer experience with instant feedback and zero-config tooling
Seamless research-to-production without rewrites
Reliable dependencies that work everywhere, every time
One command for everything: Build, run, deploy - across all languages
Composable robotics: Install proven components instead of rewriting everything
Knowledge sharing: Community builds on each other's work through the registry
Sharing is effortless: Publishing your node benefits the entire robotics community

We're creating the robotics framework we wish existed when we started - and the ecosystem that makes robotics truly reusable.

Ready to get started? Check out the Installation Guide or the Quick Start Guide.

Goals & Vision

What is HORUS Trying to Achieve?

Core Objectives

Problems HORUS Solves

High IPC Latency in Traditional Frameworks

Memory Safety Issues

Dependency Hell and "Works On My Machine"

Complex Build and Runtime Management

Poor Developer Experience

Reinventing the Wheel Every Project

Sharing Across Developers & Organizations

Lack of Multi-Language Support

Cons HORUS Avoids

Robotics Scenarios That Benefit from HORUS

High-Speed Manipulation

Drone Control & Stabilization

Collaborative Robots (Cobots)

Autonomous Vehicles

Industrial Automation

Research Prototyping

Teleoperation & Haptics

Multi-Robot Systems

When NOT to Use HORUS

The HORUS Vision