Concurrent Graph Exploration with Multiple Robots Hui Wang 11/19/2018

Outline Review of basic problem Concurrency-related practice More on concurrency-related practice Experiencing ordering information of concurrent events Results and conclusion 11/19/2018

Outline Review of basic problem Concurrency-related practice More on concurrency-related practice Experiencing ordering information of concurrent events Results and conclusion 11/19/2018

Review of Basic problem Exploring graph-like world with multiple robots Common starting place Perception and communication capability (within vertex) Exploring in parallel Gut: Use marker (bread crumbs) to disambiguate places Alternating phases of common map := initial starting place while common map has unexplored part Partition the common map (Task split) Explore in parallel Meet at rendezvous place (common) after a certain time steps Merge the partial maps Merged map shared by all robots, becoming new common map end while independent exploration coordinated merging of partial representations. 11/19/2018

Multiple robot exploration example 11/19/2018

Outline Review of basic problem Concurrency-related practice More on concurrency-related practice Experiencing ordering information of concurrent events Results and conclusion 11/19/2018

Concurrency-related practice Basic design Each robot represented by a thread Share underlying data structure (the graph) Communication by shared memory Non-rendezvous place: lock current place for accessing and updating place := current place synchronized (place){ accessing & updating the place … } Rendezvous place: sleep and wake up synchronized (place) { if nobody here //earlier one place.wait(); else // later one place.notifyAll(); … 11/19/2018

Outline Review of basic problem Concurrency-related practice More on concurrency-related practice Experiencing ordering information of concurrent events Results and conclusion 11/19/2018

Experiencing and exploiting ordering information of concurrent events We want to experience more concurrency-related concerns. Time information, one of the tons of options Robots can do certain things if they have global clocks Global clock is too luxurious in real distributed systems Can we do similar things without the global clocks? Only order matters. Logic clocks -- determine order in which events in distributed systems occurred Vector logical clocks invented in 1988-89 “I saw your marker at place X @ 10:20 am” “I dropped my marker at an unknown place @ 10:15 am” 11/19/2018

Vector logic clocks (1,0,0) (2,0,0) (3,2,2) Process P1 A B G (0,0,0) (2,2,0) C D Process P2 (2,2,2) (2,1,0) (2,2,0) (0,0,0) E F Process P3 (2,2,2) (0,0,1) (0,0,0) 11/19/2018

Vector Time and Ordering Given two vector clocks C(X) and C(Y) of event X and Y respectively C(X) < C(Y) iff all C(x)[i]<=C(Y)[i] and some C(X)[i]< C(Y)[i] e.g., (2, 0, 0) < (2, 4, 0) C(X) || C(Y) iff not( C(X) < C(Y) or C(Y) < C(X) ) e.g. (2, 0, 1) || (2, 4, 0) Given two events X and Y X  Y iff C(X) < C(Y) ----- “X happened before Y” X || Y iff C(X) || C(Y) ----- “X and Y are concurrent (incomparable)” Captures “happened-before” relation exactly Requires communication, clocks synchronized as much as necessary 11/19/2018

Vector Time Example - revisit (1,0,0) (2,0,0) G (3,2,2) Process P1 A B D Process P2 C (2,2,0) (2,1,0) E F Process P3 (2,2,2) (0,0,1) A  B  C  D  F  G E  F  G (1,0,0) < (2,0,0) < (2,1,0) < (2,2,0) < (2,2,2) < (3,2,2) (0,0,1) < (2,2,2) < (3,2,2) E || A E || B E || C E || D 11/19/2018

Exploiting event ordering in our problem Objective Does logical vector time really works? Can we exploit it? Each edge traversal is an event Synchronized as much as necessary, requiring communication Robot dumps all traversal history up on a vertex Label of the node traversed , logic time stamp, whether other’s marker is seen For other robot to observe At least synchronizes logical time Another robot’s traversal history - I have visited A C F H My last event time (5,3) - at logical time 0,2 0,3 3,4 3,5 - seen others marker? X  X X My current event time (6,5) 11/19/2018

Exploiting event ordering -- scenario I Upon on arrival, retrieve other’s traverse info The other robot traversed some to-be-visit nodes Which happened after my latest drop Not seen my marker Another robot’s traversal history - I have visited A C F H - at logical time 0,2 2,3 3,4 3,5 I am in searching stage I dropped (at unknown place) at time (3,2) I still need to search node [B C D E F G H] - seen your marker?  X X X The marker must not at F & H !!! I will need to search node [B C D E F G H] 11/19/2018

Exploiting event ordering -- scenario II Upon on arrival, retrieve other’s traverse info The other traversed some to-be-visit node Which happened after my latest drop Have seen my marker Another robot’s traverse history - I have visited: A C F H - at logical time: 0,2 2,3 3,4 3,5 - I am in searching stage - I dropped at time (3,2) I still need to search node [B C D E F G H] - seen your marker?:  X  X My marker is at node F !!! I will need to search node [B C D E F G H] 11/19/2018

Results and Conclusion Graph are explored successfully as before So vector logical time really works! Graph are explored with fewer steps So vector logical time really helps! 11/19/2018

Thank you References Logical clocks [1] Lamport, L Time, Clocks and the Ordering of Events in a Distributed System. Communications of the ACM 21 (7): 558–565. 1978 Vector logical clocks [2] Mattern, F. Virtual time and global states of distributed systems. In M. Cosnar, editor, Proceedings of the International Workshop on Parallel and Distributed Algorithms, pages 215-226, 1989. [3] Fidge, C Timestamps in message-passing systems that preserve the partial ordering. In K. Raymond, editor, Proceedings of the 11th Australian Computer Science Conference (ACSC'88), pages 56-66, 1988. Thank you 11/19/2018

Extra: Summary and future work Good experience of concurrency-related knowledge Too many directions of future work This is simple model, may not real Ignore possible enhancements that are not related to event ordering 11/19/2018

Extra: more work Marker seen and drop record Dump partial map instead Use history as unique identification Multiple robots, multiple markers 11/19/2018

Extra: Classes Graph Robot Nodes[] Graph: Real word Clock int: real location int [] Graph: local word Node Int: local location Traversal histories[] Clock: myClock Info bulletin [] 11/19/2018

Extra: work of vector clock Initially all counts in the vector are zero Each time a process experiences an internal event, it increments its own event count in the vector by one Each time a process prepares to send a message, it increments its own event count in the vector by one and then sends its entire vector along with the message being sent Each time a process receives a message, it increments its own event count in the vector by one and updates each element (count) in its vector by taking the maximum of the value in its own vector clock and the value in the vector in the received message (for every element). 11/19/2018

Unavailability of global clocks Don’t have global clocks Local clock Don’t run in a synchronized way Don’t run with same speed Have offsets 11/19/2018

Extra: common vs. local 11/19/2018

11/19/2018

Extra slide: Two robots vs. single robot 11/19/2018

Extra Slide: About isomorphic Problem (goal) : Given an unknown environment modeled as a graph, formulate an exploration strategy which enable the robot to form a representation of environment that is isomorphic to the finite world it has been assigned to explore. isomorphic: Two graphs are isomorphic if there is a one-to-one correspondence between their vertices and there is an edge between two vertices of one graph if and only if there is an edge between the two corresponding vertices in the other graph. v2 v1 v1 v2 v3 v4 v4 v3 11/19/2018