Version 1.3.0

Hazards, Recoil and Conflict Resolution

Version 1.3.0 introduces hazard detection, local recoil, priority signalling and conflict resolution, extending Octopus Controller's distributed control architecture beyond reaching, obstacle avoidance and grasping.

Previous releases established how a central controller could assign objectives while individual arms independently determined how to execute them. This release explores the next question:

What happens when local sensory information conflicts with an arm's current objective?

The simulation can now represent hazards that provoke avoidance or withdrawal, escalate significant threats to central control, and resolve competing intentions through explicit priority rules.

The central principle remains unchanged: local decisions should remain local wherever possible, with central intervention reserved for situations that require wider coordination.

What's New

1. Local Hazard Detection and Recoil

Hazards are introduced as a new type of environmental feature, distinct from physical obstacles.

• Physical obstacles represent impassable regions that constrain movement
• Hazards represent aversive regions that an arm can enter but should attempt to avoid

Individual arm segments detect hazards locally and adjust their movement without requiring the central controller to prescribe an avoidance manoeuvre.

Depending on hazard severity, an arm may alter its approach, recoil away from the hazard, temporarily interrupt reaching, and subsequently resume its original objective.

This introduces an important behavioural distinction: an arm can now deliberately move away from its assigned destination in response to local sensory information.

2. Hazard Escalation and Central Signalling

Hazard warnings may be escalated to the to the central controller, extending local hazard responses with a mechanism for communicating significant threats to central control.

Not every hazard requires intervention. The system distinguishes between hazards that can be handled locally and those serious enough to warrant escalation.

The signalling mechanism supports:

• Severity-dependent hazard reporting
• Escalation based on sustained exposure
• Priority-based communication with the central controller
• Withdrawal instructions in response to serious threats
• Clearance and recovery when reported hazards are no longer detected

This establishes a distinction between what an individual arm senses and what the central controller knows.

The central controller responds to significant reports rather than maintaining complete knowledge of every local environmental interaction.

3. Conflict Resolution and Behavioural Priorities

Explicit arbitration is required when multiple intentions or behavioural requirements cannot all be satisfied simultaneously.

The controller uses a transparent priority hierarchy:

Behaviour	Priority
Withdrawal	100
Local hazard avoidance	80
Maintain grip	60
Assigned reach	50
Incidental discovery	20
Idle	0

The new conflict-resolution mechanisms address several important situations.

Approach versus avoidance: An arm may temporarily suspend progress towards a target while responding to a hazard, without necessarily losing its original assignment.

Holding food versus withdrawal: Safety can override an existing grasp, causing an arm to release held food before withdrawing.

Competing arms: When multiple arms claim the same resource, deterministic arbitration selects a winner. Other arms yield while retaining their assignments.

Assigned task versus incidental discovery: An arm pursuing a specifically assigned food object does not abandon that task simply because it encounters another potential food source.

Critical hazard reports can also trigger withdrawal across all eight arms, demonstrating how a local observation can produce a coordinated, whole-system response.

Experimental Scenarios

The release introduces scenarios for observing and investigating the new behaviours, including:

Scenario	Demonstration
local-hazard.json	Local hazard detection, recoil and avoidance
hazard-escalation.json	Priority signalling and withdrawal
food-vs-danger.json	Safety taking precedence over an existing grasp
competing-arms.json	Arbitration between arms pursuing a shared resource
discovery-vs-task.json	Assigned objectives taking precedence over incidental discoveries
reef-forage-extended.json	Combined reaching, capture, hazard escalation and competing priorities

These scenarios make it possible to observe not just the resulting arm movements, but the decisions and competing intentions that produce them.

Distributed Control Architecture

The additions preserve the project's distinction between three levels of control:

1. Segment-level sensing and response — detecting nearby hazards and influencing local movement
2. Arm-level control — managing assigned objectives, recoil, avoidance, grasping and hazard reports
3. Central coordination — receiving significant reports, resolving resource conflicts and issuing withdrawal instructions when required

The central controller does not calculate individual joint movements or construct complete avoidance routes.

Instead, it determines which intentions should take precedence while individual arms continue to execute movement through their existing local control mechanisms.

This provides a framework for investigating when local autonomy is sufficient and when central arbitration becomes necessary.

Scope and Limitations

Octopus Controller remains a biologically inspired computational experiment, not a detailed physiological or neurological simulation.

Hazards represent computationally aversive regions rather than biological pain or injury. Recoil and withdrawal are implemented control behaviours, not models of actual octopus defensive physiology.

Similarly, conflict resolution currently uses explicit, deterministic rules rather than learning, reward optimisation or a biologically realistic decision-making process.

Whole-system withdrawal is represented through the coordinated retraction of individual arms; the central body remains fixed.

These simplifications are intentional. They keep the mechanisms observable and make it possible to investigate the consequences of different control rules.

Why This Release Matters

The original controllers demonstrated how local mechanisms could produce purposeful movement in response to centrally assigned intentions.

With hazards, escalation and conflict resolution, the system can now demonstrate how those intentions may be interrupted, challenged, prioritised and resumed.

An arm no longer simply asks:

How do I reach my target?

It must also respond to:

Should I continue towards my target, avoid danger, preserve an existing grasp, or yield to another arm?

The resulting simulation provides a richer experimental framework for exploring the relationship between local autonomy, communication and central coordination.

Version 1.2.0

Scenario Management Improvements

This release focuses on making scenario creation and management easier and more accessible, introducing the ability to create, name, save and load scenarios directly from the application's user interface.

Previously, creating or modifying scenarios required manually editing JSON files. With v1.2.0, scenarios can now be managed entirely within the application, making it much easier to experiment with different configurations.

What's new

• Scenario naming — Assign meaningful names to scenarios directly through the UI
• Clear field — Reset the field to a blank state, ready to create a new scenario
• Save current state — Save the current field configuration as a scenario without manually creating or editing JSON
• Load scenarios in-app — Load an existing scenario without having to leave the application

Improvements

These changes introduce a more natural workflow for working with scenarios:

1. Clear the field to start a new scenario
2. Configure the field as required
3. Give the scenario a meaningful name
4. Save the configuration for future use
5. Load saved scenarios directly within the application to continue experimenting

Version 1.1.0

Scenario Support

Version 1.1.0 introduces scenario support, allowing users to define, save and reproduce experimental configurations using JSON files.

Scenarios specify the initial conditions of a simulation, including the octopus's position, food objects, obstacles, individual arm targets and movement parameters.

Rather than prescribing a scripted sequence of movements, a scenario establishes an environment in which the existing distributed arm controllers operate independently.

This release also introduces a Behaviour Showcase scenario, demonstrating multiple control behaviours within a single simulation.

New Features

JSON-Based Scenarios

• Define simulation configurations using UTF-8 JSON files
• Specify the initial body position, food objects and circular obstacles
• Assign individual arm targets using coordinates or named food objects
• Configure shared arm parameters with optional per-arm overrides
• Support up to eight individually configured arms, with unassigned arms remaining idle
• Load scenarios directly from the command line

Scenario Playback and Reset

• Scenarios open paused, allowing their initial configuration to be inspected before execution
• Press Space to start or pause the simulation
• Press N to advance a single simulation step while paused
• Press D to restart the scenario from its original configuration, including arm poses, targets and environmental objects
• The scenario name is displayed in the application window title
• Existing interactive controls remain available

Scenario Validation

• Strict validation of JSON structure, field names, object references and parameter values
• Detection of duplicate keys, invalid arm assignments and unknown food references
• Clear error messages identifying invalid scenario configurations
• Validation takes place before the simulation window opens

Behaviour Showcase

This release includes scenarios/behaviour-showcase.json, a demonstration combining several existing controller capabilities in a single experimental environment.

The showcase illustrates:

• Multi-arm control: Four arms independently pursue different targets
• Local sensing: Contact with a food object produces sensory responses
• Obstacle avoidance: An arm negotiates an obstacle while reaching towards its target
• Grasping: Sustained contact initiates a grasping response, resulting in the capture and holding of a food object

The demonstration uses different arm movement parameters to make the individual behaviours easier to observe.

Because the scenario defines initial conditions rather than a timed sequence of commands, the demonstrated behaviours arise through the existing simulation controllers.

See the Behaviour Showcase Wiki page for instructions and a description of the demonstrated behaviours.

Why Scenario Support Matters

Scenario support makes it possible to reproduce experimental setups without manually configuring the simulation each time.

It also provides a foundation for systematic investigations, such as comparing arm configurations, testing obstacle arrangements and examining how movement parameters influence reaching and grasping.

Importantly, scenarios do not replace or bypass the existing movement, sensing, avoidance or grasping mechanisms. They provide a convenient way to configure the conditions under which those mechanisms operate.

Scope and Limitations

• Scenarios define initial conditions, not timed movement scripts or sequences of future commands
• Targets are resolved when the scenario loads and do not automatically track subsequently moved objects
• A valid scenario is not guaranteed to be physically achievable; unreachable targets and obstructed paths remain possible
• Scenario restart restores the original configuration held in memory. Changes made to the JSON file require the scenario to be reloaded

Summary

Octopus Controller v1.1.0 extends the simulation with a reusable scenario system, enabling configurable, repeatable experiments and demonstrations.

Version 1.0.0

The first public release of Octopus Controller, an experimental simulation exploring octopus-inspired distributed arm control, local sensing and object interaction.

Inspired by the remarkable organisation of the octopus nervous system, the project investigates how flexible arms can exhibit increasingly complex behaviours through a combination of movement control, local sensory feedback and environmental responsiveness.

Version 1.0.0 establishes the foundation for further experiments in biologically inspired control and embodied behaviour.

Features

Flexible Arm Control

• Simulation of flexible, multi-segment arms capable of changing curvature along their length
• Target-directed reaching and arm positioning
• Independent control of arm movement

Multi-Arm Coordination

• Simulation of a complete eight-arm configuration
• Simultaneous movement of multiple arms
• Foundation for experimenting with distributed control and coordination

Local Sensing

• Detection of nearby objects through local sensing mechanisms
• Arm responses influenced by environmental information
• Integration of sensory feedback with movement control

Obstacle Avoidance

• Detection of environmental obstacles
• Adaptation of arm movement to negotiate obstacles while reaching towards targets
• Exploration of environmentally responsive movement strategies

Grasping

• Target-directed reaching and object interaction
• Arm curling and positioning to produce grasping behaviour
• Foundation for future experiments involving tactile feedback and object manipulation

Demonstrations

Five demonstrations illustrate the development of the controller, from basic arm movement to more sophisticated interactions with the environment:

1. Single-Arm Controller — flexible movement towards a target
2. Multi-Arm Controller — independent movement of eight arms
3. Local Sensing — responses to nearby environmental objects
4. Obstacle Avoidance — movement adapted to environmental constraints
5. Grasping — reaching towards and grasping an object

Videos and explanations are available on the Demonstrations Wiki page.

Scope and Limitations

Octopus Controller is a biologically inspired computational experiment, not a detailed or biologically validated model of octopus neurophysiology.

The project explores principles of distributed control, sensory feedback and flexible movement without claiming to reproduce the precise neural mechanisms employed by living octopuses.

About This Release

Version 1.0.0 marks the first complete public milestone of the project, bringing together flexible movement, multi-arm control, environmental sensing, obstacle avoidance and grasping in a single experimental framework.

It establishes a baseline for exploring how progressively more complex behaviours can arise from the interaction of local control mechanisms and environmental feedback.