Skip to content
Dave Walker edited this page Oct 30, 2026 · 9 revisions

An octopus has eight extraordinarily flexible arms and an unusual nervous system, with substantial neural processing taking place outside its central brain. How, then, does it coordinate all those arms without prescribing every detail of their movement?

That question provided the starting point for Octopus Controller, a computational experiment exploring how individual arms can pursue objectives through local movement rules, sensory contact and responses to their surroundings.

The model is deliberately simplified. It is not an attempt to reproduce octopus neurophysiology, nor to claim that an octopus moves according to these particular algorithms.

Instead, it provides a way to investigate a broader question:

How much central control is necessary when the parts of a system can make useful adjustments locally?

Intention and Movement

Imagine asking one arm to reach a particular position.

That instruction describes an intention, but it says nothing about the angles of the arm's individual segments, how those segments should negotiate an obstacle, or what should happen if the arm encounters something unexpected.

In Octopus Controller, those responsibilities are separated.

A central controller gives an arm its objective, while the arm's local controller works out how its connected segments should move. Nearby obstacles can modify movement requests, hazards can provoke local recoil, and sustained contact with food can initiate a grasp without a separate central instruction.

The arrangement can be understood at three levels:

Level Responsibility Example
Central controller Assign objectives to arms and receive significant reports Ask Arm 3 to reach a position
Individual arm Manage its movement, contact, grasping and local behavioural state Continue reaching, recoil from a hazard or establish a grip
Neighbouring segments Exchange movement requests and obey local limits Ask the next segment towards the body for a different attachment position

The same arrangement applies to all eight arms. One arm can hold food while another reaches past an obstacle, another recoils from a hazard and several others remain idle. They operate independently within a shared environment, although the simulation still needs common rules for concerns such as ownership of captured food and conflicts between competing priorities.

flowchart TD
    Objective["High-level objective"] --> Central["Central controller"]
    Central --> Arm["Individual arm"]
    Arm --> Local["Local movement and sensing"]
    Local --> Movement["Constrained movement"]
    Environment["Food, obstacles and hazards"] --> Local
    Local --> Reports["Significant local reports"]
    Reports --> Central
    Central --> Arbitration["Conflict resolution when required"]
    Arbitration --> Arm
Loading

The diagram follows the flow of responsibility rather than every implementation detail. The important idea is that the central controller specifies what an arm should try to achieve, while the arm determines how to attempt it.

What Can the Controller Do?

The simulation combines a number of behaviours, building from movement towards increasingly rich interaction with the environment:

Behaviour Description
Flexible reaching Each arm consists of connected, fixed-length segments with limits on how sharply neighbouring segments can bend
Local control Movement requests pass between neighbouring segments rather than every joint independently aiming at the distant target
Independent arms Each of the eight arms maintains its own objective, geometry and activity state
Contact sensing Segments detect local contact with food and environmental features
Obstacle avoidance Nearby obstacles alter local movement, while a separate safety check rejects movements that would pass through solid geometry
Hazard response Hazardous regions remain physically accessible, but local detection can provoke avoidance or recoil
Hazard escalation Significant or sustained encounters can be reported beyond the arm and may request withdrawal
Conflict resolution Fixed priorities arbitrate incompatible safety responses, grips, shared targets and incidental discoveries
Grasping and carrying Sustained contact with food can establish a grip; the arm can then hold, carry, retract with or release the object

These capabilities are described in more detail throughout the Wiki.

Explore the Simulation

Reading about distributed control is one thing; watching the individual arms respond to a changing environment makes the idea considerably easier to investigate.

The desktop application and browser-based Octopus Explorer allow you to:

  • Assign destinations to individual arms
  • Inspect arm state and local sensing
  • Reposition food, obstacles and hazards
  • Change arm movement parameters
  • Pause the simulation
  • Advance it one step at a time
  • Load reproducible experimental scenarios

A few experiments worth trying:

  • Move one arm's target and see whether the other arms continue pursuing their own objectives
  • Change the number of segments, their length, bend limit or turning speed and observe how the character of the reach changes
  • Place food where only one segment touches it, then move it until two adjacent segments can maintain contact
  • Put an obstacle in the path of a reach and observe whether local steering can negotiate a route around it
  • Place a hazard between an arm and its target and compare the recoil with ordinary obstacle avoidance
  • Try carrying food through a gap that is wide enough for the arm but too narrow for the object
  • Create situations in which two arms compete for the same resource and observe which one yields

The Demonstrations page develops the controller's capabilities step by step, while Behaviour Showcase brings several of them together in a single reproducible experiment.

What the Simulation Does Not Attempt to Reproduce

The simulated octopus occupies a flat, two-dimensional world.

Its central body and arm attachment points remain fixed. Arm segments retain their lengths, and the geometry does not simulate muscle forces, tissue deformation or water resistance.

Contact sensing acts as a simplified stand-in for the far richer sensory capabilities of real octopus arms.

Grasping creates a rigid attachment once the model's contact conditions are met; it does not simulate sucker adhesion, gripping pressure, friction or continuous wrapping.

Arms can cross one another and the body because arm-to-arm collision handling is not currently included.

Local control also does not guarantee that a route will be found.

A target may be out of reach, an arm may be unable to bend sufficiently, an obstacle may leave it blocked, or a withdrawal request may be impossible to complete safely even though a different path might exist.

Hazards are computationally aversive regions rather than models of pain or subjective experience, and conflict resolution uses explicit fixed priorities rather than learned biological decision-making.

These are deliberate boundaries.

By keeping the rules relatively straightforward, the experiment makes it easier to see what local control achieves — and where it begins to need wider coordination.

Where to Go Next

A useful path through the documentation is:

  1. Central Controller
  2. Reach Controller and Arm Movement
  3. Hazards and Local Avoidance
  4. Conflict Resolution
  5. Demonstrations
  6. Behaviour Showcase
  7. Architecture

The Scenarios documentation provides the practical format for creating repeatable experiments of your own.

Clone this wiki locally