Inter
national
J
our
nal
of
Robotics
and
A
utomation
(IJRA)
V
ol.
8,
No.
4,
December
2019,
pp.
217
244
ISSN:
2089-4856,
DOI:
10.11591/ijra.v8i4.pp217-244
r
217
Concurr
ent
asynchr
onous
r
obotic
subsumption
using
actors
&
pr
omises
Ratnesh
Sri
v
asta
v
1
,
G.
C.
Nandi
2
,
Rohit
Shukla
3
,
Harsh
V
erma
4
1,3,4
Department
of
Information
T
echnology
,
Colle
ge
of
T
echnology
,
P
antnag
ar
4
Indian
Institute
of
Information
T
echnology
,
Allahabad
Article
Inf
o
Article
history:
Recei
v
ed
Jun
9,
2019
Re
vised
Aug
20,
2019
Accepted
Sep
11,
2019
K
eyw
ords:
Actor
Concurrenc
y
Promise
Petrinet
Player
Stage
Subsumption
ABSTRA
CT
F
ascinated
with
robotics
open
source
inte
grated
components
MARIE
[1],
R
OS
[2]
PLA
YER/ST
A
GE
[3]
and
CARMEN
[4]
are
a
v
ail
able
in
the
field
of
robotics
application.
W
e
aim
at
de
v
eloping
an
asynchronous
concurrent
robotics
application
based
on
subsumption
[5]
architecture
using
PLA
YER/ST
A
GE
and
already
freely
a
v
ailable
services
on
the
internet.
W
e
used
w
anderer
and
w
all
follo
wer
services
embedded
inside
an
actor
[6]
[7]
and
inte
grated
these
services
to
tw
o
dif
ferent
robots
of
same
configurations
in
our
promise
based
frame
w
ork
that
pro
vides
actor
as
a
service.
The
tw
o
robots
switch
their
services
based
on
color
detected
(red,green,blue)
during
their
mo
v
ement
in
an
en
vironment
asynchronously
.
Using
actor
as
a
service
fills
the
g
ap
of
SO
A
[8]
&
ED
A
[9]
by
pro
viding
synchronous
and
asynchronous
support
for
communication.
W
e
measured
the
performance
of
time
tak
en
in
completion
of
services
in
promise
[10]
based
implementation,
synchronous
and
asynchronous
callback
[11]
based
implementation.
W
e
de
v
eloped
a
model
to
pro
v
e
deadlock
freeness
in
our
inte
grated
architecture
using
petrinet
[12]
interf
ace
composition.
W
e
ha
v
e
also
been
able
to
justify
that
component
int
e
grated
on
promise
based
frame
w
ork
tak
es
less
time
in
s
ervice
completion
than
synchronous
and
asynchronous
callback
based
services.
Copyright
c
2019
Insitute
of
Advanced
Engineeering
and
Science
.
All
rights
r
eserved.
Corresponding
A
uthor:
Name:
Ratnesh
Sri
v
asta
v
Af
filiation:
Assistant
Professor
Address:
Department
of
Information
T
echnology
,
Colle
ge
of
T
echnology
,
P
antnag
ar
Phone:
+91-9458359031
Email:
write2ratnesh@gmail.com
1.
INTR
ODUCTION
F
or
the
e
v
aluation
of
the
field,
it
is
required
to
inte
grate
a
v
ailable
services
so
that
comple
x
syst
ems
can
be
b
uilt
upon
these
a
v
ailable
services
without
w
asting
time
in
code
replications.
Components
are
b
uilt
independently
follo
wing
an
o
wn
set
of
protocols
and
communications
strate
gies,
inte
grating
these
together
is
not
a
tri
vial
task.
This
is
also
f
a
v
ored
because
services
that
are
well
tested
and
deb
ugged
can
be
reused.
Proposed
Architecture
is
implemented
using
principles
of
Service
Oriented
Architecture(SO
A)
&
Ev
ent
Dri
v
en
Architecture(ED
A).
W
e
ha
v
e
used
Service
Oriented
Actors
which
fulfill
the
g
ap
of
SO
A
and
ED
A
by
e
xposing
services
as
actors
and
pro
viding
asynchronous
communication.
Here
an
actor
containi
ng
a
list
of
robotic
services
are
e
xposed
and
used
for
communication
by
another
client
actors.
Actor
&
Promise
is
used
to
f
acilitate
asynchronous
concurrent
communication
using
promise
and
maintains
the
state
of
messages
using
actors.
W
e
ha
v
e
de
v
eloped
an
e
xtension
of
actor
model
discussed
in
[13]
and
pro
vided
an
abstraction
of
promises
to
accept
and
deli
v
er
concurrent
request
and
response.
The
service
oriented
actor
pro
vides
services
which
ha
v
e
return
type
either
v
oid
or
promise.
T
w
o
actors
communicate
with
each
other
by
implicit
message
passing.
None
of
J
ournal
homepage:
http://iaescor
e
.com/journals/inde
x.php/IJRA
Evaluation Warning : The document was created with Spire.PDF for Python.
218
r
ISSN:
2089-4856
the
other
actor
-based
frame
w
ork
for
Ja
v
a
de
v
eloped
earlier
supports
promises
and
implicit
message
passing
mechanism
as
the
y
are
de
v
eloped
on
an
older
v
ersion
of
Ja
v
a
8.0.
While
de
v
eloping
the
application
we
ha
v
e
k
ept
in
mind
that
inte
grated
services
should
be
cost
e
f
ficient
and
easy
.
Moreo
v
er
,
architecture
should
be
fle
xible
enough
to
inte
grate
modified
and
ne
w
service
without
obsoleting
or
reb
uilding
the
architecture
[14].
Such
inte
gration
should
not
be
too
comple
x.
Inte
grating
ne
w
service
to
architecture
should
not
in
v
olv
e
reb
uilding
whole
archite
cture
ag
ain
thus
service
can
be
connected
on
the
fly
to
the
architecture.
If
service
is
on
the
host
computer
,
it
is
being
in
v
ok
ed
from
the
same
host
and
if
not,
service
is
requested
from
the
host
ha
ving
that
service.
In
case,
if
a
service
is
not
present
then
system
should
terminate
gracefully
with
proper
error
messages
so
that
user
can
diagnose
the
problem
with
the
application
created.
SO
A
based
architectural
concept
uses
description
language
to
define
the
function
and
services
of
the
component
interf
aces
to
be
disco
v
ered
o
v
er
the
netw
ork.
SO
A
f
acilitates
isolation
practice
of
softw
are
de
v
elopment.
Earlier
SILO
[15]
based
approach
had
been
inef
ficient
where
same
functionalities
were
being
de
v
eloped,
deplo
yed
and
maintained
multiple
times
by
other
or
g
anizations
refer
to
Figure
1
and
2.
Figure
1.
SILO
Vs
SO
A
Figure
2.
Request/Reply
Mechanism
in
SO
A
Gartner
,
in
2003
proposed
a
ne
w
design
paradigm
based
on
e
v
ents
using
publisher/subscriber
pattern
as
e
v
ent-dri
v
en
architecture(ED
A).
ED
A
is
not
a
replacement
of
SO
A
b
ut
complements
SO
A
by
asynchronous
message
communication
than
request/reply
used
in
SO
A.
Ev
ery
actor
writes
their
messages
to
other
actor’
s
mailbox
for
sending
their
request
to
be
processed.
The
response
sent
by
another
actor
is
written
back
to
callback
queue
of
the
actors.
Ev
ery
actor
reads
its
mailbox
queue
after
reading
the
messages
of
its
callback
queue.
Finally
,
each
actor
is
copied
to
global
actor
space
of
a
single
thread.
Thus
w
orks
as
a
single
t
hreaded
model
and
each
actor
may
w
ork
as
publisher
and
subscriber
.
W
e
are
using
our
actor
-based
frame
w
ork
as
sho
wn
in
Figure
3,
it
uses
dif
ferent
actors
with
their
mailbox
and
callback
queue.
Int
J
Rob
&
Autom,
V
ol.
8,
No.
4,
December
2019
:
217
–
244
Evaluation Warning : The document was created with Spire.PDF for Python.
Int
J
Rob
&
Autom
ISSN:
2089-4856
r
219
Figure
3.
Request/Reply
in
actor
-based
frame
w
ork
This
paper
is
or
g
anized
as
follo
wed:
section
II
introduces
the
implementation
archit
ecture,
section
III
m
odels
services
and
discuss
the
challenges
and
implementation
details
of
subsumption
architecture.
Section
IV
discuss
the
performance
e
v
aluation
of
services
on
synchronous
vs.
asynchronous
using
callback
vs.
asynchronous
using
promises,
section
V
deals
with
v
erification
of
deadlock
in
the
composed
system
using
Petri
net
model
and
finally
section
VI
introduces
conclusion
and
future
w
ork.
2.
IMPLEMENT
A
TION
ARCHITECTURE
Our
architecture
inte
grates
loosely
coupled
components
based
on
Service
Oriented
Actors.
An
application
needs
to
be
de
v
eloped
using
the
functionalities
pro
vided
by
dif
ferent
components.
A
single
component
may
pro
vide
more
than
one
functionality
which
may
or
may
not
interrelated,
such
as
audio
and
video
processing
or
collision
a
v
oidance
and
path
planning.
Further
,
it’
s
possible
that
these
packages
are
not
present
on
the
same
machine
hence
creating
a
distrib
uted
en
vironment.
At
the
highest
le
v
el
of
abstraction,
the
proposed
architecture
will
look
as
illustrated
in
Figure
4.
Figure
4.
High
le
v
el
abstraction
of
Application
Concurr
ent
async
hr
onous
r
obotic
subsumption
using
actor
s
&
pr
omises
(Ratnesh
Srivastav)
Evaluation Warning : The document was created with Spire.PDF for Python.
220
r
ISSN:
2089-4856
Proposed
architecture
can
be
understood
from
the
follo
wing
tw
o
perspecti
v
es:
A.
Abstraction
Layers
B.
Component
Frame
w
ork
2.1.
Abstraction
Lay
ers
T
o
pro
vide
multiple
le
v
els
of
abstraction
three
layers
are
defined
in
proposed
architecture
[16].
Each
layer
pro
vides
the
certain
set
of
functions
to
the
layer
abo
v
e
it.
The
three
layers
are
illustrated
in
Figure
5.
Figure
5.
Dif
ferent
Layers
of
Architecture
2.1.1.
Ser
vice
Lay
er
It
is
the
lo
west
layer
where
the
services
reside.
This
layer
is
also
the
core
layer
ha
ving
all
the
functionalities
required
by
the
application
need
to
be
de
v
eloped.
Each
service
is
nothing
b
ut
functionality
that
a
component
pro
vides
[17].
All
the
components
inte
grated
are
an
inte
gral
part
of
the
Service
Layer
.
These
components
may
pro
vide
much
functionality
.
These
packages
may
be
heterogeneous,
b
uilt
in
dif
ferent
programming
l
angu
a
ges,
using
dif
ferent
communication
protocols
and
may
present
on
dif
ferent
machines.
Hence
in
SO
A
’
s
terminology
Service
layer
is
a
collection
of
Service
Pro
viders.
2.1.2.
Communication
Lay
er
This
layer
is
present
abo
v
e
Service
layer
and
responsible
for
all
types
of
communication
between
the
services
and
application.
This
layer
defines
the
communication
mechanism,
strate
gies,
and
protocol.
The
communication
mechanisms
used
are
publish/subscribe
and
request/reply
[18].
2.1.3.
A
pplication
Lay
er
This
layer
sits
right
abo
v
e
Communication
Layer
.
The
user
interacts
with
this
layer
.
It
pro
vides
functions
lik
e
service
disco
v
ery
,
service
in
v
ocation
and
synchronization
between
services.
2.2.
Component
Framew
ork
Proposed
architecture
composed
of
dif
ferent
b
uilding
blocks
.
These
blocks
are
services,
interf
aces,
b
us,
brok
er
a
n
d
application.
These
b
uilding
blocks
are
defined
belo
w
in
Figure
6,
which
sho
ws
component
together
with
the
interf
ace
internal
w
orking.
2.2.1.
Ser
vice
Each
of
the
robotics
components
can
be
treated
as
the
service.
The
application
requires
these
s
ervices
to
perform
the
designated
task.
A
service
may
pro
vide
man
y
functionalities
lik
e
na
vig
ation
and
path
planning.
Int
J
Rob
&
Autom,
V
ol.
8,
No.
4,
December
2019
:
217
–
244
Evaluation Warning : The document was created with Spire.PDF for Python.
Int
J
Rob
&
Autom
ISSN:
2089-4856
r
221
Figure
6.
Interf
ace
2.2.2.
Interfaces
The
interf
ace
is
component
specific
that
mak
es
component
compatible
with
architecture.
Such
an
interf
ace
can
be
considered
as
middle
w
are
between
architecture
and
component.
All
the
communications
between
component
and
architecture
occur
through
the
interf
ace
only
.
All
the
components
need
to
be
connected,
the
y
must
ha
v
e
an
interf
ace.
If
a
ne
w
component
needs
to
be
connected
then
an
interf
ace
is
required
according
to
requirement
of
that
component.
De
v
eloping
an
interf
ace
requires
the
deep
study
of
a
component
to
be
connected
for
the
insight
kno
wledge
of
communication
protocols,
data
formats,
and
robotics
standards.
Interf
ace
has
dif
ferent
units
as
listed
belo
w:
2.2.2.1.
Component
Communication
Unit
(CCU)
This
unit
communicates
with
the
component,
more
precisely
with
the
service
in
which
an
applic
ation
is
interested.
CCU
supports
both
control
signal
and
t
he
data
signal.
Control
signals
ar
e
responsible
for
in
v
oking
and
termination
of
required
service.
Data
signals
are
for
the
transfer
of
service
specific
data.
2.2.2.2.
Data
Con
v
ersion
Unit
(DCU)
Robotics
packages
are
data
spec
ific.
The
y
require
the
data
in
parti
cular
format
and
type.
This
unit
is
responsible
for
con
v
erting
data
from
application-specific
data
to
service
specific
data
and
vice
v
ersa.
This
data
is
read
and
written
to
the
b
uf
fer
b
uilt
inside
DCU
for
pro
viding
latenc
y
.
2.2.2.3.
Bus
Communication
Unit
(BCU)
It
is
responsible
for
communication
between
interf
ace
and
b
us
and
vice
v
ersa.
2.2.3.
Bus
The
b
us
is
a
messaging
infrastructure
to
allo
w
dif
ferent
systems
to
communicate
through
shared
set
of
interf
aces.
This
is
analogous
to
b
us
in
a
computer
system
which
serv
es
as
the
focal
point
for
communication
between
CPU,
Main
memory
,
and
peripherals.
Messages
may
be
data
messages
or
control
messages.
Control
messages
enable
managing
services
while
data
messages
are
service
specific
data
that
is
input
and
output
data
of
services.
2.2.4.
Br
ok
er
It
synchronizes
dif
ferent
services.
The
duty
of
the
brok
er/arbitrator
is
to
disco
v
er
services
required
for
the
application
to
w
ork.
F
or
this
record
of
services
are
maintained
for
rapid
service
disco
v
ery
.
This
also
in
v
olv
es
in
v
oking
the
service
in
case
service
is
not
running.
Concurr
ent
async
hr
onous
r
obotic
subsumption
using
actor
s
&
pr
omises
(Ratnesh
Srivastav)
Evaluation Warning : The document was created with Spire.PDF for Python.
222
r
ISSN:
2089-4856
3.
IMPLEMENT
A
TION
DET
AILS
Problem
Statement:
There
are
tw
o
robots
which
we
need
to
run
asynchronously
from
a
single
JVM.
W
e
need
to
implement
subsumption
of
the
services
by
using
dif
ferent
colors.
There
are
tw
o
main
services
(w
all
follo
wer
and
space
w
anderer)
which
can
be
run
on
an
y
of
the
robots.
These
robots
are
equipped
with
sonar
,
position2d,
and
blob
finder
se
nsors.
W
e
w
ant
to
implement
this
subsumption
architecture
on
promise
based
asynchronous
frame
w
ork
by
measuring
the
processing
time
of
services
running
asynchronously
.
W
e
ha
v
e
an
actor
as
a
service
pro
vider
for
pro
viding
asynchronous
services
w
all
follo
wer
and
space
w
anderer
.
T
w
o
robots
(robot1
and
robot2)
as
an
actor
using
or
switching
these
services
based
on
the
color
detection.
An
actor
as
an
arbitrator
is
used
to
switch
service
from
one
robot
to
another
,
based
on
the
color
detection.
The
challenges
in
the
implementation
are:
[i]
Ho
w
to
ensure
required
sensor
data
is
ready
before
in
v
oking
the
service?
[ii]
T
o
define
a
rule
to
switch
services
from
one
robot
to
other
based
on
the
color
detection.
[iii]
Starting
and
stopping
services
running
on
dif
ferent
robots
asynchronously
based
on
color
detected.
[i
v]
Ho
w
to
update
the
color
detected
by
a
robot
at
the
run
time
to
the
main
code?
[v]
Ho
w
to
model
a
system
which
has
N
number
of
services
running
on
N
dif
ferent
robots
detecting
N
number
of
dif
ferent
colors?
[vi]
Ho
w
to
v
erify
that
inte
grated
components
do
not
produce
an
y
deadlock?
W
e
ha
v
e
tw
o
robots:
1.
Robot1
(id
=
0,
port
6665,
color
orange)
Sensors
i.
Sonar
sensor
(distance
with
the
obstacles)
ii.
Position2d
(used
to
control
the
robot
mo
v
ements)
iii.
Blob
finder
(used
to
detect
the
color
obstacles
in
range)
and
2.
Robot2
(id
=
1,
port
6665,
color
black)
Sensors
i.
Sonar
sensor
ii.
Position2d
iii.
Blob
finder
The
y
are
connected
with
PLA
YER
serv
er
for
transmitting
and
recei
ving
data
on
the
netw
ork
and
the
simulation
en
vironment
is
pro
vided
by
ST
A
GE.
The
details
of
the
tw
o
services
are:
3.1.
W
all
f
ollo
wer
ser
vice
In
this
service,
first,
the
connection
is
established
with
the
robot.
After
connection,
the
sonar
v
alues
are
check
ed
if
the
y
are
ready
or
not.
When
sonar
v
alues
are
ready
,
these
v
alues
are
used
to
find
the
distance
of
the
obstacles
in
front
and
left
side.
First,
the
robot
is
aligned
to
the
left
w
all
then
the
robot
is
made
to
follo
w
the
w
all.
The
logic
behind
alignment
with
the
w
all
and
follo
w
the
w
all
is
written
separately
.
Both
the
codes
are
dif
ferentiated
by
a
temporary
(temp)
v
ariable.
First,
the
robot
left
side
is
aligned
with
the
w
all
(T
able
1).
When
the
robot
left
side
is
aligned
with
the
w
all,
the
v
alue
of
the
temporary
(temp)
v
ariable
is
changed
to
0
which
causes
second
part
of
the
code
to
run
i.e.
follo
w
the
w
all.
The
logic
behind
getting
the
w
all
aligned
to
its
left
side
is
that
the
robot
will
mo
v
e
forw
ard
until
its
left
side
sonar
or
front
side
sonar
detects
an
y
obstacle.
Max
w
all
threshold
=
0.4
cm
Min
w
all
threshold
=
0.3
cm
x:
translational
speed
&
y:
angular
speed
(radian/sec)
If
none
of
these
condi
tions
is
satisfied
then
our
robot
detected
the
w
all
to
be
follo
wed
and
conditions
in
T
able
2
are
check
ed.
This
phase
is
kno
wn
as
follo
wing
the
w
all
present
at
left
side.
The
temporary
(temp)
v
ariable
v
alue
is
made
0
because
there
is
no
need
to
align
the
w
all
ag
ain
to
the
left.
These
conditions
in
T
able
2
help
the
robot
to
follo
w
the
w
all.
If
the
w
all
in
the
front
is
less
than
max
w
all
threshold
then
the
robot
will
turn
right
and
if
the
l
eft
side
w
all
is
too
near
then
also
the
robot
will
turn
right.
If
the
left
side
sonar
v
alue
is
more
than
max
w
all
threshold
t
hen
it
will
turn
left.
By
def
ault,
the
robot
will
mo
v
e
forw
ard
when
no
abo
v
e
condition
is
satisfied.
There
is
a
priority
order
in
the
abo
v
e
conditions.
Upper
conditions
ha
v
e
more
priority
then
belo
w
conditions.
Int
J
Rob
&
Autom,
V
ol.
8,
No.
4,
December
2019
:
217
–
244
Evaluation Warning : The document was created with Spire.PDF for Python.
Int
J
Rob
&
Autom
ISSN:
2089-4856
r
223
T
able
1.
Logic
for
w
all
alignment
to
the
left
side
of
the
robot
Left
sonar
v
alue
Front
sonar
v
alue
Result
<
max
w
all
threshold
>
max
w
all
threshold
Mo
v
e
forw
ard
(x=0.2,
y=0)
<
pre
vious
left
side
<
Left
side
T
urn
right
(x=0,
y=
-0.45)
<
pre
vious
left
side
>
left
side
T
urn
right
(x=0,
y=
-0.15)
T
able
2.
Logic
for
follo
wing
the
w
all
Left
sonar
v
alue
Front
sonar
v
alue
Result
No
condition
<
max
w
all
threshold
T
urn
right
(x=0.1,
y=
-0.6)
<
min
w
all
threshold
No
condition
T
urn
right
(x=0.1
,
y=
-0.15)
>
max
w
all
threshold
No
condition
T
urn
le
ft
(x=
0.1,
y=
0.15)
By
def
ault(
no
condition
)
By
def
ault(
no
condition)
Mo
v
e
forw
ard
(x=0.2,
y=0)
3.2.
Space
W
ander
er
and
Color
Finder
In
this
service,
first,
the
connection
is
established
with
the
robot.
After
connecti
o
n,
the
sonar
v
a
lues
are
check
ed
if
the
y
are
ready
or
not.
When
sonar
v
alues
are
ready
,
these
v
alues
are
used
to
find
the
distance
of
the
obstacles
in
right
and
left
side
of
the
robot.
In
this
service,
a
robot
is
made
to
tra
v
el
in
between
the
obstacles
or
w
all
and
if
the
left
sonar
distance
is
less
than
right
sonar
distance
then
turn
right
with
y
=
0.5
radian/sec
and
x
=0.
T
o
mo
v
e
in
between
the
w
alls,
x
is
set
as
((left/
10)+(right/10))/2
and
y
=
((left/10)-
(right/10))*(180/pie)/wheel
diameter
.
x
is
translational
speed
and
y
is
rotational
speed
in
radian.
While
the
robot
w
anders,
the
color
finding
service
is
also
running.
This
servi
ce
uses
blob
finder
sensors
to
detect
the
color
.
The
logic
for
sending
the
color
to
the
main
code
is
dif
ferent
in
callback
and
promise.
3.3.
Synchr
onous,
Callback
and
Pr
omise
based
implementation
When
subsumption
occurs,
or
change
in
the
running
state,
services
switches
to
other
services.
The
switching
is
f
ast
so
that
robot
does
not
colloid
with
the
w
all
when
no
one
is
controll
ing
the
actions
of
the
robot.
The
code
sho
wn
in
Figure
7
has
used
runThreaded
a
function
of
the
player
client.
This
function
calls
the
start()
function
of
thread
class.
Run
function
is
called
asynchronously
.
Run
function
in
player
client
interact
with
the
player
serv
er
and
gets
the
sensors
v
alues.
This
function
updates
the
isDat
aReady
function
of
player
client
about
the
sensors
v
alue.
i
sDataReady
function
is
used
in
the
services
for
checking
the
sensors
v
alues
are
ready
or
not.
When
isDataRedy
funct
ion
replies
truly
then
only
we
start
the
service.
This
is
the
solution
to
the
first
challenge
discussed
abo
v
e.
Figure
7.
Connection
with
robot
sensors
Concurr
ent
async
hr
onous
r
obotic
subsumption
using
actor
s
&
pr
omises
(Ratnesh
Srivastav)
Evaluation Warning : The document was created with Spire.PDF for Python.
224
r
ISSN:
2089-4856
Here
we
ha
v
e
used
color
as
subsumption
e
v
ent.
If
a
color
detected
other
than
orange
(another
robot
color),
black
(w
alls)
and
the
color
of
the
state
the
y
are
in,
then
the
state
of
the
model
will
change.
On
the
basis
of
color
detected
by
the
robots,
service
is
decided.
W
e
ha
v
e
tw
o
main
services,
the
possible
arrangement
of
services
among
tw
o
robots
is
4
as
sho
wn
in
T
able
3.
T
able
3.
Possible
arrangements
of
services
Robot1
Robot2
W
all
F
ollo
wer
Space
W
andere
r
Space
W
anderer
W
all
F
ollo
wer
Space
W
anderer
Space
W
anderer
W
all
F
ollo
wer
W
all
F
ollo
wer
The
state
transition
diagram
of
the
services
based
on
color
detection
is
sho
wn
in
Figure
8,
which
w
orks
on
3
states
of
the
model.
Figure
8.
State
transition
diagram
of
service
switching
In
state
1,
as
sho
wn
in
running
demo
of
Figure
9,
w
all
follo
wer
se
rvice
in
robot1
and
space
w
anderer
with
color
finder
service
in
robot
2,
it
is
def
ault
services.
This
state
occurs
when
robot
senses
blue
color
.
Note,
color
finder
service
is
only
with
space
w
anderer
service.
Only
the
robot
running
the
space
w
anderer
can
detect
the
color
and
perform
the
subsumption
of
its
o
wn
service
with
the
other
robot
service.
In
state
2,
as
sho
wn
in
running
demo
of
Figure
10,
space
w
anderer
and
color
finder
service
runs
in
robot
1
and
w
all
follo
wer
service
runs
in
robot
2.
This
state
occurs
when
robot
senses
red
color
.
In
state
3,
as
sho
wn
in
running
demo
of
Figure
11,
both
the
robots
runs
with
space
w
anderer
and
color
finder
s
ervice.
This
state
occurs
when
robot
senses
green
color
.
In
this
state,
both
the
robots
can
detect
the
color
and
change
the
state
of
the
model.
The
switching
of
the
services
can
be
depicted
as
in
Figure
12,
which
w
orks
on
the
follo
wing
rules
which
solv
es
our
second
challenge
discussed
abo
v
e
are:
[1]
The
def
ault
condition
for
state1
i
s,
let
s
assume
this
condition
as
A=
robot1.color
!=
black
&
robot1.color
!=
orange
&
robot1.color
!=
state.color
.
[2]
The
robot
changes
its
priority
and
goes
to
state2
based
on
condition,
lets
assume
this
condition
as
B=
robot1.color
=
blue
or
robot2.color
=
blue.
So
priority
of
services
are
(robot1.service
=
SW
>
robot1.service
=
WF
&
robot2.service
=
SW
<
robot2.service
=
WF)
if
condition
A
and
B
are
true.
Int
J
Rob
&
Autom,
V
ol.
8,
No.
4,
December
2019
:
217
–
244
Evaluation Warning : The document was created with Spire.PDF for Python.
Int
J
Rob
&
Autom
ISSN:
2089-4856
r
225
[3]
Ag
ain
the
robot
changes
it’
s
priority
and
goes
to
state2
based
on
condition,
lets
assume
this
condition
as
C
=
robot1.color
=
red
or
robot2.color
=
red.
So
priority
of
services
are:
(robot1.service
=
SW
<
robot1.service
=
WF
&
robot2.service
=
SW
>
robot2.service
=
WF)
if
condition
A
and
C
are
true.
[4]
The
robot
changes
it’
s
priority
and
goes
to
state3
based
on
condition,
lets
assume
this
condition
as
D
=
robot1.color
=
green
or
robot2.color
=
green.
So
priority
of
services
are
(robot1.service
=
SW
>
robot1.service
=
WF
&
robot2.service
=
SW
>
robot2.service
=
WF)
if
condition
A
and
D
are
true.
where
State.color:
color
of
the
present
state,
WF:
W
all
follo
wer
service,
SW
:
Space
w
anderer
ser
v
i
ce,
Robot1.color:
color
detected
by
robot1
and
Robot2.color:
color
detected
by
robot2.
A
T
able
4
based
on
the
abo
v
e
rule
is
presented
belo
w
.
T
able
4.
Conditions
and
outcome
of
dif
ferent
states
Blue
Color
Red
Color
Green
Color
Robot1
Robot2
State
Y
es
No
No
W
all
F
ollo
wer
Space
W
anderer
1
No
Y
es
No
Space
W
anderer
W
all
F
ollo
wer
2
No
No
Y
es
Space
W
anderer
Space
W
anderer
3
Figure
9.
Running
demo
of
tw
o
robots
e
xchanging
their
services
on
color
detection
in
state1
Concurr
ent
async
hr
onous
r
obotic
subsumption
using
actor
s
&
pr
omises
(Ratnesh
Srivastav)
Evaluation Warning : The document was created with Spire.PDF for Python.
226
r
ISSN:
2089-4856
The
BIP
[19]
model
of
the
implementation
of
the
problem
is
presented
belo
w
in
Figure
13
for
the
tw
o
robots.
W
e
ha
v
e
used
3
dif
ferent
implementations
of
the
same
problem
using:
i)
Subsumption
using
Synchronous
mode.
ii)
Subsumption
using
Asynchronous
model
of
Actor
&
Actor
with
callback.
iii)
Subsumption
using
Asynchronous
model
of
Actor
&
Actor
with
Promise.
Figure
10.
Running
demo
of
tw
o
robots
e
xchanging
their
services
on
color
detection
in
state2
Figure
11.
Running
demo
of
tw
o
robots
e
xchanging
their
services
on
color
detection
in
state3
Int
J
Rob
&
Autom,
V
ol.
8,
No.
4,
December
2019
:
217
–
244
Evaluation Warning : The document was created with Spire.PDF for Python.