Animaquina: Controlling Industrial Robots Inside Blender
We spoke to Luis Pacheco about the story behind Animaquina, from early experiments rigging robots with Blender's Python API to its real-world applications and how Geometry Nodes became the technical core of the project.
Introduction
My name is Luis Pacheco, though most people know me as Luigi. I'm an Assistant Professor of Architecture at Florida Atlantic University's School of Architecture, where I direct the Interactive Machines Lab. I'm an architect by training, but I've always been interested in technology and how things get made.
I got into digital fabrication in the early 2010s when I co-founded MakerMex, one of Mexico's first desktop 3D printer companies. We built 3D printers, laser cutters, and educational tools around STEAM learning. One of those projects was MakerScad, a visual programming platform my business partner developed to make 3D design more approachable for kids. Building open tools has always been a big part of my career.
My Blender story actually started in architecture school. My Windows PC crashed right before a final, and the only thing I could get running on Linux fast enough to finish my missing renders was Blender. I never looked back, and it became my home base for everything 3D. So when I started working with industrial robots, I naturally wanted to bring them into Blender. That curiosity eventually became Animaquina, which grew into the core of my doctoral research.
Animaquina
It started pretty organically. Early on, I was rigging robots and experimenting with Blender's Python API through lots of small prototypes and little experiments. When I began my Doctor of Design, I unified all of those ideas into a single interactive robotics environment. I emphasize interactive because that's where Blender really changed the game.
What surprised me along the way was how much animation has to offer robotics. Blender's IK, constraints, drivers, and Geometry Nodes turned out to be a surprisingly powerful robot programming toolkit; it just wasn't labeled that way. With Blender's animation tools, you can tell one robot to look at another, track a person, or respond to a moving object in real time.
That kind of reactive behavior is genuinely difficult to achieve in traditional robot programming software. In Blender, it's almost trivial because animators have been solving these kinds of problems for decades.
Blender for Real-Time Robotic Fabrication
I didn't start out trying to reinvent robot programming. I simply wanted to replace my Rhino, Grasshopper, and KUKA|prc workflow because I was already spending most of my time inside Blender. Originally, I treated toolpaths as a static list of points that a robot followed one after another. Blender pushed me beyond that. Once your robot lives inside a real-time scene, toolpaths stop being static and become behaviors that you can animate, modify, and react to while everything is running.
It's already being used in production. Animaquina has been used across multiple research labs, but it's also been used on real built projects. The Dancing Columns project with Joseph Choma, exhibited at the Phase Gallery in Miami Beach, was entirely fabricated with Animaquina. More recently, a six-meter-tall column by artist Edouard Duval-Carrié, currently on display at the Venice Biennale, was produced using it for both the robotic 3D printing and robotic milling.
Today, Animaquina is in open beta, and besides the beta users, I use it daily for research across KUKA, Universal Robots, and xArm platforms. While the project started around robotic fabrication, I'm increasingly interested in motion control, entertainment, and robotic cinematography. I'm excited to see what that community builds with it.
This is a light painting with the robot made by students in a course I give to master's students at Universidad de las Americas in Quito, Ecuador.
Geometry Nodes
Geometry Nodes has become the foundation for building custom procedural fabrication workflows. I use it to slice surfaces, rearrange points to avoid collisions, generate toolpaths, visualize the result, and simulate the robot before anything happens in the real world. The workflow itself is straightforward. You add a robot, select its brand and model from the available rigs, and connect to the physical machine.
Once connected, Blender continuously reads the robot's state, so its joint positions and TCP are mirrored inside the scene. Move the real robot, and the digital twin updates instantly. That's incredibly useful when mapping real-world objects (like a 3D printing surface) into Blender. To program the robot, you simply move a target Empty. Position it, rotate it, and command the robot to follow it. You can also assign a curve, and the robot will automatically follow that path.
This is where Geometry Nodes becomes really powerful. Every point along the path can carry attributes such as speed, extrusion rate, cooling fan values, or any custom parameter you define. The fabrication logic travels with the geometry itself instead of living somewhere else in the software.
For robotic 3D printing, custom node groups slice the geometry using different strategies. Traditional directional slicing follows the Z axis, while non-planar and geodesic slicing follow the surface to improve overhangs. Multi-axis strategies also reorient the robot's tool continuously to optimize printing.
At this point, I've built node groups for portrait drawing, vase printing, milling, non-planar printing, and several other fabrication processes. Because everything is procedural, changing the design automatically updates the robot path. Tweak a curve, and the toolpath, the simulation, and ultimately the physical robot all update with it.
Then there's Puppet Mode, where Blender's animation tools really shine. Animate the target with a Follow Path constraint (or any other animation tool), and the physical robot follows in real time. Because the robot is driven directly from Blender's animation system, iteration becomes incredibly fast.
The area I'm most excited about now is bringing live data into Blender. I'm developing an add-on that exposes OSC and MQTT data as Blender properties, allowing Geometry Nodes to react to live sensor information. The same workflows that have driven procedural animation for years can now drive physical robots. It's still a work in progress, but I think it opens the door to truly real-time procedural robotics.
Other Projects
Besides Animaquina itself, I've developed FabNodes, a companion add-on for generating G-code and fabrication workflows using Geometry Nodes attributes. It's heavily inspired by Alessandro Zomparelli's G-code Exporter, which showed how powerful Blender could be for digital fabrication.
I've also built an MQTT add-on that lets Blender both receive and publish MQTT messages. MQTT is a lightweight messaging protocol widely used in IoT, and it's how Blender communicates with end effectors such as motors, LEDs, sensors, cameras, and other hardware. Because it's hardware agnostic, the same workflow works whether I'm controlling a KUKA, Universal Robots, or xArm robot.
One of Blender's greatest strengths is that it ships with a full Python interpreter. That makes it straightforward to integrate almost any Python library, and it's one of the reasons Blender has become such a flexible platform for building a complete robotics development environment.
Development of Animaquina
The biggest challenge has been supporting multiple robot manufacturers. Every brand has its own programming language, communication protocol, controller, and limitations. A huge amount of the development work goes into hiding that complexity behind a single interface, so artists and designers can focus on creating instead of learning the quirks of each robot.
The most unexpected part wasn't a solution; it was a discovery. I kept running into robotics problems, reaching for whatever Blender had, and realizing it already solved them. Constraints, armatures, drivers, Geometry Nodes, and keyframes kept solving robotics problems they were never designed for. It feels like the tools were already there, waiting to be used differently.
Advice to Indie Developers
I think we're at a point where a single developer has access to tools that simply didn't exist or weren't as accessible ten years ago. Blender, Python, GitHub, AI assistants, and open-source communities have dramatically lowered the barrier to building software.
Animaquina itself started as a side project during my doctoral research. My advice is not to try to build the whole thing at once. Pick one problem you're genuinely interested in solving, and keep building from there.
Conclusion
Animaquina is currently in open beta. At the moment, it supports KUKA, Universal Robots, and UFactory robots, and I'm currently working on adding ABB support. Anyone interested in trying it can register for the beta here. I'll continue sharing updates, tutorials, and development progress as new features are added.
