Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due

COM1005 Machines and Intelligence

Weeks 10-11 Lab Brief

Robotics & Layered Control Architectures

Changelog

Introduction

In this lab, you will explore layered control architectures and their applications in robotics.

The specific architecture you’ll implement draws inspiration from some of the well-known works in robotics and AI, such as Grey Walter’s Tortoise and Valentino Braitenberg’s Vehicles, as well as natural behaviours, like run-and-tumble and phototaxis observed in bacteria.

Objectives

00001. To be introduced to and implement a layered control architecture on a simulated robot.

00002. To observe and be able to link the behaviours produced by layered control architectures to those observed in nature.

00003. To be able to reason and suggest improvements to the base layered control architecture based on observations about the agent’s behaviour.

Before the lab

To prepare, review the following lecture slides:

· Robotics I, II and III

· MiRo Lab Introduction

Lab materials

You will be using MiRoCODE and the associated phototaxis world to program the layered control architecture.

Remember the following requirements for working with MiRoCODE:

· Firefox browser

· Eduroam + FortiClient VPN

Architecture Specification

Overview

The layered control architecture is implemented on a MiRo robot within MiRoCODE. For simplicity, we’ll refer to the robot running the model as Elowen.

Elowen’s behaviour in the environment can be likened to that of a bacterium such as E. coli. It seeks out nutrient clusters and exhibits run-and-tumble behaviour while also mimicking the photosynthetic ability of chloroplasts and demonstrating phototaxis.

Elowen operates using a layered control architecture, where sensor data is processed across multiple layers that determine the robot's actions. These layers are interconnected and can either inhibit or stimulate each other. Generally, the lower layers are more reactive but less adaptable, while the higher layers are more flexible but require longer processing times.

Programmatically, this means there is a main control loop that polls the sensors and then processes the layers iteratively in a fixed sequence, at some frequency.

Layer 1:  Metabolism

This is the base layer on which all other layers depend for their functioning. At each step, Elowen consumes energy and must actively seek ways to replenish it to remain operational. Elowen begins with an energy level of 100%, which represents the maximum capacity and cannot be exceeded.

All energy calculations happen in this layer. When the energy level reaches 0%, the run is stopped.

Energy expenditures are:

· Base Metabolic Rate (BMR): A fixed energy loss of 0.01% per step, independent of any other activities.

· Movement: Energy loss is directly proportional to velocity. For instance, moving at 0.2 m/s results in a 0.2% energy reduction per step.

· Dim Lighting: Being in areas with low brightness increases energy expenditure.

Energy replenishments are:

· Boosters (AprilTags): Each booster restores 25% of Elowen’s energy, but boosters are single-use only.

· Bright Lighting: Being in areas with high brightness restores energy.

Elowen's energy gain or loss due to lighting depends on the brightness level. The threshold brightness is set at 0.5; levels above this threshold restore energy, while levels below it cause energy depletion. This relationship is modelled as an arctangent function, with the specific values illustrated in the accompanying plot.

Layer 2:  Safety

Elowen operates in an environment containing cliffs and walls, which it must detect and avoid using its sonar and cliff sensors. Upon detecting a cliff or wall, Elowen should immediately stop moving. This layer overrides the ‘run’ behaviour  from the layer higher up.  The tumble mechanism in the yet higher layer will eventually help Elowen reorient itself to face away from the obstacle.

Layer 3:  Run (Phototaxis)

Elowen’s primary drive is to move forward, with her velocity determined by the overall brightness of her surroundings. This relationship is modelled as a piecewise non-monotonic function, as illustrated in the plot below.

Layer 4:  Tumble

The tumble involves a random change in the robot's facing direction, with the turn angle uniformly distributed between -180° and +180°. Elowen performs, on average, a tumble every 5 seconds (in simulator time) under normal conditions, which gives a tumble rate of λ = 0.2  (tumbles per second).

However, to actually implement this layer you will need to know the tumble rate per iteration. The nominal frequency of the Periodic Control Loop Block is 10 Hz, but in reality this can be slower due to the simulation environment and code complexity. Testing reveals that with fully implemented layers the code runs at about 5 iterations per second (5 Hz). However this can be different on different machines and might require adjustment.

You can use the Poisson probability distribution to calculate the probability of a tumble per iteration:

assuming k = 1 (representing one tumble event) and λ = 0.04 (tumbles per iteration, assuming control loop runs at 5Hz).

Layer 5:  Acquisition (AprilTags)

Six AprilTags are scattered throughout the environment, each with a unique ID ranging from 1 to 6. When Elowen comes within 1 meter or less of an AprilTag, a resource acquisition mode should be triggered. In this mode, Elowen must orient herself so that the AprilTag is  visible in both cameras.

Once properly aligned, Elowen receives an energy boost of 25%. However, each AprilTag is a single-use resource; once it has been ‘consumed’, it no longer provides an energy boost.

Task Description

Use the provided MiRoCODE template to implement the specified model, then proceed to the Lab Question Sheet to complete the assignment.

Submission details

This is an individual assignment. Each student must submit their own completed copy of the Lab Question Sheet along with the associated .mirocode file.

Use of any generative AI tools in the preparation of the solution to this work is not permitted.

Submissions should be made by 3:00 PM on Thursday, 12th December.

Marks and feedback will be provided approximately five weeks after the submission deadline, taking into account the holiday period.

In Week 12, you will have the chance to test your implementation on the physical MiRo robots. This session is optional and will not contribute to your mark.

Mark breakdown

Base Model [12p]

· [4p] Correct layer implementation as per specification (including math).

· [2p] Robust Elowen movement.

· [2p] Effective use of the robot’s expressive capabilities (cosmetic joints, LEDs, etc).

· [2p] Good coding style and code organisation (use of variables, functions, etc).

· [2p] Sensible trial data

Modified Model [8p]

· [4p] Description of a beneficial modification

· [4p] Evidence, including code.

COM1005 Machines and Intelligence        Ver 1.2        2024–2025