algorithmics for robot swarms

267
Algorithmics for Robot Swarms David Peleg The Weizmann Institute

Upload: others

Post on 03-Feb-2022

14 views

Category:

Documents


0 download

TRANSCRIPT

Algorithmics for Robot Swarms

David Peleg

The Weizmann Institute

Background

Mobile Robots

Units (robots) equipped with:

Motor Capabilities:Freely move on a two dimensional plane

Sensory Capabilities:Sense the positions of other robots

Mobile Robots - History

Grey Walter’s tortoise (1953)

Shakey - Stanford (1960’s)

Shannon’s electromechanical mouse - Theseus (1952)

Mobile Robots - Industrial

Mobile Robots - Military

DARPA challenge 2004: Unmanned vehicles must cross 150km of desert

GSR (1980’s)

T-800 (~2029AD)

Mobile Robots – Space Exploration

Sojourner - Mars Pathfinder mission (1997)

Europ. Space Agency (ESA):Automated transfer vehicle (~2005)

A long time ago in a galaxy far, far away…

Mobile Robots – Personal Use

Sony’s Asimo Sony’s Aibo

Friendly Robotics: - Vacuum cleaners- Lawn mowers

Various Means of Mobility

Flying

Insect-like

Marine

Reconfigurable Mobile Robots

Reconfigurable Mobile Robots

Robot Swarms

Robot Swarms

Swarm: Collection of independent, autonomously operating mobile robots

Motivating Metaphor: Insect Swarms

[Bees]

Motivating Metaphor: Insect Swarms

[Locust]

Characteristics of Robot Swarms

Typically, the robots in a swarm arevery smallvery simplevery limited in capabilities:

• weak energy resources• limited means of communication• Limited processing power

Why Multiple Robot Systems?

Can use several cheap & simple robots (rather than one complicated robot) - low total cost

Can solve tasks impossible for a single robot (e.g., sweep large regions)

Can perform risky / hard / tiresome / boring tasks in hazardous / harsh environments

Can tolerate the destruction of some robots

Robot Swarms - Exploration

Robot Swarms - Cleanup

Robot Swarms – Engine Cleanup

Robot Swarms - Robocup

Robot Swarms – Robocup (2)

Distributed Robot Algorithmics

Coordination & Control Issues

Large swarms must perform complex coordinated operations

In particular, movement management must ensure smooth performance and avoid collisions / bottlenecks

Most Work up to 90’s

Single robot or small robot team Centralized control Implementation and engineering

aspects (mobility, function) Coordination issues handled in

an ad-hoc / heuristic manner

[Fukuda +, 89], [Brooks, 85], [Mataric, 94], [Cao +, 95], [Durfee, 95], [Balch, Arkin, 98]

Such approaches - might be inadequate for large swarms

Need for Distributed Control Algorithms

General Aims of Study

Develop algorithms for distributed control

of a set of autonomous mobile robots

Given a task, what kind of local coordination

is necessary so that the robots can

accomplish it?Given a task, analyze minimum level of

(sensory, computational, motoric) capabilities that the robots must possess to collectively solve it (how "weak" can each robot be?)

Example Coordination Problems

• Gathering

• Alignment

• Pattern Formation

• Election

Example Coordination Problems

• Flocking

• Partitioning

• Searching / patrolling / …

• Spreading

Model

Common Model for Distributed Control Algorithms

Robots are independent Robots have limited capabilities Each robot operates in look-

compute-move cycles

General characteristics:

Initiated [Yamashita+, 96], [Suzuki+, 96]

Robot Operation Cycle

Compute

Move

Look

Robot Operation Cycle

Look:

• Use sensors to observe surroundings

• Take a snapshot of the world

• Identify all robots in your local coordinate system

Result: configuration C = {p1,…,pN} consisting of all robot coordinates

Robot Operation Cycle

Compute:

• Execute local algorithm ψ on configuration C

• Non-oblivious case: use also history

Result: Goal point pG

pG

Robot Operation Cycle

Move:

• Move towards the goal point pG

Implication: The robot movement might terminate before reaching pG

Restrictions: The distance a robot can move in one step is:• bounded above by some Smax>0• bounded below by some Smin>0,

unless the goal point is reached

Common Model Assumptions

Robots in the swarm are: homogeneous anonymous (no ID’s) dimensionless (can pass through each

other without noticing) without explicit communication mechanism oblivious (no memory / state)

Common Model Assumptions:Oblivious / Non-oblivious

Non-oblivious: remember history (e.g., the robot positions in the previous cycle, or all robot positions since the beginning of the computation)

Oblivious: lack memory, cannot record state

Why Study Oblivious (& Relatively Dumb) Robots?

Algorithms will work in a dynamic environment (where robots join/leave the system)

Algorithms are inherently self-stabilizing (i.e., withstand transient errors)

Algorithms that work correctly for weaker robots will work for stronger robots

Rad

Common Model Assumptions:Visibility Radius

Unlimited visibility: A robot sees all other robots

Limited visibility: A robot can see only robots within its visibility radius

r1

r2

x

y

Unit

Algorithm:1.2.3.….

Model Assumptions:Coordinate system

Possible Model Assumptions:Agreement on Coordinate system

x

y

x

y x

y

x

y

Total agreement

x

x

x

x

Agreement on one axis direction and orientation

Agreement on directions

x

y

x

y

x y

x

y

x

y

x

y

x

y

x

y

x

yx

y

Possible Model Assumptions:No Agreement

Common Model Assumptions (cont.)

Robots in the swarm do not have common coordinates, scale or orientation

Common Model Assumptions (cont.)

Robots in the swarm have:• Unlimited visibility• Perfect position measurements

(distances and angles)• Accurate computations with reals

(no calculation errors)• No failures

From the point of view of the “distributed computing” community:

• gives rise to interesting new communication model, based solely on positional / “geometric” information exchange

• differs in key aspects from traditional models• raises intriguing research problems

The new model

Modelling Time

Time is a critical aspect of every distributed system Synchronous? Asynchronous?

Common models for robot swarms: Fully synchronous (FSYNC) Semi-synchronous (SSYNC) Fully asynchronous (ASYNC)

Fully / Semi-Synchronous Model

Discrete time steps 0,1,2,...

Fully-synchronous model (FSYNC): At each time instant t, every robot ri is active

Semi-synchronous model (SSYNC): • At each time instant t,

every robot ri is either active or inactive• At least one active robot at each time instant• Every robot is active infinitely often

LOOK

COMPUTE

MOVE

Instantaneous Actions in FSYNC / SSYNC

pi(t)= Position of ri at time t

For all t0 : ri inactive pi(t+1) = pi(t) ri active pi(t+1) = pG

or some middle point on the

way to pG

pG = goal point returned by ψ

t

t+1

Modeling Robot Cycle in ASYNC

LOOK

COMPUTE

MOVE

WAIT

The robot moves towards the goal point pG (it might not reach it)

Movement is non-instantaneous

Assumptions: • A robot cannot wait indefinitely• A robot can see other robots while they move• A robot cannot distinguish between moving

and waiting robots

Modeling Robot Cycle in ASYNC

Timing Models - summary

ASYNC - Fully asynchronous [Flocchini et. Al, 1999]

Arbitrary & varying operation rates and delays

SSYNC - Semi-synchronous [Suzuki+Yamashita, 1996]

Fixed time cycles, but robots may be active / inactive

FSYNC - Fully synchronous [Suzuki+Yamashita, 1999]

Fixed time cycles, all robots active in every cycle

Comparison of Timing Models

SSYNC vs ASYNC

Problem P solvable in ASYNC

P is solvable also in SSYNC

Reason: Consider algorithm A for problem P

SSYNC = { possible runs of A in SSYNC }ASYNC = { possible runs of A in ASYNC }SSYNC ASYNC

• Algorithm A solves problem P in ASYNC must succeed in every run in ASYNC

succeeds also in every run in SSYNC

SSYNC vs ASYNC

Problem P solvable in SSYNC

P solvable also in FSYNC

FSYNC vs SSYNC

(same reasoning)

ℙFSYNC = Problems solvable in FSYNCℙSSYNC = Problems solvable in SSYNCℙASYNC = Problems solvable in ASYNC

Lemma: ℙASYNC ℙSSYNC ℙFSYNC

Comparison of Timing Models (cont)

Movement Awareness Problem (MA):Each robot must perform two tasks consecutively

T1: ri moves along an arbitrarily chosen directionT2: ri switches to doing something else

Strictness

Switching point: ri starts T2 only after for every other rj :• ri observes rj in at least 3 different positions,• rj observes ri in at least 3 different positions.

Note: Only applies in non-oblivious models

MA is not solvable in ASYNC

T1: I saw him once...

1st cycle

1st cycle

ri

MA is not solvable in ASYNC

2nd cycle

1st cycle

T1: I saw him twice...

ri

MA is not solvable in ASYNC

3rd cycle 1st cycle

T1: I saw him three times!

ri

MA is not solvable in ASYNC

T2??

1st cycle

Cannot distinguish between two possibilities:• rj is still in its 1st cycle saw me once,• rj is in its 3rd cycle saw me 3 different times…

ri3rd cycle

MA is solvable in SSYNC

Instantaneous actions in SSYNC mean:

if rj changes position once

then rj observes once

MA is solvable in SSYNC

Instantaneous actions in SSYNC mean:

if rj changes position 3 times

then rj observes 3 times

MA is solvable in SSYNC

Lemma: ℙASYNC ℙSSYNC

Review of Previous Results

Two Well-Studied Problems

• Gathering:

All robots should occupy a single point within finite number of steps

• Convergence: For every ε>0 there is a time tε

by which all robots are at distance at most ε of each other

Impossibility of gathering N=2 robots in SSYNC (hence also ASYNC) model [Suzuki, Yamashita,96]

Algorithms for gathering N>2 robots in SSYNC and ASYNC models [Suzuki, Yamashita, 96,

Cieliebak, Flocchini, Prencipe, Santoro, 03]

Review of Previous Results

Gathering with limited visibility Convergence algorithm for every N

[Ando, Oasa, Suzuki, Yamashita, 99]

Gathering algorithm with compass in ASYNC model

[Flocchini, Prencipe, Santoro, Widmayer, 96]

Previous Results – Cont.

Convergence via gravitational algorithms Center-of-gravity algorithm converges

in ASYNC model

[Cohen, Peleg, 04]

Previous Results – Cont.

Pattern formation Robots should arrange themselves in simple

geometric shapes (circle / square / line etc.) Several algorithms for exact formation or

convergence in ASYNC model

[Ando, Suzuki, Yamashita, 95; Sugihara, Suzuki, 96;

Suzuki, Yamashita, 96, 99; Defago, Konagaya, 02;

Flocchini, Prencipe, Santoro, Widmayer, 99;

Chatzigiannakis, Markou, Nikoletseas, 04;

Katreniak, 05]

Previous Results on Other Tasks

Flocking Algorithm allowing the robots to

follow a predefined leader

[Prencipe, 02; Gervasi, Prencipe, 04]

Previous Results – Cont.

Spreading / partitioning Algorithms allowing the robots to

spread evenly in a given region or partition themselves into groups

[Sugihara, Suzuki, 96; Cohen, Peleg, 06; Efrima, Peleg, 07]

Previous Results – Cont.

Wake-up (a.k.a. Freeze-Tag) Algorithms allowing one robot to

efficiently wake up all the others [Arkin, Bender, Fekete, Mitchell, Skutella, 02;

Sztainberg, Arkin, Bender, Mitchell, 02]

Previous Results – Cont.

The Gathering Problem

Initially the robots are in arbitrary

distinct positions

In finite time, they gather in the same place

The Gathering Problem

Istantaneous activities All robots are active in every round

The problem is easily solvable

Gathering in the FSYNC Model

Gathering in the FSYNC Model

Example solution:Go towards Center-of-Gravity (CoG)(a.k.a. center of mass / barycenter)

of the robot group

c=1N∑i=1

Np i

Gathering in the FSYNC Model

Analysis - sketch:• Once all robots are within distance smin of center of gravity – meet in one round

• Until then – in each round, robots get closer to center of gravity by at least smin

(complication: center of gravity can change from one round to the next…)

Gathering in SSYNC / ASYNC

More problematic…

Gathering: an easy solutionWeber Point [Weiszfeld,36] (a.k.a. Fermat / Torricelli point)

WP=argminp∈ℜ2

∑i

dist p , r i

Given r1,…,rn, the Weber point WP is the point minimizing the sum of distances to it:

Fact 1: The Weber point WP is unique

WPr2

r3

r4

r5

r1

r4

r2

r1

r5

r3

WP

Gathering to the Weber Point

Fact 2: WP is also the Weber Point of other points on the line [ri,WP]

WP=argminp∈ℜ2

∑i

dist p , r i

r4

r2

r1r5

r3

WP

Gathering to the Weber Point

WP=argminp∈ℜ2

∑i

dist p , r i

Fact 2: WP is also the Weber Point of other points on the line [ri,WP]

r4

r2

r1r5

r3

WP

Gathering to the Weber Point

WP=argminp∈ℜ2

∑i

dist p , r i

Fact 2: WP is also the Weber Point of other points on the line [ri,WP]

WP is invariant under robot movements toward it

WP

Gathering to the Weber Point

WP=argminp∈ℜ2

∑i

dist p , r i

r1

r2

r3

r5

r4

Fact 2: WP is also the Weber Point of other points on the line [ri,WP]

Proposed gathering algorithm: • Compute Weber point WP• Move Towards WP

Gathering to the Weber Point

Problem: WP is not computable… (even for N=5)

Gathering to the Weber Point

Gathering in the SSYNC Model

Thm 1 [Suzuki, Yamashita, 96;

Ando, Oasa, Suzuki, Yamashita, 99] :

For N=2, the problem is unsolvable

Gathering Two Robots - Illustrating the difficulty

In FSYNC model: Go to middle point.

Gathering Two Robots (2)

In SSYNC model: adversary might wake up only one robot each round.

achieves convergence but not gathering…

Gathering Two Robots (3)

Alternative ideas:

1. Each robot goes to other’s location?

Adversary will wake up both

(The robots have no dimension and cannot bump...)

Gathering Two Robots (4)

Alternative ideas:

2. One robot goes, one stays?

Adversary will wake up the staying.(besides, this solution is non-uniform)

Impossibility of Gathering Two Robots

Possible rules for robot:2. Go to other robot’s place

3. Stay in place

4. Go to some other (vacant) point.

r2r1

Impossibility of Gathering Two Robots

Possible rules for robot:2. Go to other robot’s place

3. Stay in place

4. Go to some other (vacant) point.

Adversarial responses:• If both robots apply rule 1: wake both.• Else: wake one robot that does not apply

rule 1.

r2r1

But …

Randomization can help…

Randomized Gathering of Two Robots

Possible rules for robot:2. Go to other robot’s place

3. Stay in place

Algorithm:2. Flip a fair coin.

3. Apply rule 1 or 2 accordingly.

Fact: In each round, the robots gather with probability at least 1/2.

Gathering in the SSYNC Model

Thm 2 [Suzuki, Yamashita, 96;

Ando, Oasa, Suzuki, Yamashita, 99] :

For N=3,4, the problem is solvable

Gathering in SSYNC, N=3

r2r1 r3

p p

r2

r3r1

p≥120° p

Procedure 3-Gather

ce r3r1

r2

ce= center of equi-angularity

Gathering in SSYNC, N=3

r3r1

r2

Gathering in SSYNC, N=3

∠r1cer2

Properties of ce :

r3r1

r2

Gathering in SSYNC, N=3

∠r1cer2 = ∠r2cer3

Properties of ce :

Gathering in SSYNC, N=3

∠r1cer2 = ∠r2cer3 = ∠r3cer1

r3r1

r2

⇒ Equi-angularity center is invariantunder movements towards it

Properties of ce :

r3r1

r2

ce

Gathering in SSYNC, N=3

ce r3r1

r2

r3r1

r2

r3r1

r2

r2r1 r3

p p

r2

r3

r1

p≥120° p

ce

Gathering in SSYNC, N=3

Procedure 3-Gather – summary:

Gathering in SSYNC (N≥3)

Multiplicity point: point p* where two or more robots reside

(Algorithm from [Agmon,Peleg,04] )

By assumption: • Initially, there are no multiplicity points

(namely, each robot is in a distinct location)• Robots can detect multiplicity

Gathering in SSYNC (N≥3)

Stage A: create a single multiplicity point p*

Stage B: move to p* along “free corridors”

Strategy: two stages

p*

Gathering in SSYNC (N≥3)

Note: If two or more multiplicity points occur,

then the problem becomes unsolvable

(cannot break symmetry, similar to N=2 case)

Gathering in SSYNC (N≥3)

Risk to avoid: multiplicity points can be created accidentally, if:

• the paths of two robots intersect, and

• the robots halt prematurely (after moving a distance ≥ Smin)

Basic tool: Smallest Enclosing Circle (SEC)

Stage A: Creating One Multiplicity Point

Fact: For a given point configuration, the SEC:

• is unique• is computable in

polynomial time• is invariant while the

points on it do not move

Stage A: Creating a Multiplicity Point

Recursive procedure Create_Mult

• If N=3, invoke 3-Gather• [N>3:]

Calculate Smallest Enclosing Circle (SEC)• Cint = # robots inside SEC

IN0 |Cint|= 0:

go to center of SEC

Stage A – Cont.

IN1 |Cint|= 1:

go to the internal robot

Stage A – Cont.

IN2 |Cint|= 2:

The two internal robots create one multiplicity point (MULT) (the external ones remain stationary)

Stage A – Cont.

• Compute the Voronoi partition of the robots on SEC

• Continue by case analysis:

How?

Stage A – Cont.

IN2(a):

internal robots do not share a cell:

move to center of SEC

Stage A – Cont.

IN2(b):

internal robots share one cell:

move to robot defining the cell

Stage A – Cont.

IN2(c):

internal robots share two cells:

inner robot: move to outer robot

outer robot: move to one of the defining robots

Stage A – Cont.

IN3 |Cint| ≥ 3:

invoke procedure recursively

for internal robots

(external robots remain stationary)

Flow of Execution

Creation of multiplicity point: DAG of transitions

Configuration P = {p1, …, pN}

IN0

IN2

IN1

IN3

MULT

Flow of Execution

Creation of multiplicity point: DAG of transitions

Configuration P = {p1, …, pN}

IN0

IN2

IN1

IN3

MULT

Flow of Execution

Creation of multiplicity point: DAG of transitions

Configuration P = {p1, …, pN}

IN0

IN2

IN1

IN3

MULT

Flow of Execution

Creation of multiplicity point: DAG of transitions

Configuration P = {p1, …, pN}

IN0

IN2

IN1

IN3

MULT

Flow of Execution

Creation of multiplicity point: DAG of transitions

Configuration P = {p1, …, pN}

IN0

IN2

IN1

IN3

MULT

Flow of Execution (cont.)

Note:

The trajectories of robots moving towards pG never intersect

robots will never create additional multiplicity points on their way to pG

Stage B: Going to Multiplicity Point

Procedure Go_To_Mult

If you have a free corridor:go to p*

If other robots block trajectory:Go counterclockwise 1/3 angle to closest robot

p*

*p

Illustration of Go_To_Mult

*p

1/3

1/3

Illustration of Go_To_Mult

Illustration of Go_To_Mult

*p

1/3

Recall: Complete asynchrony:• robots operate in different and variable rates• robots may have arbitrary wait periods

between cycles

Gathering in ASYNC

For N=3,4: The simple algorithms for the SSYNC model still work

Gathering in ASYNC

r3r1

r2

r3r1

r2

r2r1 r3

pp

r2

r3

r1

p≥120° p

ce

Gathering in ASYNC (N≥3)

Easier models: • Common coordinate system• Non-oblivious robots (even without

multiplicity detection) [Cieliebak, 04]

Gathering in ASYNC (N≥3)

Easier initial configurations: 2. bi-angular configuration

(particularly, regular N-gon)• robots do not form a regular

N-gon

α β

α

α

α ββ β

Note: The two cases cover all possibilities…

Difficulties

If initial configuration is symmetric....

General Algorithm!!

If initial configuration is asymmetric....

Difficulties

....after a while....

DifficultiesIn the ASYNC model....

Symmetric…

General Algorithm…

....hence, they might never gather!!!!

Difficulties

Initially: no multiplicities Eventually, some robots gather at a

point p The algorithm ensures that the

multiplicity point p is unique Subsequently, all robots move to p

[Cieliebak, Flocchini, Prencipe, Santoro, 03]

Gathering in ASYNC (N≥3)

Scheme overview:

• Algorithm handles bi-angular case separately• Algorithm ensures the biangular and general

procedures do not get “mixed up”• Decision process:

If ∃ multiplicity point: move towards itElse If biangular: move to centerElse elect some robots to gather

Gathering in ASYNC (N≥3)

Scheme overview (cont):

Gathering with Limited Visibility

Visibility Graph:

rad

Gathering with Limited Visibility

Necessary Condition: The initial visibility graph must be connected

Correctness Condition: The visibility graph must remain connected during the computation

Gathering with Limited Visibility

[Ando, Oasa, Suzuki,Yamashita, 99]

Solution in SSYNC

Provides only convergence

Solution assuming common knowledge on direction and orientation of both axes

[Flocchini, Prencipe, Santoro, Widmayer, 01]

Solution in ASYNC

General approach:• Robots move only if they are on the extreme left or top of their visible region

• The move: to the right / down

• internal robots - wait

Solution in ASYNC

When a robot sees other robots only below:

Solution in ASYNC

go down

When a robot sees other robots only to its right:

Solution in ASYNC

go right

When a robot sees robots to its right and below:

Solution in ASYNC

go diagonally

For any vertical axis y at distance d>0 from the rightmost robot, all robots that are initially to the left of y will pass y within a finite number of steps.

y y'

Rightmost robot

Solution in ASYNC

Once all the robots are on the rightmost vertical axis, they will gather to the lowest robot in a finite number of steps

Solution in ASYNC

Convergence via Center-of-Gravity

Algorithms

Convergence ViaCenter-of-Gravity Algorithms

[Cohen, Peleg, 04]

Central Point Algorithms

General approach: In each cycle, the robots:

• calculate some median position of the group • move towards that position.

Center-of-Gravity (CoG) Algorithms

Natural variant:Use the Center-of-Gravity (CoG)(a.k.a. center of mass / barycenter)of the robot group.

c [ t ]=1N∑i=1

Np i[ t ]

pi[t] = location of robot i at time t

ci[t] = CoG last calculated by robot i prior to time t

c[t] = True CoG at time t

Analyzing CoG Algorithm

In fully synchronous (FSYNC) model:

easy to analyze, as discussed before

Analyzing CoG Algorithm (cont)

In semi-synchronous (SSYNC) and asynchronous (ASYNC) models:

more involved.

Correctness Result (in ASYNC)

Thm: CoG algorithm achieves convergence in the asynchronous model for any number of robots

Proof method: Define some convergence measure and show that it decreases to 0.

Monotonicity of Convex Hull

Assume: Robots reside on x-axis. (Handle each axis separately)

H[t] = convex hull of N robot locations and N calculated CoG’s

Lemma: H[t] cannot increase in time.

Quantities

ϕ1 [ t ]=∑i=1

N∣c [ t ]−c i [ t ]∣

ϕ2[ t ]=∑i=1

N∣p i [ t ]−c i [ t ]∣

ϕ[ t ]=ϕ1 [ t ]ϕ2[ t ]

h [ t ]=∣H [ t ]∣ψ [ t ]=

ϕ[ t ]2N

h [ t ]

Monotonicity of Progress Measures

Lemma 1: φ , h and ψ are non-increasing functions of time.

Main Lemma

For every time t0

there exists a time t’>t0 such that

ψ [ t ' ]≤1− 1

8N2 ψ [t0]

Convergence Rate

Assumption:

during any time interval [t,t+1], every robot completes at least one cycle.

(for complexity analysis only, not for correctness proof)

Asynchronous Model (ASYNC)

Lemma: In any execution of CoG algorithm, over any O(N2) time interval, the convex hull of robot locations + CoG’s is halved (in each dimension separately).

Lemma: There exist executions of the CoG algorithm in which cN time is required to halve the convex hull of N robots in each dimension.

Fully synchronous model (FSYNC)

Lemma: In any execution of the CoG algorithm, robots achieve gathering in O(h[0]) time.

Semi-Synchronous Model (SSYNC)

Lemma: In any execution of CoG algorithm, over any O(N) time interval, the convex hull of robots + CoGs is halved (in each dimension separately).

Overcoming Robot Imperfections

Aspects of Fault-Tolerance

Two separate aspects:

Overcoming robot imperfections Overcoming robot malfunctions

Robot ImperfectionsIn practice: Robot distance / angle measurements

suffer inaccuracies range estimation in sonar sensors:

about 1% Accuracy Angular separation: about 3o

Robot movements are imprecise due to unstable power supply, friction and force control

Calculations are bounded-precision

Problematics of Calculation Errors

Correctness of many robot algorithms relies on basic Euclidean geometry properties.

Unfortunately, these properties are invalid when measurement / calculation errors occur.

Overcoming Measurement Errors

[Cohen, Peleg, 06]

Model: • Robot location estimation and movements

are imprecise• Imprecision bounded by accuracy parameter ε known at robot design stage.

• Measurement imprecisions affect distance / angle estimations

ε-precision

D = real distance to observed pointd = measured distance

Robot's distance estimation is ε-precise if (1- ε) d < D < (1+ ε) d

Similar definition for angle estimations

Impossibility Results

Thm: (1) Gathering is impossible (for any N>1) assuming inaccuracies in both distance and angle measurements, even

• in FSYNC model • when robots have unlimited memory• when robots are allowed to use randomness

Impossibility Results – Cont.

(2) Gathering is impossible for N=2 assuming inaccuracies only in distance measurements

(3) Deterministic convergence is impossible if angle measurement imprecision is large, even

• in FSYNC model • when robots have unlimited memory

Algorithmic Results

Thm: The gravitational algorithm:

• converges in FSYNC model for small (ε<0.5) distance / angle measurement imprecision

but

• fails to converge in ASYNC model for any distance measurement imprecision

Algorithmic Results (cont.)

Thm: Deterministic convergence in SSYNC model assuming small ( ε < 0.2 or so) distance and angle measurement imprecision

(by a “guarded” gravitational algorithm)

For robot i :

• Observe configuration

• Calculate vcogi , vector to measured center of

gravity• Let ρi = estimate for max possible error

between vcogi and actual CoG

• If |vcogi| ≤ ρi then stay in place

• else (|vcogi > ρi|) move to ci=(1- ρi/|vcog

i|) vcogi

Algorithm

Algorithm

Perceived CoG

Actual CoG

Motion by algorithm

ρi

Fault Tolerance

Fault Tolerance

Essential requirement for swarms: Fault-tolerant algorithms, which will succeed in performing their tasks despite the failure of some of the robots

Failure Models

Crash fault model: robots may suddenly stop functioning

Byzantine fault model: Robots may malfunction and disobey their protocol in arbitrary ways

Fault-Tolerant Recruiting[Yoshida, Masuzawa, Fujiwara, 97]

• Introduced fault tolerance in robot swarms• Dealt only with initial crash failures:

all crashes occurred before the start of the run

crashed robots do not recover• Assumed non-oblivious robots

(with unlimited memory)

Fault-Tolerant Recruiting

Task solved: ARSP Assuming at most k robots have crashed, the nonfaulty robots must form a team A of size |A|≥N-k.

Each non-faulty robot must know if it belongs to the team or not.

Fault-Tolerant Recruiting

Intuition: • A crashed robot will never move.• A non-faulty robot moves infinitely often.• So by watching other robots and noting which of them moved, one can identify the non-faulty ones.

Exercise 1:Devise a solution in the FSYNC model.

Solution:• make a “small” move• observe movements (position changes)

Fault-Tolerant Recruiting

• A = {robots that moved} (the rest crashed)

Q: Why “small” moves?A: To allow identification

of “matching”

Fault-Tolerant Recruiting

Exercise 2:Devise a solution in the SSYNC model.Difficulty:Some nonfaulty robots might not move due to being inactive in this round.Solution:Repeat process, gradually increasing A, until it is of size |A|≥N-k.Difficulty:Preventing additional (late) joiners?

Fault-Tolerant RecruitingThe main result [Yoshida, Masuzawa, Fujiwara, 97]:

In the asynchronous model

(complicated by the fact that robots operate without any coordination whatsoever)

Gathering: All nonfaulty robots must occupy a single point within a finite number of steps

Fault-Tolerant Gathering[Agmon, Peleg, 04]

The Adversary

For nonfaulty robot: Determines if active in the cycle

(“fairness”) Determines the distance it will move

in the cycle

For faulty robot: Determines the course of action in

the cycle (crash / Byzantine)

Gathering with Crash Faults

Problems with known algorithms: Depend on single multiplicity point -

easy to breach (in intersecting trajectories)

Depend on movement of k≤f robots – easy to freeze

Gathering in SSYNC(3,1)-Crash System

Procedure 3-Gathercrash:

Verify that a crash will not fail the algorithm

:AcutepG

:Obtuse pG

:CollinearpG

Multiplicity:

pG

Generalizations

More complex algorithm for N robots Algorithm for Byzantine faults

(assuming fewer than N/3 failures)

Gathering in SSYNC(N,1)-Crash System

Use same algorithm described before for SSYNC without failures

Idea: Robot trajectories never intersect, so robots never create a multiplicity point

Must verify that a crash will not fail the algorithm

Gathering in SSYNC(N,1)-Crash System

Reminder:

p*

Stage A: create a single multiplicity point p*

Stage B: move to p* along a “free corridor”

• IN0 |Cint|= 0: go to center of SEC

• IN1 |Cint|= 1: go to the internal robot

• IN2 |Cint|= 2: two internal robots create one MULT (external remain stationary):

• Compute the Voronoi partition of SEC

Stage A

IN2(a): internal robots don’t share a cell

IN2(b): internal robots share one cell

IN2(b): internal robots share two cells

Stage B

*p

1/3

1/3

Gathering in SSYNC(N,1)-Crash System

Thm: Gathering is possible

in SSYNC model in (N,1)-Crash system

Gathering with Byzantine Faults

Thm: Impossible to gather

in SSYNC / ASYNC model

in (3,1)-Byz system

We focus on fully synchronous (FSYNC) model

Problems with (N,f)-Byz System

Current algorithms rely on:• Single multiplicity point• Stationary robots in a multiplicity point• No separation of robots in a multiplicity point

Trivial solutions (e.g. center of gravity) don’t work

Center of gravity

Gathering in FSYNC(3,1)-Byz System

Procedure 3_Gather_Byz• If collinear: Go to mid robot.• Else: Go to intersection point of

angle bisectors.

Lemma: Nonfaulty robots decrease the distance between them in each cycle by at least c·Smin, for c>0

Achieves Gathering

Gathering in (N,f)-Byz System,f ≥ 1 and N ≥ 3f+1

Convex hull intersection: Hkint(P)

Intersection of all sets

Hull(P\{pi1, …, pik}), for 1≤k≤N, pijP

H1int

Nk

The algorithm

Compute the hull intersection Hfint

Q = set of vertices in Hfint

Set goal point pG center of gravity of Q

Procedure Gather_Byz

H1int

xpGQ

Justification

For finite family A of convex sets in ℝ2, |A|≥3 :

If every three sets of A have a common point

then there is a point common to all sets of A

Helly’s theorem for d=2:

Justification (cont.)Observe: Every 3 sets Hull(P\{pi1, …, pik}) have at least one intersection point (robot location)

P

≤k robots≤k

≤k|P|≥3k+1

Intersection is non-empty

≥1

Justification (cont.)

Cor:

The sets Hull(P\{pi1, …, pik}) have at least one common intersection point (by Helly’s theorem)

The set Q is nonempty

Justification (cont.)

The center of gravity is well-defined

pG is well-defined Let NF = set of non-faulty robots NF is one of the sets participating

in the intersection Hfint

pG is inside Hfint

pG is inside Hull(NF)

Justification (cont.)

The diameter of NF decreases by at least c·Smin in each cycle

The nonfaulty robots (NF) move towards a point inside Hull(NF)

The diameter of NF becomes 0 within finite time, thus all non-faulty robots gather

Gathering in FSYNC (N,f)-Byz System

Thm: Gathering is possible in FSYNC model in (N,f)-Byz systemwhen N ≥ 3f+1

Fault-tolerance of Gravitational Convergence

Transient failures: robots will converge by CoG algorithm following any number of transient errors

(due to obliviousness)

Fault-tolerance (cont.)

Crash failures:

If M < N-1 robots crash during execution, then remaining N-M robots will converge to center of gravity of crashed robots.

Flocking

Flocking

Flocking

LeaderFollowers

Followers recognize Leader

No Agreement on Local Axes

Unlimited Visibility

Leader acts independently (e.g., human driven)

Flocking (cont)

Flocking (cont)

Followers must converge to a (commonly known) pattern

Flocking (cont)

and (approximately) keep it

Flocking (cont)

Flocking (cont)

Assumptions

Followers: • do not know the path in advance• have no way to observe direction of

movement• have no common velocity

• Time spent on Look and Compute steps is negligible w.r.t. time spent on Move

History

• [Wang, 91]– Followers have observable identities– Fixed assignment to slots

• [Chen, Luh, 94]– Fixed geometric patterns (matrix)– Followers know the path in advance

• [Balch, Arkin, 98]– Followers know the path in advance

12

3

Necessary Conditions

Common unitOtherwise, the followers could scale the pattern instead of following the leader

Bounded speedsThe leader cannot be much faster than its followers

Followers may only form patterns that are symmetric w.r.t. leader’s movement direction

Algorithm[Gervasi+Prencipe,01]

Followers need a way to approximate the Leader’s movement direction

Estimated movement direction:Given by axis passing through baricenter of Leader’s positions and Followers’ position

Baricenter

Algorithm (cont)

Algorithm (cont)

S1

S2

Baricenter

1

2 3 4

Algorithm (cont)

S1

S2

Baricenter

1

2 3 4

1

2

Algorithm (cont)

S1

S2

Baricenter

1

23 4

1

2

1 2 3

1

2

3

Fleet Symmetry

The pattern must be symmetric w.r.t. the leader’s movement direction

Other patterns may be formed with more agreement (e.g., one axis)

Remark

Limits on the leader’s angular velocity

Real vs Estimated Heading

Baricenter

Real

Estimated

Real heading of the leader (and thus formation) may be different from estimated

Line (4 followers)

Wedge (6)

Spread (10)

Experimental Results

Random (2-8)

V-flock Project[Albocher, Bruckstein, Gordon, Leibovitz, 04]

V-flock Project

Considerations for V formation

• Aerodynamic considerations (reducing air resistance)

• Visibility considerations (increasing field of view)

V-flock Project

Hardware

• Rotating light sensor (indicates amount of light sensed)

• Odometer - measures rotation cycles• Engines• Mini light-bulb system• Programmable Lego Mindstorm RCX unit

("brain" system)

V-flock Project

V-flock Project

Robot rules for finding its place in the formation:

Zone 1 = Dangerous zone: (moving forward might result in collision)

Turn away and slow down

If you see your nearest neighbor in:

V-flock Project

Robot rules for finding its place in formation:

Zone 2 = Blocked view zone: Speed up a bit

If you see your nearest neighbor in:

V-flock Project

Robot rules for finding its place in formation:

Zone 3 = Good zone: Maintain position and speed

If you see your nearest neighbor in:

V-flock Project

Robot rules for finding its place in formation:

Zone 4 = Unhelpful zone: Slow down

If you see your nearest neighbor in:

V-flock Project

2

1

3 4

5

What will each robot do?

V-flock Project

2

1

3 4

5

4: maintain direction and speed (current leader)

V-flock Project

2

1

3 4

5

2: maintain direction and speed (3 in good zone)

V-flock Project

2

1

3 4

5

3: slow down (4 in unhelpful zone)

V-flock Project

2

1

3 4

5

1: slow and break left (2 in dangerous zone)

V-flock Project

2

1

3 4

5

5: speed up (chase leader 4)

V-flock Project

Failing case 1: Other robots out of site

V-flock Project

Failing case 2: cyclic configuration(unstable equilibrium)

Ant Robotics

Ant Robotics

Biological Inspiration

• Inspired by foraging behavior of ants• Ants find shortest paths from nest to food

source• Ants deposit pheromones along traveled path,

which is used by other ants to follow the trail• This kind of indirect communication via the

local environment is called stigmergy• Provides adaptability, robustness and

redundancy

Foraging Behavior of Ants

• Two ants start searching from the nest with equal probability of going on either path

Foraging Behavior of Ants

• The ant on the shorter path completes the round-trip faster

• The density of pheromone on the shorter path is higher (2 ant passes as opposed to 1)

Foraging Behavior of Ants

• The next ant takes the shorter route

Foraging Behavior of Ants

• Over many iterations, more ants use the path with higher pheromone level, thereby further reinforcing it

Foraging Behavior of Ants

• After some time, the shorter path is used almost exclusively

Foraging Behavior of Ants

• Simulating this technique leads to the algorithm of Ant Colony Optimization within the area of Swarm Intelligence in AI

Ant Colony Optimization

Conclusions and Future Directions

Conclusions

• Better understanding of the power and the limitations of the distributed control from an algorithmic point of view

• Development of provably correct and

efficient protocols

Future Directions

More accurate models for robot swarmsRealistic assumptions regarding resources

& capabilitiesCapturing inaccurate measurements,

movements & calculationsAdditional complexity measures (distance

traveled, number of turns?) Practical (local, simple, robust) algorithms Handling more complex tasks Fault tolerance

Problems With Common Model:

Incompatibility with practical state-of-the-art:

• Some overly pessimistic assumptions concerning robot weaknesses

• Some overly optimistic assumptions concerning robot capabilities

Future Direction: Better Models

Overly Pessimistic Weaknesses

Obliviousness Lack of common orientation Anonymity Lack of explicit communication

Original Motivation

Good reasons for studying weak robots:

• Explore border between attainable and unattainable under most extreme model:– weakest possible type of robots– harshest possible external environment

• Algorithms for weakest possible robots will work for any model

Reasons against:

• Leads to cumbersome / impractical algorithmic solutions

• Does not support modularity and multi-phase processes

Unlimited visibility Perfect measurements and

computations No failures Lack of dimensions

Overly Optimistic Strengths

Reasons against:

• Unrealistic expectations• Algorithms based on these

assumptions will fail in reality

Desirable Model Modifications

Introduce additional ingredients: some stable memory robot identification / signaling limited communication limited common orientation dimensional robots (taking collisions

into account)

THE ENDTHE END