Coming from ROS 2
Most of what you know transfers. Publishers, subscribers, topics, parameters, services,
actions, transforms, launch files, rosbag-style record and replay — HORUS has all of
them, under names you will recognise. What changes is the machinery underneath and the
build.
This page is the routing table. It does not teach the API; it tells you which of the three migration guides, the bridge recipe or the example projects is the right first click for the situation you are in.
Pick your situation
"I want to see the same node written both ways." Open the migration guide for your language. Each one is a side-by-side: the ROS 2 code, then the HORUS code, then what the difference is for.
"I have a working ROS 2 stack and I am not replacing all of it." You do not have to. Run HORUS for the real-time part and keep RViz, Nav2 and the rest of the ecosystem where they are — the ROS 2 Bridge recipe is the multi-process shape for that, and it is the usual way in.
"Show me a finished robot instead." The repository ships ten complete applications,
and the Example Projects page maps each ROS 2 tutorial you
might have followed onto the HORUS example that covers the same ground —
publisher/subscriber, tf2, nav2 sensor pipelines, ros2_control, MoveIt, rosbag2.
"I just want to run something." Quick Start is five minutes and assumes nothing about ROS 2 either way.
Vocabulary
Enough to read the rest of the documentation without translating in your head:
| ROS 2 | HORUS | Note |
|---|---|---|
rclcpp / rclpy / rclrs | the horus crate, the horus Python module, <horus/horus.hpp> | One library per language, no client-library layer to pick |
| node (a class you inherit) | node (a struct or class with a tick()) | Composition, not inheritance |
spin() / executor | Scheduler | You add nodes to it and call run() |
| callback on subscription | recv() inside tick(), or .on(topic) | Polling is the default; event-driven is opt-in |
| DDS domain ID | HORUS_NAMESPACE | Same job: isolate one system from another on a machine |
.msg files + codegen | plain structs, no IDL | See "No IDL" in the migration guides |
ros2 topic echo | horus topic echo | Most ros2 <noun> <verb> commands have a horus counterpart |
rosbag2 | horus record (list, replay, diff, export) | Record & Replay |
| tf2 | TransformFrame | Transform Frame |
colcon build | horus build | No workspace overlay, no source install/setup.bash |
What is genuinely different
Three things surprise people, and all three are covered properly elsewhere — listed here so they are not a surprise:
- There is no middleware to configure. No RMW implementation, no QoS profile, no
discovery daemon. Transport is shared memory by default; the LAN case is a flag
(
horus run --net). See Communication Patterns. - Timing is declared per node, not per executor. Rate, budget, deadline and miss policy are builder calls on the node itself. See Execution Classes.
- The build has no workspace. One
horus.tomlper project, no overlay to source before a binary will run. See Configuration Reference.
Where the honest comparison lives
Performance claims are on Benchmarks, including which figures are measured on the reference machine and which are published reference values that were not measured here. If you are evaluating rather than migrating, start there rather than with any number quoted in prose.