One way to increase the intelligence of a robot is to train it with a series of missions, analogous to the missions (aka levels) in a video game.
In a developmental robot, the training would not be simply learning—its brain structure would actually change. Biological development shows some extremes that a robot could go through, like starting with a small seed that constructs itself, or creating too many neural connections and then in a later phase deleting a whole bunch of them.
As another example of development vs. learning, a simple artificial neural network is trained when the weights have been changed after a series of training inputs (and error correction if it is supervised). In contradistinction, a developmental system changes itself structurally. It would be like growing completely new nodes, network layers, or new networks entirely during each training level.
Or you can imagine the difference between decorating a skyscraper (learning) and building a skyscraper (development).
What Happens to the Robot Brain in these Missions?
Inside a robotic mental development mission or stage, almost anything could go on depending on the mad scientist who made it. It could be a series of timed, purely internal structural changes. For instance:
- Grow set A of mental modules
- Grow mental module B
- Connect B to some of A
- Activate dormant function f() in all modules
- Add in pre-made module C and connect it to all other modules
Instead of (or in addition to) pre-planned timed changes, the stages could be in part based on environmental interactions. And I think that is actually a possibly useful tactic to make a robot adjust to its own morphology and the particular range of environments that it must operate and survive in. And that makes the stages more like the aforementioned missions as one has in computer games.
Note that learning is most likely going to be happening at the same time (unless learning abilities are turned off as part of a developmental level). In the space of all possible developmental robots, one would expect some mental change gray areas somewhere between development and learning.
Given the input and triggering roles of the environment, each development level may require a special sandbox world. The body of the robot may also undergo changes during each level.
The ordering of the levels/ sandboxes would depend on what mental structures are necessary going in to each one.
One problem that I have been thinking about is how to prevent cross-contamination of mental changes. One mission might nullify a previous mission.
For example, let’s say that a robot can now survive in Sandbox A after making it through Mission A. Now the robot proceeds through Mission B in Sandbox B. You would expect the robot to be able to survive in a bigger new sandbox (e.g. the real world) that has elements of both Sandbox A and Sandbox B (or requires the mental structures developed during A and B). But B might have messed up A. And now you have a robot that’s good at B but not A, or even worse not good at anything.
Imagine some unstructured cookie dough. You can form a blob of it into a special shape with a cookie cutter.
But applying several cookie cutters in a row might result in an unrecognizable shape, maybe even no better than the original blob.
As a mathematical example, take a four stage developmental sequence where each stage is a different function, numbered 1-4. This could be represented as:
where x is the starting cognitive system and y is the final resulting cognitive system.
This function composition is not commutative, e.g.
A Commutative Approach
There is a way to make an architecture and transform function type that is commutative. You might think that will solve our problem, however it only works with certain constraints that we might not want. To explain I will show you an example of a special commutative configuration.
We could require all the development stages to have a minimal required integration program. I.e. f1(), f2(), etc. are all sub-types of m(), the master function. Or in object oriented terms:
The example here would have each mission result in a new mental module. The required default program would automatically connect this module with the same protocol to all other modules.
So in this case:
I don’t think this is a good solution since it seriously limits the cognitive architecture. We would not even be able to build a simple layered control system where each higher layer depends on the lower layers. We cannot have arbitrary links and different types of links between modules. And it does not address how conflicts are arbitrated for outputs.
However, we could add in some dynamic adaptive interfaces in each module that apply special changes. For instance, module type B might send out feelers to sense the presence of module type A, and even if A is added afterwards, eventually B will find it after all the modules have been added. But, we will not be able to actually unleash the robot into any of the environments it should be able to handle until the end, and this is bad. It removes the power of iterative development. And it means that a mission associated with a module will be severely limited.
The most damning defect with this approach is that there’s still no guarantee that a recently added module won’t interfere with previous modules as the robot interacts in a dynamic world.
A Pattern Solution
A non-commutative solution might reside in integration patterns. These would preserve the functionality from previous stages as the structure is changed.
For instance, one pattern might be to add a switching mechanism. The resulting robot mind would be partially modal—in a given context, it would activate the most appropriate developed part of its mind but not all of parts at the same time.
A similar pattern could be used for developing or learning new skills—a new skill doesn’t overwrite previous skills, it is instead added to the relevant set of skills which are triggered or selected by other mechanisms.
- Georgia State University Library via Atlanta Time Machine
- crooked brains
- diagram by the author