| | Six simulated proteo RD modules. |
|
|
|
The main focus of this
project is to explore the issues in scaling up the number of distributed
robotics. When you have many (100's, 1,000's, 1,000,000's more?) small identical
limited-functionality robots, what new capabilities are enabled? What are the
issues in decentralized scalable computation and control, and what
design/fabrication issues need to be addressed? When scaling the numbers up we
would also like to scale the size down.
If you had a pile of little robot modules - perhaps ball shaped, sitting on
your desk, you could command them to form arbitrary shapes.
Of course more exotic applications can be thought of other than cups which
can't hold water... Some applications (depending on scale) include:
| • | arbitrary shaped tools as needed (e.g. hammer, screw driver etc)
| | • | 3D visualization in prototyping
| | • | 3D flow visualization
| | • | self optimizing airfoil shapes
| | • | self moving/adapting furniture
| | • | portable ladders, building materials etc. |
Another
example of morphing in the extreme (110k)
Module Design
We can restrict motion of the modules in several ways, to keep the design
manageable, while keeping many important capabilities. First:
| • | A module can only stop in a close-packed
position.
| | • | A module can only move from a close-packed position to one of his
neighboring positions along one degree of freedom. |
These constraints reduce the computational complexity. The dimensionality of forward and inverse kinematics scales with the number of modules in a chain. This way motions are reduced to a series of independent modules which move in a set of discrete one dimensional paths.
Second:
| • | A module can only carry itself.
| | • | Power is passed from one module to his neighbors from one location so
modules must remain in one connected component. |
These constraints make the physical implementation a little easier. The first
takes into account that actuation is limited. The second means that the modules
do not have to carry their own batteries (weight). Further, by explicitly planning for limited
actuation, the control and computation also become simpler. Note, that the
limited actuation constraint can be relaxed somewhat, allowing a finite number
of modules to be carried.
Finally:
| • | Modules can only communicate locally with their neighbors. |
This constraint removes a limit on the number of modules. Any kind of global
communications bus would require some sort of addressing scheme. The address
space would limit the number of modules. In addition, compartmentalizing modules
will tend to limit the damage that a failing module can impart.
| Sliding motions are not
desirable as friction becomes a major problem as the size of modules are
decreased. Rolling or rotations about small axles are preferable.
One way to implement this is to have rotations about the edges of a
polyhedron.
|
 |
 |
The Rhombic Dodecahedron
The rhombic dodecahedron is a three dimensional shape
(polyhedron) with 12 identical sides in the shape of a rhombus. |
It turns out that the rhombic dodecahedron shape has many interesting properties
that make it a good shape for a 3D module.
| • | It is space filling.
| | • | It is an isohedron.
| | • | The ratio of the diagonals of the rhombus is sqrt(2),
| | • | The triangles formed by the diagonals are sqrt(1) sqrt(2) sqrt(3).
| | • | It packs in
face-centered cubic.
| | • | All face-edge-face relationships are exactly 120 degrees. |
It is this last item that is most useful. What this means is that every rotation
about an edge by one module from one packed position to another packed position
is exactly 120. Packed cubes for instance does not have this property. Cubes
rotating about an edge may need to rotate 90 degrees or 180 degrees if rotating
over a corner.
One of the interesting problems is motion planning for modules of this shape.
Other rhombic dodecahedron links
|
