Design robot behavior.
Export production code.
A drag-and-drop designer for ROS robots. Compose a workflow from blocks, validate it against your robot’s real limits, and export a deployable ROS 2 package in Python or C++. No embedded engineer in the loop for every change.
It isn’t the robot. It’s the firmware queue.
Hardware is cheaper and more capable than ever. What’s scarce is the person who can make it do something new — and every routine change waits on them.
Hiring is not the answer
Embedded and robotics roles sit open for months. You can’t staff your way out of a shortage that everyone else is also bidding into.
Every tweak is a ticket
Reordering a pick, changing a threshold, adding a SKU — trivial in intent, but each one means a developer touching ROS-level code.
ROS is developer-first
It’s the right standard, and it assumes you write C++ or Python. Your process engineers know the task better than anyone, and can’t touch it.
Three steps, no lock-in
The graph is the source of truth. Everything downstream is generated from it, and the generated package is yours to keep.
Compose
Drag blocks onto the canvas — motion, manipulation, perception, logic, I/O, safety — and wire them into a sequence with branches and loops. Parameters are typed, with units.
Validate
Before anything is generated, the graph is checked against the target robot: unsupported capabilities, speeds and forces beyond its envelope, poses outside its reach, unreachable nodes, unbounded loops.
Export
Out comes a complete ROS 2 package — node source, package.xml, build files, launch file and a test. Build it with colcon like anything else.
Real code, not a black box
This is actual generator output for the graph above — readable, reviewable, and diffable in your own repository. If you ever stop paying us, the code keeps running.
# Source : generated from an iMechSpace behavior graph
class InspectAndAdvanceBehavior(Node):
def __init__(self) -> None:
super().__init__("inspect_and_advance")
self.hal = HardwareAbstractionLayer(
node=self, target="ros2-jazzy")
self.range_front = None
def run(self) -> BehaviorResult:
self.range_front = self.hal.read_sensor(
sensor="lidar", samples=3)
if self.range_front < 0.5:
self.hal.wait(duration=1)
else:
self.hal.rotate(axis="z", angle=90,
angular_speed=30)
self.hal.move_relative(axis="x",
distance=0.2, speed=0.2)
return BehaviorResult.SUCCESS$ imechspace-run inspect_and_advance_node.py \
--sensor lidar=0.42,0.41
[ 0.000s] lifecycle hal.ready(backend='simulation')
[ 0.000s] command read_sensor(sensor='lidar')
[ 0.150s] result read_sensor.value(value=0.42)
[ 0.150s] command wait(duration=1)
[ 1.150s] command move_relative(axis='x')
[ 2.150s] lifecycle shutdown()
final pose : (0.2, 0.0, 0.0) yaw=0 deg
simulated time : 2.15 s
result: success- ✦Your repository, your code. Export the package and commit it. No runtime dependency on our servers.
- ✦Run it before you build it. A deterministic simulator executes the behavior on a laptop — a five-minute routine finishes in milliseconds.
- ✦Versioned by default. Every graph change snapshots a version you can diff and restore.
- ✦Python or C++. Same graph, either target, chosen at export time.
Hardware-agnostic by design
Blocks map to capabilities; each robot declares what it can do. Ask a fixed arm to drive two metres and the build fails with the offending block — rather than shipping code that faults on the floor. Status below is stated plainly, including what isn’t ready.
| Target | Languages | Driver status | Notes |
|---|---|---|---|
| ROS 2 Jazzy | Python, C++ | Stable | Full capability set |
| ROS 2 Humble | Python, C++ | Stable | Full capability set |
| Generic HAL | Python, C++ | Stable | Portable target for bring-up and simulation |
| ROS 1 Noetic | Python, C++ | Beta | No lifecycle safety service |
| Universal Robots | Python | Beta | Arm only — no mobile base capabilities |
| FANUC (Karel) | C++ | Planned | Simulates today; live transport not built |
Guardrails, honestly described
Speeds, forces and reach are checked against the target’s declared envelope twice: when the code is generated, and again at runtime for values that only exist while running. Violations stop the command before it reaches the robot.
- ✦Capability gating per robot, before any code is emitted
- ✦Speed, force and workspace limits enforced at generation and at runtime
- ✦User-typed expressions validated before they reach generated source
- ✦Emergency stop latches; further motion commands are refused
⚠ What this is not
These are software guards. They are not a certified safety controller, an ISO 10218 stop category, a safety PLC or a light curtain, and they must not be treated as one. Commission a generated behavior exactly as you would hand-written code: dry-run it, keep an operator on the e-stop, and verify the workspace bounds match the real cell.
Questions worth asking
Is this production ready?
Not yet, and we’d rather say so. The designer, the code generator and the simulator all work today — you can build a graph, generate a ROS 2 package and execute it against the simulator. What hasn’t happened is sustained validation on customer hardware. That is exactly what early access is for, and it’s why we’re looking for design partners rather than sign-ups at scale.
Does this replace our robotics engineers?
No. It removes them from the queue for routine changes. “Pick up the red box, move two metres, place it” is the easy 80% of the work, and it currently consumes engineering time it shouldn’t. The hard 20% — perception in bad lighting, gripper slip, recovery from an unexpected obstacle — is still engineering, and pretending otherwise would waste your time and ours.
What if our robot isn’t on the list?
The generic HAL target emits portable code against a plain interface, which is usually the fastest way to bring up something new. Adding first-class support means writing a driver that declares its capabilities and limits — a contained piece of work, not a change to the designer or the compiler. Tell us what you run.
Do we depend on you to keep running?
No. Generated packages are ordinary ROS 2 packages: node source, build files, launch file, tests. Commit them to your own repository and build them with colcon. If you stop using iMechSpace, the robots keep doing what they were doing.
Who is it actually for?
Teams running ROS or ROS 2 robots where more people understand the process than the codebase: systems integrators deploying similar cells repeatedly, manufacturers with in-house automation, warehouse and logistics operators, and research labs that want to spend their time on the research rather than the plumbing.
How much will it cost?
Pricing isn’t set. Early access participants get it free during the programme, and we’d rather learn what it’s worth to you than anchor on a number we invented.
Put your robots to work sooner
We’re taking on a small number of design partners running ROS or ROS 2 hardware. You get the tool and direct input on the roadmap; we get honest feedback from a real cell.
Prefer to talk first? Email us directly.