Hi everyone!
I mentioned this project at ROSCon Italy a couple of days ago but it was literally just released!
Meet ManyForge, which is an evolution of ManyMove.
It’s not just its “newer version”: it’s redesigned from ground up around a few core concepts, some of which I took directly from @scastro’s RoboPlan (the planner I use as standard in ManyForge):
- The core is ROS-free: all core ManyForge components are C++ or Python and don’t depend on ROS.
- Realtime-sensitive functionalities are C++, never Python.
- ManyForge is the authority for all important functionalities (scene, collisions, execution, stop), while ROS is the integration layer: stock ros2_control/JTC and vendor drivers through adapters.
- Mock, Sim and Real behave the same, so you can build a program on Mock and run it on Isaac Sim or a real robot.
The best part for UX is the GUI (the Composer): you build programs as behavior trees in a dedicated drag&drop editor allowing most of the functionalities you’d expect to ease programming a manipulator:
- a 3D scene where you place and move objects with gizmos, or edit them in the object editor;
- manual moves with a ghost robot that shows where the arm will end up (collision-checked) before you send it;
- Draft + Apply, so nothing changes on the cell until you say so;
- live robot state, I/O and stop handling right in the same window.
Honestly, it’s a huge application and it’s still in Beta, and I’m the first to recognize it would require more documentation and educational material to be understood correctly. I’m working on it. In the meantime, I’m making it as much operable and discoverable by LLMs as possible, so any frontier model should be able to install it and explain how it works in detail without much trouble.
A note about the development process: the public repository is for deployment and I’m using AI coding assistants heavily. But all development is based on a (for now private) Specs repo that is the authority on what each and every component of ManyForge is, what it does and how, in painstaking detail. Every change is checked against the Specs, reviewed independently and run through thousands of tests, sanitizer builds and stress runs, plus live checks on Mock, Isaac Sim and the real robot, so even structural changes don’t break execution.
Still, since I am the one doing all the architectural and design decisions, I’m pretty sure this could be better and I’m very open to discussing architectural and design choices, hardening, and also to introduce useful functionalities.