An attempt at modular robotics / software-reconfigurable 3D lattice.
I always thought that modular robotics where everything composed of robots are too inefficient; why does every part of the thing need to have its own actuators, uC, etc?
Scaffold, as the name suggests, separates the system into two:
- modular rail segments (straight, twist, turn)
- robots that traverses on the rail, capable of carrying & (dis)assembling rail segments one-by-one
… like human workers constructing scaffold. Then rail segments can be cheap & strong. That was the idea.
I was working on this project for about a year, lots of iterations.
In retrospect, the concept was good, but I was trapped in a few misguided design philosophies.
Rail Segments
I figured we need 3 minimum types of segments to access the entirety of 3D space.
They have the same unit length, and mating interface.
The first two are straightforward. The last is passive turn table
- A robot steps on it
- Stops at the center
- Use “aux” motor to rotate the center piece
- Exit
Mating interface
A single mating interface consists of
- M3 nut x1
- M3 capbolt x1 (captured in segment assembly)
After much research and trials, I figured bolts & nuts are the best interface.
Considered
- Low-melting point metal
- Electropermanent magnet
- Mechanical spring+latch mechanism
- …
They’re all unreliable, expensive to make, non-performant, etc.
Robots (“Workers”)
Each robot has
- Custom PCB w/ uC
- Wireless (Zigbee) connection to PC
- LiPo power circuit
- Actuators
- DC geared motor x1: to move on the rail rack
- DC geared motor x1: fasten/unfasten the mating bolt
- Servo motor x2:
- engage/disengage rail arm
- engage/disengage the bolt driver
- DC geared motor x1: “aux” motor
- to help in quick turn
- to control the passive turntable segment
- Sensors
- Optical/magnetic sensor: detect rail marker
The worker is dumb; it can receive only a few commands (“go forward to next marker”, “open arm”, etc.) and report back their battery status. All the rail assembly & control takes place in the central software.
What stalled the project?
tl;dr I put myself into too complex puzzle which I cannot solve.
To begin with, there’s an inherent tension in a self-reconfigurable system like this.
They surface like:
- 3D rail lattice structure limits the robot size in all 3 dimensions
- rail rigidity vs design difficulty
- if rail flexes too much, connection become unreliable
- if rail is very rigid, it can be
- too heavy to carry
- motion needs to be perfectly designed; no room for “it happens to work”. Even 0.1mm depth collision stalls the movement.
- requires complex linkages or more servos to avoid collisions perfectly & handle all the edge cases
- … list goes on …
For example, the introduction of the aux motor did make the “passive turntable” concept work. However:
- → the aux gear can collide with unwanted objects.
- → need to remove collidable parts from all the rail segments
- → suddenly: gripping force is not enough, rails become non-3d printable, optical marker is gone, …
Every fix is like this. A typical “fix” just moves the problem to another (often surprising) domain. The project was basically an endless whack-a-mole.
Bad design directions on my side was the nail in the coffin.
- Too much minimalism on worker, especially sensors and compute
- Actuator is more physically constrained, and COTS motor is already “good enough”
- On the other hand, we can pack much more sensors and compute in the same volume / mass / energy budget. The economic cost increase is also tiny.
- To make full use of rail/worker separation, rails should be dumber and workers should be smarter.
- Making almost everything out of same material (plastic) when volume constraint is paramount
- Using metal in critical parts (like gears, structural beam) makes a real difference of 10x ~ 100x.
- To utilize cheap metal COTS, unit length should be more like 100mm instead of 60mm.
- Control loop must be closed at many layers
- Every problem that system cannot auto-detect (& correct) will break the entire system
In retrospect, underlying theme is that I was fixated too much on “scalable” methods (simple PCB, 3D printable segments) which did not matter.
Learning: “smart” equivalence
We generally consider only computers, sensors, or complex algorithms as “smart”. Open-loop is dumb (and cheap), closed-loop is smart (and expensive).
One thing this project told me is it’s not that simple. “Smartness” can take many forms.
An autonomous self-configurable system like this needs to make many successful actions. All physical objects have errors. Then something needs to account for all the errors. That is smartness.
Let’s say we want to insert object A into object B, with some path constraints & within some tolerance. There’s no fundamental difference between:
- sensor + control algorithm
- complex high-precision mechanical cams & linkages
- well-designed guide geometry
- geometry + magnetic alignment
- …
All of them are doing “sensing + computation + action”. Something needs to absorb all the needs of the system; otherwise it falls on outside humans.
Appendix
Memo fragments during the project: https://scrapbox.io/scaffold/