Kinetic Loop

Built at Volvox Labs for Pixera's Basecamp event. Printed cubes travel a lap. 32 linear lifts, fired on a clock and with no sensors, raise each cube to the next chute, and it slides down to the next lift. At each end a UFACTORY 850 arm picks the cube up and places it at the start of the other side.

Would a timed, open-loop rig keep many cubes moving without jamming? The rig was not available yet, so I commissioned it in Isaac Sim first, then built the control that runs it.

The installation

The loop in simulation

The Rhino design file became a SimReady USD asset, each lift a prismatic joint. In Isaac Sim the lifts fire on the show's schedule, at the timing read frame by frame from a phone video of a real lift; each cube tips off the head by itself and slides on the real chute meshes. The arms' passes were planned in the shape of a hand-taught program, with NVIDIA cuRobo for any leg that does not clear the rig and Ruckig for the timing, and they carry the cube in the gripper.

Where cubes stop

Every one of the loop's 30 segments was run 256 times, each run with its own friction and its own release off the lift. Then the whole loop: 102 runs of 10 cubes from seeded starts, at the friction measured on the bench (0.276).

• Above a friction of 0.31, three shallow runs stall slow cubes. Below it, friction hardly matters.
• Three segments jam at any friction, and each points at a part to change: two pocket entries to chamfer, a low-friction tape run to extend by 25 cm.
• 45 of the 102 full runs had a cube stop for good within 8 minutes. Two places took over half of those, the cube resting in the same pose every time: a trap in the geometry, and the first thing to check on the rig.
• One fault came first: 17 of the CAD's 96 acrylic panels cut into a chute. With them colliding, 10 cubes collapsed to 7 % carried.

Running the rig

The show runs from a Pixera timeline. I built the control between it and the rig in TouchDesigner: it drives the 32 lift motors and both arms, and reports the rig's state back to Pixera.

A cue runs the lift schedule once: over 15 s every lift fires at its own second, so ten cues are one cube's whole lap. The network may say "go now"; it may not say "you may move". The gate that decides whether the rig can move stays on the rig's own machine, and a cue buys exactly one cycle: if the cues stop, the rig finishes the cycle and stops within 15 s, instead of leaving 32 actuators cycling in an empty room. Driving each lift from the timeline would have meant 320 cues a lap, none of which knows where the cube is.

On the real rig

The rig first ran on 10.21, and I compared it with what the sim predicted.

• Right: where cubes collect and queue, the lift's timing, the arms' reach, and the extra 30 mm of travel a stair needs. The lift heights set by hand on site fit the sim's travel on one straight line (r = 0.97).
• Wrong: the arms' bases stand about 11° off the CAD, one 14 cm nearer. Two taught points per arm solve for the real base to within 6 mm; an arm's base is a measurement, not a drawing.
• Wrong: the taught passes rise over the towers and take about 26 s, twice the plan, so the loop holds 5 cubes, not 10.