Anibots: Agent Collaboration Using Anigrafs

Posted in artificial intelligence on March 22nd, 2018 by Samuel Kenyon

It’s been a decade since I finished a Cognitive Architectures course at MIT (9.364) under professor Whitman Richards. My final project was a little thing called “Agent Collaboration Using Anigrafs.” Anigrafs were a pedagogical cognitive architecture that Richards defined. I wrote some code to implement anigrafs and hooked it to simulated robots, which I called “anibots.”  What follows is essentially my 2008 final report to Prof. Richards.

(I noticed several years later that he published Anigrafs: Experiments in Cooperative Cognitive Architecture as a real book from MIT Press.)

Ultra-simplified summary: Identical robots can cooperate if they use a type of mental network that votes with the Condorcet method on what behavior to do next.

Anibots

Introduction

The General Problem

The development goal is to achieve collaboration of situated agents to perform shared tasks and/or goals. These software agents are virtually embodied in a simulated world. The experimental aspect of this project is to determine if anigrafs (described below) can be used as the basis for teams of collaborative creatures—I refer to these creatures as anibots. And if so, what emergent behavior strategies work best? Do team members have to be specialized or can they all be identical?

What are Anigrafs?

Anigrafs [1] are graphs of agents intended to model the minds of situated creatures. An anigraf can also be thought of as an architecture for a real time control system at multiple levels, which furthermore is intended to have more complex behavior than a merely reflexive machine. Each agent represents a possible goal or action, and has a certain weight relative to other agents in the same local graph. The agents are connected by edges which indicate relations such as similarity. There may many subgraphs in the system, but the details of how those are connected and interact are not under introspection here, with the exception of proxy agent graphs which will be discussed later. Decisions are made with a tally machine (a voting algorithm), which results in only one action per iteration. There are various parameters to the tally machine, such as how many ranked choices each voter is allowed to vote with (knowledge depth). The choices are indicated by the graph itself—edges and edge directionality indicate preferences. Each candidate (an agent with a particular action or goal) is also a voter.

There are basically two levels of agents here: These networks of agents that vote are like sub-agents and they make up a “brain” of an agent that’s a robot.

The primary reason to experiment with anigrafs for collaborative artificial creatures is that the framework provides a means for arbitration of a creature’s actions/goals and a way to integrate the decision-making process of multiple creatures. The tally machine—this project uses a Condorcet Tally—acts as the arbiter of possible behaviors. This voting system inherently results in a winner (assuming we have a process for ties and cycles) to resolve what goal gets the limited resources at each iteration.

The parameters of the voting system and the actual layout of the network of agents have various useful properties of both democracy and graph theory. For instance, “top” cycles in the outcome of a vote, in which multiple candidates are preferred to each other in a loop, e.g.: A > B > C > A, can be taken advantage of in the mental design.

Collaboration

The key components/properties of anigrafs I am using for collaboration:

  • basic concept of “fair”/”best” decision making from many choices/goals
  • proxy agents
  • top cycles
  • shared knowledge structures

Dancing

“A survival machine may be said to have communicated with another one when it influences its behavior or the state of its nervous system,” wrote Dawkins [2]. This definition of organism communication is perhaps enlightening for the anigraf approach. In later publications Dawkins revised this position to one of signals between animals being manipulative.

The three conditions for anigraf “dancing” [1] , translated to conditions for “team collaboration”:

  1. Each team member must have a common action set (or meta-actions—in this experiment each choice was hooked directly to a movement routine, but that is not necessary).
  2. Each agent can communicate with its corresponding agent in the other anigraf (I don’t specify yet whether it can link to multiple other anigrafs).
  3. Each anigraf’s tally includes votes from the other anigraf(s).

Interfacing practicality requires a shared protocol. In this experiment, the anibots are all exactly identical, both in the anigraf organization and starting weights.

Environment Interfaces

From the anibot point of view, environment is everything; in some cases even its own body could be considered environmental. In the implementation, as is likely in biological machines, the environment from the point of view of an anibot is bottlenecked through the anibot’s sensor inputs. In reality, the abstract agency that is the creature’s mind, which considers the environment as something else, is itself the operation and structure of an object (e.g., a computer or a nervous system) that is part of that same environment. The anigraf agents within the mind of the creatures described here could themselves have points of view. After all, anigraf agents represent goals and/or actions. Does this mean we also draw the line of me vs. environment (or us vs. them) within the mind at the level of mental agent? Is there any point in considering how an agent interacts with the anigraf system from its point of view? It is not as if it even has a sense of self—it is part of a larger system which could after much growth and evolution have a sense of self. But it is useful to consider the interfaces the agents have and what schemes might develop for them to gain advantages for the goal they represent. This might lead to the need for agents to make alliances, cliques, and to incubate the role of brokers [1]. Alliances and other strategies developed through evolution or other means of search/generation would perhaps be conceptually similar to biological ESSes [2] (Evolutionarily Stable Strategies) both within the brain and at the scale of macro organisms. This experiment does not test those developments, however, a focus on interfaces between agents at various levels—within a mind, between minds, between teams, etc.—is worth continuing in future experiments.

My anibots can interface with each other, but what about other objects in the environment? As [2] described it for biological creatures: “To a survival machine, another survival machine (which is not its own child or another close relative) is part of its environment, like a rock or a river or a lump of food. It is something that gets in the way, or something that can be exploited. It differs from a rock or a river in one important respect: it is inclined to hit back.” For our purposes, the difference between creature and object is that objects have a different interaction protocol. The experiment implementation will contain creatures with anigraf brains, but objects are not even handled in the mind. Objects (e.g., the block) exist only in the simulation, interacting at a physics level.

Implementation

Anigrafs

The real time control and communications system of each anibot is constructed with anigrafs. This experiment uses an implementation of anigrafs I wrote in C++. It is based on the concepts presented in the text Anigrafs [1]. Things that are specific to an implementation include vote tie resolution. Since the Condorcet method of voting is being used, in the case of cycles there must be a process to handle this. Anigrafs presents top cycles as something to take advantage of for control systems and inter-creature coordination, and is thusly exploited in this experiment. Therefore our voting system is set up so that in the case of cycles, each iteration retains state of the last iteration, and the resulting decision will be sequentially the next decision in the cycle of winners. Other non-winner resolution methods could have been used, such as recasting the vote with a system different than Condorcet, or merging the top two or three actions together (although that would require actions that can be combined, such as low-level motor command vectors). The other reason not the use merging is that it would no longer be a pure anigraf—which is part of the point of this experiment—as one of the fundamental hypotheses of anigrafs is that “the society of agents will choose one ‘category’ for action, no mixtures of categories” [1]. Although one might then ask, does “category” allow exceptions such as mixing actions of the same category which are for some reason in the same local graph?

This code for this experiment creates the proxy graph by cloning the anigraf proper (which is loaded from a file). The clone maintains whatever edges the original did, but not necessarily the weights (depends on parameters). The graphs are linked together with an edge set loaded from a file.

Representing Intent

The proxy graph—as a model of another anigraf—updates to represent the choice of this external anigraf. The method used to represent intent is to shift a constant value around depending on the winner (of the external anigraf), e.g., on each iteration:

  1. Subtract constant from previous winner.
  2. Add constant to current winner.

A problem observed in implementation was the issue of a node in the proxy graph winning. The intention was that a node in the original anigraf must win, since the proxy nodes don’t cause actions, they are just there to affect the final vote. The weights do not change at all except for this weight change, although in future experiments one would probably want to make a more complicated architecture in which anigraf weights are dynamic.

If we take an anigraf by itself, it will always have the same winner (or the same cycle if there’s a top cycle). If we then have two anigrafs interfacing, their proxy graphs start changing to reflect the winner of the other anigraf. The edges linking the proxy graph to the action graph determine how the weight change affects the vote.

Taking turns

How do we get identical anibots to avoid the simultaneous “sidewalk cha-cha” or stepping-on-toes phenomenon (they both have the same states at the same moment, thus the next same states, and so on)? Unless that’s the desired group goal (like flocks of birds), there has to be a way out of it. Maybe noise from environment helps keep the timing slightly off to prevent an infinite cycle. This simultaneous issue was resolved by using a turn taking scheme.

This allows cycles to happen—within the system of the pair of anibots—even without using top cycles of the anigrafs, and without any external stimuli, and with the exact same starting configuration of homogeneous anibots. In other words, my code exploits the nature of anigrafs to get behavior cycles which emerge only when multiple anibots interact.

With top cycle resolution, we can generate possibly-useful behavior patterns by constraining the the proxy weights to be proportional to the corresponding original anigraf weights. For example:

Behavior pattern:

Here is another example, although probably less useful for the block task (described later) since there seem to be too many Left Push actions happening:

Behavior pattern:

The Environment

The anigraf system itself is abstract, its environment consisting simply of communication with other non-embodied, non-situated anigrafs. Anibots are embodied and situated as spherical robots in a physical simulation and visualizer. Ultimately, I want to see how real-world constraints and creature abilities affect the systems and collaborations. The simulation is implemented with Breve [4]. A Python script connects the anigraf C++ program (with the help of SWIG) to the Breve simulation environment. My Python code also defines low-level physical actions triggered by higher-level anigraf actions.

An Experiment

This experiment tests creatures’ (anibots) ability to do a very simple task, which is to push a block as far as possible. They are tested both alone and in teams. There are only three high-level actions (the anigrafs are at this level):

  • Push block in center
  • Push block on right side
  • Push block on left side

In the physical simulation, intermediate actions are handled automatically. For instance, the anibots do not have to search for the block—I merely orient them so they are ready. Just as low level actions of a robot would be handled in other parts of the architecture, this simulation handles low level actions of propulsion and aligning with the block. For the purposes of this experiment I am only dealing with three high level commands.

The single inanimate object in this experiment—the block—does not interact at the level of the anigrafs. These anibots are so simple they do not attempt to model anything except other anibots.

Desired Sequence of Events:

  1. Anibot 0 (A0) reaches block first
  2. Default winner is Center
  3. A0 starts pushing block in the center
  4. Another anibot arrives (A1)
  5. A2 and A1 become aware of each other and establish communication
  6. A2 updates proxy that A1 has center winner
  7. This causes A2 to have a winner for Left or Right
  8. A1 can either keep pushing Center, or even better switch to the opposite side that A2 has chosen
  9. They continue to take turns, possibly not changing now that they have stabilized, until some external event happens.

The benefit of the second anibot is twofold:

  1. Twice the force upon the block should move it faster.
  2. Reduces failure due to the metastable nature of a pushing the block at a single point.

And of course in a more complicated scenario, having a teammate brings many other benefits, such as a replacement in case of death, or necessary help when the environment changes (e.g. they have to push it uphill), or they have different roles (e.g., one is a scout or a bodyguard).

Anigraf A

C = Center Push
L = Left Push
R = Right Push

In the middle you can see the proxification edges, which connect the proxy graph to the original graph. The design of the proxification edges is done here to influence the state machine nature of interaction anibots. Right Push (prime) favors Left Push because that is best for a mutual cooperation of the block pushing task. Likewise, Left Push (prime) favors Right Push. With this simple example it is evident that proxification edges take on a more complicated meaning than the edges within anigrafs without models. The edges may mean not just a preference for “what action is like me,” but also “what action works best with me” (or “what action is harmonic with me”).

It may seem logical that the C’ has an edge to C, however when I experimented with Anigraf B (shown below) in which C’ is not connected to C, it was actually easier to generate weight configurations that result in more interesting patterns. “Interesting” means the anibots in the group choose different behaviors and switch between behaviors in a cyclic pattern.

Anigraf B

This asymmetrical graph could represent noise in a system that is deployed. However, when generating configurations (weights) for this experiment, Anigraf B was found to be much easier to produce configurations with desirable behaviors. The results section describes experiments used with Anigraf B.

Behavior Strategies

In this experiment the anibots are homogeneous. At the moment, each anibot can only “lock on” (interface with) one other anibot at a time. At the moment, they completely ignore the inanimate object (the block), although that could eventually be part of the system’s model(s), for instance as described in Anigrafs Chapter 5 [1].

Proxification edges (the edges between the proxy graph and the original graph) can cause transition states from one anibot’s state to another anibots state. The push object task shows this—you can configure the proxy edges so that if Push-Left is the state of Anibot 0, then its buddy Anibot 1 will have extra preference to choose Push-Right. In this case, proxification edges don’t necessarily indicate preferences for similarity, but in some cases preferences for what agent (anigraf node) should win if this agent has already won, e.g. from the point of view of an agent: what agent complements me best?

In this example world, with two anibots, the block task is accomplished optimally if one anibot pushes on the left, and another pushes on the right. Alignment on the X axis is automatic, so the anigrafs in this experiment do not worry about that. There are starting configurations which lead to this behavior pattern—even though the anibots are homogeneous, because of the turn-taking, it is possible for one to settle on one action and the other to settle on a different action. However, settling on one task for the duration of teamwork is not always the best strategy.

A possible escape from settling is that top cycles in the proxified anigrafs can be used by the anibots to “dance” with each other. This “dance” may not result in the optimal block pushing (although it’s better than a sole anibot), but it has the potential to be more robust in a more dynamic or more complex environment. The dance could also be used for different tasks—for instance, if the goal was to move the block in a nonlinear path, then a particular set of dances would achieve that. Anigraf proxy modeling supports a social protocol which can be investigated from its communication potential for teams of anibots in various environments. This potential will be tested in further experiments.

Results

Case 1: One Anibot

In Case 1, a single Anigraf B anibot ran with the starting weights shown in Fig. 1. The resulting behavior pattern of is show in Fig. 3. Sequentially ordered (from top to bottom) screenshots from the simulation environment are show in Fig. 4. The block was moved a total distance of 87.18 units before failure.
This anibot does not have any intelligence to compensate for the metastable nature of the block pushing task. Because it is always choosing to push in the center, the physics of the environment cause the block to slowly rotate until the anibot blindly leaves it behind. One can imagine a few ways to make the anibot more robust in this task:

  1. Add more low-level automatic routines to the anibot, leaving the anigraf the same.
  2. Change the configuration of the anigraf so the behavior is more robust, e.g. alternating between right and left. However, this requires an additional agent in the anigraf in order to generate top cycles.
  3. Use a team of anibots instead of just one, which I demonstrate in Case 2.

With proxification turned on for a single anibot (Fig. 2), the mental situation is that of a “ghost”—it is modeling another anibot that is not there. With the given starting configuration, this disturbed variation of Case 1 will end up always choosing to Push Left, which is even worse than always choosing Push Center. The block in that case was only moved a total distance of 30.90 units.

Fig. 1: Case 1 anigraf

Fig. 2: With ghost proxy

Fig. 3: Case 1 behavior pattern

 

Fig. 4: Case 1 simulation screenshots

Case 2: Two Anibots

In Case 2, two identical Anigraf B anibots ran with the starting weights shown in Fig. 5 (the same weights used in Case 1). Case 2 is the point of the experiment, because here multiple anibots are interacting, each one modeling the other. The resulting behavior pattern of is show in the table below, which can also be represented graphically as shown in Fig. 6. Sequentially ordered (from top to bottom) screenshots from the simulation environment are show in Fig. 7.

Fig. 5: Case 2 anigraf

Fig. 6: Case 2 behavior pattern

Fig. 7: Case 2 simulation screenshots

 

The only blatant disregard for physics in the Anibots Simulation is the lack of collision handling between anibots. So they can occupy the same space when both doing the same action (see Fig. 8). If I allowed collision reactions in the physics simulation, they would be bouncing off each other like pinballs. This shows a need for automatic routines and/or rules such as how to crowd together or follow a partner. Or it could be something more specific to the situation, such as in this environment a fuzzy routine for each action so they find the next available open spot in the general vicinity of the Left, Center, or Right of the block.

The block was moved a total distance of 133.41 units before failure.

Fig. 8: Both Anibots Pushing Left (They Overlap)

Conclusion

Homogeneous agents containing anigrafs (with proxy graphs)—which are used to decide the agent’s actions—can be designed to behave differently when in groups than when alone, without any special case programming. The behavior strategies and patterns are a result of the graph edges and starting weights. A physical simulation with these agents, called anibots, has shown a very simple example of anigraf teamwork being more effective than the exact same anibots working alone. The simulation shows potential for anibots to be robust collaborative decision-makers in more complicated environments.

Comparison to Reflexive Machines

From the external point of view, after recognizing the behavior cycles, it might appear that these anibots are reacting to each other purely reflexively, perhaps like Braitenberg vehicles [3]. It also appears that at a given instance you can represent the architecture as a state machine.

The anibots in this experiment may appear to be simple reflexive machines because they are not changing their own action weights (or doing anything else mentally). The architecture within each anibot is doing social arbitration—the decision is based on their own wishes combined with the wishes of the other anibot. Since the simple anibots in this experiment do not change egotistical wishes, it might appear (except for the variability introduced from top cycles) that they aren’t modeling/integrating each other. To see the modeling effects (as an external observer), there must occur a change in the environment, team structure, or from other mental structures within the anibot’s control system. As a test, if I inject a change by altering the weight of one of an anibot’s action agents, the mutual behavior patterns completely change. For example, take the configuration used in Case 2, which results in this repeating pattern for a pair of anibots:

Upon injecting a weight change to increase the first anibot’s Right action to a large value (it really want to push right), the other anibot follows along—pushes left to compensate—changing the team behavior to the repeating pattern shown below.

Generating Behavior Patterns

It was expected that the process of anigraf generation would be a search in developer space for general classes of anibots that have the potential to conduct cooperative tasks. Then one must try to find examples of the anigraf configuration for the bots—which mental networks result in cooperative task execution—if any—and which ones do not work at all. The anigraf configuration consists of the graphs themselves and the starting weights, as well as various other parameters such as knowledge depth. However, after initial experimentation, it became apparent that resulting behavior patterns in an abstract sense are probably more important than concrete behavior results—i.e., you do not need to know the actual task or actions to generate potentially-useful anigrafs. The anigraf configuration is not the only important element in whether it will succeed at a task/environment. The anigraf can be assigned to make decisions at any n-level (i.e., ranging from low-level to high-level). So the mapping and routing of those decisions to the actual actions of the anibot in its environment also affects whether the anigraf is appropriate for a task/environment.

Future Investigation

Anibots as Interfaces Between Other Architectures

It may be feasible to turn an anibot into an interface. Existing software agents could add this interface in order to become collaborative agents. This interface, which could be a “black box,” would allow an arbitrary architecture to have a multi-agent arbitration mechanism. It could also allow heterogeneous agents to interact and act as a team on a mission if they have a shared standard for communication.

Evolutionarily Stable Strategies

Different and better methods for generating the graphs should be investigated. In the experiment described here, I basically was just trying to generate graphs that have certain kinds of top cycle patterns both alone and when combined with themselves (as a proxy). The act is like composing melodies so they generate harmony in polyphony, as in a canon. The patterns are affected by weights (which are dynamic in our system) and graph edges (which are static in our system). With proxy graphs, the patterns are also affected by the inter-graph edge patterns (“proxification” edges).

It may be useful to research evolving anigrafs for that work well with heterogeneous agents and how these evolutions and resulting anigrafs differ from those that work well with homogeneous agents. Homogeneous anibots which work in teams can be compared to animal symbiosis, e.g., aphids and ants [2]. Anibot behavior strategies can be viewed as ESSes for mutual cooperation [2].

Comparisons to nature may allow anibots to help investigate questions such as: do models of self appear before models of others or vice-versa? Can proxy agents be developed to serve the same roles as mirror neurons?


References
[1] W. Richards, Anigrafs: experiments in collective consciousness, 2007. Online: http://people.csail.mit.edu/whit/contents.html
[2] R. Dawkins, The Selfish Gene, Second Ed., 1989, Oxford University Press.
[3] V. Braitenberg, Vehicles: Experiments in Synthetic Psychology, 1984, MIT Press.
[4] J. Klein, Breve simulation environment: http://www.spiderland.org/s/

Tags: , , , , , , , , ,

2017: Postmortem

Posted in film, meta on December 27th, 2017 by Samuel Kenyon

I skipped a couple years, but here’s a new personal postmortem. If you are wondering, a “postmortem” in project management is a retrospective to figure out lessons learned. Postmortem articles were featured in the classic magazine Game Developer, where I learned of the concept.

red carpet at Newark International Film Festival

What Went Right

  • Finished my feature film directorial debut “Brute Sanity.”
    • I traveled around with the movie on the film festival “circuit.” It won a couple awards. (You can get more info here.)
    • Massive amounts of learning technical post-production skills (continuing from 2016.)
    • It was picked up for distribution. This led to even more work and learning…
  • Did another Boston 48-hour Film Project. This time, instead of just acting, I also assisted with the screenplay and casting.
  • Left tech job (writing robotics software). It was forced—but they gave us a severance, and it freed up my time to work on film stuff.
  • Started working on my film company Imaginary Danger Productions LLC.
  • Skied in the Rocky Mountains (Brighton Resort, specifically) for the first time. Easily found—backcountry of course—what was probably the most difficult skiing I’ve ever experienced.
  • Visited Atlanta for the first time, Salt Lake City for the first time, Newark NJ (which I’ve been to before but this time I was more immersed). Also went to Kansas City, the Cleveland area (first time in Ohio), the Detroit area, Washington DC, and New York City.
  • Got divorced from Emili.

Brighton Resort, Utah

What Went Wrong

  • My tech job employer, the Cambridge division of Bio-Rad, which was a continuation of a start-up company called GnuBIO, was shut down completely by the parent company.
  • Started doing job interviews. The reason I put this under “What Went Wrong” is that I shouldn’t have rushed into it so soon. I was caught up in the excitement, with recruiters bombarding me, and now I regret wasting time on this. Instead what I decided I needed to do is take a break for couple months from normal tech employment and work on my own projects.
  • Stretched my leg a bit too much during the aforementioned Brighton ski trip and had to do some physical therapy.
  • Got divorced—so you might say that the marriage “went wrong” but that depends on how you spin it. The relationship itself was a fantastic journey and a mere marriage-and-divorce does not sully that.

Sam and the Philip K. Dick robot at Escape Velocity in Washington DC

2014: Postmortem

Posted in film, meta on October 20th, 2015 by Samuel Kenyon

Oh no! I forgot to post a personal postmortem 1 for the year 2014 like I did for the previous year! Oh well, here it is ten months late.

What Went Right

  • Started a new day job at a biotech company called GnuBIO, now the skunkworks division of Bio-Rad. Essentially I write robotics code for microfluidics inventions that will ultimately contribute to human health improvement via diagnostics.
  • Made a short film based on my screenplay Enough to be Dangerous.
  • Got married to Emily. On Halloween. Proposal happened…on April Fool’s Day.
  • Visited Istanbul, Turkey.
  • Visited Philadelphia, including the Mütter Museum.
  • Moved to a smaller but better located apartment in Cambridge.
wedding dance to dubstep

wedding dance to dubstep

 

Istanbul

Istanbul

We had a few drinks with AI researcher Eray Özkural in Istanbul:

Eray Özkural, Samuel H. Kenyon, and Emily Durrant in Istanbul

Eray Özkural, Samuel H. Kenyon, and Emily Durrant in Istanbul

The Movie

I was able to kick my film Enough to be Dangerous into gear fairly quickly once I decided it should be done. Aside from writing and producing it, I also was the lead actor.

Enough to be Dangerous

Enough to be Dangerous

Making a film has all the same problems that a startup company does, although the boundaries between the “company” and the “product” can be different. Particularly in this case, my new company (called at the time “Subterfugue Films” (a horrible portmanteau)), is vaporous and all the resources existed for the “product”, which is the film itself. Recently (in 2015) I renamed my film company to Imaginary Danger Productions.

Enough to be Dangerous was finished under budget, although I went over-budget on film festival costs. It was accepted to various film festivals (see the official page for more info), so it was successful in that regard. I’d love to remake it as a full-length feature, however, as it really is uncomfortably compressed to fit into 35 minutes.

What Went Wrong

Startup

I co-founded a tech company called Glug, but within a few months decided to leave it (the company is now dissolved).

This startup turned out not to be ideal for me for various reasons, so I quit. Also at that time I realized I’d rather put all that startup energy into making my film.

The most important lesson learned is not to invest any money on incorporation or legal fees before you know if the product/company will even launch for real. Another thing I learned is a proposed new tech product should be able to garner followings from hundreds if not a thousand people (e.g. on mailing lists or social networks) even if those first thousand people aren’t the actual early adopters—it’s a crude measure of general interest.

Image Credits
– wedding photo by Tanya Rose

Notes

Tags:

The Ideal Film AI

Posted in film on February 18th, 2015 by Samuel Kenyon

This is prompted by Ben Bogart‘s question “What do you consider the most seminal representations of AI in cinema of all time?”

I think the best is yet to come. Ideally an AI (Artificial Intelligence) in a film would have two elements:

  1. The alien aspect: It’s not a human or some other animal (although it can be very similar).
  2. Some connection with humans (or a human), e.g. humanity created them for a job, or this particular human created this particular AI for some reason, etc. This is the difference between the screen character being just another sci-fi alien (extraterrestrial, previously-unknown terrestrial monster, et cetera).
cropped_Automata-crossing-the-river-of-time

Autómata (dir. Gabe Ibáñez)

 

Automata and Tron: Legacy both make meager attempts to show AI emerging and evolving and trying to figure out their own way that’s not quite the same as for humans.

The robot R2D2 (Star Wars) superficially meets these ideals: we know it’s intelligent, yet it doesn’t speak English or get subtitles. Its connection with humans however is not really used in any interesting way in the film (we don’t analyze the slavery of robots in Star Wars …at least I don’t). And if the history stories are true, R2D2 and C3PO are just metal copies of the peasants from Akira Kurosawa’s The Hidden Fortress.

fortress1

The Hidden Fortress (dir. Akira Kurosawa)

 

Tags: , ,