However, being widely adopted has turned its design into a messy blob that is not only "thick" - and not in a good way - but also too tangled. Therefore, I came up with the design for HORUS -Hybrid Optimized Robotics Unified System.
At first, I was just experimenting to see whether building a system that respects both the versions and dependencies of low-level packages like drivers, and high-level packages like ML/robotics algorithms would be that hard - unlike in ROS2. Surprisingly, with current modern technology, we can do a lot to make this vision come true. ROS2 users are always looking to avoid "reinventing the wheel" by trying to pick whatever exists in that tangled web and sticking it into their project. This workflow was good, at least in the old days. But now we have AI and modern frameworks/packages, yet developers are still struggling to make them work with ROS2.
My vision is to create a robotics framework that is "thick" as a whole (we can't avoid this - the tools, drivers, etc. make it impossible to be slim and fit everyone's needs), but modular by choice. I mean that developers, similar to ROS2, can still integrate their packages, but in a way that won't require opening at least 10 tabs. The design makes parts swappable - it's like building with Lego blocks, but with easy integration. You don't like this IPC communication mechanism? Swap it with a different IPC framework by editing 1 configuration line, and it won't break. You don't like these environment settings or how upgrading a single package breaks everything else? HORUS solves this.
HORUS aims to provide developers an interface where they can focus on writing algorithms and logic, not on setting up their environments and solving configuration issues. HORUS is designed to be both hybrid and unified. For example:
You can run horus run app.py driver.rs, and Python and Rust will communicate with each other seamlessly, as they all use shared memory for IPC. If a package is missing, the HORUS manager detects it and auto-installs a version that fits your current dependencies.
By design, every HORUS project can be a virtual environment if you want it to be. You can use packages already installed on your machine and link them to your project, or install new ones exclusively in your project. This solves dependency hell and the "works on my machine" problem. We also have horus env freeze, which freezes your environment and provides you an ID that other developers can use with horus env restore <ID> - similar to requirements.txt in Python.
I know what you're thinking: don't we already have these features elsewhere? Why not just install them and integrate them into ROS2, like virtual environments or multiple compilers? That's where the unified part of HORUS comes in. Robotics as a whole should be cohesive for the most part. Continuously splitting things apart and then piecing them back together will just create another ROS2. Therefore, by original design, the ecosystem should easily adopt new components and make them native. HORUS has a registry - a database of sorts - that aims to grow by gaining more HORUS packages. This makes future development easier by making every HORUS project part of the ecosystem.
Given all that, a modern robotics framework should have better performance, be high-level, easily integrate with AI/ML, and be user-friendly - even for students breaking into the field of robotics. HORUS is trying to achieve all of this, but without growth in the ecosystem, HORUS would be just another forgotten project.
You can try it out with the documentation to see the vision and goals: https://docs.horus-registry.dev/