The Project

• How does agency first appear at the level of molecular chemistry? This question is inspired by the Evolution 2.0, $10M, Technology Prize Challenge  wherein this question appears. This project will not be an entry into that challenge, since the required solution must be in the form of a synthesizable chemical pathway. But the underlying question of agency is worth pursuing in its own right. 

• My first sense that the Evolution 2.0, Artificial Intelligence + Origin of Life, $10M Prize challenge was doable was when I ran across to the work of Natalia Ares, et al. on the subject of ultra-strong coupling in qubit systems.

• Qubits are chimeras of sorts; belonging to both the realms of quantum and classical physics at the same time. Thus, making them potentially useful as bridges between the worlds of quantum and classical physics.

• Is it possible to leverage this phenomenon of ultra-strong coupling to create the quantum gate equivalent of a Schmitt trigger? That is, a physical system that takes a quantum interaction as input with corresponding mechanical change in physical shape as output.

• If so, then a quantum gate Schmitt trigger could be used as an active element to construct a molecular version of a finite state machine. At which point, one could then show that the encoder and decoder elements required for the Evo 2.0 challenge would be, at least in principle, constructible.

Project Journal:

• 17Aug2025, Journal Entry 

Discussions:

• Agency as a physics question,

• Computation by construction,

• Agency is a symphony of choices over time,

• Computation as dance,

• Information as defined relative to agency.

Simulations:

• Classical systems,

• Quantum systems.

Theory:

• Ultra strong coupling in qubit systems.

Conclusions.

• TBD

17Aug2025, Journal Entry

• The challenge for the coming days is to start building a simulation in LTspice demonstrating how a Schmitt trigger, as the active element, can be used to fabricate a finite state machine. Since the realm of physical systems hinges on potentials and forces rather than flows, this suggests a MOSFET-based, voltage-driven, Schmitt trigger circuit rather than a BJT-based, current-driven, circuit.

• I have never seen a finite state machine assembled using Schmitt trigger circuitry as its active elements. So, this simulation will be an exploration into uncharted territory.

• In practice essentially, universally, all finite state machines are assembled using registers (flip-flops) to encode states. With additional combinational logic circuitry used to capture the state machine’s corresponding rule set. Stepping through accessible configurations being initiated by an external clock source.

• At the molecular level, there are no obvious way to instantiate bi-stable (flip-flops). Nor ways to assemble freestanding molecular arrangements corresponding to a companion system of combinational logic.

• Here the Schmidt trigger arrangement serendipitously gets us around the above challenge. Rather than combinational logic to couple the various states together, one can use instead the parametric coupling captured in the ratio of the resistor values R3, R7. See accompanying schematic.

• This is where things get really interesting. Suppose our Schmitt trigger based finite state machine is built using a combination of circuit elements and mechanical elements. Then that resistor ratio can be instantiated as a mechanical flexing of the state machines physical body itself.

• So, first step is to SPICE simulate a finite state machine using the Schmitt trigger as its active element. Then extend that SPICE simulation to include additional flexing mechanical elements.

RoboDog, First Steps

TBD. Posted as a placeholder for anyone arriving here to read about RoboDog project.

Notes in the Margins: “The Value Learning Problem”, Nate Soares, 2016

This post will initiate a different style of posting. The idea is to capture my thoughts as I’m reading through various technical papers; the kind of notes that you would write in the margins of a journal article or paper as you’re reading it. I need to emphasize that these kinds of notes mostly reference an article’s content, but can also take the form of loosely associated thoughts and questions triggered by some point made within the article.

• You will also notice from this post how scattered my thought process can be as I’m reading through technical papers like this. I’ve been accused of having an amazing power of association, given how far afield my mind will wander in the process of trying to understand the core ideas of what an author in a paper is trying to communicate.

This post is on a technical paper referenced by Robert Miles in one of his recent YouTube videos.

• “The Value Learning Problem”, Nate Soares, 2016.

• A lengthy list of specification gaming examples can be found here.

• The “Robert Miles” YouTube channel devoted to AI questions.

It is my typical reading style, when it comes to reading a journal paper like this, is to first skim over it multiple-times until I start to get a feel for the flow of the ideas the author(s) are attempting to communicate. Then, I start reading through it in detail. Until about the 20th or 30th time through, at which point I usually start to feel like I have some understanding of what the paper is trying to say. But in the case of this article, each new time I read through it, I became more confused. After the fourth time through, I found myself thinking, “What a word salad!”

• The first thing that came to mind as I was reading this paper was, I noticed how all of the examples given were hypothetical. But every AI system will have to be instantiated in some physical entity, at which point it is no longer a hypothetical system, and the physical limits that are built into it will preclude the very hypothetical situations that the paper relies upon to make its points.

Another way of saying this is that the hypothetical examples presume that AI systems have some level of omnipotence; that if the AI system proceeds to game its specifications, then there is no speedbump for that to happen. But in practice, the laws of physics will put hard boundaries on what an AI system is capable of doing, regardless of the nonintuitive solutions that might be possible given an unconstrained hypothetical situation to start with.

• A common thread in many of the AI dilemmas is the assumption that the AI system under consideration controls its own reward function. But this case occurs in human societies as well, and takes the form of a despot, monarch, tyrant. In fact, many government bureaucracies and regulatory agencies follow this pattern of being able to control politically their own reward functions. This phenomenon might also be related to psychological personality disorders like narcissistic, sociopathic, psychopathic. In the real world, though, members of society depend on each other to be part of their feedback loop. Or more generally, many of the hypothetical dilemmas proposed in this paper would go away if the AI entity itself did not have any control over its reward feedback loop.

• One objection to this point about an AI having to have a physical instantiation, is the possibility that an AI program can live in the Internet as an independent entity. Not tied to any specific piece of computational hardware, but rather infecting itself like a virus across some distributed system of processors. This is an interesting possibility to consider. It’s a trope that appears in many science-fiction films and novels. The best exploration of this possibility, that I’ve found, is in the anime series "Ghost in the Shell", where it takes the form of what it means to be a stand-alone complex. At first pass it appears that for an AI program to spread itself out across a distributed system of processors is a possibility that faces certain practical problems; problems that make it difficult if not impossible for such a situation to actually occur in practice

• I noticed that the hypothetical examples often begin with a machine-level misunderstanding of a problem stated in natural language format. But what if it’s possible to talk to an AI using a formal verbal language, rather than a natural language? For example, a programming language like Forth? If humans were constrained, when programming AI systems, to use a formal language rather than a natural language, would this preclude some of the hypothetical problems discussed in this paper?

• It comes to mind that many/most/all(?) of the hypothetical examples given would have been much better approached using expert systems rather than AI. What’s the point of trying to use AI to solve a problem, when an expert system would have been a much better approach to the task at hand?

• Question: Whatever happened to the concept of expert systems to begin with? It used to be a term in common usage, but as I think about it, I don’t recall seeing it used in publications anymore.

Imagine the task of designing a welding robot to work in a shipyard. Why spend time designing an AI system to teach itself to be able to generate quality welds, when one can simply go and talk to actual experienced welders? Often, it seems that AI is just a lazy programmer’ s excuse or way of avoiding having to work with experienced skilled labor to develop a proper expert system for the task at hand. After all, if a robot can teach itself to master a specific task, then that avoids all of the work necessary to interface, both personally and technically, with the people who already know how to do that task.

• Why ask an AI system to figure out what it has to do based on some kind of machine learning process, when it would have been easier to just program its basic tasks, by hand, to start with? Again, I question the usefulness of such a publication when the author did not first consider the option of tackling these problems using an expert systems approach. It strikes me that a paper like this would be much more useful if it chose as its hypothetical examples problems that cannot be solved better using expert systems.

• The usefulness of an AI system over an expert system is that the AI should theoretically be able to teach itself how to do something that there is no human expertise available to do. But this raises another question, what kind of hypothetical examples should the author of this paper have used?

• Then there is the fundamental moral question, why are we, in the first place, expecting AI to make decisions for us that carry with them a moral component? Shouldn’t we as humans be reserving for ourselves such decisions? Is the desire to make an AI system capable of driving a car, for example, at its core a desire to help your fellow man commute more safely and efficiently? Or is it, rather, a path of moral cowardice to offload the responsibility of being a safe and capable driver to some third-party entity?

• Every stable system requires negative feedback loops; and societies are no exception to this fact. Part of a society’s dynamic that enables these required negative feedback loops arises when the individuals forming the society hold each other accountable/responsible for the outcomes of the decisions they make. The more we offload our responsibility for making morally correct decisions to some nonhuman AI, the less we as individuals will need to interact with each other; a sure recipe for the collapse of a society.

• Another way to say this is that the author’s hypothetical examples envision AI systems that do not have to pay some kind of a “personal” price for any bad decisions they make. An AI system may decide that the best way to bring peace on earth is to kill all humans. But after doing that, how would the AI system maintain its physical self? It couldn’t, and it would die. The ability to make moral decisions is a property again of living systems only.

• Consider the observation that true AGI is a property of a living system. Any hypothetical example of true AGI has to include the constraints of self-organization, self-preservation and self-reproduction. And if these three constraints are included in all of the author’s hypothetical examples, would they still hold up as useful thought experiments?

• I wrote in a past blog about the difference between a CNC system and a robot. My observation then applies in many ways to the distinction between expert systems and AI today. The general pattern seems to be that AI refers to speculative possibilities, whereas expert systems encompasses doable projects. That is, once something in AI becomes doable in a computational, algorithmic, practical manner, then it ceases to be AI and becomes lumped in with expert systems.

• Another random thought was that many of these AI dilemmas are not actual problems to be found in practice, but rather take the form of archetypal stories; that is, parables.

• The rambling point here is that within the current state-of-the-art, machine learning is considered part of AI. But I’m beginning to form the opinion that machine learning should more properly be considered another aspect of expert systems.

The T2-Tile Project, Artificial Life Form Simulations, An Interesting Proposal

This post is in reference to a comment thread on the gitter.im/t2tile/hardware webpage.

This post will also be a work in progress. What I’m proposing within this post is a difficult assertion to make, and more importantly, to make clear. I expect as I get feedback, I will continue to edit this post until it seems that I’m getting my point across reliably.

It seemed that the forum’s discussion contained a thread of frustration with the lack of progress that A-Life simulations seem to be having. Simulations, as run, don’t seem to express the kind of spontaneous jumps to higher levels of complexity that one would’ve hoped to see. After decades of research in this area, the inability for such simulations to mimic what we see in Mother Nature has taken away any academic and research interest in further pursuit of these subjects. This is probably also the reason that there are so few people pursuing research in ISAAC’s: since they would have been the natural platforms to enable simulations to run in real time and on real hardware.

There is a sense that there is a puzzle piece missing. No one knows what that missing piece is so they wait for someone else to produce the answer. What I want to suggest is that people in the field already know what that missing piece is, and it’s called intelligent choice.

Unfortunately, the topic of intelligent choice has been twisted into an intelligence => design => designer argument which has been glommed onto by various religious groups who use this line of reasoning to justify their concepts of what God might be. This has turned the topic of intelligent choice into an academic, no-go, toxic wasteland. Anyone attempting to follow this line of thinking into their A-life research risks sinking into the tar pit of intelligent design => designer arguments; which would be a career-ending move.

But suppose there were a way to introduce intelligent choice into A-life simulations that would not only keep one from getting caught up in the intelligent design => designer tar pit, but also, at the same time, strike a fatal blow to those very arguments?

/******************/

It took about 2 billion years before the first eukaryote cells appeared; cells that are capable of forming multi-cellular lifeforms. Another billion years (roughly speaking) passed before the resultant composite lifeforms became rigid enough in their structure to leave a fossil record. Considering how long it took Mother Nature to make these simple evolutionary steps, it should not be surprising if our own numerical models might take “forever” as well.

But I think the problem goes deeper than this. If you look at the world of bacteria today, you will see the same forwards and backwards evolutionary progressions that you see in A-Life simulations. The process of evolution towards ever more complex lifeforms seems to correlate with the appearance of the first creatures that can move in a self-directed manner; to swim, rather than just float around with the sea currents like a jellyfish.

The better response to the lament about the progress of A-Life simulations would have been to note that, since simulations are not reproducing what we see in the natural world around us, then Mother Nature must be doing something that is not being captured in simulation. A suggestion for what that might be, as noted above, is the appearance of the ability to choose. Something a higher lifeform can do that an agent in a simulation can’t do, is to say to itself, “Screw this. I’m sick and tired of this game. I’m going to leave and go somewhere else.” Note, this choice can only be made for agents that have the ability/option to get up and move away.

This is where A-Life simulations will always stall out. They take place within a bounded arena, with no frontiers to go to and with agents having no ability to step outside the simulation. There is no reward within the simulation for an agent to make the kind of fundamental evolutionary step these simulations are trying to recreate in the first place.

Randomizing an agent’s behavior within a simulation only leads to the phenomenon of “drift to the mean.” Whatever spawns an agent’s evolutionary steps toward higher complexity can’t, therefore, be based on random choice alone. The attribute which needs to be added to A-Life simulations to finally allow for that spontaneous evolutionary jump to increasingly complex ordering is the option of intelligent choice.

Returning for a moment to contrast my approach to ISAAC design versus that of Dave Ackley is to note that the Atoms in my case carry their own programming with them, while the Atoms in the T2-Tile Project rely on an external set of pre-programmed routines, shared by all of the other atoms in common, and which are indexed by a lookup table that in turn points to a common program memory.

There is no way within the T2-Tile Project approach for a single Atom to spontaneously reprogram itself and go off in a new direction. The reason I’m taking this particular approach to ISAAC design, is that, by having each Atom contain all of its own programming, independent of all other atoms, would allow for individual mutations to occur. Subsequently, those mutations can be shared with other Atoms by a process akin to sexual reproduction.

/******************/

Now back to the topic at hand. The hint for me as to how to proceed with the quest of introducing intelligent choice into A-life simulations began with this simple paper, "What does Maxwell's demon want from life? When information becomes functional and physical.” Author: J. H. van Hateren.

Within the discipline of physics, Maxwell’s demon is the archetypal lifeform; that is, an intelligent free-willed agent that can not only observe the world around it, but also interact with it in a way that allows it to extract energy from its environment; energy which can then be used to do the useful work of sustaining that intelligent agent’s existence.

But can a Maxwell’s demon actually exist? The existence of such an agent, at first pass, seems to violate the second law of thermodynamics. There have been various attempts through history to explain the paradox of Maxwell’s Demon. Current thinking is that Landauer’s erasure principal seems to have finally offered a reasonable explanation. But as the paper above argues, Landauer’s principal is still not sufficient yet to resolve the Maxwell’s demon paradox.

It has become my opinion, after several decades of pondering this physics problem, that the source of the paradox for Maxwell’s demon begins with the fact that there is no derivation or explanation within the laws of physics to allow for the demon’s existence. And for this reason, the demon never gets folded into the physics of the experiment’s description to start with. And since it never shows up in the experiment’s construction, its existence always remains an outside element without resolution.

There is a way out of this paradox, and this is the humble proposal I want to put up for consideration.

The essential nature of Maxwell’s demon is one of intelligence and free will, but there is no place in physics for the concept of free will. No one can prove that free will is a property of intelligent life forms, nor can anyone prove that such is not the case. Faced with such a situation in mathematics, if a statement can neither be proven true nor false, then one is free to take it or reject it as an axiom and develop one’s mathematics from there.

The assertion I would like to make is that free will, as a property of intelligent agents, should simply be taken as an axiom within the laws of physics. Then we shall see what theoretically arises out of such an assertion.

Dear readers, please note, I have no intention or desire to become an apostle or apologist for some new way of thinking. All I want to do is propose a new idea as a subject of exploration.

So how does one embed the concept of free will into the laws of physics? First step is to strip the term free will of all its historical, philosophical, theological baggage and see what’s left at its core. That is, what needs to be added to the laws of physics that will allow for something like free will to arise from and be logically compatible with the already existing known laws of physics? Here is my humble proposal.

/******************/

What one needs to do is introduce a fifth law of thermodynamics, one which would state that something like “choice” exists, and which could then play the role of an anti-entropic force. This proposed fifth law would seem to be sufficient to allow for the breaking of strict determinism within the laws of physics. How this would work is the discussion that follows.

Start by taking a page from the field of mathematics: constructability is to mathematics what determinism is to physics. What broke the constraint of constructability in mathematics was the introduction of the Axiom of Choice. With the Axiom of Choice, you can now prove the existence of sets which are not constructible in any manner. Something that a mathematician will take for granted, but will seem foreign to a physicist, is the fact that the Axiom of Choice can’t tell you “how”; it only gives you “permission.”

It is been shown mathematically that the Axiom of Choice produces no contradictions with any of the preceding rules for set theory and math logic. It can be taken as true, after which one gets one logically consistent mathematics. Or it can be rejected, which then generates an alternate but still logically consistent mathematics.

In some ways, the Axiom of Choice is a lot like Euclid’s Parallel Postulate which can be taken as either true or false with no contradiction to any of the preceding geometric postulates. And then, how you take this Parallel Postulate, generates either Euclidian or Non-Euclidian geometries.

In a similar way of thinking, in order for intelligent choice to exist, determinism has to be broken within the laws of physics. So, what could be the equivalent in physics to the Axiom of Choice in mathematics?

What first needs to happen within the discipline of physics is we need some kind of rule that will allow us to replace the constraint “derivable-from” with the less restrictive constraint “compatible-with.” In some sense, this is what Stephen Wolfram has suggested in his book “A New Kind of Science.”

It would seem at first pass that the introduction of intelligent choice into the laws of thermodynamics would produce an immediate contradiction to the second law. But it turns out that such would not be the case. The second law is an outside observer’s black-box view of a thermodynamic system. It can only make global statements about a thermodynamic system. It makes no specific statements about what can, or cannot, go on internally within such a system.

By contrast, this proposed new fifth law makes only local statements about what can happen within a thermodynamic system. As long as its application does not change the outside view of the system, then the second law is not violated. A useful analogy might be Heisenberg’s uncertainty principle, which allows for the violation of energy conservation; but a violation which is allowed only locally in space-time.

If one assumes such a fifth law of thermodynamics, then one can simply introduce into an A-life simulation, without needing to justify its presence on any physical grounds, an intelligent choice function, and do so without fear of the specter of Maxwell’s demon showing up and calling into question your results. Remembering, like the Axiom of Choice, this fifth law doesn’t tell you how to create an intelligent agent within your simulation, it only gives you permission to do so.

Again, what this fifth law effectively does in practice is that it frees one from having first to demonstrate a strict derivability from existing laws of physics before one introduces a particular intelligent choice function into a A-Life simulation. All one needs to demonstrate is that the resultant outcomes are merely consistent with the laws of physics. Or to say it another way, this fifth law breaks the equivalence between “not-provable-from” and “in-contradiction-to” when discussing topics in physics in general.

/******************/

One could waste a lifetime debating the philosophical merits of such a proposal, so I won’t. But just say, for the sake of discussion, that this proposal is taken as a given. What happens then, if this extra faculty of choice, along with the addition of some kind of frontier region, outside of the simulation’s boundaries, that an agent can remove itself to, is folded in an A-Life’s simulation programming. Would it finally start to reflect the behavior of real evolutionary systems that you’re hoping to find?

John Deere Tractors and the Right-to-Repair

First, for anyone within the robotics community unfamiliar with this controversy, before reading further, they should enter this section’s title into their favorite search engine and start reading through the information found there. While at this point in time, this Right-to-Repair controversy is only affecting farmers who own John Deere equipment, it is only going to become more acute as robots leave the engineering lab and factory floor and move out into the field.

As a note, while my blog writing focuses on agricultural robotics, and I will be using the term farmer exclusively, the issues discussed here will be common to any/all field-deployed robots, whether that field of operation be farming, logging, mining and/or construction.

Sophisticated electronic systems are now ubiquitous in the cabs of modern farm equipment. That by itself is not the problem. The problem is that equipment manufacturers like John Deere have increasingly integrated the mechanical functioning of their machines with the internal control electronics. Now even a minor mechanical repair requires a factory technician to come out and reset the on-board computer system. For the farmer this turns a two hour and $50 repair job into one dragging out a day or two and costing another $500 to $1000 extra. You can appreciate why the farmers are upset about this situation. And it gets worse. The penalty for not calling in the factory technician to properly reset electronics is that the farm equipment won’t run; effectively John Deere is holding a farmer’s tractor hostage.

What we are seeing played out with the Right-to-Repair controversy is a clash of two incompatible economic models, along with the clash of two different design philosophies. Specifically:

• Every single engineer I’ve encountered and interacted with, who was also involved with robotics, sees a robot as primarily a computational system with mechanical subsystems tacked on to the periphery. But for the farmer, a robot is a mechanical system that has an embedded computer system for its operation.

• Unfortunately, in the high-tech world, engineers see a robot as a design challenge. The more complex the solutions, the more job satisfaction your typical engineer will get. While for the farmer, simplicity and reliability in construction, operation and maintenance is what is of paramount importance.

• For equipment manufacturers, economically speaking, it is to their advantage if they can turn an equipment purchase into an ongoing income stream. This is usually accomplished by some form of service contract servitude.

• For the farmer, the economic situation is the exact contradiction of this. The farmer needs to be as free as possible from any corporate constraints so that they can make proper use of their equipment; use that depends unforgivingly on the ever-changing and unpredictable day-to-day conditions that mother nature and the economy throw at them. For the farmer, with the loss of control over their own equipment, they effectively have lost control over their own farming operation. Less reliance on the original equipment manufacturer and the greater ability to rely on their own resources is the economic model the farmer wants and needs.

/******************/

Farming is an endeavor which, in exchange for uncertain weather and market conditions, the offerings in return are nothing but headaches, along with very low, to sometimes losing, profit margins. The only way for a farmer to function in any kind of economically sustainable fashion is to maintain very tight control over expenses and operations. An engineer in Silicon Valley might not think about it this way, but for the farmer, this Right-to-Repair issue becomes yet another uncontrolled factor, like the weather, that can make or break them economically.

I find myself almost taking it personal sometimes when I encounter the casualness which many within the engineering community approach this problem of not only Right-to-Repair, but most importantly Ability-to-Repair; an ability that for a farmer can be the difference between keeping the family farming operation running and having to sell out to one of the bigger corporate farms.

The way the robotics industry functions now, what is best economically for the engineering designers and manufacturers creating and producing the next generation of field-deployed robots, has become incompatible with the economic realities of what farmers, loggers, miners and construction site foreman need.

There is no solution to this conflict that will make everyone happy. So, each member of the community of engineers devoted to robot design will have to individually make their decision as to which side of this conflict they want to stand on. Will they put their creative effort into making a product that works for the farmer? Or will they devote their creative energies to product design that enables a high-tech corporate domination of the field-deployed robot market?

/******************/

A classic historical analogy was the original IBM PC against Apple and others in the marketplace. While its competitors maintained closed and proprietary designs, the IBM PC’s architecture was open; as such, it provided a universal platform that third-party developers could build their own applications upon. And so, it became the go-to platform for anyone wanting to use a PC as an intelligent controller for whatever their product idea might be. As consumer demand went up, competition in the PC market kicked into gear. Because the IBM PC’s architecture was open, it was easy for third parties to copy it. As the market became big enough, manufacturing went offshore; prices dropped, ultimately forcing IBM out of the PC marketplace.

In the end, what was best for the consumer turned out to be a losing proposition for IBM. And although IBM ultimately lost in the marketplace, the open architecture it had introduced is the reason home and desktop PCs are so ubiquitous today.

This historical outcome will repeat again for field-deployed robots, provided that some manufacturer makes the bold creative step to give the world a non-proprietary, open and modular architecture that would be simple in construction, reliable in use, and easily manufactured, serviced and repaired. But most importantly, an open architecture that would allow third party, aftermarket additions, modifications and enhancements to be created; thus, becoming a channel for the creative efforts of a much larger field of entrepreneurs. Whichever equipment manufacturer becomes the first to do this, might ultimately lose in the marketplace, but their creative efforts will survive into posterity

/******************/

(*) As a hardware designer, it’s impossible for me to upgrade a part value or an IC specification remotely over the Internet. So as a hardware designer, when my creative work is done, it’s done. The only way to change or upgrade my work is via a product-wide recall costing my corporate employer a major financial hit. But software lends itself to remote upgrades. And because it’s easy to do, the temptation to do so becomes overwhelming. Therefore, software development often devolves from a creative effort to merely a rent-seeking endeavor, turning product purchasers into ongoing income streams via the offer of future software upgrades with the co-commitment mechanism of service contract servitude.

One of the occupational fallouts that will come with a modular form of construction will be that software developers will now be in the same boat that hardware developers currently are; that is, they will have to get it right the first time since, once their coding leaves the factory, they can’t access it again to fix any of the mistakes they made. If the reader senses a bit of Schadenfreude in this attitude, well, they would be correct.

Widjets is Running Again, So what’s next?

For the last three months, life’s complications and health concerns have kept me from getting any writing done. My hope was to be able to post at least once a week. I’ll be trying better as time goes forward.

But despite not getting any writing done, progress on the hardware side has gone forward satisfactorily. All of my old Widjets hardware has been moved from boxes on the shelf and is up and running. I’ve installed new versions of LabVIEW and my Verilog EDA tools.

I’ve produced two new boards for the project; a 4-port hub and an 8-port hub as expansions for my WSB serial bus. I was also able to rework an old stepper motor drive card using the new programming format, so I now have a collection of dual H-bridge driver cards.

The original control board hardware I’m working with dates back to 2009 and used Lattice-Semi XP FPGA parts. These are now obsolete and no longer obtainable, so I also updated the control box design targeting a current FPGA part, generated new revised schematics, and even completed the artwork for a new PCB.

Everything was ready to start building upon, but what’s the next direction to go?

Ultimately the purpose of building any further hardware was for it to act as a showcase for what I’ve come to call the Widjets-concept or the wordier Widjets-design-paradigm; that is, a computational architecture based on a system of distributed processing, built up from task-specific preprogrammed modules, connected together by a common serial interface, and programmable in a verbal manner by users not necessarily computer literate.

As a way to showcase this alternate paradigm for robot construction, I thought that reproducing the functionality of the robots used in the NASA Swarmathon competition would be the best way to go about this. But as I went through the details of such a design effort, I realized I was not going to have the financial resources to finish. Further, I can’t see any way, within my financial resources, that I will be able to build any kind of robot, which would be sufficiently complicated in its functionality, to take advantage of this alternate paradigm of distributed processing. At this point, further progress seems to have come to an end; which has forced me to think about what exactly I’m trying to do with this Widjets-concept.

At this point, I must confess, my ultimate goal is to write a science fiction story. And the underlying motivation for exploring the possibility of my proposed alternate robot design paradigm was to prove to myself that it would actually work in practice.

Though I will not be able to finish the actual building of a system of robots based on this concept, I’ve done enough prototype development so far that I am entirely confident that such a system would work in practice. The next blog post will be exploring how this works out.

But for now, it appears that further work on the Widjets hardware has come to its end. I’m not saying that I will never get back to it again – just not until I win the lottery, or something, and have the financial resources to do so

The Economic Reality of Agricultural Robotics and the Return of Widjets, Part 4 of 4

Which finally brings us to the topic of Widjets; here are the background references

• WIDJETS and LEGO-LOGO
• My Home Brew Robotics Project
• My Home Brew Robotics Project, Embedded Controller Based Peripheral Devices

Widjets first started out in the mid-1990s is a concept to compete with the STEM educational kit LEGO-LOGO. But that dream came to a slow and financially draining end. My wife and I had to learn the hard way that no matter how new and clever your idea might be, or how much better you think your concept is than any currently existing product on the market, if your idea doesn’t fit into the economic realities of the market you want to sell to, then it’s not going anywhere.

I posted about this chapter of my life here: • WIDJETS, A Postmortem.

In short, we did not understand how much the STEM grant process dictated which products would be considered eligible for purchase by schools and institutions, and which would not. And that, unless we made the extra and very costly effort to get into the STEM grant pipeline, our Widjets concept had no chance of commercial success. It’s this experience with my own startup venture that has left me sensitive on this subject; that is, the absolute necessity of paying attention to the question of its economic viability before trying to turn an idea into a business venture.

To make a long story short, when our personal financial resources for such a venture ran out, the Widjets project ceased and went into boxes on the shelf. The Widjets concept seemed an obvious one to me and therefore I always expected to see it rediscovered and developed independently by someone else who had the financial resources to play the STEM grant game. But the idea has never shown up commercially; no one seems to have landed on it. And because I’ve never seen anyone else develop it, I’ve never had a good excuse to just finally let it go. So, over the following years the project has gone on and off the shelf as time and life would permit me the opportunities to work on it.

But going back to 1995, almost as soon as I started working on Widjets, it became apparent that I had created a system of distributed intelligence, inter-connected by a common star-tiered serial interface, that could also be programmed by users not necessarily possessing a technical background. This was all of the three attributes a field-deployed robot would have to possess before it ever has a chance at commercial viability

The first two attributes listed above are hardware aspects and are solved problems as far as the Widjets design goes. But the third piece of the puzzle, the requirement that, however one ends up programming a field-deployed robot, it must be in a way that is accessible to those already working in the farming industry. That is, by a system of verbal programming commands.

So, starting with the existing Widjets component PCB’s as a development platform, the challenge for the next few months will be to see if this type of architecture will lend itself to some kind of verbal programming modality.

So here at the start of 2020, I’m retired, and I finally have the time to turn Widjets into a proper robot programming system

The Economic Reality of Agricultural Robotics and the Return of Widjets, Part 3 of 4

Over the course of my first year of blogging, I covered a number of the design issues that have to be addressed before any kind of useful ag-robot can be offered to the farming community.

Regarding issues of mechanical design, all but one of the challenges I could foresee were either solved or solvable engineering problems. The one remaining/missing piece of the puzzle, as far as the mechanical side of deployable robotics is concerned, is the invention/discovery of an electro-mechanical equivalent to biological muscle. Once this last hurdle is crossed, the world of field-deployable robotics will expand through the farming industry exponentially. The only concern, then, is: What will society do with the resultant unemployed semiskilled work force?

The programming side of field-deployed robotics is a different issue. Whatever methods are used to program field-deployed robots in the future must be something that the existing workforce already has the competency to do.

So just exactly what does it mean to program a field-deployed robot? And, what exactly is the competency level of the individuals you can already find working in the farm industry?

/***********************/

Regarding the question of workforce competency, when it comes to working with machinery, working with your hands, and getting dirty in the process, I’m afraid that many within the academic world have a prejudice against such individuals. I’ve found there is an ever-present attitude that, unless you have college degrees and are professionally successful, you can’t possibly be intelligent.

Thankfully, life gave me a wonderful lesson in this regard. Over the years I attended Humboldt State University earning my degrees in physics and math, I supported myself working in the woods as a logger. I was blessed with the good fortune to work with many individuals (equipment operators, mechanics, and rigging men) who, if you paid attention to the complexity of the tasks they performed, and their ability to think through solutions, were most certainly above average in intelligence and mechanical ability.

Here’s a nice video showing the rebuilding of the D8 Caterpillar tractor. Pay attention to the complexity of the tasks required for rebuilding such a machine. Hopefully this will give a good appreciation for the technical expertise that can be found within our modern skilled industrial workforce, “CAT D8R Dozer: Full Machine Rebuild”.

To suggest that the existing workforce, that can already be found within the farming industry, is incapable of dealing with the complexities of robot programming is a faulty assumption. The only challenge for the academic engineering community is to create a programming modality that can be adapted to the skill set already existing there.

/***********************/

Now, in order to answer the question, “What does it mean to program a field-deployed robot?” let’s start by asking the question, “How does one currently “program” a crew of field workers?” Field supervisors do not occupy their time creating lists of written instructions for each fieldworker to read and execute. Crew supervisors can assume that individual workers under their direction are already skilled at their assigned tasks. So, as supervisors, they only need to act as task managers, giving instructions verbally in a natural language setting.

This last observation suggests what the proper model for field-deployed robot programming should be. Rather than the compiled source code model of programming you find in languages such as C/C++, Java, Python, and etc., it should be more reminiscent of a scripting language expressed in verbal form.

Robots should arrive for work already programmed with the basic functionality they will need in order to complete the tasks expected of them. Additionally, their internal programming needs to include a learning mode that allows them to adjust their preloaded code to the ever-changing working conditions of the moment. Given this alternate paradigm for programming, the field supervisor “programmer” just continues to do their job exactly as they always have; giving verbal instructions to the deployed worker ag-bots.

Honestly, how can anyone within the engineering community imagine that ag-robot programming should/could be done by someone sitting with a laptop computer, out in the rain and mud or in the hot sun and dust, typing in code before downloading it to some robot? But over the years that I’ve tried to keep up with developments in agricultural robotics, this seems to be an implicit, but unrecognized, assumption underlying a lot of the ideas I see put forth.

/***********************/

The act of programming is really just the act of expressing a list of instructions that will delineate the operation of some intelligent processing system. Our typical association of programming with writing source code in a formal language format stems from the fact that the underlying processing system in these cases are digital micro-processors; with the objects manipulated being bits, bytes, and words of information. In the case of human field workers, though, the underlying processing entity is a person; while the objects being manipulated are tasks to be performed.

The “programming” design challenge, then, is to re-create in field-deployed robots, the same programming modalities that are currently employed with their human counterparts. Taking up this challenge will be the subject of part 4 in this series of posts.

The Economic Reality of Agricultural Robotics and the Return of Widjets, Part 2 of 4

The first post of this series begins to reveal, in backdrop, the interplay between several different design constraints and design paradigms for robots.

• The first of these interplays is between the design requirements for stationary floor-mounted robots versus those for mobile field-deployed robots. In the case of a stationary floor-mounted robot, the work comes to the robot, and the work environment is known; the tasks are repeatable and predictable. For a field-deployed robot, the robot needs to travel to the work, and the work environment is neither known, nor repeatable, nor predictable. These two qualitatively different work environments force qualitatively different economic expectations onto the resulting robot’s design. While this blog focuses on agricultural robots, it should be noted that what applies to ag-robots will apply equally to any field-deployed robot, whether the industry is farming, logging, mining, and/or construction.

• The second interplay is the perennial conflict that faces every design engineer between what can be built versus what should be built.

If your interest, dear reader, is in designing robots using existing technologies, then you can stop here.

Otherwise, the assertion being made in this post, is that the only way to make any real progress in agricultural robotics is first, stop trying to build more robots! Focus on the hardware side of ag-robot design and let the hardware tell you what it wants to be. Next, define what actuator technologies will need to be developed before such ag-robot hardware can be built. Finally, the engineering design community needs to focus some of its creative energy on developing those new technologies. For example, there is no electro-mechanical equivalent to biological muscle. If such an actuator already existed, our dream ag-robot would have been a reality years ago.

/***********************/

Starting with my first post on agricultural robotics back in 2011 and following on for the rest of that year’s posts, I tried to address in detail many of the design issues that would have to be tackled before one can make a useful robot replacement for a typical farmworker: “Agricultural Robotics, Design Challenges”.

In the process I coined a few “WID Rules” for robot design: “WID Rules for Robotics”.

• WID Rule: It makes no economic sense to replace a worker with a robot if that robot's total cost-of-ownership is not competitive with the total cost-of-labor for the worker it is going to replace.

• Corollary 1: When designing a robot, it is the worker you want to duplicate, not the worker’s task.

• Corollary 2: Regarding operation, service and maintenance, follow the K.I.S.S. principle (“Keep it simple, stupid!”), since the workers who will be responsible for these jobs in the future will be the same people that now operate, service and maintain the existing farm equipment.

The WID Rule implies that the only way robots will ever leave the engineering lab and move out to the farm field will be when they can finally compete economically with their minimum wage human counterparts. This basic cost of employment puts a severe cost constraint on any AI/robotic system intended for field deployment.

Corollary 1 implies that, for a robot to be a worthwhile investment for the farmer, it must be multipurpose. A farm tractor can be repurposed by just swapping out attachments; something that can be done in under an hour. While human labor, for example, can go straight from picking cauliflower to moving irrigation pipe without any pause for repurposing. Any piece of robotic equipment that cannot be repurposed, in short order, and in similar fashions, will always be a non-starter for any farmer.

Finally, Corollary 2 implies that a field-deployed robot needs to be modular. Its mechanical construction needs to be based on interchangeable subassemblies. And its computational architecture should come in the form of pre-programmed bricks or modules connected together using a single shared serial interface to form a system of distributed intelligence. This form of construction allows for easy manufacture, easy maintenance, and easy service. Programming, in any traditional sense, is not part of this paradigm. If one wants to change some functionality in a robot, just swap in a different module. The upside of this kind of construction is that this is the level of service, maintenance, and rebuild competency that already exists within the workforce currently employed in the industries of farming, construction, logging, and mining.

/***********************/

As a “worked example” of the point I’m trying to make: I touched again on the economics of field-deployed robots in a post on the now-defunct startup Willow Garage: “Willow Garage's Legacy, Blessing or Curse”. What was once a celebrity startup in the field of robotics disappeared into the dustbin of tech history in the space of a few years. The hubris of the developers behind Willow Garage was that they thought that by creating a standardized general-purpose robot, they could then divorce software development from the underlying hardware development. The desire seems to have been to turn robot design into a software developer’s game; and it is the ghost of this desire that still haunts the earth to this day in the form of ROS.

But reality will always bite back hard on any ill-conceived startup venture. It’s the hardware side of a robot's design that connects it to physical reality and, most importantly, to the economic reality of its intended arena of application. By divorcing software development from any underlying hardware development, Willow Garage also divorced itself, in its corporate thinking, from any consideration of the underlying economic factors involved in robot design such as the costs of manufacturing, operation, and maintenance. The foregone result was that the PR2 never became anything more than a vanity purchase for a few dozen financially well-endowed research and academic institutions.

/***********************/

At this point, I’m ready to assert that, in regards to stationary/floor-mounted robots, traditional software development modalities are sufficient. But when it comes to mobile field-deployed robots, some new way of programming needs to be articulated and implemented.

What this last, somewhat fuzzy, statement might mean in practical terms will be the subject of the remaining two parts of this post.

The Economic Reality of Agricultural Robotics and the Return of Widjets, Part 1 of 4

If by progress in agricultural robotics one means that concepts being explored in the engineering lab are maturing into viable commercial products that farmers are willing to make capital investment in, then there really hasn’t been any progress over the last decade or more. When I look at a trade publication today showcasing the latest ag-robot commercial venture, what I see looks exactly the same as what people were doing 10 years ago.

The easy, and least charitable, explanation is that researchers in agricultural robotics are more concerned with making clever robots than they are in addressing the economic realities that farmers are constrained to work within. I personally think the real answer goes much deeper than this. But I would like to start by addressing this first speculation.

Regarding the economic reality farmers face; not once have I seen any article or research group address the fact that in the farming industry, productivity and profit do not necessarily correlate. In fact, often they are found in inverse correlation. If one farmer has a productive crop yield, chances are other farmers in that region have done as well. At harvest time, this gluts the market causing the price per commodity to go down; at which point the farmer actually ends up losing money. It is not unheard for a farmer to let a field go fallow midseason when it becomes apparent that a crop has become a money loser for the year.

And regarding the question of crop rotation, at least in my area (Pajaro Valley), except for the apple orchards and berry fields, I never see the same crop in the same field for more than one growing cycle. For example, for vegetable crops, it’s a given that there will be several different crops in the same field over the course of any growing season. This means that any ag-robot technology that requires permanent field-installed components will also become a nonstarter for the farmer.

For these reasons, farmers are extremely reluctant to make any kind of capital investment in equipment or infrastructure beyond what is minimally necessary. In other words, telling a farmer, as a sales pitch, that using a certain ag-robot technology can raise his/her productivity is not going to be, by itself, a useful marketing strategy.

For a farmer, a robot will be just another piece of equipment like a tractor or harvester; and, whether purchased or leased, machine payments come every month whether the equipment is working in the field or not. Contrast this with the economic reality of hiring a field worker; when the work stops, the field worker can be let go and the farmer’s financial commitment ends. This is a point universally overlooked. Yes, machinery and robotics, on paper, will appear to be far more productive then human labor. But the financial commitment that comes over the lifetime of ownership of a single-crop ag-robot negates any short-term/seasonal financial advantage it has over human labor.

The large corporate farms, whose operations encompass thousands of acres, can make the risky financial choice of purchasing a large sophisticated single-crop harvester or planter.

But for family farms, whose operations are measured in hundreds of acres rather than thousands, investing in such large sophisticated machinery is an out-of-reach financial decision; which is why smaller farming operations are more dependent upon hand labor.

One needs to be careful in reading the last two paragraphs. One has to make the distinction between mechanization and robotics. There are crops like wheat, corn, potatoes, peanuts, sugar beets, and etc., that lend themselves to a high degree of mechanization. From soil preparation to planting through to harvesting, each phase of the farming operation can be taken care of in one pass and at one point in time, with the handling of these particular crops all done mechanically. Contrast this with crops like berries, green beans or zucchini squash, where the harvesting goes on continually over the course of a plant's growing cycle, and which also require careful handling to avoid damage to both the food item and the plant itself.

When looking at those crops that lend themselves to mechanization, one finds that the farming industry has already reduced the need for human labor down to a handful of equipment operators running large integrated computerized machines. At this current state of affairs, robotics and AI offer little-to-no marginal return on investment. The best the robotics community can offer is to replace the remaining equipment operators with AI-based control systems. But the truth is, having a reliable, conscientious and responsible human operator on payroll represents a far greater return on investment to the farmer than spending money on a complicated computer-based AI control system that leaves them at the mercy of some outside, distant, and often unresponsive tech support.

To appreciate how serious this last situation is for farmers, one only needs to look to the recent controversy over the “right to repair” that has affected John Deere tractor owners across this nation.

• Wired Magazine, "John Deere Just Swindled Farmers out of Their Right to Repair".
• YouTube, "Right to Repair”.
• YouTube, "Tractor Hacking: The Farmers Breaking Big Tech’s Repair Monopoly”.

Where robotics can offer a true return on investment to the farmer is with crops that require special handling: picking fruit and berries and harvesting a variety of the vegetable crops. These are the crops for which the cost of labor is the largest single expense the farmer has to face. And with coming minimum-wage laws and other rules respecting work week hours, these are the kinds of expenses that will break a farmer financially. So, the incentive to replace the human fieldworker with an equivalent AI-driven machine could not be more immediate. For example: YouTube, “Harvesting Squash & Eggplant in Fresno County”.

In other words, agricultural robotics will only/finally arrive commercially on the farm when it can offer the farmer a human fieldworker equivalent.

But, here’s the catch, until there is an electro-mechanical equivalent to biological muscle, such a human equivalent robot is an unattainable dream.

Developers develop the ideas they can based on the current technologies available to them. Electromagnetic, hydraulic, and pneumatic are the only robust actuator technologies available to design with. So whatever ag-robot might be designed, its functionality, by necessity, will always be constrained to what these actuator technologies are capable of implementing.

This last observation brings this post back to the speculation as to why the field of agricultural robotics is not progressing. The answer is that, given the existing technologies available, it simply can’t.

The T2-Tile Project, Publications, Race Conditions, and Breaking Symmetry in Asynchronous Arrays

To get myself back up to speed with the MFM, I went back and reread Dave Ackley’s two papers on the subject: “Pursue Robust Indefinite Scalability”, Ackley, Cannon, 2011, and “A Movable Architecture for Robust Spatial Computing”, Ackley, Cannon, Williams, 2011.

Then I dove further, reading publications cited in these two papers; at least, those that are accessible on the Internet. There are two main design considerations that have come to mind as I have been reading through this literature.

The first is that for very large and indefinitely scalable arrays, power considerations will dominate any design effort and asynchronous arrays are the only ones that satisfy this design constraint. Why this is so is that, neglecting leakage currents, CMOS circuits only consume power when being switched. For large synchronous CMOS logic circuits, the current consumed with the constant clock switching of 100's of MHz to GHz speeds, becomes the dominant power drain. For example, the datasheet for the fifth generation Intel core processor family lists I-ccmax values from 18 to 40 Amps!

Reducing power consumption in CMOS circuitry means clocking individual logic elements only when necessary. How this works in practice is that each individual processor cell in an asynchronous array is given a ring oscillator to act as its own local clock. The crucial feature of a ring oscillator is that it only turns on when an individual processor cell is accessed, then turns off when the cell’s internal programming has run to a stopping point. Therefore, when not in use, the individual processor cells turn off, effectively consuming no power at all. The potential drawback of this scheme is that once a cell has gone to “sleep”, it will only wake up again when accessed from a neighboring cell; that is, only when its ring oscillator gets “rung” again.

The second consideration came to mind as I read through this paper: “Embedding Universal Delay-Insensitive Circuits in Asynchronous Cellular Spaces”, Lee, Adachi, Peper, Morita, 2003.

It struck me as a good example of the kind of disconnect one finds between the theory of array computation versus the reality of hardware design. In this case, the authors considered the situation of a communication race condition; that is, the situation when two neighboring cells initiate communication at the same time. The question, then, of “who goes first?” comes into play with the possibility of a resultant lockup situation occurring. The authors presented a theoretical fix which they called delay-insensitive circuits. Theoretically, this is a fascinating piece of work in that it shows that every synchronous array is equivalent to some asynchronous version of it. But in reality, at the timescales where such communication race conditions would occur, digital electronics starts to behave in an analog fashion, in which case the paper’s straightforward theoretical results will no longer apply.

Race conditions within asynchronous arrays will always be the norm, not the exception. Some way has to be found, so that when communication is initiated between individual cells, they will automatically know who gets to go first and who waits. Just like in any social group, there has to be some kind of dominance hierarchy imposed on the global array.

In terms of what can be accomplished in a practical sense, one has to break the array’s global symmetry – directions have to be defined: up/down, right/left, top/bottom. Then communication is given preferred directions either based on a rule set or by the addition of a “breathing mode”; that is, a phase during which all communication goes in one preferred direction, followed by an alternate period of time when all communication flows in an opposite direction, with information flowing back and forth within the array something like the tides in the ocean.

This is one of the aspects of asynchronous array design that makes simulation qualitatively different than running on bare silicon. In simulation the programming for the virtual machine can be written to arbitrate any race condition that might come up between the individual CA-atoms. But when you forgo the virtual machine and try to run your asynchronous cellular automata on bare-metal processors, then the processor coding itself has to take care of these race conditions. It’s an extra layer to the hardware design that needs to be added to the MFM concept in order to make it work for real.

Dave Ackley’s T2-Tile Project, First Thoughts

My interest in asynchronous arrays started with my interest as a physicist in cellular automata (CA) and the thermodynamics of computation. That interest then turned itself into a personal challenge to see if I could actually create hardware that would implement these ideas. It was in researching the topic of very large asynchronous arrays of simple processors that I first ran across Dave Ackley’s YouTube channel. That was several years ago, and I’ve been lurking there ever since. I was excited about his work with his Demon Horde Sort simulation. Now that he has started building actual hardware, I’m watching with interest the T2-Tile Project.

Back when I first became interested in arrays of simple processors, I read through a lot of publications on the subject. But at that time, I don’t recall reading any papers that combined the separate subjects of self-assembling and processor arrays into a single research effort.

Papers that dealt with the concept of self-assembly seemed to focus on self-assembly of electrical elements, using techniques of nano-assembly and DNA to implement this process; that is, self-assembling primitive logic elements that could then be self-assembled further into logical computational structures.

While looking at the subject of array processor IC’s and processor arrays, I found that the published research is all over the road-map. But despite the wide range of approaches found in the literature, they all still have one thing in common; that is, the array elements are the computational mechanism of the structure. This is fundamentally different than what Dave Ackley is proposing with the Movable Feast Machine (MFM). In his case, the underlying silicon electronics is not responsible for the computational action of the array structure; rather, it is the interactions of the CA-atoms that are responsible for computation. The underlying electronics is just the structure that the CA-atoms move upon and reside within.

This is the conundrum of the T2-Tile Project: the CA-atoms are running within a virtual machine, which in turn is running upon a classical computational architecture – the very design constraint that Dave is trying to get away from with his concept of Robust-First-Computing. I don’t want this to be taken as criticism; I find Dave’s work fascinating, just not complete. But then again, he is a software person, not a hardware designer. And as a hardware guy myself, I consider the work he’s done to date pretty damn good for someone whose background is not hardware to start with. What I would like to do in the coming months is to pick up where the T2-Tile Project leaves off and carry it further into the design of the underlying hardware – the complementary construction where the MFM will finally be able to become what it wants to be.

What this means, as far as hardware design goes, is that any processor element that forms the array sub-structure underneath the MFM has to be designed, not as computational element in itself, but rather for its ability to support whatever the CA-atoms are programmed to do. In other words, the CA-atoms and the underlying silicon form a symbiotic structure; you can’t design one side of the concept without designing the other side at the same time. It is for this reason I think that this area of research has never been explored; there is no research group out there that has the breadth of expertise to develop both sides of the “robust-first CA-computation” and “self-assembling processor array” combination within a single research effort.

The first step is to outline the fundamental hardware problem, so here it goes…

It is a problem I’ve run into before in hardware design; trying to take a project that ran within a virtual system, then re-cast it as an FPGA based design. It turns out that there are subtle things that virtual machines allow you to do that you can’t reproduce with hardware alone. Something that software people don’t always appreciate, but hardware designers will, is that a virtual machine can step outside of itself and take advantage of computational processes at the hardware level, that the CA running under the virtual machine can’t. The best way to illustrate this is with an example…

The reason DReg or Res can read what’s in a neighboring cell is that the virtual machine, that the MFM is running under, can take advantage of the fact that all of the data of neighboring cells is contained within the same common area in RAM. But this can’t be done within an array where each cell of the array is hardware-independent from its neighbors. In such an arrangement, each cell only knows what’s in its own memory; to find out what resides in a neighboring cell, some form of hardware interrogation must transpire. This kind of interrogation process is not contained in Dave Ackley’s core programming for the CA-atoms.

The virtual MFM machine also keeps a common library of function calls that each cell can access. The only information then that a cell needs to contain is a single 64(?) bit data string. But this feature doesn’t translate from the virtual machine environment to an array of hardware-independent processor elements either. In this case, each CA-atom has to maintain an independent local copy of all of its programming code.

That is, before we can re-create the MFM at the hardware level, a number of the functional attributes that the CA-atoms currently possess get thrown out, while other features will have to be added. That’s where the hardware design becomes challenging. Basically, short of inspired brilliance, one has to work by an iterative process of cut and try; propose a primitive computational structure for the underlying hardware elements, then try out complementary sets of instructions for the CA-atoms, run it all in simulation, and see what happens; then rinse, repeat!

Emergence

The last of the topics I’ve devoted time to these last months is the subject of emergence; sometimes referred to as emergent behavior/phenomena/systems. It’s an area of inquiry that crosses boundaries from philosophy and theology all the way to physics, chemistry, and biology.

This additional area of interest is the natural continuation of my interests in systems of distributed intelligence and cellular automata as computational systems. That is, both of these areas of inquiry take you right to the heart of emergent behaviors. To jumpstart my research in this area, I’ve started reading the book “Re-emergence of Emergence, The Emergentist Hypothesis from Science to Religion”, edited by Philip Clayton and Paul Davies.

So far this book seems to be a very good introduction to the depth, breadth and history of the cross discipline discussions on what constitutes emergence.

To go along with this added dimension to my interests, I’ve now added the keywords emergent-systems underneath the blog header.

Whither goes K-12 STEM education? Is it time to bring back shop classes?

The second of three topics that occupied my thoughts these last few months was the question, where stands STEM education in K-12?

After spending several days trying to put my thoughts into words, I had to give up. There’s no way to engage in this topic without finding oneself drawn into the politics of K-12 education. And the last thing I want is for politics to show up in my blog. So, I’ve abandoned any attempt at a discussion of the subject.

The only aspect of my thoughts, that I think I can express without getting drawn into a political discussion, is to note that the robotics/technology side of STEM education would be far better served if it were taught within a traditional shop class format. But, the traditional shop class is now inextricably associated with the older practice of tracking; a practice which has become much maligned within today’s educational communities.

So I’ll just put the question out there and move on to other things.

Willow Garage’s Legacy, a Blessing or a Decade’s Long Detour in the Evolution of Robotics?

One result of my not being able to work on electronics for the last year was that I had a chance to ponder other questions. One of these questions was wondering about, "whatever happened to Willow Garage?" There was a time about a decade ago it was heralded as one of the great innovators of the robotics community. Then it just sort of disappeared. It had a number of spinoffs; but none of them ever turned into, what you might call an above average commercial success. It seems that the software innovation ROS has been left as Willow Garage’s only remaining legacy to the robotics community.

Despite WG’s universal acclaim, there was always something about that operation that bothered me. I was never able to quite put my finger on it. So with time on my hands, I “googled” Willow Garage to see if I could find any links to posts that might have made critical comments about it; to see if anyone else might have picked up on what I might be sensing.

Nothing!

As critical and contrary-for-the-sake-of-contrariness as some people can be on the Internet, you would’ve thought that there would have been at least a few critical posts or articles to be found.

So what was I seeing in WG that everyone else seems to have missed? I think I finally have an answer that I can articulate. So here it goes.

The formation of Willow Garage brought together some of Silicon Valley’s top-tier talent. Not only was WG’s initial formation generously self-funded, but over time it was able to attract even more venture capital to fund its ambitious creative efforts. The enthusiasm that WG brought to the robotics community attracted a cadre of dedicated and very talented engineers and programmers. You might be forgiven if you started to see WG as a sort of modern-day robotics Camelot.

But here’s the nagging question; if this is the level of funding and talent it takes to do robotics, then how will robotics ever be able to leave the engineering lab and move out to the farm field, the construction site, or the logging or mining operation?

For example, whatever commercial value an agricultural robotic-field-worker might have to a farmer, it must compete with its $25K a year human counterpart. This basic cost of employment puts a severe cost-constraint on any robotics system intended to be used in the field.

The second and more critical issue is that the people who will be selling, operating, servicing and maintaining field-deployed robots in the future, will by necessity be the same people that are doing those jobs now as regards to farm, construction, logging, or mining equipment. In other words, any robotic system deployed in the field, that requires the additional technical support of a team of Stanford University engineering graduate students, is a nonstarter.

To put it in another way, WG’s approach to robotics completely bypassed the questions of cost, manufacturing, operation, service, and maintenance; all absolutely critical elements for any robotic system to be commercially viable in the field.

What a field-deployed robot needs to be is modular. Its mechanical construction needs to be based on interchangeable subassemblies. And its computational architecture should come in the form of pre-programmed bricks or modules connected together using a single shared serial interface to form a system of distributed intelligence.

This form of construction allows for easy manufacture, easy maintenance, and easy service. Programming is not part of this paradigm. If one wants to change some functionality in a robot, just swap in a different module. The upside of this kind of construction is that this is the level of service, maintenance, and rebuild competency that already exists within the workforce currently employed in the industries of farming, construction, logging, and mining.

This last observation returns us to the question of ROS as being a useful addition to the robotics community’s programming toolkit. Sadly, to run ROS is to become dependent on a particular type of supporting hardware architecture; a computational architecture which is the complete antithesis of what needs to be implemented before robots will leave the engineering lab and proceed out to the field.

So this is my pondering, will ROS, rather than the boon to industry it was held out to be, in the years ahead, turn out to be a decade’s long detour in the evolution of field-deployable robotics?

Last Year’s Hiatus

A year ago, last June; I was diagnosed with dilated cardiomyopathy. In hindsight, I can see that its onset was probably around March of that year. At that time, I was running 30 to 40 miles a week on the trails at a local state park. But I began to notice my usual 6 or 9 mile runs were getting slower and slower. Then my runs got shorter and shorter. By June, I couldn’t climb to the top of the stairs here at the house without getting out of breath.

It’s not certain what caused this condition. My cardiologist’s best guess is a possible viral infection. I seem to have fallen victim to a condition that usually hits younger and healthier people. Whatever it was that damaged my heart muscle, its onset was most likely around February/March of last year. But being in such good shape to start with, it took several more months for my condition to deteriorate to the point that it was no longer ignorable.

On the downside, there’s nothing that can be done to help except putting me on blood thinners and blood pressure medications. On the upside though, as my cardiologist has told me, “…except for a weakened heart muscle, [I’m] as healthy as a horse.” An angiogram showed my heart arteries wide open and clear and I have no other signs of cardiovascular disease anywhere in my body. I guess a lifetime of endurance-level physical activity had left me, at the age of 65, in exceptionally good health.

So the good news was, I can’t possibly have a heart attack. A defibrillator was implanted last November. With that addition I felt braver and started working out again.

Then, just when I thought I was getting better, I had a TIA (transient ischemic attack), a mini-stroke. I’ve fully recovered, but it left me fatigued again. Hence my further delay getting back to blogging.

I’m one of those people that, in order for my brain to work, my body must be physically engaged as well. Some people call this being a kinesthetic learner. When I was a kid, I was just called fidgety.

Making a long story short, finally getting back to being physical activity again is enabling me to be mentally active again, too.

So time to restart this blog, and finish up where I was last February.

Langton's Ant, Part 1

Good news is that a full simulation routine, written in C, and running under Linux is working. As a validation test for my coding I successfully ran Langton’s Ant, the results were animated, a video made, and posted to YouTube. 

The first pass of my simulation routine used Ncurses for text graphics display.

After I had debugged my code using a simple text graphics display, I redid the code to generate binary output data-files. Those files were in turn converted into bitmap graphic file format using a program I’ve written in LabVIEW. Lastly, with those files in turn, I could then animate using the software package Frames.

Frames might not be the best way to generate animations, but it was left over from our family’s home-schooling days when my son was working with stop motion animation. It’s a frustrating package to use, but I have it and it works… if you’re patient enough. After the animation was done, the actual video was put together using Adobe Premier Elements: version 9. Again, a software package left over from my son’s home-schooling days.

The actual simulation program was running 2 weeks ago, but it took me a week of messing around to get the animation sequence into a form I was satisfied with. I haven’t used these animation tools in five years. It took several days just for me to get back up to speed with using my old software.

The next step for me and this project is to create a Langton’s Ant program that starts out already in its stable “highway” configuration. Since the “highway” is a 104 step repeating pattern, one would expect that there will be countless ways to seed a Langton’s Ant program in this way. The question though, is there a minimal set? Or is that even a meaningful question? The next step in this direction is to recast Langton’s Ant as a two-dimensional Turing machine and analyze the system from that point of view.

For anyone finding this blog via the YouTube video post, I think I should emphasize again that Langton’s Ant is not my goal. My interests are in the underlying hardware that it will take to create a large asynchronous array of simple processors. I’m just using Langton’s Ant at this point as a simple and accessible test example.

I have recently come across the work of Dave Ackley. I’ve watched all of his posted YouTube videos and have downloaded a couple of his published papers. This paper in particular is what I’m working through right now: “A Movable Architecture for Robust Spatial Computing”, David H. Ackley*, Daniel C. Cannon and Lance R. Williams  If this is any indication, I have a lot of work ahead to catch up to the current state of the art in this field.

One way to characterize this project of mine is to see it as trying to develop the underlying silicon hardware, FPGA or ASIC, that you would need to re-create in hardware what Professor Ackley is trying to do in software. But I can’t speak for him about that. Maybe someday I’ll have a chance to talk to him and find out. 

On the more academic side, I’m steadily working my way through Hamilton’s book. I’m struggling a little more with the video lecture series; mostly because I find it very hard to sit still and watch them on the computer screen. It’s clear my brain has gotten pretty rusty over the last 25 years since I left grad school. My goal at this point is, over the next six months, to come up to speed on Turing machines and all the mathematics that goes behind them.

Array Processor Simulation: Current Progress

The first pass of a simulation routine, written in LabVIEW, is working. I probably spent more time debugging the handshaking routine than anything else, but it’s working now. I can generate a seed code-worm that starts at cell (0, 0) then travels across to a destination cell.

In this debug stage, I need to display all the registers so I can watch what is happening within each of the individual cells. This verbose display mode means that I can only fit a 4x4 display array on my monitor. But a 4x4 array, at this first pass stage, was good enough to get things working.

I have an old Windows-XP legacy system that I kept available for periodic maintenance work on projects that I did for clients years earlier. Now that I’m retied and don’t need it anymore; time to turn it into Linux system. I’ve ordered a new hard drive and will upgrade this old XP system to Linux running Debian. The hard drive should arrive next week. At which point I’ll start the second phase of the array processor simulation project.

On the cellular automata front, it only took a little bit of research to find out that Stephen Wolfram, of Mathematica fame, has already done a significant amount of work in this area. I checked his book out from the library, “A New Kind of Science” and have started reading it.

My intent is to start with duplicating some of the classic cellular automata featured on YouTube, like the Game of Life and Langton’s Ant. The challenge is going to be how to visualize the time evolution of such systems; especially in the case of arrays on the order of 100x100 and bigger. Needing to display the progress of such a large array on a standard monitor means I can’t use much more than a 10x10 pixel area per display cell. Outputting numbers in this case is out of the question. So, what I have to explore next is ways to use colors to encode what each cell is doing.

For the simple examples I will be starting with, just displaying either a light or dark shaded area will be sufficient. But as I progress to more complicated relationships between the cells I’ll need to try something different. One obvious trick is to use the assembly language “org” instruction to partition various sections of each cell’s program-code into different segments of program-memory. Then assign different colors to each of these code segments; that way encoding the program-counter as a color will indicate which subroutine is active at any one time. What other cell-variables will be relevant to visualize, and how to visualize them with color-encoding is something I need to work on in the weeks ahead.

Next, is to start making “evolution” videos of these two-dimensional cellular automata and watch to see if any patterns appear to emerge. And regarding this effort, something worth noting is that when it comes to pattern recognition, the human brain is the best visual processing system we have access to. Even Google, Facebook, Stanford, MIT and the rest, even with their unique access to massive amounts of computational horsepower, and even using advanced techniques like deep learning, are still struggling to visually recognize a cat in a picture; something that humans can do quite easily.

I need to remember that my goal is not to just recreate work others have already done, but to explore the possibilities of using code-worms as a way of stabilizing the evolution of cellular automata so that they will stay stationary and not move off screen. If I can get that far, then the next question to explore will be whether these stationary automata can be used as computational engines to process an input to an output stream? Specifically, I’m curious if an automata could be used to function as a Szilard’s Engine or a Maxwell’s demon.

On a second note: It has been over 20 years since I left physics and went into engineering. I’m afraid my math skills have gotten quite rusty. So, in an effort to get my skills backup to par, I’ll be working through my old textbook on math logic “Logic for Mathematicians” by A. G. Hamilton. and starting to work through the YouTube video series on the “Theory of Computation.”

Array Processor Simulation: First Pass

My first pass at a simulation program is mostly done now. All I need to do next is to start running it, debug any problems with the coding, and see what it does. This first “proof-of-principle” simulation program I’ve done in LabVIEW. Yes I know, LabVIEW? The reasons are that it’s a software tool I have, I’m very accustomed to using it, and it’s a great tool to put together a Windows program very quickly. This first pass is only intended to get a feel for the direction I’m trying to take this programming.

There are a number of initial choices about the construction of an asynchronous-array-of-simple-processors that I don’t have any good answers for. I’ll just have to try different things out first and see if they work or not. And that sort of effort is best done with the simplest programming environment you have to work with.

One of those choices is the machine instruction set I’ll need to give each of the simple processor cells. There is also the choice of how the I/O handshaking works between each of the neighboring cells.

For my case, I’m opting for a stack-based architecture using a dual stack arrangement with the program memory and data memory mapped to the same physical block of RAM. Mapping data space and program space together will allow the program code to modify itself on the fly.

If it all works, then the next step is to go to a simulation routine written in C running on a Linux desktop system. At that point, I’ll be able to take some screenshots and make source code available on my webpage.

The one thing that became obvious very quickly, once I started coding, was that whatever machine instruction set I give each simple processor cell, it will have to be both rotationally and translationally symmetric with respect to right/left and up/down directions. This forces some constraints on the design. One of the interesting implications of this requirement for symmetry is that the individual cells in such a processor array can’t have absolute array-location addresses. And any stable programming that can exist in this array has to be relative and not absolute in its addressing of neighboring cells. Anyway, fun stuff to think about.

Writing the simulation routine is only half of the effort. The second part is writing the programs that will run in the individual processor cells. But in this regard, most of the work has already been done. I already have a generic assembler that I created years ago that takes a file written in assembly code format, along with a list of mnemonic/machine-code associations, then outputs a machine code file that I can import into each processor cell’s program memory.

Over the years, I’ve written in Verilog a number of small processor cores that were embedded into the FPGA designs I've worked on. In these design situations, I needed such a generic assembler to create the code files to run in these minimal cores.

Just as an aside, it’s fun to work at the HDL-Verilog level of programming. You can create custom processor cores that have just the machine instructions that you want; no more, no less. This really lets you dial-in the performance of your FPGA part!

Slightly off-topic now… Why my interest in asynchronous array processors as a likely candidate for a learning system? There have been a number of attempts to create chips that mimic neural networks at the silicon level. But these attempts to mimic the human brain fall short in one important aspect, the nerve cells that form your brain can grow and/or prune the neural connections between them. A neural network built on an IC chip can’t do this. Whatever connections there are between individual cells, these connections are permanent and cannot be modified later via software.

But there is a trick in asynchronous arrays that can get around this hardware level limitation. While the individual cells within an asynchronous array only connect to their nearest neighbors, there is a concept, what you might call a “code-worm”, where a data packet can originate in one cell and travel across the array to a destination cell that is not a nearest neighbor. These code-worms can be spawned or pruned on a real-time basis and can be used to reproduce the functionality of the axons forming the neural connections in the brain.

So that was my first realization, that you can use an asynchronous array like you would a neural network with code-worms acting like the axon connections between the individual neurons. So not only can you train such a neural network using the standard methods, but a neural network, constructed as an asynchronous array, would also be able to change connections between the cells as well. It would seem that a neural network built this way would be much closer to how our brains function than the techniques currently used.

So this is the goal of the first proof-of-principle simulation program; to see if I can get this code-worm concept to go.

The idea of using an asynchronous array as an ecosystem for cellular automata came later to me. But it’s also an extremely fascinating one which I’d like to pursue for its own sake.