Managing Swarms of Robots: From Centralized to ...

Managing Swarms of Robots: FromCentralized to Decentralized Scheduling

Daniel Graff, Reinhardt Karnapke

FG Kommunikations- und BetriebssystemeTechnische Universität Berlin

13. September 2018

OS Support for Mobile Robots

Set of heterogeneous devices(with different capabilities)

The Swarm

Daniel Graff (TU Berlin) Decentralized Scheduling 13. September 2018 1 / 20


Management, control and coordination by the operatingsystem

Swarm Runtime System

The Swarm

The OS



Multiple (distributed) applications executed (simultaneouslyon the “swarm”


Example: Exploration

USVUAVUGV

Virtual MovementObservation Spot

Coast-lineRough Terrain



USVUAVUGV

Virtual MovementObservation Spot


VirtualMovement



USVUAVUGV

Physical MovementObservation Spot



Types of Movement

DefinitionVirtual movement: “Logic” movement of applicationPhysical movement: Real physical movement


Application Model

Building blocksFlexible composition of actions at runtimeConnect input / output

ActionsConstrainable in space and timeE.g., take picture, measure temperature

ExecutionConcurrent / sequential execution of (in-)dependent actionsTransparent execution across node boundaries

c

b

a d e f

node 1 node 3node 2 node 4

application


Scheduling of ActionSuites

Input: ActionSuite as, dependency graph gd

Action a ∈ as = (g, tmin, tmax ,d)gd is a directed, acyclic graph

Output: Scheduled job (ja, j t) for each ai ∈ asja = (p, t , r)j t = [(x1, y1, t1), ..]

WorldStatic obstacles Os

Dynamic obstacles Om, f : T → R2


Determine Slot Candidate

Determine slot candidateEuclidean distance: s = ||~xai − ~xaj ||Overhead of detour: ∆s := (s1 + s2)− s12Select slot candidate with minimal detour

Temporal constraintstmin, tmax are action constraintst1, t2 define begin / end of free slot

1 2 3 4 5 6 7

12345

x

y r2r1

g

P

a1

a2a3

s1

s2

s12

Schedule a3

schedule new job a3

job a1 job a2

tmax

job a3move a1 a3 move a3 a2

tmin

job a1 job a2move a1 a2

t

t

t1 t2

Schedule of r2


Path PlannerComputes trajectory

.. from ~xa1 to ~xa3(s1)

.. from ~xa3 to ~xa2(s2)

Resulting problem is a Trajectory Planning Problem (TPP)Solution: Path-Velocity-Decomposition

Static Path Planning Problem (PPP)Dynamic Velocity Planning Problem (VPP)

Path Planner obtains input from the job schedulerloc: location candidate (P)slot : (r , [t1, t2])

1 2 3 4 5 6 7

12345

x

y r2r1

g

P

a1

a2a3

s1

s2

s12


Forbidden Regions

Compute possible collisions with dynamic obstacles andmark them as forbidden regionsOm crosses robot path πThe result is a forbidden region in s × t spacen robot segment and m segments of Om creates n ×m tiles

x

y

Om crosses π

s

t

tF

t2

t1

tI s1 s2 sFsI

Forbidden region

s

t

n

m

n × m tiles


Velocity Planning Problem (VPP)

Computes velocity profile along path πs × t-space shows forbidden regions (dynamic obstacles)Find time based mapping s : T → S, S = [sI , sF ] = [0,8]s(2) = 1 or s(2) = 4Extend to: ~xπ : T → ~x ⇔ ~xπ : (T → S)→ ~x

vmax > 2

1 2 3 4 5 6 7 8

1

2

3

4

5

6

7

8

s

tt2

(sI,tI)fr

ee s

lot

[t1, t 2

]

path length [sI, sF]

Intial with vmax = 2




1 2 3 4 5 6 7 8

1

2

3

4

5

6

7

8

s

t

vmax > 2

(sF,tF,1)(sF,tF,2)

(sF,tF,3)

(sF,tF,4)

(sI,tI)

s = sF

Graph Construction




1 2 3 4 5 6 7 8

1

2

3

4

5

6

7

8

s

t

vmax > 2

(sF,tF,4)

(sI,tI)

Shortest Path


Complexity and Scalability

VPP induces high complexityMeshing to obtain velocity graphCheck of visibility

→ Execution time depends on Om, πm, π (segments)planningHowever, scalability problem still remains

Very large worldsHuge amount of robots


Possible Solutions

GPGPU computing suitable for trajectory planningApproaches from autonomous driving, TP with time horizon→ Loose guarantees and predictability, deadlocksScalability→ Decentralized Approaches

Static ApproachDynamic Approach


Static Approach

Splitting the world into static regionsEach regions has its own schedulerScheduling decentralized and in parallel


Static Approach

Cross-boundary movement possible.. requires lockingFull locking→ degenerates to centralized version→ unlikely


Static Approach

~250 trajectory segments17 segments with cross-boundary movement≈ 93.2%


Dynamic ApproachRegions emerge dynamically based on scheduling requestsFormation of “scheduler groups”Run distributed and in parallelGetting destroyed after request


Dynamic Approach

Each group creates a region lockBounding box of groupIf overlap→ dependency (waiting) graphVariants

One node becomes schedulerAll nodes become schedulers (first one wins)All nodes become schedulers (consensus / majority voting)


Preliminary Results25 nodes: Core i3-6100U CPU @ 2.30GHz, dual coreTime: Centralized vs. decentralizedf (o), number of obstacles10,000 jobsMore obstacles create more path segments→ Complexity of forbidden regions increase

20

1750

1000

tim

e (

sec)

obstacles

1500

1250

750

500

250

00 10 30 40 50 60 70

decentralizedcentralized


Preliminary Results

25 nodes: Core i3-6100U CPU @ 2.30GHz, dual coreTime: Centralized vs. decentralizedf (r), region size10,000 jobs

0

50

100

150

200

tim

e (

sec)

250

region size200x200

300x300 2k x 2k1k x 1k

700x700500x500



Preliminary Results50 nodes: Core i3-6100U CPU @ 2.30GHz, dual coreAcceptance rate: Centralized vs. decentralizedf (n), number of nodesNon-linear increase of acceptance rate(De-)centralized approach has only little impact

20nodes

0 10 30 40 50

0.05

0

0.10

0.15

0.20

0.25

acc

epta

nce

rate


5k jobs

20nodes

0 10 30 40 50

0.02

0

0.04

0.06

0.08

0.10

acc

ep

tance

rate

0.12

0.14 decentralizedcentralized

10k jobs


Conclusion / Future Work

OS support for mobile robot swarmsTPP has high complexityAddress scalability by decentralization

Static approachDynamic approach

Locking vs non-lockingDistributed data structures: transfer only delta schedule

After schedulingOn request


Managing Swarms of Robots: From Centralized to ...

Documents

Transcript of Managing Swarms of Robots: From Centralized to ...