[Show and Tell] ROS 2 Blueprint Studio: Visual Node Editor & Boilerplate Generator (Alpha)

ROS ROS General
, , , ,
1

Hi everyone!

Like many of us, I appreciate the power and flexibility of ROS 2, but I’ve always found the amount of manual boilerplate to be a bottleneck for rapid development. Keeping track of all the configuration details making sure CMakeLists.txt and package.xml are perfectly synced, or manually wiring launch files and topic connections takes a significant amount of time. I wanted to find a way to automate this infrastructure setup so I could focus purely on writing the actual robotics logic.

To solve this, I started building ROS 2 Blueprint Studio a visual node-based editor (inspired by Unreal Engine Blueprints) designed to take the routine off your shoulders.

image
image1402×933 47 KB

Under the Hood (Architecture) I tried to avoid any “black magic” and stick entirely to standard ROS 2 practices:

1. Code Generation & Build System The studio doesn’t compile the code itself; it acts as a smart templating engine. Creating a standard node generates a base C++ template. If you duplicate a node (from the palette or canvas), it creates an independent file with a new name and copied code. Modifying the copy doesn’t break the parent. For the actual build, it relies on standard colcon build under the hood.

2. File Watcher & Dependency Tree To build the dependency tree, I wrote a custom FileWatcher. Before building, it scans the files to check for includes and node communication. For performance, it only parses files that have been modified. (I realize this might theoretically cause “phantom connections” on massive graphs, so I plan to add a forced full-rebuild mode in the future).

3. Topic Routing (Two Approaches) Node linking currently works in two modes:

  • Hardcoded (Bottom-Up): If publisher and subscriber topic names are explicitly hardcoded in your C++ or Python files, the UI detects this and automatically draws a visual “locked” wire between them.

  • Visual (Top-Down): You can define the topic name only on the publisher, drag a visual wire to a subscriber, and the FileWatcher will find a special placeholder in the subscriber’s code and automatically replace it with the publisher’s topic name. (Full disclosure: the visual routing is still a bit unstable and not recommended for huge projects yet, but I’m refining it).

0316

4. Runtime Environment (Docker) I chose Docker (osrf/ros:humble-desktop) as the execution environment. Why?

  • Setting up ROS 2 natively on Windows is a special kind of pain.

  • It provides painless deployment and saves you from dependency hell when migrating to future ROS versions.

  • You can send your project folder to someone who doesn’t even have ROS installed, and their system will build and run your entire architecture in just a few clicks.

image
image706×454 21.7 KB

The Ask: Roast My Architecture The project is currently in early alpha. Honestly, my biggest doubts right now are around the core architecture and the automated build system (package and launch file generation).

I would be incredibly grateful if experienced ROS architects could take a look at the repo, point out my blind spots, and give me some harsh architectural critique. I’d much rather rebuild the foundation now than drag architectural flaws into a full release.

Source code here: GitHub - NeiroEvgen/ros2-blueprint-studio · GitHub

Any feedback is highly appreciated!

3 Likes
ROS News for the Week of March 16th, 2026
2

Hi everyone!

Back in spring I shared the first alpha of ROS 2 Blueprint Studio — a visual node-based editor (inspired by Unreal Engine Blueprints) that generates, builds and runs real ROS 2 systems in Docker, so you can focus on robotics logic instead of boilerplate. Since then I’ve been quietly grinding through the parts that didn’t work yet, and I’ve just released v0.5.0 — the biggest update so far. Some of you gave me architectural feedback last time, so here’s what changed under the hood.

What’s new in v0.5.0

  1. Hierarchical subgraphs. You can now collapse a group of nodes into a single composite block and dive in and out of it. Large graphs finally stay readable. Groups survive save/load, can be dissolved (Del) or deleted with their contents (Ctrl+Del).

  2. Deploy groups → docker-compose. Each subgraph can become its own deployment unit: the studio generates a per-group launch file and a service entry in a docker-compose.yml. One visual graph maps onto multiple isolated containers. No magic here either — it’s all standard launch files and plain compose, you can read every generated line.

  3. Python nodes now work end-to-end. Graph → generated rclpy code → live running nodes. Previously the Python side was, let’s be honest, decorative. (One known gap: port-to-code generation for Python templates isn’t wired yet — publishers/subscribers defined on the canvas don’t materialize in the generated code. Queued for 0.5.1.)

  4. Live code sync. Double-clicking a node now opens its real source file in your system editor — no more temp-file dead ends. A FileWatcher picks up external edits and syncs them back into the graph, and manual changes survive regeneration (the template engine no longer overwrites your hand-written code). (Full disclosure: there’s a save-sync race on freshly created nodes — sometimes you need a manual “Rescan Code for Ports” after the very first save. Fix queued for 0.5.1.)

  5. Foxglove-based visualization. This one was personal. Fighting VcXsrv/XLaunch on Windows every single release finally broke me, so now one click starts foxglove_bridge inside the container and opens a live 3D view — markers, topics, cameras, no X server involved. Classic X11 mode is still there as an option for RViz die-hards.

  6. Portability. Portable Docker export (send the folder to someone without ROS — it builds and runs) and a shareable custom-node palette format: your hand-made nodes can be exported as a single .bppalette file and imported by someone else.

A quick reality check: hand-teleoperation demo

To smoke-test the new workflow end-to-end, I built a small demo: webcam hand-tracking on the host → UDP → three C++ nodes (receiver, smoothing controller, marker renderer) → a 6-axis arm mirroring my hand live in Foxglove.

It took about 30 minutes from empty canvas to a working arm, which honestly surprised me — most of that time was writing the actual nodes, not fighting infrastructure. Which is, I guess, the whole point of the project.

hand_teleop_loop_800px

I’ll publish this demo as an example project in the repo.

Status

Still alpha, and I try to keep the known rough edges documented rather than hidden: the save-sync race and the Python port generation mentioned above are the two biggest ones, both queued for 0.5.1. Proper documentation and tutorials are planned for August.

Source code here: GitHub - NeiroEvgen/ros2-blueprint-studio

The Ask

Last time I asked you to roast my architecture — this time I’d love input on direction:

  1. Does the Docker-based workflow make sense for your teaching or prototyping use cases?
  2. What’s missing before you’d consider trying it with students or interns?

Issues and PRs are very welcome. Any feedback is highly appreciated!

[UPDATE] v0.5.1 + the promised example

Two quick follow-ups:

The hand-teleop demo now ships inside the studio as a built-in node palette: drag three nodes onto the canvas, press Run, start the host tracker script — and wave at your webcam. A sticky-note node with the full guide sits in the palette right next to them; the host-side script lives in examples/hand_teleop/.

(Side effect: the studio now has sticky notes on the canvas that don’t affect the build — turned out we needed them for exactly this.)

2 Likes