Self assembly and nanomachines:
Complexity, motion, and computational control

by Eric Drexler on 2010/01/28

A commenter on the previous post raised several important issues, and my reply grew into this post. The comment is here, and my reply follows:


@ Eniac — Thanks, you raise several important questions.

Regarding readiness to build extended, self assembling structures, yes, I think that the existing fabrication abilities (that is, the range of molecular structures that can be synthesized) are now more than adequate. The bottleneck is design software, including the development of rules that adequately (not perfectly) predict whether a given design satisfies a range of constraints. These include synthesis, stability, solubility, and sufficiently strong net binding interactions.

As for specifying face combinations that would result in unique binding, this becomes easier with increasing face size, and more difficult with the number of simultaneously exposed faces. Hierarchical assembly can address both of these, but the most practical schemes require the ability to convert reversible binding interactions into irreversible ones. One approach is to introduce covalent linkages after assembly of the intermediate blocks lower in the hierarchy of sizes. There are several ways to do this.

The problem of enabling motion between self-assembled components can be addressed at the level of interactions between assemblies that are held together by (for example) a combination of large-scale complementary shapes and non-contact colloidal binding interactions.

Flexible hinges in self-assembled structures are also practical, as shown by natural systems. Protein engineers have successfully designed structures that undergo conformational switching.


Downstream, there’s a continuum of assembly approaches that spans the range between free Brownian motion, constrained Brownian motion, and more macro-machine-like devices (discussed in “From Self-Assembly to Mechanosynthesis”, and Motors, Brownian Motors, and Brownian Mechanosynthesis).


You are right that the relative sizes of machines for manipulating matter and for manipulating information become similar (or reversed) at the nanoscale, relative to what we are familiar with in today’s macro-machine, micro-computer world. The resulting design constraints can be met by a various combinations of several techniques, including

  • Offloading computation to conventional computers that direct what would typically be large numbers of nanosystems (a good early solution).
  • The same single-computer / multiple machine approach with nanosystems for both operations.
  • Extensive use of hard automation, in which repetitive operations require no computation at all.

Regarding the last point above, this is how high-throughput manufacturing works today. I’ve discussed this in posts with videos of machines in action: “High-Throughput Nanomanufacturing: Small Parts” and “High-Throughput Nanomanufacturing: Assembly,” with a more quantitative discussion of “molecular mills” on E-drexler.com).


{ 18 comments… read them below or add one }

Eniac January 29, 2010 at 6:02 am UTC

Eric,

Thanks for addressing my concerns so elegantly.

I have a feeling, though, that mere blind control, which is implied by your three points above, will not be sufficient for automated systems. By “blind” , I mean control without individual corrective feedback loops, as is implied when using a single computer for multiple machines or no computer at all. On the macroscale, even a deceptively simple device like an electric motor usually has a dedicated controller (with microchips) that regulates its function. Each individual robot arm in an assembly line has a complex controller, and even the nut-and-bolt producing machines you showcase (I LOVE those videos, by the way) surely have, and probably need, individual controllers for each machine.

The problem may go even deeper. No process is absolutely perfect, and every once in a while things will go wrong. In the absence of repair people to fix things, any automated manufacturing system will need to be able to self-maintain. This in turn requires the machine to be able to store and process its own blueprints. In mathematical terms, it needs to be a von-Neumann machine. That requires a lot of information processing.

Now, we know that a von-Neumann machine is possible on the macroscale, as microchips these days easily have the ability to hold blueprints for all kinds of machinery, including, in the extreme, chip manufacturing plants that can manufacture those same microchips. But, given that those chips are already near the nano-scale, while chip plants tend to be quite large, how much can the whole thing be scaled down?

This, to me, leads to a simple strategic question: Would it not be better to first produce a working von-Neumann machine on the macro-scale (a clanking replicator), and then (perhaps) think about how it could be reduced to smaller scales? A working von-Neumann machine can already give us many of the revolutionary effects expected from molecular manufacturing, such as labor-free manufacturing and the consequent limitless supply of materials and energy. On the macroscale, it would be a whole lot easier to design and build, since we would not have to invent every single nut and bolt from scratch. We could simply copy from our already proven industrial processes. Plus, until it is fully working, we can still grab a spanner and screwdriver and help out here and there when self-maintenance fails. Lastly, but not least for public perception, it would be a lot less scary, as it can be clearly observed and have the plug pulled, or a wrench thrown into it, before it “takes over the world”.

I submit that information technology has only recently, within the last decade or so, reached the point where a clanking replicator can physically be built. The challenge is great, but much less so than that of achieving the same feat on the nano-scale. The benefits of either would be enormous. Why is everyone so focused on nanosystems? Can we really expect to build fully automated systems on the nano-scale before doing so on the macro-scale?

Vasilii Artyukhov January 29, 2010 at 7:04 pm UTC

As far as “hard automation” is concerned, there’s a brilliant example: life. Living cells manage to do tremendous lots of atomic precision assembly literally without a single bit of computation. Every component just functions according to the laws of physics, and it all somehow works. There’s no computer driving the stuff, it just happens the way it does, but it still looks like if there was one. Surely, designs that complex are probably not the best idea for a molecular manufacturing system, but it’s a nice demonstration of how far one can get without needing any computers at all.

Secondly, about self-maintenance. While it may be cheaper to introduce some failure-preventing feedback loops in macroscale machinery than to build new machines each time, this doesn’t necessarily have to hold in the microscopic realm! In fact, what you’re making is a perfetly good point: complex control circuitry on nanoscale would most probably be a bad solution – OK, let’s not go that way, then! Let’s make cheap replaceable designs. Again, look at living cells: they don’t repair damaged proteins, these just get recycled. And we do know that life is “aware” of the possibility to repair molecules: it does so with DNA. So that’s a hint that recycling might probably be more efficient than complex corrective feedback loops.

Chris Phoenix January 29, 2010 at 9:01 pm UTC

Vasilii, I don’t think it’s fair to say that cells do no computation. There are all sorts of non-linear feedback systems that do computation. There’s also, as you point out, a lot of intricate near-steady-state recycling. And there are various error correcting mechanisms at various stages, some of them rather more sophisticated than I’d want to try to design into a bolt-cutting machine.

The traditional engineered-molecular-manufacturing answer to Eniac’s question is that the error rates of mechanosynthetic operations can be made quite low – low enough that even a relatively large nanosystem can process many times its own mass before it breaks. In early mechanosynthetic systems, which may be more error-prone, it may be necessary (and possible) to do external error sensing, and have some sort of “reset” or “dump and start over” that gets triggered when the machine jams.

Here are some off-the-cuff guesstimates: A modern computer, connected electrically to a nanomachine, could sense and control 10,000 operations per second – limited mainly by speed of actuators: I think sensing could go much faster. Nanomachines could be built in parallel, for example self-assembled to a cm^2 lithographed substrate. If each machine was 500 nm on a side – one to four orders of magnitude bigger than anything that’s been built so far, depending how you count – then you could fit millions of them into a square centimeter. At that point, you’d be asking computers to control billions of operations per second – which is actually quite doable. And that’s trillions of operations per hour.

So I don’t think sensing and control will be a problem for quite a while. By the time we’re building trillion-component machines, we’ll be able to build nanocomputers into the machines, spreading the workload – and we’ll know a lot more about how to make the machines reliable.

We would not, of course, design a trillion different components. We would design 100 components and combine them, then design 100 combinations, and so on for six levels. This is similar to how computers are designed today: a laptop playing a DVD does something like a millimole of transistor operations!

I hope Dr. Drexler will correct and perhaps expand on this comment…

Chris

Eniac January 30, 2010 at 4:12 am UTC

Life is a somewhat different animal from the automated “hard” machinery that most envision for productive nanosystems. In my view, there are two critical characteristics of life: 1) It relies almost exclusively on stochastic self-assembly for growth and maintenance, and 2) it relies heavily on diffusion (aka Brownian motion) for transport of parts and materials.

As Vasilii points out, parts need not be fixed, just rebuilt and replaced. But, replacement means you have to get it from where it is made to where it belongs. So, you have to move it and know where to put it. The above two characteristics of life make many things a lot easier. Life moves parts by diffusion, and knows where to put them by surface pattern matching. A machine would most naturally use computer controlled universal manipulators to move parts and a blueprint stored in a memory system to know where exactly to place them. Thus the need for computers much more more complex than the “paper-tape-reader” system (aka DNA) life uses.

Life does computation implicitly, by making clever use of physical and chemical interactions at the molecular level. A machine works differently. Who needs a machine then, you say? Well, I would submit that if we wanted a system like life, we can stop searching. All funds now spent on nanotechnology should go to bioengineering, instead. We have been producing food, building materials, and transportation devices using this type of nanotechnology since ancient times, and modern biotechnology has brought much and will bring more astonishing progress in the area.

However, I doubt that we will ever be able to “grow” cars, airplanes, rockets, or nuclear power plants using this method. We have found it useful to circumvent life and build machines ourselves, from metal, using tools, and their physical power has far outpaced that of the ancient bionanotechnology. Machines are best built by machines, so we need fully-automated productive machines, any scale will do. The macro-scale is easier, which is why it should get priority. In reality, though, it doesn’t, and I am missing the reason for that.

Eniac January 30, 2010 at 4:40 am UTC

Chris, I am willing to accept that the error rates can be made low, perhaps even negligibly low. However, even if parts never have to be replaced for maintenance, they have to be put in place at least once, upon the machine’s construction. I believe that presents the exact same problems as self-maintenance, and thus a low error rate does not solve them at all. The root of the problem is that there are no builders, so the machine will have to build itself, which implies knowing itself, which implies processing information.

Now, I am not saying this is not possible on the nanoscale, just that it requires an unprecedented solution that we have few ideas how to develop, and which is not needed when building on a large enough scale so we can use off-the-shelf microchips and nuts and bolts from the hardware store.

Chris Phoenix January 31, 2010 at 8:27 am UTC

Eniac,

There are at least two reasons to prefer nanoscale to micro- or macroscale fabrication machinery. One is atomic precision, which you only get at the nanoscale. Chemistry is digital: get it approximately right, and it snaps into place all by itself. (This costs energy, so you’re not beating entropy for free.) Another reason to prefer the nanoscale is scaling laws: faster operating frequency means that a factory will take far less time to process its own mass in product.

Life uses diffusion, yes, but also uses active transport. Even single eukaryotic cells move molecules around in containers dragged along microtubules by molecular motors.

A machine constructing another machine does not have to “know” it in any complicated sense. Simply perform a sequence of operations, with appropriate conditional branching to deal with error conditions, and you get the machine. Yes, some nanoscale computation will probably be required – but perhaps not even a full CPU – and in any case, computation hardware can be built using the same type of mechanical devices that might be used to do the fabrication.

Eniac February 1, 2010 at 8:00 am UTC

Chris,

Complicated or not, in a very fundamental sense a self-replicating machine does in fact need to know itself. It needs instructions for the fabrication of every one of its parts. It needs instructions for how to get the part to where it belongs, and assemble it with the other parts. Whether these instructions are in the form of a list of process steps or in a more abstract form such as blueprints is a matter of design choice.

Either way, the instructions must be stored and processed. How much information is needed for a clanking replicator? My guess is as good as anyone else’s, but given the large number of parts and even larger number of process steps needed, mine would be in the high mega- to low gigabyte range. That is why I think self-replicating machines have just very recently become feasible. Would a nanosystem somehow be simpler than a macroscale one? I don’t see how.

Storing the instructions is only the beginning. They must be physically executed. At least for assembly, some sort of a universal manipulator (i.e. robot arm) will be needed. A seemingly trivial step like “attach the hinge to the beam using three #2 nuts and bolts” (or a molecular equivalent) breaks down into a complicated series of actuator movements for the arm to perform all the motions needed to complete the step. There is no way this could be done without CPUs, in my opinion.

Given this deep hierarchy of process steps, it is likely that to fit into reasonable memory space, the “genetic” instructions will have to be be on a fairly abstract level, and that the fine details will be generated by general algorithms. For example, the primary process description might say “bring part X to workstation Y and mount it in the starting position for process Z”. The “bring” and “mount” parts will be further expanded on in lower-level subroutines that are universal in the sense that they can be used for many different parts, workstations, and processes.

This requires software with a large number of layers, from logistics planning down to motor control. Perhaps I have the wrong idea about it, but I cannot even begin to think of a self-replicating machine that does not require such software, especially a hard, mechanical one where diffusion and spontaneous self-assembly are not an option.

It is a tough problem to solve, but it is many orders of magnitude more difficult on the nanoscale, because every physical process, even the nuts and bolts, has to be designed from scratch. I doubt that atomic precision and a faster replication rate, useful as they are, can make up for that.

For example, a starter project for a clanking replicator would be to design a robot arm that is capable of mounting and unmounting a copy of itself on a scaffolding. Software can then be written for robot arms to move around in the scaffolding, by unmounting and remounting each other to different positions. Add software to attach more scaffolding at the edges, and you have a self replicating system, right there. Feed it more robot arms and scaffolding parts, and it can grow. Program it to split in the middle, and you have offspring. Now you can start adding software to assemble the robot arms from smaller pieces, and pretty soon you have a universal fabricator going that requires only materials bought at the local hardware store. Note the extensive use of existing materials and methods. You could not do any of this on the nanoscale anytime soon.

Eniac February 1, 2010 at 8:16 am UTC

I apologize for all the arguing and rambling. I understand the promise of nanotechnology and think it needs to be pursued. However, I also feel that we may be missing a tremendous opportunity to get many of the benefits, much, MUCH sooner using the clanking replicator approach, and I do not understand why nobody seems to notice. I must be missing something, and I would love to be set straight on this point, specifically.

Valkyrie Ice February 5, 2010 at 5:08 am UTC

@ Eniac

Actually, I see us taking that approch already with such projects as RepRap, and the continuing advances being made in object printing. K Eric and I have a bit of a difference in vision on this we discussed several posts ago. Between current electronic design firms outsourcing manufacturing, the ever shorter times between electronic “generations” and the ability to now print electronics on a wide variety of substrates, I see a considerable push towards universal assembler “printers” being used to produce a large majority of our most sophisticated products. With DARPA now wanting to develop a business model for most manufacturers based on that of the semi-conductor industry, there’s now even more pressure to develop on this direction.

Yes, a 3d object printer is not a Nanofactory. But it is a desktop manufacturing device that could be used to create an economy of abundance even before we have full nanofacture. We already have a printer for organs, electronics, 3d objects, and I’ve even seen a design for one that can “print” a house. It’s something I believe is going to become a dominant paradigm in the near future. We’ll always have high throughput machines for simple object making, and standard parts, but anything complex and subject to frequent re design is going to be printed.

Chris Phoenix February 5, 2010 at 4:50 pm UTC

Eniac,

I agree with you that a full nanoreplicator will need integrated nanocomputers.

In the early stages of nanoreplicator R&D, the computers can be external, just as they can for clanking replicators.

In the later stages of nanoreplicator development, it will be relatively easy to design and build nanocomputers.

The design of nanocomputers does not seem to pose any significant problem. The construction of nanocomputers will be quite repetitive – if you can build transistors and wires, you’re a large part of the way there.

I think a nanocomputer will turn out to be simpler than several other components of a nanoreplicator – and also will turn out to be simpler than a macro-replicator. Overall, I think a nanoreplicator – with computer – will be simpler to get working well than a macro-replicator.

We’ve been building digital computers for well over half a century… we haven’t built a single replicator yet (though some work with Lego comes reasonably close). Replicators need precision that is hard to get without precise building blocks, as in Lego or atoms. I think in the end, that will be a major factor in which kind of replicator gets built first. (And scaling laws will be decisive in which kind of replicator wins in the end.)

Chris

Eniac February 8, 2010 at 5:40 am UTC

Valkyrie: You are right about those 3D printers, they have a lot of potential. But one key to self-replication is assembly, and printers are no good for that, you will always need a manipulator. Given a manipulator, you can use something simpler than 3d printing for parts forming, such as metal casting (with casts carved from ceramic paste and fired), or sheet rolling, punching and bending.

Chris: You make good points, but you do not address what I think is the mother of all advantages for macro-systems: We can build them before they are ready to build themselves. And we can use well-known materials and methods. We currently have no way to build a nano-system, and the bootstrapping that will be necessary to even build the most primitive machines, never mind self-replicating, will be a far greater hurdle than mere self-replication, tricky as that is.

True, we have been building digital computers for well over half a century, but not with the capacity needed to hold and process the blueprints or construction instructions for a self-replicating machine. That became possible within the last decade, give or take a few years.

Chris Phoenix February 11, 2010 at 9:03 am UTC

Eniac,

The most primitive machines? How about this: A nanomachine that is programmed by DNA – you mix in different combinations of short strands. In response, it twists parts of itself into alignment, and templates the formation of any one of several DNA strands. And the machine itself is built out of DNA.

This machine, engineered by Ned Seeman, has existed for several years.

A design for a self-replicating nanomachine has been worked out in a fair amount of detail by Merkle and Freitas. It is pretty darn simple – about two hundred million atoms, most of them in simple wall structures. It does not have an onboard computer. An off-the-shelf mainframe computer circa 1970 could have held its blueprint and directed its operation. Certainly a desktop computer could have controlled it by 1990.

Have you actually thought in detail about the mechanics of mechanical self-replication in a domain where precision is easy to maintain? Until someone demonstrates specific flaws with the Merkle/Freitas design, I am taking it as representative of the complexity of nanoscale self-replication. It’s just not very difficult!

Pick-and-place of individual atoms (under automated control, with error correction) was achieved as long ago as 1994 (by Aono).

General appeals to the trickiness of solving practical problems are not going to convince me of anything. Show me the math. I claim a blueprint for a self-replicating nanosystem is well under a gigabyte. The IBM System 370, available in 1970, could store hundreds of megabytes. Show me your math.

Eniac February 12, 2010 at 4:27 pm UTC

Chris,

Thanks for that link. I had not previously seen that. I will look more closely at that design, but just looking at the description in KSRM has given me more questions than answers. I have a hard time imagining how the device would produce and extrude some of its own parts, particularly the diamond hull. That one certainly does not fit through the extrusion hole, so it must be assembled outside. In what environment? By what other machines? Hopefully I will find answers when I look up the publication. Is there one? Any reference beyond the KSRM book would be greatly appreciated, I could not find one right away in the on-line book or via Google.

Eniac February 12, 2010 at 5:34 pm UTC

Ah, the “replicating brick”. Explained here: http://www.zyvex.com/nanotech/nano4/merklePaper.html it appears to be the answer to the self-extrusion problem. That and the pressure actuated “broadcast” mechanism could work, I think. It would not be autonomously self-replicating, but self-replicating nevertheless. It would be challenging to get the transmission/actuation error rate down to where it belongs, but perhaps not impossible.

It would give you a soup of “billions and billions” of devices, which should be complex enough to cooperate to produce larger things, or self-organize into same.

Mmmh, however, there are 200,000,000 atoms to be placed. To move an atom from the I/O port to the workpiece will require hundreds, if not thousands of ratchet signals. If we use, say, a 40 kHz pressure transducer to generate those, it would take (optimistically assume 100 ratchets per atom placement) about a week per generation. Not so bad, really…

The transmission/actuation error rate would have to be well below 10^-10, though, assuming a single missed signal will lead to failure, which I think is fair.

I should really go read that Nanosystems book…

Eniac February 15, 2010 at 4:51 pm UTC

Has any work been done to investigate light as the source of energy and broadcast signal? Pressure is inherently noisy at the nanoscale, due to Brownian motion. Light is not. Pressure requires (comparably) huge volumes and parts, light can be transduced into mechanical work by something as small as a retinal chromophore. Pressure has only one useable variable, intensity, light has two: wavelength and intensity. Retinal can be tuned to different frequencies, as happens to give us color vision. Hybrid approaches are also possible, perhaps pressure for energy and light for control.

Perhaps even more promising could be nuclear or electron magnetic resonance. It permits extremely detailed control of spins at the atomic level, if only it could be made to have chemical/mechanical effects. I think it might be possible to do that using singlet/triplet conversions and associated radical reactions. Magnetic resonance can convert between singlet and triplet spin states of radicals, and the two have distinctly different reaction paths that could be used for control purposes, theoretically. The radical states can be created by light absorption, so we would have a hybrid optical/magnetic system: light for energy and magnetic resonance for control. The electron transfer chain in the photosynthetic reaction center is a good example of this kind of controlled radical reaction, albeit without external control.

It is quite likely, I think, that nanocomputers will use spin states for computation, because that requires much less energy than electronic excitations or even mechanical interactions. This, too, would make magnetic resonance a natural way of interaction between nano and macro systems.

Chris Phoenix February 16, 2010 at 10:01 pm UTC

Eniac,

First, let me congratulate you and thank you for stepping up with an idea that may be genuinely new: broadcast control via singlet/triplet conversions. I don’t know if it’ll work – I’ve written to a physicist who’s interested in nanotech – but it’s a great idea.

Now some details: as proposed in this section of KSRM, the signaling frequency is 10 MHz, over 200 times better than 40 kHz. On the other hand, 100 pulses seems a bit low to place an atom. The device floats in a 2 micron chamber – rather small, but makes the high frequency plausible.

…OK, according to the numbers buried in Appendix B, the device seems to require 1 million seconds – about 1 month – to replicate. That implies 200 atoms per second, or 50,000 pulses per atom.

Acoustic pressure can vary within any of several pressure bands, driving any of several pistons while leaving other differently-sprung pistons pinned at either end of their stroke. Thus, multiple dimensions of control.

Photon absorption is probabilistic, so you would need to spend several times the energy per photon pulse to make sure that the pulse was received. Acoustic and photonic noise thus get handled similarly.

Rather than building a soup of devices, it would be more efficient to build a double-long device, which could then be used to build a double-wide device… it’s not too many doublings till you attain a device large enough to be controlled and powered with direct physical links. This should be thought of as a bootstrapping stage, not a useful manufacturing system in itself.

I suspect that significantly faster devices will turn out to be possible in practice. For example, this device has rigid walls, which use most of its atoms. An inflated flexible-wall device, as Merkle originally proposed, would replicate much faster. It would have other problems that the present design aims to solve, but I don’t think those problems are actually very important for bootstrapping devices. Also, I suspect that they may have gone farther than they needed to in simplifying the control system.

Chris

Eniac February 18, 2010 at 4:08 pm UTC

This is fascinating stuff. I am still bothered, though, that for all the ingenuity we put into the design of these devices, there is currently no path to making them, nor is one obviously emerging in the near future. DNA origami are fine, but from there to something that could start putting atoms together is a long way.

There seem to be three distinct ways we can currently put atoms together: 1) old-fashioned synthetic chemistry, 2) programming organisms to make biopolymers, and 3) STM/AFM style methods of mechanosyntesis. Each of these is in the embryonic stages when it comes to atomically precise manufacturing, corresponding perhaps to chipping stone tools. No lathes, no drills, not even a screwdriver. The biological systems could be compared to animal husbandry. Useful, but a technological dead-end.

In contrast, if I wanted to roll up my sleeves and build a clanking replicator, I could go to a hobby/toy store, buy a few dozen R/C servos and Meccano kits and start putting together manipulators. Add some easily available controller boards and connect them to my PC. Next thing I know, I am sitting there losing hair over creating software to make the manipulators put parts together. Granted, that would not yet be a replicator, but it is still a long way from square one, where we are with nanosystems.

Eniac February 19, 2010 at 2:23 pm UTC

Acoustic pressure can vary within any of several pressure bands, driving any of several pistons while leaving other differently-sprung pistons pinned at either end of their stroke. Thus, multiple dimensions of control.

Yes, but with wavelength to vary you get an additional signal dimension, so if there are n bands in intensity and m bands in wavelength, you have m x n dimensions of control.

Photon absorption is probabilistic, so you would need to spend several times the energy per photon pulse to make sure that the pulse was received. Acoustic and photonic noise thus get handled similarly.

Good point, I hadn’t thought this through. Still, you’d be averaging over a (small) time interval only, not a volume, which should save space, at the very least. You get much more energy from photons than you could acoustically, I think, which could be good or bad, depending on how much you need.

{ 5 trackbacks }

Leave a Comment

Previous post:

Next post: