Computer Aided Formal Design of Swarm Robotics Algorithms
Thibaut Balabonski, Pierre Courtieu, Robin Pelle, Lionel Rieg, Sébastien Tixeuil, Xavier Urbain
CComputer Aided Formal Design of Swarm Robotics Algorithms *Thibaut Balabonski , Pierre Courtieu , Robin Pelle , Lionel Rieg , Sébastien Tixeuil , andXavier Urbain Université Paris-Saclay, CNRS, LMF Cédric, Conservatoire des Artts et Métiers, Paris VERIMAG, UMR 5160, Grenoble INP, Univ. Grenoble Alpes Sorbonne University, CNRS, LIP6 Université Claude Bernard Lyon 1, LIRIS
UMR
Abstract
Previous works on formally studying mobile robotic swarms consider necessary and sufficient system hy-potheses enabling to solve theoretical benchmark problems (geometric pattern formation, gathering, scattering,etc.).We argue that formal methods can also help in the early stage of mobile robotic swarms protocol design, toobtain protocols that are correct-by-design, even for problems arising from real-world use cases, not previouslystudied theoretically.Our position is supported by a concrete case study. Starting from a real-world case scenario, we jointlydesign the formal problem specification, a family of protocols that are able to solve the problem, and theircorresponding proof of correctness, all expressed with the same formal framework. The concrete framework weuse for our development is the P
ACTOLE library based on the C OQ proof assistant. Swarm robotics envisions groups of mobile robots self-organizing and cooperating toward the resolution of com-mon objectives, such as patrolling, exploring and mapping disaster areas, constructing ad hoc mobile commu-nication infrastructures to enable communication with rescue teams, etc. As several of those applications arelife-critical, the correctness of the deployed protocols becomes of paramount importance. In turn, correctnessreasoning about autonomous moving and computing entities that collaborate to achieve a global objective in a set-ting where unpredictable hazards may occur is complex and error prone. A first step into more formal reasoningis to use a sound mathematical model .Suzuki & Yamashita [28] introduced such a mathematical model describing the behaviour of robots in thiscontext. The model is targeted at swarms of very weak robots evolving in harsh environments. At its core, themodel simply commands individual robots to repetitively observe their environment before computing a path ofactions to pursue and acting on it, usually by moving to a specific location. Three different levels of synchron-ization have been commonly considered. The fully-synchronous (FSYNC) case [28] ensures each phase of eachcycle is performed simultaneously by all robots. The semi-synchronous (SSYNC) case [28] considers that time isdiscretized into rounds, and that in each round an arbitrary yet non-empty subset of the robots are active. Finally,the asynchronous (ASYNC) case [19] allows arbitrary delays among the Look, Compute and Move phases, andthe movement itself may take an arbitrary amount of time. The Look-Compute-Move model received a consid-erable amount of attention from the Distributed Computing community, yielding a large variety of submodelsinduced by refined system assumptions. Such submodels were typically used to assess the solvability of a certain * This work was partially supported by Project SAPPORO of the French National Research Agency (ANR) under the reference 2019-CE25-0005-1. Yamashita received the “Prize for Innovation in Distributed Computing” for his seminal work on this model. a r X i v : . [ c s . C G ] J a n ask assuming certain system hypotheses. As such, the Distributed Computing literature about mobile robots sofar can be seen as computability-oriented .Alas, the various submodels make it extremely tedious to check whether a particular property of a robotprotocol holds in a particular setting. Furthermore, these variants do not behave well regarding proof reusability:checking that a property holding in a given setting also holds in another setting that is not strictly contained in theformer often amounts to developing a completely new proof, regardless of the proof arguments similarity. Thisconstitutes a major issue when one investigates the correctness of new solutions or implementations of existingprotocols to be used in more realistic execution models. This problem is specially acute because of the greatdiversity of subtly different models: one may be tempted to simply hand-wave their way around the issue bydeclaring that the proof in this model is “obviously” also valid in this very close model, even more so as even acareful examination may not always find the most subtle errors. Last but not least, protocols are typically writtenin an informal high level language: assessing whether they conform to a particular model setting is particularlycumbersome, and may lead to hard to find mismatches. As a result, sustained research efforts were made in thelast decade to use formal methods in the context of mobile robotic swarms. Formal methods encompass a long-lasting path of research that is meant to overcome errors of human origin.Perhaps the most well known instance in the Distributed Computing community is the
Temporal Logic of Actions and its companion tools TLA/TLA+ [13, 24]. Though very expressive, TLA is designed for the shared memoryand message passing contexts, thus not perfectly suited to studying mobile robotic swarms.
Model-checking and its powerful automation proved useful to find bugs in existing literature [6, 17, 18], and to assess formallypublished algorithms [6, 16], in a simpler setting where robots evolve in a discrete space where the number ofpossible positions is finite. Automatic program synthesis (for the problem of perpetual exclusive exploration ina ring-shaped discrete space) is due to Bonnet et al. [8], and can be used to obtain automatically algorithmsthat are “correct-by-design”. The approach was refined by Millet et al. [25] for the problem of gathering in adiscrete ring network. However, those approaches are limited to instances with few robots. Generalizing themto an arbitrary number of robots with similar models is doubtful as Sangnier et al. [27] proved that safety andreachability problems are undecidable in the parameterized case. Another limitation of the above approachesis that they only consider cases where mobile robots evolve in a discrete space ( i.e. , graph). This limitation isdue to the model used, that closely matches the original execution model by Suzuki and Yamashita [28]. As acomputer can only model a finite set of locations, a continuous 2D Euclidean space cannot be expressed in thismodel. Défago et al. [14] used a more abstract model to model-check rendez-vous algorithms in a continuous 2DEuclidean space, however, their model is highly specific to rendez-vous and thus is not as versatile as one couldhope, hinting at a more general and systematic technique.The approach on which we focus in this work is formal proof , that is proof development mechanically certi-fied by a proof assistant. Mechanical proof assistants are proof management systems where a user can expressdata, programs, theorems and proofs. In sharp contrast with automated provers (like model-checkers), they aremostly interactive, and thus require some kind of expertise from their users. Sceptical proof assistants provide anadditional guarantee by checking mechanically the soundness of a proof after it has been interactively developed.Formal proof allows for more genericity as this approach is not limited to particular instances of algorithms.During the last twenty years, the use of tool-assisted verification has extended to the validation of distributed pro-cesses, in contexts such as process algebras [7, 20], symmetric interconnection networks [21], message passingsettings [23], and self-stabilization [1, 15], etc. The main approach for mechanized proof dedicated to swarmsof mobile entities is so far the P ACTOLE framework. Initiated in 2010, The P ACTOLE framework enabled theuse of high-order logic to certify impossibility results, as well as soundness of protocol, for swarms of autonom-ous mobile robots. To certify results and to guarantee the soundness of theorems, the proof assistant it uses isC OQ . Briefly, C OQ is a Curry-Howard-based interactive proof assistant that enjoys a trustworthy kernel. Its baselanguage is a very expressive λ -calculus, the Calculus of Inductive Constructions [10], where datatypes, objects,algorithms, theorems and proofs can be expressed in a unified way, as terms. The syntax is close to that ofan ML-like programming language, and a proof development consists in trying to build, interactively and usingtactics, a λ -term, the type of which corresponds to the theorem to be proven (Curry-Howard style). The smallkernel of C OQ simply type-checks λ -terms to ensure soundness. Most importantly : a theorem or a lemma canonly be saved/defined in the system if it comes with its type-checked proof . Designed for mobile entities, and https://pactole.liris.cnrs.fr OQ ’s assets, P ACTOLE allows for working on a given protocol to establish and certify itscorrectness [4, 12], as well as for quantifying over all protocol so as to prove impossibility results [2, 5, 11], withan unspecified number of robots, possibly including a proportion of Byzantine faults, in continuous or discretespaces. FSYNC/SSYNC and ASYNC modes are all supported, and the framework is expressive enough to stateand certify formally results as theoretical as comparisons between demons or models [3].
Taking some perspective over aforementioned works mixing formal methods and swarm robotics, one can onlynotice that the computability-centric approach of the Suzuki and Yamashita model yielded a concentration ofefforts towards few benchmark problems that are theoretically interesting (one can get impossibility results orcorrectness certification) but of little practical relevance, such as perpetual or terminating exploration of a ring-shaped graph, and gathering or concentrating all robots at a particular location.On the other side, relevant practical problems, such as constructing ad hoc mobile communication infrastruc-tures to enable communication with rescue teams, remain untouched using a formal approach. Yet, their correct-ness is crucial, and possibly life-critical, so it should be assessed formally and mechanically verified. Overall,for those practical problems, the question is not really to characterize which system hypotheses enable problemsolvability, but rather how to design a provably correct solution using hypotheses that correspond to real devices.This paper is the first step in this direction. In more details, we start from a real-life application scenarioto jointly design (i) its formal specification, (ii) a family of protocols that are able to solve the problem, and (iii) their corresponding proof of correctness, all expressed with the same formal framework, P
ACTOLE . In thisprocess, we illustrate how formal methods and P
ACTOLE in particular could be used to derive protocols that arecorrect-by-design before they are deployed to actual devices.The developments for C OQ v8.12 described in this work are available at https://pactole.liris.cnrs.fr/pub/connection_8.12.tgz One of the most advertised applications of robotic swarms is the Search and Rescue situation: a devastated zonehas to be explored to bring assistance to survivors. A particular scenario in that context is the “life line” onewhere, static communication infrastructures having been destroyed, a robotic swarm establishes a dynamic net-work between a moving search team and the rescue station, by sending mobile transmitters relays.The same problematic is faced in the less dramatic context of the pursuit of a hornet with drones whose sensorsand transmitters are of limited range [26].In such situations :• A mobile target follows an unpredictable path and must always be in sight.• Mobile robots with limited sensors/transmitters track and follow the target.• To maintain contact with the base station which might be lost due to range limits, some of the robots act asrelays.The link between the base and the target, the so-called life line, must never be broken. More precisely: theexistence of such a life line should be ensured at each and every point in the execution.As practical applications may be critical, with lives at stake, it is imperative for that invariant to hold, and oneneeds formal guarantees about it.
Focusing on the search and rescue scenario, we have drones flying and monitoring a rescue team on the ground.Though the most natural space would be the 3D space, it is enough to consider that the mobile robots are movingon a continuous plane, at a fixed altitude. Thus, we can choose the space to be the 2D Euclidean plane. In this space, there is a point called the base from which robots are launched. The second defining object isthe companion which moves on the plane and follows the rescue team, regardless of other robots; it has to beconnected to the base, one way or another. This incidentally will allow us to use vertical movement as a way to remove robots from the protocol, see Section 4.2.3. a) (b) Figure 1: Let us consider in (a) a configuration of the system where is the base, is the companion, andwhere visibility range are denoted as dotted circles. In this situation, the two robots cannot detect the others.Nonetheless there is a chain of visibility between the base and the companion, denoted as a dashed blue path. Thecorresponding visibility graph is in (b), with a suitable path we ask for in blue.
To avoid the problem being trivially solvable, we require the sensors and transmitters to have a limited range.Hence we grant robots the ability to see neighbouring robots up to some finite range D max . Indeed, infinite rangewould make the whole protocol moot as a single robot located at the base would be able to see the target.Note that we merge vision and transmission capabilities. As a matter of fact relays that do not see others wouldprobably be lost, and the point of a relay is to have neighbours to transmit to.There is no need to consider multiplicities, as the protocol has to avoid collision: two launched robots willnever be at the same location (provided this property holds in the starting configuration).Similarly, to avoid any trivial counter-example involving a straight line fleeing of the companion followingthe search team, we constrain the speed of drones to a certain D denoting the bound on the distance that can betravelled within one cycle. Also, we only consider executions where the number of available relays is sufficient. We may assume the execution to be fully synchronous, with a short time span for each cycle. As pointed out inSection 1.3, our goal is not to find minimal synchrony assumptions that allow problem solvability, but rather makesensible and realistic assumptions that permit deployment with actual devices. When robots are homogeneous,they operate at a similar pace, and the fully synchronous model is a sensible choice. Furthermore, keeping thetime span short makes the assumption close to what continuous time practitioners envision [9, 22].For the same reason, we also consider movements to be rigid, that is robots do not start a new cycle before theyhave reached their computed destination. Since robots always select as a target another robot within the visibilityradius, movements are always of limited length.The fact that the rescue team departs from the base allows us to define a notion of valid initial configuration.Trying to solve the problem if the rescue team is already out of reach would make no sense in that context.
As it is critical to keep the rescue team connected to the base, we want a formal guarantee that there is always achain of robots going from the base to the target, such that robots along this chain can relay communication.Given a configuration of the system (see e.g.
Figure 1), we say that two robots are connected if they are locatedat most D max apart, that is within visibility range. We formalize this idea by a visibility graph , where nodes are4obots and edges relate connected robots. Thus, having a chain of connected robots going from the base to thecompanion can be expressed as having a path from the base to the companion in the visibility graph .A second objective of our protocol is to avoid collision for obvious reasons, that is, to make sure that no twodistinct robots are ever at the same location.Overall, we end up with:• A list of hypotheses characterizing our context and the environment, on space, sensors, synchronicity. . .• An invariant that, provided there are enough relays to be sent, has to hold at each point of any executionstarting from a valid configuration: there is a path in the graph of visibility and there is no collision. ACTOLE
Framework
One of the aims of P
ACTOLE is to stay as simple and as close as possible to the definitions of the robotic swarmcommunity.Thus, a state of the overall system, a configuration is defined as the collection of the states of all robots,conveniently combined into a map from robot names to robot states:
Definition configuration := ident → state. A robot state can be anything (to accurately describe reality) but must at least contains its location , accessiblethrough a function get_location : state → location , where the type location denotes the space whererobots evolve.An execution is an infinite sequence of configurations: Definition execution := Stream.t configuration.
Executions are usually built by executing a protocol (called a robogram ) against an environment, represented as a demon , that is, an infinite sequence of decisions called demonic actions . Definition demon := Stream.t demonic_action.
The robogram represents the Compute part of the Look-Compute-Move cycle. It takes the observation of the robotas input and outputs the action that the robot should perform.
Definition robogram := observation → action. This observation denotes a degraded version of the configuration centred on the observing robot, dependingon its sensors. It is a parameter of the model and its computation from a (local) configuration is performedby an obs_from_config function, which hides the information unavailable to robots and takes as input theconfiguration and the state of the observing robot. This function is specified by a logical formula obs_is_ok relating any configuration to its possible observation from any robot state.
Parameter observation :
Type . Parameter obs_from_config :configuration → state → observation. Parameter obs_is_ok :observation → configuration → state → Prop . Parameter obs_from_config_spec : ∀ config st,obs_is_ok (obs_from_config config st) config st. To represent the fact that robots observe from a personal point of view, they have their own frame of reference that need not be consistent in time or with other robots (other orientation, other scale, other origin, etc.). Thisframe of reference allows to create a local configuration (by opposition to the point of view of the demon denotedas global ) from which the observation is computed, it depends on the underlying space and it is picked by thedemon.In such an execution, the robogram corresponds to one Look-Compute-Move cycle and the demonic action tothe reaction of the environment. Their interaction is described by a function round so that the resulting executionis simply repeatedly calling this function with the robogram, the demon and the starting configuration.The round function is the heart of the model, implementing the Look-Compute-Move cycle and computingthe configuration obtained after one round. Note that this function is the same for all variants, FSYNC/SSYNC/A-SYNC synchronization, all spaces, all sensors, etc. This is done in the following consecutive steps for each robotname id : 5. If the robot id is not activated, its state may undergo some change by the inactive function to representan ongoing action or the effect of the environment.2. If id is a byzantine robot, it is relocated by the demonic action da .3. Use the local frame of reference provided by da to compute the local configuration.4. Transform this local configuration into an observation.5. Apply the robogram on this observation.6. If moves are flexible, compute the new position of id using information given by da .7. Convert the new position from the local frame to the global one.The full round function is: Definition round r da conf : configuration :=(* for a given robot, we compute the new configuration *) fun id ⇒ let state := conf id in (* id’s state read from conf *)(* first see whether the robot is activated *) if da.(activate) id then match id with | Byz b ⇒ (* byzantine robots *)da.(relocate_byz) conf b| Good g ⇒ (* change the frame of reference *) let frame_choice := da.(change_frame) conf g inlet new_frame :=frame_choice_bijection frame_choice inlet local_config := map_config new_frame conf inlet local_state := local_config (Good g) in (* compute the observation *) let obs :=obs_from_config local_config local_state in (* apply r on the observation *) let local_robot_decision := r obs in (* the demon chooses how to update the state *) let choice :=da.(choose_update) local_config glocal_robot_decision in (* the actual update by the update function *) let new_local_state := update local_config gframe_choice local_robot_decision choice in (* return to the global frame of reference *)new_frame − new_local_state endelse inactive conf id (da.(choose_inactive) conf id). The first step is to instantiate in the formal framework the assumptions listed in Section 2, as well as the propertythat we want to be holding throughout a relevant execution.Those specifications are “refined” until a set of constraints on robots and protocol candidates is formallyproven sufficient. Ultimately, our family of protocols will be given by an abstract protocol parameterized byseveral functions that will be specified enough for the correctness proof to hold.6he final specifications are thus designed together with a solution and its proof.For the sake of readability we use cf x as a shorthand for cf (Good x) , i.e. the position of a (non-Byzantine)robot named x in a configuration cf . The parameters of the problem are the number n of robots, the visibility radius D max of robots and the maximumdistance D they can travel in a round. Parameter n : nat.
Parameters
D Dmax : R.
Using the number n of robots, we define canonical names to be able to refer to them: Instance
Robot_Names : Names := Robots n 0.
The represents the absence of Byzantine failures.The space is the 2D Euclidean space, already predefined in P ACTOLE : Instance
Loc : Location := make_Location R2.
Initially, a robot’s state contains only its location, and its observation consists of the set of inhabited locationswithin its vision range:
Instance first_State : State R2 := OnlyLocation.
Instance
SetObs : Observation :=LimitedSetObervation.limited_set_observation Dmax.
The changes of frame of reference allowing to switch between global and local observation (and vice-versa)are similarities (that is, moving the origin around and changing the orientation, chirality, and scale):
Instance first_Frame : frame_choice (similarity location):= FrameChoiceSimilarity.
The FSYNC setting is reflected in an hypothesis made over demonic actions, by requiring property
FSYNC_da to hold (as will be seen the final statement of the invariant).Movements are defined as rigid.
Instance setting_is_rigid : RigidSetting.
As a consequence of our FSYNC and rigid setting with no Byzantine failure, some parameters of the P
ACTOLE framework are not used and can be set to arbitrary values, namely what happens to a robot whenever it is inact-ive, how the demon interferes with a robot movement, what happens to robot suffering Byzantine failures, etc.Essentially, one can skip the first two steps of the round function described in Section 3 and focus on the Look-Compute-Move cycle.
Context { inactive_choice_ila : inactive_choice bool } . Instance demon_upd : update_choice unit := NoChoice.
We say of a robot participating to the task that it is launched (by the base station) and alive . (These no-tions will be formally motivated and introduced during the design of the protocol, respectively in Sections 4.2.2and 4.2.3.) The main goal of any candidate protocol is to maintain the following properties at any momentduring the execution:1. There is no collision between robots, i.e. any two distinct alive robots not at base do not share the samelocation:
Definition no_collision_conf (cf : config) := ∀ g g’, g (cid:54) = g’ → get_launched (cf g) = true → get_launched (cf g’) = true For the sake of clarity, some notations may slightly differ between the actual code and this section, and some irrelevant technical overheadmay have been pruned. get_alive (cf g) = true → get_alive (cf g’) = true → dist (get_loc (cf g)) (get_loc (cf g’)) (cid:54) = R .
2. There is a sequence of connected robots from the base to the companion (numbered , always alive). Inother words: for any robot alive (we shall see that there is always some robot alive on base) either it is thecompanion or it has a visible, active, launched neighbour with a smaller id. Definition path_conf (cf:config) := ∀ g,get_alive (cf g) = true → get_ident (cf g) = 0 ∨ ∃ g’,dist (get_loc (cf g)) (get_loc (cf g’)) ≤ Dmax ∧ get_alive (cf g’) = true ∧ get_launched (cf g’) = true ∧ get_ident (cf g’) < get_ident (cf g). Note that this definition implies the existence of a connection from the base to the companion only if thereis a robot alive (launched or not) close to the base, i.e. the set of robots waiting to be launched never getsexhausted. The fact that this property always holds during the considered execution is stated as the premise exists_at_based below.The preservation of this invariant is expressed as
Definition
NoCollAndPath e :=Stream.forever (Stream.instant( fun cf ⇒ no_collision_conf cf ∧ path_conf cf)) e. Being assumed that the invariant holds in the initial configuration config_init
The final lemma will statethat the invariant holds forever along any execution of the (abstract and parametric) protocol rbg_ila , providedthat the set of robots alive at base never gets empty. (* There is a robot not yet launched *)
Definition exists_at_base cf := ∃ g, get_launched (cf g) = false.(* This property holds forever *) Definition exists_at_based e :=Stream.forever (Stream.instant (exists_at_base)) e.(* Hypotheses on each demonic action: it is FSYNCand local frames are centred on the observing robot *)
Definition da_assumption da := change_frame_origin da ∧ FSYNC_da da.(* The demon must forever satisfy these properties *)
Definition demon_ILA demon :=Stream.forever (Stream.instant da_assumption) demon.(* Main lemma *)
Lemma validity_conf_init: ∀ demon, demon_ILA demon → exists_at_based (execute rbg_ila demon config_init) → NoCollAndPath (execute rbg_ila demon config_init).
We show in the remainder of this work that the aforementioned lemma can in fact be formally proven for any rbg_ila fulfilling some sufficient conditions that we discovered in the next section. A concrete suitable protocolis outlined in Section 4.4.
We describe in the following how we refine this initial formal model according to the issues we ran into and thehypotheses (whether necessary or by design) we find helpful along the protocol and proof co-development. Weupdate the formal instantiation accordingly. For the sake of clarity, we use the following notation: the successivere-definitions of the parameters are indexed with the refinement step (e.g.
State is second refinement of theinitial default robot state State ). We drop that numbering when we reach the final version of the parameters.8 .2.1 Robot path needs an orientationProblem : When robots see neither the base nor the companion, for instance when they only see their two neigh-bours on the life line, they have no way of knowing in which direction the base lies and in which direction thecompanion lies.This information is important since the behaviour of relay robots is not symmetric: they should follow thecompanion as the base is responsible for launching new relay robots whenever necessary. Therefore relay robotsneed a way to know in which direction lies the companion. Solution : We provide visible identification and a strict ordering between those robot identifiers. To this goal weuse a unique positive integer per robot, and assume that robots will be launched in ascending order. This way, thedirection of the companion is given by smaller identifiers. The definition of a state is updated accordingly.Note that the newly introduced identifiers are visible information and are not to be confused with
Names ofrobots (Section 4.1), which are constructs internal to the formal framework.
Definition identifier := nat.
Definition info := identifier. Definition
State := AddInfo info OnlyLocation.
The companion will be given number , and at any moment if a robot is launched then all other robots alreadylaunched have a smaller id. : What if a robot is located at the base but is already launched? Should this configuration be indistin-guishable from the one where it is not yet launched? Obviously not, as collisions may occur in the former but notin the latter. Solution : The state of a robot should contain a boolean indicating if the robot is “launched” or not. The stateshould be updated accordingly.
Definition launched := bool.
Definition info := identifier*launched. Definition
State := AddInfo info OnlyLocation. : When the companion comes closer to the base, the connection line shrinks making the connectingrobots possibly unable to stay out of collision risk. Therefore a useful feature of a candidate protocol would bethe ability to withdraw from the line.
Solution : We assume available any arbitrary procedure for robot removal, and we add a boolean alive to therobot state, making sure that dead (that is, withdrawn) robots are not taken into consideration by alive robots. Forsimplicity and separation of concern, we make dead robots not even observable by the other robots by adding newconstraints to the specification of the observation.
Definition alive := bool.
Definition info := identifier*alive*launched. Definition
State := AddInfo info OnlyLocation.
Definition obs_is_ok s config pt:get_alive pt = true ∧ ( ∀ l, In l s ⇔ ... ∧ get_alive l ≡ true). For instance, we may make them change altitude making sure they no longer represent a collision risk.
90 8 39 (a)
10 8 39 (b)
Figure 2: In situation (a), robot 8 will withdraw as it is too close to 3. Robot 10 can see 8 and 9, 3 is out ofsight, and it may choose 8 as its target. Situation (b) shows what can happen in this case: 10 moves towards 8 (itsprevious position is shown in grey), which disappears. With 3 moving further, 10’s connection with any suitablerobot is lost.
Since robots are ordered, and the problem essentially revolves around following some robot of lower identifier,we choose to consider protocols where any given robot makes its decisions depending only on the robots of loweridentifier. While this choice is not an answer to any particular problem, it reduces drastically the design space weexplore. Once we make this assumption, several formerly open choices become closed. In particular, no robot ofsmall identifier will ever take into account robots of higher identifier nor try to avoid collision with them. Thatmeans avoiding collisions and, if necessary, withdrawing, will always be the responsibility of the robots withhigher identifiers. : A robot too close to others shall disappear, but there are cases where a robot immediately behind itmay move too far and break the link, precisely because it tried to avoid that collision , even if that collision is nowimpossible due to the robot removal. This situation is illustrated on figure 2. We decide to give robots the abilityto warn neighbours about the possibility that it may withdraw in the next round.
Solution : We add a light to the robots capabilities. The light of a robot is either on or off . Any robot that seesanother robot sees its light. Light on means the robot might be about to withdraw and should not be followedanymore, see Figure 3. Definition light := bool
Definition info := identifiant*light*alive*launched. Definition
State := AddInfo info OnlyLocation. : Any robot must ensure it avoids collision with other robots and keep in range the neighbour it choosesto follow. Since robots do not know their neighbours views, they cannot predict the moves other robots are aboutto make. Thus any robot must choose its move so that collisions are avoided and connection with the followedneighbour is preserved for any possible simultaneous move of the other robots.
Solution : Since we assume no robot can travel a distance greater than a constant D in one cycle, we take alldecisions with a D margin. This entails defining several zones around a robot using this distance D , summed up100 8 39 (c)
10 8 39 (d)
Figure 3: Situation (c) is similar to Figure 2 (a) as 8 will withdraw but now it switches its light on (here in red).As 10 knows that 8 is likely to disappear, it chooses 9 as target, thus keeping a connection with a robot of loweridentifier (situation (d)).in Figure 4.• A neighbour at distance less than D from the range limit, that is a neighbour at a distance comprised between D max − D and D max might become out of range after its move. If the followed neighbour is in this particularrange, a move is necessary to ensure connection. This defines the Pursuit Zone. The distance of pursuit isthen defined as D p = D max − D .• A neighbour at distance less than D might provoke a collision. Since cycles are atomic we do not model howrobots move inside a cycle and we can never ensure that robots with crossing trajectories will not collide.Thus the distance D defines a Collision Zone. When two robots are at a distance less than D , either theyhave to agree on moving apart, or one has to withdraw.• A neighbour that is not in the Collision Zone, but is still at a distance less than D might enter the CollisionZone after its move. This range defines the Danger Zone, and letting another robot enter this zone meansrisking an imminent collision.The range between distances D and D max − D gives no particular constraint: neighbours in this Relay Zone areneither too close nor too far. : A robot may not see far enough to connect without risk. An exemple of this situation is given onFigure 5 where too long a wait to avoid collision risks at launch time leads to a connection break. Solution : We put a defensive safe limit for launching distance at D max − D , small enough to avoid losing robotsin the example. It must also be large enough to allow for safe launch, at least D . A bound follows on D max thatmust be strictly greater that D . At this point, we have gathered a few conditions that appear to solve the problems we foresee, and should helpin maintaining the invariant. As we formalized them in the P
ACTOLE framework, we may now prove formally that indeed any protocol fulfilling these conditions is a solution to our connection problem. We define that way afamily of protocols satisfying our needs.Let us first recap the description of this family of solutions before moving to the proof of its correctness.11ursuit Relay Danger Collision D max Figure 4: The visible surroundings of a robot can be divided into several zones that characterize the situations itmay encounter: need to follow a robot (Pursuit zone, width D ), high risk of immediate collision (Collision zone,radius D ) or possibly at the next round (Danger zone, width D ), and finally just transmission (Relay). Description of the family of solutions
We describe the family of solutions to the problem by exhibiting a generic protocol rbg_fnc parameterized bythree auxiliary functions.
Context { choose_target : obs_ILA → (R2*ILA) } .Context { choose_new_pos: obs_ILA → location → location } .Context { move_to: obs_ILA → location → bool } . Definition rbg_fnc (s:obs_ILA) : R2*light :=(* Chose target and new position accordingly *) let target := choose_target s inlet new_pos := choose_new_pos s (fst target) inmatch move_to s new_pos with (* Is this dangerous? *)| true ⇒ (new_pos,false) (* Safe: move + light off. *)| false ⇒ ((0,0), true) (* Danger: stay + light on. *) end . The role of choose_target is to select among the visible other robots the one that should be followed, i.e.the one we should maintain connection with on the next round. The role of choose_new_pos is to decide, giventhe target computed by choose_target , where the robot should move to ensure connection to it. Finally, therole of move_to is to decide whether it is dangerous to move to the selected new position. If that is the case,then the protocol decides not to move and warns neighbours that it may withdraw soon by turning on its light (andtherefore should preferably not be selected as a target by another robot on the next round).Our claim is that any three functions verifying the specifications described below will make the protocolachieve our goal. In the following section we give an example of a working instance, thus ensuring that this familyis not empty.The first hypothesis specifies the behaviour of the choose_target function. It expresses that its outputmust:• be in range, that is be within the input (an observation) to choose_target ; In the actual code, each of these five properties is split into its own independent statement for greater flexibility. ba c D ba c Figure 5: To avoid elimination at launch, the base waits for a robot a to be at more than D max − D beforelaunching another robot. On the left, as the base decides to launch a new robot, robot a is too close to robot b andwill withdraw. The next round is on the right: b is now too close to c and may withdraw, leaving only c, whichmoves further away. As the new robot is launched, robot c should however be still visible from the base . The newrobot was launched too late.• be alive;• have a smaller identifier that the observing robot;• preferably have its light off , that is, if the target has its light on, then all robots within range also do;• preferably select close robots, that is, if the target is in the pursuit zone and has its light on, then all robotswithin range are also in the pursuit zone. Axiom choose_target_spec : ∀ obs_id local_config, let obs := obs_from_config local_config inlet target := choose_target obs_id obs in (* the target must be in range *)target ∈ obs(* the target must be alive *) ∧ get_alive target = true(* the target must have a smaller id *) ∧ get_ident target < get_ident obs_id(* the target must preferably have its light off *) ∧ (get_light target = true → ∀ id ∈ obs, get_light id = true)(* the target must preferably be close *) ∧ (get_light target = true → dist (0,0) (get_loc target) > Dp → ∀ id ∈ obs, dist (0,0) (get_loc elt) > Dp). The second property specifies choose_new_pos : the new location is reachable with the speed of the ob-serving robot (it is at most D away from its current location) and not too far from its target (at most D p away fromit, thus out of the pursuit zone). Axiom choose_new_pos_spec : ∀ obs target, let new := choose_new_pos obs target in dist new target ≤ Dp ∧ dist new (0,0) ≤ D. Finally, the specification of move_to is split in two depending on whether movement is possible or not. If itis possible, the chosen location is at least D away from all other robots.13 xiom move_to_true_spec : ∀ obs choice,move_to obs choice = true → ∀ id, id ∈ obs → dist choice get_loc id > 2*D. If movement is not possible, there is a robot with smaller identifier too close to the chosen location, that is,inside its danger zone (within a disc of radius D ). Axiom move_to_false_spec : ∀ state local_config new_loc, let obs := obs_from_config local_config state in move_to obs new_loc = false → ∃ other, other ∈ obs ∧ get_ident other < get_ident state ∧ dist (get_loc other) new_loc ≤ Correctness proof of the family of solutions
The proof amounts to ensuring that the property
NoCollAndPath given in Section 4.1 is an invariant of theexecution. This property combines no_collision_conf (the absence of collision) and path_conf (whichentails the existence of a path from the base to the companion). We only sketch the proofs to convey their insight,for further detail we direct the interested reader to the C OQ files.The absence of collision can be directly proven to be an invariant. Assume that two robots that do not start atthe same location collide after their move. Let id and id (cid:48) be the identifiers of the robots, with id < id (cid:48) . Sincethe robots are going to collide and none of them can travel more than D , they start at most D apart. Since id (cid:48) observes a robot with lower identifier id in its danger zone, it does not move. Thus, to provoke a collision, id and id (cid:48) should start at most D apart. In this case, id is actually in the collision zone of id (cid:48) , so id (cid:48) withdraws andthere is no collision.Proving that the existence of a path is invariant is more subtle and we need to introduce three other propertiesthat give more insight into the behaviour of the protocol:• executed_means_light_on expressing that if a robot withdraws at the next round, then it has its light on (it is aware that it is in a potentially dangerous situation);• executioner_means_light_off expressing that if a robot withdraws at the next round, then the robotcausing this removal has its light off (ensuring that it cannot disappear too);• exists_at_less_than_Dp expressing that if all robots of lower identifier in range of an alive robot r have their light on , then one of them is not in the pursuit zone of r (at most D p away from r ).These properties are proven by case analysis over two consecutive rounds, let us call them cf , cf (cid:48) .For the property executed_means_light_on , remark that if a robot r alive in cf withdraws in cf (cid:48) , it iseither because, in cf (cid:48) , there is no robot in range or there is one too close (at most D away). By contradic-tion, let us assume that r withdraws in cf (cid:48) while not deciding to turn its light on in cf . Since the light is on when move_to returns false , we know this function returns true in cf , and r thus performs the move chosenby choose_new_pos between cf and cf (cid:48) . Thus r cannot lose contact with its target: by the specification of choose_new_pos r moved at a distance no greater than D p to the cf -location of its target, that is at a distanceno greater than D P + D = D max to the cf (cid:48) -location of the target. Moreover, r cannot withdraw due to anotherrobot at a distance less than D in cf (cid:48) : by the specification of choose_new_pos it moved at a distance more than D apart from the cf -location of any other robot of lower identifier, that is more than D − D = D apart fromthe cf (cid:48) -location of any other robot of lower identifier.For the property executioner_means_light_off , note that by the definition of the abstract protocol, amoving robot always has its light off (by a simple case analysis on move_to ).By the property executed_means_light_on a robot r alive in cf that withdraws in cf (cid:48) has its light on and did not move between cf and cf (cid:48) . If r stays alive in cf and withdraws in cf (cid:48) , then some other robot r (cid:48) is at a distance from r that is greater than D in cf and at most D in cf’ . Since r does not move between theconfigurations, r (cid:48) necessary does, and thus has its light off .We show now that exists_at_less_than_Dp holds for cf (cid:48) . Let us consider an alive robot r in cf (cid:48) suchthat all robots in range have their light on . We want to prove that at least one of them is at most D p away. Notethat as r is alive in cf (cid:48) , there was a robot in range in cf and r had a target r (cid:48) in cf . Since r (cid:48) has its light on in cf (cid:48) ,14t did not move between cf and cf (cid:48) . If r (cid:48) was out of the pursuit zone of r in cf (that is, at most D p away from r ), we can conclude because r either did not move or moved to a position not farther that D p away from r (cid:48) . If r (cid:48) was inside the pursuit zone if r in cf , by the specification of choose_target , so were all robots in range of r .In particular, r could move towards r (cid:48) as no robot was inside its danger zone and since r (cid:48) did not move, r and r (cid:48) are at most D p away in cf (cid:48) .Finally, let us turn to the proof that the property path_conf is an invariant. Let r be a relay robot. We provethat it has a visible, active, launched neighbour with a smaller id. We consider several cases depending on thevalue of move_to and whether the target of r withdraws.If move_to is true and r (cid:48) has its light off , then by property executioner_means_light_off r (cid:48) cannotwithdraw, and cannot get out of range of r since r moves closer to r (cid:48) .If move_to is true and r (cid:48) has its light on , the invariant exists_at_less_than_Dp and the specificationof choose_target entail that all robots in range of r have their light on and that r (cid:48) is out of the pursuit zone.Hence, r (cid:48) cannot withdraw since all robot close enough to eliminate it have their light on thus cannot cause it towithdraw (by executioner_means_light_off ).If move_to is false , then by move_to_false_spec , there is a robot with smaller id in range of r . Proof effort
The proof effort for this work is decomposed in setup, specifications and actual proofs.It consists of lines of setup to instantiate the context (definition of robots state, observation, etc.), linesof C OQ of specifications to describe the problem.The proof part is much more verbose, the table below show how many lines of proof tactics were used for themain invariants. Stability of main invariants no_collision_conf executed_means_light_on executioner_means_light_off exists_at_less_than_Dp path_conf ≈ In the previous sections we designed a family of solutions defined by a template robogram function. The templaterobogram is parameterized by three auxiliary functions, each one being restricted by some axioms. Hence we canobtain a concrete solution by providing for each of the auxiliary functions a concrete definition that is consistentwith the corresponding axioms.It is again possible to develop such a concrete solution in our formal framework. Indeed, the P
ACTOLE libraryalready provides some instances of concrete algorithms proven correct for other problems [4, 12]. However, if theaxioms are simple enough one can also consider that most of the complex and error-prone reasoning on the modelhas been taken care of, and that a traditional pen-and-paper check provides a satisfying level of certainty.In this section we exhibit a concrete solution, for which we check the axioms by hand. Please note that theselected solution has no particular property, and is not supposed to be more efficient, or better in any sense thanthe other members of our family of solutions. The concrete solution is chosen as one of the most straightforwardvalidations of the axioms. In other words, the solution we present is a naive solution (or at least, it is naive oncethe axioms have been designed ). Such a solution provides a sanity check of our axioms: it witnesses that ourfamily of solutions is not empty.
Concretisation of choose_target
We take the point of view of a robot with identifier n , in a configuration satisfying the invariants of the algorithm.Define V the subset of the observed robots that are• alive• at a distance at most D max
15 with an identifier strictly smaller than n If there is at least one robot in V whose light is off , then select any robot in the subset V off of V containing therobots with lights off . For instance, select the robot in V off with minimal identifier. If however all robots in V have their lights on, then select any robot in the subset V Dp of V containing the robots at a distance at most D p .For instance, select the robot in V Dp with minimal identifier. Otherwise select any robot in V , for instance therobot in V with minimal identifier.We have to check that this function is defined and satisfies all the axioms. First note that, following theinvariant path_conf , there is at least one robot that is alive, at a distance at most D max of n and with an identifierstrictly smaller than n . Hence the set V is not empty, and our function is defined. Second, the result of thisfunction is a robot of V . As such it is visible, alive and and with an identifier strictly smaller than n (three firstparts of axiom choose_target_spec are satisfied). Third, the result has its light off as soon as there is at leastone visible robot with its light off : fourth part of choose_target_spec is also satisfied. Finally, when thereare only robots with their lights on, the result is a robot at a distance at most D p if there is one: the fifth and finalpart of axiom choose_target_spec is again satisfied. Hence our naive choose_target function satisfies allthe relevant axioms. Concretisation of choose_new_pos
We take the point of view of a robot with an already chosen target at distance at most D max . One can select thepotential move of the robot as follows:• if the target robot is at a distance greater than D p , then choose a move of length D toward the target;• otherwise, choose a null move.This tentative move aims at a position at distance at most D from the starting position, and at most D p from thetarget. It thus complies with the axiom choose_new_pos_spec . Concretisation of move_to
We take the point of view of a robot with a potential move already selected, with some observed configuration.Validation of the potential move can be performed as follows:• if there is any other robot at most D away from the potential destination, then invalidate the potential moveby returning false ;• otherwise, validate the potential move by returning true .This function returns true only if there is no robot at a distance to the potential destination less or equal to D : the axiom move_to_Some_zone is satisfied. Conversely, the function returns false only if there is anobservable other robot at a distance to the potential destination less or equal to D : the axiom move_to_None isalso satisfied.Finally, the three parameter functions choose_target , choose_new_pos , and move_to all satisfy theirrespective axioms: they define a proper member of our family of solutions, which is not empty. In this paper, we demonstrated by example how formal methods, and the P
ACTOLE framework in particular,can help mobile robotic swarm protocol designers to formally specify, design, and prove their algorithms arecorrect, balancing expressivity to tackle practically relevant problems, and formality to preserve the mathematicalsoundness of software developments.Of course, proving correct algorithms for new problems is only the first step. A natural second step is to ensurethe implementations of the algorithms maintain the relevant invariants when actually deployed on real devices. Weleave this path for future research. 16 eferences [1] K. Altisen, P. Corbineau, and S. Devismes. A framework for certified self-stabilization. In E. Albert andI. Lanese, editors,
Formal Techniques for Distributed Objects, Components, and Systems - 36th IFIP WG6.1 International Conference, FORTE 2016, Held as Part of the 11th International Federated Conference onDistributed Computing Techniques, DisCoTec 2016, Heraklion, Crete, Greece, June 6-9, 2016, Proceedings ,volume 9688 of
Lecture Notes in Computer Science , pages 36–51. Springer-Verlag, 2016.[2] C. Auger, Z. Bouzid, P. Courtieu, S. Tixeuil, and X. Urbain. Certified Impossibility Results forByzantine-Tolerant Mobile Robots. In T. Higashino, Y. Katayama, T. Masuzawa, M. Potop-Butucaru, andM. Yamashita, editors,
Stabilization, Safety, and Security of Distributed Systems - 15th International Sym-posium (SSS 2013) , volume 8255 of
Lecture Notes in Computer Science , pages 178–186, Osaka, Japan, Nov.2013. Springer-Verlag.[3] T. Balabonski, P. Courtieu, R. Pelle, L. Rieg, S. Tixeuil, and X. Urbain. Continuous vs. discrete asynchronousmoves: A certified approach for mobile robots. In M. F. Atig and A. A. Schwarzmann, editors,
NetworkedSystems - 7th International Conference, NETYS 2019, Marrakech, Morocco, June 19-21, 2019, RevisedSelected Papers , volume 11704 of
Lecture Notes in Computer Science , pages 93–109. Springer-Verlag, 2019.[4] T. Balabonski, A. Delga, L. Rieg, S. Tixeuil, and X. Urbain. Synchronous gathering without multipli-city detection: A certified algorithm.
Theory of Computing Systems , 2019. https://doi.org/10.1007/s00224-017-9828-z .[5] T. Balabonski, R. Pelle, L. Rieg, and S. Tixeuil. A foundational framework for certified impossibility resultswith mobile robots on graphs. In P. Bellavista and V. K. Garg, editors,
Proceedings of the 19th InternationalConference on Distributed Computing and Networking, ICDCN 2018, Varanasi, India, January 4-7, 2018 ,pages 5:1–5:10. ACM, 2018.[6] B. Bérard, P. Lafourcade, L. Millet, M. Potop-Butucaru, Y. Thierry-Mieg, and S. Tixeuil. Formal verificationof mobile robot protocols.
Distributed Computing , 29(6):459–487, 2016.[7] M. Bezem, R. Bol, and J. F. Groote. Formalizing Process Algebraic Verifications in the Calculus of Con-structions.
Formal Aspects of Computing , 9:1–48, 1997.[8] F. Bonnet, X. Défago, F. Petit, M. Potop-Butucaru, and S. Tixeuil. Discovering and assessing fine-grainedmetrics in robot networks protocols. In , pages 50–59. IEEE, 2014.[9] J. Castenow, P. Kling, T. Knollmann, and F. M. auf der Heide. A discrete and continuous study of the max-chain-formation problem: Slow down to speed up. In C. Scheideler and M. Spear, editors,
SPAA ’20: 32ndACM Symposium on Parallelism in Algorithms and Architectures, Virtual Event, USA, July 15-17, 2020 ,pages 515–517. ACM, 2020.[10] T. Coquand and C. Paulin-Mohring. Inductively Defined Types. In P. Martin-Löf and G. Mints, editors,
International Conference on Computer Logic (Colog’88) , volume 417 of
Lecture Notes in Computer Science ,pages 50–66. Springer-Verlag, 1990.[11] P. Courtieu, L. Rieg, S. Tixeuil, and X. Urbain. Impossibility of Gathering, a Certification.
InformationProcessing Letters , 115:447–452, 2015.[12] P. Courtieu, L. Rieg, S. Tixeuil, and X. Urbain. Certified universal gathering algorithm in R for obli-vious mobile robots. In C. Gavoille and D. Ilcinkas, editors, Distributed Computing - 30th InternationalSymposium, (DISC 2016) , volume 9888 of
Lecture Notes in Computer Science , Paris, France, Sept. 2016.Springer-Verlag.[13] D. Cousineau, D. Doligez, L. Lamport, S. Merz, D. Ricketts, and H. Vanzetto. TLA + Proofs. In D. Gian-nakopoulou and D. Méry, editors, FM , volume 7436 of Lecture Notes in Computer Science , pages 147–154,Paris, France, Aug. 2012. Springer-Verlag. 1714] X. Défago, A. Heriban, S. Tixeuil, and K. Wada. Using model checking to formally verify rendezvousalgorithms for robots with lights in euclidean space. In
International Symposium on Reliable DistributedSystems, SRDS 2020, Shanghai, China, September 21-24, 2020 , pages 113–122. IEEE, 2020.[15] Y. Deng and J.-F. Monin. Verifying Self-stabilizing Population Protocols with Coq. In W.-N. Chin andS. Qin, editors,
Third IEEE International Symposium on Theoretical Aspects of Software Engineering (TASE2009) , pages 201–208, Tianjin, China, July 2009. IEEE Computer Society.[16] S. Devismes, A. Lamani, F. Petit, P. Raymond, and S. Tixeuil. Optimal Grid Exploration by AsynchronousOblivious Robots. In A. W. Richa and C. Scheideler, editors,
Stabilization, Safety, and Security of DistributedSystems - 14th International Symposium (SSS 2012) , volume 7596 of
Lecture Notes in Computer Science ,pages 64–76, Toronto, Canada, Oct. 2012. Springer-Verlag.[17] H. T. T. Doan, F. Bonnet, and K. Ogata. Model checking of a mobile robots perpetual exploration al-gorithm. In S. Liu, Z. Duan, C. Tian, and F. Nagoya, editors,
Structured Object-Oriented Formal Languageand Method - 6th International Workshop, SOFL+MSVL 2016, Tokyo, Japan, November 15, 2016, RevisedSelected Papers , volume 10189 of
Lecture Notes in Computer Science , pages 201–219, 2016.[18] H. T. T. Doan, F. Bonnet, and K. Ogata. Model checking of robot gathering. In J. Aspnes, A. Bessani,P. Felber, and J. Leitão, editors, , volume 95 of
LIPIcs , pages 12:1–12:16. Schloss Dagstuhl -Leibniz-Zentrum für Informatik, 2017.[19] P. Flocchini, G. Prencipe, N. Santoro, and P. Widmayer. Gathering of asynchronous robots with limitedvisibility.
Theor. Comput. Sci. , 337(1-3):147–168, 2005.[20] W. Fokkink.
Modelling Distributed Systems . EATCS Texts in Theoretical Computer Science. Springer-Verlag, 2007.[21] N. Gaspar, L. Henrio, and E. Madelaine. Bringing coq into the world of gcm distributed applications. pages643–662, 2014.[22] P. Kling and F. M. auf der Heide. Continuous protocols for swarm robotics. In P. Flocchini, G. Prencipe, andN. Santoro, editors,
Distributed Computing by Mobile Entities, Current Research in Moving and Computing ,volume 11340 of
Lecture Notes in Computer Science , pages 317–334. Springer, 2019.[23] P. Küfner, U. Nestmann, and C. Rickmann. Formal Verification of Distributed Algorithms - From PseudoCode to Checked Proofs. In J. C. M. Baeten, T. Ball, and F. S. de Boer, editors,
IFIP TCS , volume 7604of
Lecture Notes in Computer Science , pages 209–224, Amsterdam, The Netherlands, Sept. 2012. Springer-Verlag.[24] L. Lamport. The temporal logic of actions.
ACM Trans. Program. Lang. Syst. , 16(3):872–923, May 1994.[25] L. Millet, M. Potop-Butucaru, N. Sznajder, and S. Tixeuil. On the synthesis of mobile robots algorithms: Thecase of ring gathering. In P. Felber and V. K. Garg, editors,
Stabilization, Safety, and Security of DistributedSystems - 16th International Symposium, (SSS 2014) , volume 8756 of
Lecture Notes in Computer Science ,pages 237–251, Paderborn, Germany, Sept. 2014. Springer-Verlag.[26] L. Reynaud and I. G. Lassous. Design of a force-based controlled mobility on aerial vehicles for pestmanagement.
Ad-Hoc Networks , 53:41–52, 2016.[27] A. Sangnier, N. Sznajder, M. Potop-Butucaru, and S. Tixeuil. Parameterized verification of algorithms foroblivious robots on a ring.
Formal Methods Syst. Des. , 56(1):55–89, 2020.[28] I. Suzuki and M. Yamashita. Distributed Anonymous Mobile Robots: Formation of Geometric Patterns.