Project CHAMELEON

Introduction

Most robots are designed with a particular task or operating environment in mind, A robotic arm, for example, may be devloped around the requirmenets of a spcific manufacturing process, while a plaetary rover is designed according to the terrain and condiitons it is expected to counter. For examples the Mars Rovers are specifically designed to be able to travel through rocks and heavy slopes by having thicker wheels with straighter treads and more segements. This task-specific approach is effective when these conditions can be anticipated during the design process. Its limitation becomes apparent when the robot encounters something outside those assumptions. Since its morphology is fixed, there may be little scope for the robot to eb physically adapt when its existing configuration is no longer suitable.

Self-reconfiuration modular robotics (MSRR) provides an alternative to this fixed morphology appraoch. Rather than treating the robot as a single structure. SRMR systems cosist of multiple modules that can connect, disconnect and change their relative arrangement. A number of physical systems have demonstrated that this type of reconfiguration is feasible. ATRON, for isntance, investigated distributed reconfiguration within lattice structures, while CKBot and SMORES demonstrated alternative appraoches based on combinations of chain and lattice confgurations. M-Block took a different aproach, using magenetic connections and an internal flywheel to enable individual modles to move and recconect with one another. Collectively, these systems demonstrate that a robot can change its physical organisations during operation rather than remaining constrained to the morphology established during manufacture.

These are also exmaples of modular robots adapring their behaviour without requiring a central controller to explicitly determine the actions of every modules. Christensen, Schultz and Stoy (2013) demonstrated adaptation using a shared outcome signal, allowing a modular system to respond to changes including modular failure. Such work is relevant to CHAMELEON because it demonstrates how relatively simple modules can produce adaptive behaviour through decentralisied mechanisms. However, the adaptation considered is primarily behavioural; the question of how the robot should select its physical morphology remains seperate.

Project CHAMELEON builds on this distinction. The central question is whether a modular robot can select an appropriate physical configuration for a tast or environment that was not specified in advance, without being provided with a predefined target morphology. The project therefore treats morphology not simply as a property determined during the design stage, but as something that could potenntially emergy through the interation of individual modules, local information and feedback from the enviroment. The aim is to inestigate whether relitively simple modules can collectively reorganise in response to an unfamiliar situation and produce a structure that is functionally appropriate for the task at hand.

Background

Full disclosure — this isn't some idea I came up with out of nowhere. There's an actual field for this called self-reconfigurable modular robotics, and people have been building versions of it since the 2000s. Systems like CKBot, M-Blocks, SMORES and ATRON are the ones that keep coming up when I search this — little cube or lattice-shaped modules that can physically move around and connect to each other. It's still an active research area now, not some dead niche.

The thing I noticed reading through this stuff is that almost all of it assumes the system already knows what shape it's aiming for. You tell it ,esentially, "become this shape", and the modules figure out the choreography to get there, usually just by communicating with their neighbours rather than having one central brain bossing everything around. And honestly that part's already been solved pretty well ( decentralised systems can get shockingly close to the target shape using nothing but local rules and information from neighbouring modules)

So the gap I actually want to poke at is the bit before that: what if nobody tells the system what shape to become at all?

Research Direction

A robot shouldn't be stuck with the shape it happened to be built as.

The big, dramatic version of this question would be "can robots adapt to any environment," which is basically the whole field's founding question and way too big for a first project to actually answer. So I've been trying to narrow it down to something I could realistically simulate and get a real answer to, even a boring one. Current version:

Can a group of simple robotic modules figure out a physical structure to solve a task — without ever being told the target shape — using only what's around them (local sensing), talking to their neighbours, and knowing whether the last attempt worked or not?

Normal robotics goes roughly like this:

What I'm actually trying to explore instead:

A few questions I keep coming back to while reading around this — these aren't things I've answered yet, just the stuff sitting in my notes:

Initial Approach

Realistically, building an actual physical robot with dozens of moving, communicating modules is not a "first step"— it's a final-year-project for someone with a proper robotics lab, not something i can sensibly jump straight into in my room. So this is starting purely as simulation. If the idea doesn't even work on a screen, there's no point building it out of motors and metal.

The plan is to use simulation to test different module designs, different "rules" for how modules decide to move or connect, and different ways of measuring whether an attempt succeeded, before I even think about whether any of it is physically buildable. Right now I'm treating this less like "build the robot" and more like "find out if this idea survives contact with an actual test." The long-term goal is still to take the system beyond simulation and eventually build the modules. Right now though, im trying to figure out if this idea survives contact with an actual test.

• Reading up on existing modular robotic systems (CKBot, M-Blocks, etc.)
• Identifying where current approaches to adaptive and self-reconfigurable robotics actually struggles
• Sketching possible module designs — what can one module even sense, communicate and do?
• Working out what a useful simulation of the system would need to include
• Planning how different approaches could be tested and compared.

Example Scenario

Here's a made-up example of what I'm imagining, to make this less abstract. The simulated system runs into something it's never dealt with before:

Nobody told it "build a bridge." It has to land on that shape itself, based on what worked and what didn't. Whatever it comes up with, I'd want to actually check it against something, so probably:

Development Log

• Started reading into self-reconfigurable robotics as a field
• Went through where current adaptive robotics falls short
• Started planning what a simulation would actually need
• Looking into what algorithms/approaches other people have used
• Writing all of this down before I forget it, basically

Documentation