Inspiration

We wanted to build a robot, but we did not know what form to make.

So we built a robot with over 129 million distinct forms. It is composed of a chain of 17 identical cubes, each cut in half along its body diagonal, with one servo twisting the halves against each other. Three positions per joint means 3^7, or 129,140,163 possible configurations, which turned our project from "what should our robot do?" into: how do we look for the shapes that people can actually recognize?

What it does

Our chain folds from a straight line into recognizable shapes: hearts, letters, and more. Shapes are planned offline and verified in simulation before a servo turns, because on this machine a bad move is a collision, not a wrong answer.

The pipeline: enumerate everything the chain can physically reach, rank those poses for recognisability, search for a fold sequence that passes collision, table and torque checks, then replay it in MuJoCo with gravity and friction before it goes anywhere near hardware. On the robot, 17 Feetech STS3215 servos on one serial bus take the moves one at a time.

How we built it

Hardware:

  • Custom module CAD: an 80 mm cube split on its body diagonal, with 8 mm chamfers and a turned-down neck near the cut so a half can swing past its neighbour across a 2.2 mm gap.
  • A custom 4:1 planetary gearbox in every module, so one 120° hinge detent is 480° at the motor.
  • Feetech STS3215 bus servos driven through Waveshare bus-servo driver boards, all seventeen on one serial bus.
  • A 12 V, 40 A supply, sized for the current several servos pull when they move together.

Software:

  • Integers first: can the chain, with its fixed assembly roll, occupy exactly those cells in order? Most drawn shapes fail in ~25 ms.
  • Survivors get the expensive pass: search for a move order where every pose clears collisions, the table, and the servos' torque limit.

Linq integration

iMessage → offline intent model (~2 ms) → named path → executor. Executors are swappable: dry run, MuJoCo at real servo timing, or the live bus. The robot and simulator only replay certified paths; neither can touch the planner.

  • The Feetech SDK for control, wrapped in our own Python layer: bus scan, ID assignment, zeroing, keyboard teleoperation, and a path executor that moves one servo at a time with stall detection and torque released after every move.

Challenges we ran into

Hardware ate the hackathon

  • Assembly, wiring and servo bring-up took most of our hours, leaving little time to develop shapes on the real machine. We moved the shape work into MuJoCo instead, so folds were designed and verified in simulation while the robot was still being built.
  • Torque versus 3D-printed parts. Under high servo torque the printed chassis flexes, the planetary gears unmesh, and the joint skips. Shortening the chain from 27 modules to 17 cut the weight each joint has to lift and brought peak torques back inside what the parts can take.
  • Electrical complexity. Seventeen servos on one bus means a lot of wire and several driver boards. Run externally, that loom snags, limits how far joints can swing, and is easy to damage. We routed the whole harness through the inside of the chain, so the wiring is protected and the robot stays clean from the outside.
  • AI can't be trusted alone on a physical system. The planning stack is intricate, and code that looks correct can still drive two modules into the same space. We kept AI in the loop for the software but reviewed every path and every change before it reached the servos, because on this machine a bad line of code is a collision, not a stack trace. ##Accomplishments that we're proud of
  • Wire-safe folding. Real modules trail wires that must never be crushed. We can plan a fold that keeps a keep-out zone around the wired end clear of every module and of the table, at every instant, verified across several floor-friction worlds including ones the planner never saw.
  • A proof, not a sample. For a chosen fold we can certify that no corner passes through another at any angle of any swing, with the tightest real gap measured at 1.63 mm.
  • Faster folds, gentler servos. Re-ordering and re-timing a 16-move fold cut it from 44 s to 20 s while reducing time at the torque limit from 4.7 s to under 2 s, one servo moving at a time.

    What we learned

  • We learned about the complexity of operating in a 3D space where physics applies; we needed to be mindful about overhang and cantilevering, and torque limits on not only our actuators, but our also our chassis.

What's next for cubes

  • currently, our shapes are hardcoded sequences from a library. in the future, we would like to use higher fidelity simulators such as IssacSim to train concrete shape-forming policies
  • In the future, we would like to scale our bot to even more cubes, so that it can form more complex shapes.

Built With

  • openai
Share this project:

Updates

Submission history