SideFX Houdini in a Robot Control Loop
SideFX Houdini is a tool from the visual effects industry which is used for<br>tasks which involve procedurally generating or manipulating geometry, like simulating explosions using fluid dynamics or<br>synthesizing a city based on geometric rules. It provides a node-based visual programming environment with a large<br>library of common operations built in, but also makes it easy to drop in custom code using its own C-like language<br>called Vex or Python. The networks of nodes generally flow downward, where each node is outputting modified geometry<br>based on its inputs, so the results of operations can be aggressively cached. The usual way of working in Houdini is to<br>build up to a result incrementally, and then when you have what you need you can render out the full, high fidelity<br>result (images or geometry) as quickly as your available hardware allows. It’s not a tool intended for real-time effects<br>(like Touch Designer, for example).
But what if you tried to use it in a real-time application anyway? Would that be particularly useful for anything? I<br>know the answer is yes for at least one application: rapid-prototyping algorithms for controlling robots.
Let’s look at a simple end-to-end example of doing this with Houdini.
Prototyping a Motion Planning Algorithm in Houdini
I have a mobile robotics platform I call Slug that I’ve been hacking on. It’s the bottom half of an electric wheelchair<br>stuffed with a large DIY 18650-based LiPo battery, drive electronics, and a big inverter so I can plug in my UR5 robot<br>arm. It’s held together with scrap plywood and hardware store parts. There are a few specific projects that I want to<br>use it for but it’s also just an excuse to try solving various robotics problems myself.
One of those problems is motion planning. Let’s say I wanted Slug to go over to an object and pick it up. It needs to be<br>able to figure out where it is relative to the object and then navigate to it through an environment that might have<br>various obstacles. An old, intuitive, and easy to implement means for accomplishing this is known as the dynamic window<br>approach.
Motion Planning with the Dynamic Window Approach
The basic idea of is to generate (dynamically) a bunch of paths (a window) that the robot could follow from the place<br>where it currently is, then compute costs for them based on how “good” they are, and finally pick the one that has the<br>lowest cost. The robot can then follow that path for a little while before repeating the process to adjust its path.<br>Optimization-based approaches like this can be very pleasant to work with because they allow for a smooth creative<br>space. You can start out with a naive approach for each part and get something that sort of works, then replace it in<br>bits and pieces to incrementally improve. Plus it gives you a few knobs that you can turn to explore solutions, like the<br>relative scales of your costs or how long the candidate paths you generate are, or how often you run the process to<br>update your plan.
Slug is what is called a differential wheeled robot - it moves forward if the wheels turn together and if they rotate<br>at the same speed opposite each other then it turns in place. A simple way to think about generating the candidate paths<br>is to imagine that we take the speeds that the robot is currently turning the wheels and just calculate the path that<br>the robot would take if those speeds were fixed at slightly different values. That path will look like an arc. Sweep<br>across a range of speeds and you’ll have a collection of candidate arc paths that the robot could follow in the near<br>future. Then to score them you can walk along each and see how far away the robot is from obstacles and the goal at<br>every point. Being close to an obstacle or being far from the goal adds cost to the path. Then you just pick the<br>candidate path with the lowest total cost and that gives you the new speed for each of the wheels.
Building it up in Houdini
What does an implementation of this look like in Houdini?
First, to set up the problem I needed some obstacles. I made a square and scattered some points on it. I copied a<br>cylinder onto each of the points and then shifted the points in all these cylinders by a noise function just for fun.
Then I needed a point for where the robot would start in the scene and a point for where the robot should end up (the<br>goal). I set a 4 element vector attribute on the robot point and assigned it a quaternion orientation so I could keep<br>track of what direction the robot was pointing in. I used photogrammetry to 3D scan Slug’s wheeled base and copied that<br>model onto this point. The goal got an X.
There is some information about the robot that will be needed to know how to move it and to generate the paths in each<br>window. For that I attached a few more attributes to note down the radius of the wheels, their physical separation, and<br>their current rotational velocity.
That’s all that is needed to be ready to implement...