A Formal Safety Net for Waypoint Following in Ground Robots

TL;DR

This paper introduces a formally verified safety net for ground robots that guarantees safe waypoint following by modeling, proving properties, and synthesizing runtime monitors, ensuring safety even with untrusted controllers.

Contribution

It presents a reusable, formally verified safety framework for 2D waypoint-following in ground robots, integrating modeling, proof, and runtime enforcement with machine code guarantees.

Findings

Formal safety and liveness guarantees for waypoint-following

Runtime monitor enforces model compliance at execution

Experimental validation confirms practical applicability

Abstract

We present a reusable formally verified safety net that provides end-to-end safety and liveness guarantees for 2D waypoint-following of Dubins-type ground robots with tolerances and acceleration. We: i) Model a robot in differential dynamic logic (dL), and specify assumptions on the controller and robot kinematics, ii) Prove formal safety and liveness properties for waypoint-following with speed limits, iii) Synthesize a monitor, which is automatically proven to enforce model compliance at runtime, and iv) Our use of the VeriPhy toolchain makes these guarantees carry over down to the level of machine code with untrusted controllers, environments, and plans. The guarantees for the safety net apply to any robot as long as the waypoints are chosen safely and the physical assumptions in its model hold. Experiments show these assumptions hold in practice, with an inherent trade-off between compliance and performance.

Tables

Table 1. TABLE I : Hybrid programs

Program	Means
$?\varphi$	Results in current state if $\varphi$ is true, no states if false.
$x:=\theta$	Store value of expression $\theta$ in variable $x$.
$x:=\ast$	Store arbitrary (real) number in variable $x$.
	Evolve ODE $x^{\prime }=\theta$ for any duration $t\ge 0,$
	with constraint formula $\psi$ true throughout.
$\alpha ;\beta$	Run $\alpha ,$ then $\beta$ in any resulting state(s).
$\alpha \cup \beta$	Choose between running $\alpha$ or $\beta$.
${\alpha }^{\ast }$	Repeats $\alpha$ $n$ times, for any $n\in \mathbb{N}$.

Table 2. TABLE II : Average speed, Monitor failure rates, for AirSim and human driver in each environment

	Avg. Speed (m/s)					Ctrl Fail.					Plant Fail.
World	BB	PD1	PD2	PD3	Human	BB	PD1	PD2	PD3	Human	BB	PD1	PD2	PD3	Human
Rect	4.3	6.32	7.16	12.6	9.92	0.5%	0.1%	0.1%	0.19%	1.14%	36.8%	8.23%	8.5%	14%	41.3%
Turns	3.78	3.95	4.43	4.69	9.66	1.0%	1.0%	1.1%	4.7%	3.61%	18.6%	3.95%	6.8%	11%	21.1%
Clover	X	29.5	29.5	29.5	28.9	X	0.2%	0.2%	0.19%	0.29%	X	66%	66%	66%	48%

Equations

$$\equiv \text{go}\cup \text{stop}$$

$$\equiv v:=0$$

$$\displaystyle\phi,\psi::=\phi\land\psi\$$

$$\displaystyle|\ \forall{x}{~{}\phi}\$$

$$d\ge 0\wedge V\ge 0\wedge T\ge 0\to [{(\text{1Dctrl};\text{1Dplant})}^{\ast }]d\ge 0$$

$$\text{plant}\equiv \text{t}:=0;\{$$

$${\text{t}}^{\prime }=1\&\text{t}\le \text{T}\wedge \text{v}\ge 0\}$$

$$\equiv (\text{x},\text{y}):=\ast ;[\text{vl},\text{vh}]:=\ast ;\text{k}:=\ast ;?\text{Feas};\underset{\_}{\underbrace{\text{a}:=\ast ;?\text{Go}}}{\text{ctrl}}_{\_}\text{a}$$

$$\displaystyle~{}\equiv~{}\lvert{\textsf{k}}\rvert\varepsilon\leq 1\land\Big{|}\frac{{\textsf{k}}~{}\left(\textsf{x}^{2}+\textsf{y}^{2}-\varepsilon^{2}\right)}{2}-\textsf{y}\Big{|}<\varepsilon$$

$$\equiv \text{Ann}\wedge \text{x}>0\wedge 0\le \text{vl}<\text{vh}\wedge \text{A}\text{T}\le \text{vh}-\text{vl}\wedge \text{B}\text{T}\le \text{vh}-\text{vl}$$

$$\equiv -\text{B}\le \text{a}\le \text{A}\wedge \text{v}+\text{a}\text{T}\ge 0$$

$$\wedge$$

$$\displaystyle(1+\lvert{\textsf{k}}\rvert\varepsilon)^{2}\Bigl{(}\textsf{v}\textsf{T}+\frac{\textsf{a}}{2}\textsf{T}^{2}+\frac{(\textsf{v}{+}\textsf{a}\textsf{T})^{2}-\textsf{vh}^{2}}{2\textsf{B}}\Bigr{)}+\varepsilon{\leq}{{\|(\textsf{x},\textsf{y})\|}_{\_}{\infty}}\Bigr{)}$$

$$\wedge$$

$$\displaystyle(1+\lvert{\textsf{k}}\rvert\varepsilon)^{2}\Bigl{(}\textsf{v}\textsf{T}+\frac{\textsf{a}}{2}\textsf{T}^{2}+\frac{\textsf{vl}^{2}-(\textsf{v}{+}\textsf{a}\textsf{T})^{2}}{2\textsf{A}}\Bigr{)}+\varepsilon{\leq}{{\|(\textsf{x},\textsf{y})\|}_{\_}{\infty}}\Bigr{)}$$

$$\overbrace{\vphantom{\frac{\textsf{T}}{\textsf{B}}}\textsf{v}\textsf{T}+\frac{\textsf{a}}{2}\textsf{T}^{2}}^{\mathchoice{\hbox to0.0pt{\hss$\displaystyle{\text{distance at}~{}\textsf{T}}$\hss}}{\hbox to0.0pt{\hss$\textstyle{\text{distance at}~{}\textsf{T}}$\hss}}{\hbox to0.0pt{\hss$\scriptstyle{\text{distance at}~{}\textsf{T}}$\hss}}{\hbox to0.0pt{\hss$\scriptscriptstyle{\text{distance at}~{}\textsf{T}}$\hss}}}+\frac{(\overbrace{\textsf{v}{+}\textsf{a}\textsf{T}}^{\mathchoice{\hbox to0.0pt{\hss$\displaystyle{\text{speed at}~{}\textsf{T}}$\hss}}{\hbox to0.0pt{\hss$\textstyle{\text{speed at}~{}\textsf{T}}$\hss}}{\hbox to0.0pt{\hss$\scriptstyle{\text{speed at}~{}\textsf{T}}$\hss}}{\hbox to0.0pt{\hss$\scriptscriptstyle{\text{speed at}~{}\textsf{T}}$\hss}}})^{2}-\textsf{vh}^{2}}{2\textsf{B}}+\varepsilon\leq{{\|(\textsf{x},\textsf{y})\|}_{\_}{\infty}}$$

$$\text{A}>0$$

$$\displaystyle{[{{(\textsf{ctrl};\textsf{plant})}^{*}}]}\big{(}\|(\textsf{x},\textsf{y})\|\leq\varepsilon\rightarrow\textsf{v}\in[\textsf{vl},\textsf{vh}]\big{)}$$

$$\text{A}>0$$

$$\displaystyle{[{{(\textsf{ctrl};\textsf{plant})}^{*}}]}\Big{(}\textsf{v}{>}0\land\textsf{x}{>}0\rightarrow$$

$$\displaystyle\ \ \ \ {\langle{{(\textsf{ctrl}_{\_}{\text{a}};\textsf{plant})}^{*}}\rangle}\big{(}\|(\textsf{x},\textsf{y})\|\leq\varepsilon~{}\land~{}\textsf{v}\in[\textsf{vl},\textsf{vh}]\big{)}\Big{)}$$

$${\delta }_{\_}\mathsf{Lim}(v_{\_}1,v_{\_}2,a)$$

$$\mathsf{Lim}(v_{\_}1,v_{\_}2,a,\text{x},\text{y})$$

$$\begin{gathered} J\equiv \text{Ann}\wedge 0\le \text{vl}<\text{vh}\wedge \text{A}\text{T}\le \text{vh}-\text{vl}\wedge \text{B}\text{T}\le \text{vh}-\text{vl} \\ \wedge \mathsf{Lim}(\text{vl},\text{v},\text{A},\text{x},\text{y})\wedge \mathsf{Lim}(\text{v},\text{vh},\text{B},\text{x},\text{y}) \end{gathered}$$

$$\text{immediate}\text{hypertarget}ir:loop\text{(loop)}\frac{P\to JJ\to QJ\to [\alpha ]J}{P\to [{\alpha }^{\ast }]Q}$$

$$\text{immediate}\text{hypertarget}ir:auto\text{(auto)}\frac{J,\text{Feas},\text{Go}\to [\text{plant}]J}{J\to [\text{ctrl};\text{plant}]J}$$

$$J\wedge \text{v}>0\wedge \text{x}>0\to ⟨{({\text{ctrl}}_{\_}\text{a};\text{plant})}^{\ast }⟩(v\in [\text{vl},\text{vh}]\wedge \Vert (\text{x},\text{y})\Vert \le \epsilon )$$

$$J\wedge \text{v}>0\wedge \text{x}>0\to ⟨{({\text{ctrl}}_{\_}\text{a};\text{plant})}^{\ast }⟩(\text{v}\in [\text{vl},\text{vh}])$$

$$\begin{gathered} \text{v}>0\wedge \text{v}\in [\text{vl},\text{vh}]\wedge \text{Ann}\to \\ ⟨{({\text{ctrl}}_{\_}\text{a};\text{plant})}^{\ast }⟩(\text{v}\in [\text{vl},\text{vh}]\wedge \Vert (\text{x},\text{y})\Vert \le \epsilon ) \end{gathered}$$

Full text

I Introduction

Many autonomous ground robots are safety-critical because they operate near or in concert with humans. Formally verifying these systems is important: logic allows rigorous correctness arguments that apply in all system states, providing a powerful complement to system testing. Yet for robotics, even choosing a property to formally verify is challenging: many modeling abstractions and safety properties are available, with competing trade-offs. Discrete techniques can be applied to control software, but robots are cyber-physical systems: their verification must account for discrete controllers, continuous mechanics, and interactions between them.

Hybrid systems [1] emerged as mathematical models for robots because they integrate discrete with continuous dynamics, but they raise new questions about what it means to verify a robot. Robot kinematics are endlessly nuanced, so any model is always an approximation of reality. Even control software is rarely modeled exactly: simplifications are necessary in practice to limit verification complexity. Moreover, control software evolves throughout its development, and since verification of arbitrary programs cannot be fully automated, re-verifying control code after every change would be impractical.

How then ought a robot be verified? Online monitoring, per the Simplex method [2], offers a solution: run the control software, but treat its control decision as an untrusted suggestion which is supervised against a trusted monitor condition $\phi$ describing all “known-safe” decisions. Whenever the suggestion is known-safe the supervising monitor allows it to proceed, but otherwise invokes a trusted fallback decision, like emergency braking, to regain safety before returning control to the untrusted controller. Online monitoring is appealing because it enables treating the controller as a black box: only the monitor condition and fallback are safety-critical, both of which are simpler and can often be re-used as the control software evolves, or even across hardware platforms. To promote reusability, we target a waypoint-following notion of safety: other notions of safety such as collision-avoidance often come with restrictive assumptions, e.g., on the quantity and dynamics of obstacles, whereas waypoint-following abstracts away such problems under the choice of safe waypoints.

The monitor conditions and fallback are both best kept simple. While steering enables active safety and may reduce the required braking power, we simply brake at the maximum rate. Regardless which fallback is used, however, what is essential is that the monitor conditions and fallback provide safety. The ModelPlex [3] synthesizer and VeriPhy [4] compilation toolchain ensures safety at implementation level by:

i) synthesizing correct-by-construction monitor conditions $\phi$ from a proven-safe hybrid systems model containing a proven-safe fallback (ModelPlex)

ii) soundly compiling high-level monitor conditions and high-level fallback programs to machine-code monitor implementations with sound machine arithmetic (VeriPhy).

ModelPlex and VeriPhy expand upon the reusability inherent to the black-box approach: hybrid systems models and proofs can treat many system parameters (e.g., tolerances and system delay) generically, once and for all, for all choices of the parameters. The hybrid system model can be used as a template: new monitors can often be generated for new systems without doing new proofs, so long as choosing system parameters suffices to faithfully model the new system. The VeriPhy approach is also end-to-end in that VeriPhy outputs a chain of formal proofs, in theorem provers, that the actions taken by the machine-level (monitored) program fall under the original model and are thus formally safe. Even then, some guarantees are lost when sensors and actuators are buggy, when monitor conditions for the physical dynamics are violated, or when an unsafe plan is provided: we discuss these limitations in related work (Sect. II).

The VeriPhy approach has until now only been tested on an overly simplistic low-speed robot implementing a model of straight-line motion with direct velocity control. In this paper, we show for the first time that this approach scales to realistic models and simulations:

• •

We model as a hybrid program [5] a 2D accelerating vehicle that follows bloated Dubins paths.

• •

We prove safety and liveness properties for the model with the KeYmaera X theorem prover [6] for differential dynamic logic (dL) [5].

• •

We use VeriPhy [4] to synthesize a monitor and to automatically prove its correctness down to the machine code implementation, which gives an end-to-end proof.

Waypoint-following has the advantage of a clean interface to other robot software with its dual purposes of both safety (avoiding unsafe regions) and liveness (reaching its goal). We call waypoint-following safe iff the robot always follows the given path to its waypoint within a given tolerance and obeys given speed limits. Collision freedom then reduces to checking that correct waypoints and speed limits were given. The system is live if at all points it is possible to drive the rest of the way to the waypoint.

Obstacle avoidance [7], in contrast, directly verifies collision freedom, but liveness is challenging to even state let alone prove. The mix of safety and liveness is essential because a motionless robot is technically safe, but neither live nor useful because it never reaches its goal. By studying safety and liveness of waypoint-following, we provide a clean separation of concerns compared to the orthogonal question of verifying a discrete planner [8].

Bloating the 2D Dubins dynamics adds an additional tolerance margin to the ideal dynamics which accounts for the gap between the approximate dynamical model and reality (Sect. IV). Our evaluation shows that:

i) a variety of classical control choices such as bang-bang and PD control fit within the bloated ideal path

ii) the model assumptions hold in practice because AirSim’s non-holonomic dynamics fall within bloated ideal holonomic Dubins dynamics, and

iii) there is a trade-off between meeting model assumptions and operational performance: more aggressive controllers break assumptions more often.

This paper also serves as a case study on safety and liveness verification: once the safety property is proved, much of the effort can be reused to prove liveness. The safety and liveness proof were performed interactively, but crucially need only be performed once per dL model, which describes an entire class of systems. Thanks to the automated proofs provided by VeriPhy, runtime monitors can be applied to new controls and even new hardware or simulation platforms with no additional manual proofs, so long as the controls and dynamics stay within a tolerance around the ideal holonomic dynamics, so that the same dL model applies. Because the model treats system parameters (such as system delays and tolerances) generically, a wide variety of Dubins-like systems are already supported simply by changing the parameters. That is how we developed a formal safety net for ground robots and evaluated it on a realistic simulation. Because the monitor is reusable, we hope our safety net can assist future implementers in developing new systems.

II Related work

Related work in formal methods and robotics applied synthesis and verification techniques to safe robotic control. This paper is the first to use a verified-safe monitor to enforce waypoint-following correctness of a realistic simulation.

II-A Synthesis for Verified Planning and Control

Much of the existing related work considers high-level plan synthesis in isolation, with informal proofs of correctness. Our work is complementary: we address correctness of low-level control, provide formal guarantees, and check rather than assume that runtime physics matches the model:

• •

The tools LTLMoP [9] and TuLiP [10] synthesize robot controls that satisfy a temporal logic specification. They excel at providing an intuitive user interface for specifying discrete planning problems, though discretization [11, 12] can be used to support continuous dynamics. We focus instead on providing the highest degree of confidence by proving safety in a theorem prover, including proofs of the dynamics and down to machine-code level.

• •

Controllers have been synthesized:

i) from temporal logic specifications for linear systems [13],

ii) for adaptive cruise control [14], tested in simulation and on hardware, and

iii) from safety proofs [15] for switched systems using templates.

These all assume model compliance and cannot ensure feedback controller correctness.

II-B Offline Verification for Planning and Control

In contrast to online synthesis, offline verification can show safety in all uncountably many states. High-level models of the system under consideration can already be verified during the design phase of a project when changes are cheap. Much robotics verification work focuses on hybrid systems models; common approaches are reachability analysis [16] and theorem proving [6]. Both have been applied in case studies [7, 17] and experience shows that reachability typically provides more automation while theorem proving supports a powerful combination of rigorous foundations and establishes guarantees for unbounded time and space. Both approaches can be combined with monitoring:

• •

1D straight-line motion was addressed both in dL [4] and with reachability analysis [18], but 1D uses simpler verification technology and is not suitable for real robots.

• •

Unbounded-time 2D obstacle avoidance and 1D liveness have also been proved in dL [7], and liveness has been proved on paper [19]. Their controllers, like ours, are related to the Dynamic-Window [20] algorithm. Our novel results include 2D liveness, waypoint-following, and end-to-end correctness. While collision avoidance is simpler in prior work, their approach precludes liveness, which we proved. Prior dL efforts treat sensor errors explicitly, for which synthesis is subject of ongoing work [21]. In contrast, we integrate synthesized monitors with a simulation while keeping guarantees. To this end, we use a single tolerance for sensing/actuation error and deviation of real dynamics from the model. The limitation of this approach is that our guarantees do not explicitly incorporate sensor errors.

• •

A planner for ground vehicles was verified [8] in Isabelle. Their physics are close to ours, but feedback control and implementation correctness are not addressed.

II-C Online Verification

Online/runtime verification provides a runtime safety net, but the correctness of the safety net itself is then critical to system safety. In contrast to offline verification, online verification cannot predict safety for infinitely many states.

• •

The basis of online verification is the Simplex [2] method, which uses a trusted monitor to decide between an untrusted controller and trusted fallback.

• •

The VeriPhy [4] toolchain for dL, which we use, combines offline and online verification to extend Simplex by ensuring the monitor is correct-by-construction, formally proving its safety, and maintaining those guarantees down to machine code implementations.

• •

Runtime monitoring has been combined with nonexhaustive model checking and evaluated in simulation [22]. Their relative strengths are in correctness of high-level event-handling logic and experimentally learning tolerances for the dynamics. Our relative strengths are use of a theorem-prover to show safety in all states, richer physical dynamics, and correct-by-construction monitors.

• •

Runtime reachability analysis has been used for Dubins-like car control [23], but runtime model compliance is not enforced and the reachability checker is trusted.

II-D Simulation

Simulation is an essential part of evaluating models and designs. We used the AirSim [24] simulator for autonomous cars (originally for UAVs), because it comes with accurate physical and visual models out-of-the-box. Using these existing models provides a degree of independence in our evaluation.

In short, while verification of robotics receives frequent attention, few works have addressed rigorous end-to-end guarantees. We develop the first realistic system with formal end-to-end safety and liveness guarantees for 2D waypoint following, by generating a runtime monitor from a verified model. Crucially, we expect this runtime safety net can be applied to other Dubins-like system without redoing any proofs.

III Background: Differential dynamic logic

We write our model as a hybrid program and use differential dynamic logic (dL) [5] to verify it. Hybrid programs express hybrid systems as programs containing differential equations (ODEs). They are particularly useful for verified robotics because they concisely describe both the control laws and kinematics of the system. Table I gives the syntax of hybrid programs and informally describes their semantics, wherein running a program $\alpha$ results in zero, one, or many different states. Detailed formal semantics are provided elsewhere [5].

Typical controllers use assignments $x\mathrel{{:}{=}}\theta$ to store the value of (polynomial) expression $\theta$ in variable $x,$ or assign an arbitrary value ($x\mathrel{{:}{=}}\ast$) and then test ($?\phi$) that the value satisifies some condition $\phi$. Choice ($\alpha\cup\beta$) allows choosing between control laws, each of which may have (overlapping) tests ($?\phi$) saying when each law applies. Semicolons separate statements, so sequencing $(\alpha;\beta)$ runs $\beta$ after $\alpha$, while loop ${\alpha}^{*}$ repeats $\alpha$ any arbitrary number of times. Many models follow the control-plant loop idiom (e.g., $\alpha_{\_}{\textsf{1D}}\equiv{(\textsf{1Dctrl};\textsf{1Dplant})}^{*}$), where a discrete program 1Dctrl is followed by a continuous 1Dplant modeling physics, repeated in a loop (*). The 1Dplant is an ODE ${{x^{\prime}=\theta}}\,\&\,\psi,$ which evolves according to $x^{\prime}=\theta$ for any duration such that $\psi$ holds throughout. Before we develop a realistic 2D model in Sect. IV, we recall, in Example 1, a toy example, $\alpha_{\_}{\textsf{1D}}$, of 1D motion with perfect speed control [4]. The controller can either go forward with some $v$ such that ${0}{\leq}{v}{\leq}{V}$ if we are far enough ($d\geq TV$) from the destination $d$, else it must stop by setting $v$ to 0. The differential equation $d^{\prime}=-v,t^{\prime}=1$ says the distance $d$ continuously decreases proportional to velocity $v,$ while time continuously elapses at rate 1. The constraint $t\leq T$ after $\&$ is a time trigger, saying that at most $T$ seconds may elapse between control cycles. Note that we will show safety for any number of control cycles, and thus for unbounded time.

Example 1** (Simple 1D Idealized Driving).**

[TABLE]

Formulas of dL are used to formalize program properties:

Definition 1** (dL formulas).**

Formulas $\phi,\psi$ of dL consist of the following connectives:

[TABLE]

where $\phi\land\psi$ holds when $\phi$ and $\psi$ both hold, $\phi\lor\psi$ holds when either $\phi$ or $\psi$ holds, $\phi\rightarrow\psi$ holds if $\psi$ holds assuming $\phi$ holds, $\neg\phi$ holds if $\phi$ does not, and $\forall{x}{~{}\phi}$ and $\exists{x}{~{}\phi}$ hold if $\phi$ holds for all or some value(s) of $x$, respectively. When we prove a theorem $\phi,$ all variables implicitly have a “for all” quantifier so, e.g., the safety and liveness theorems hold for all states and all values of system parameters. Formula $\theta_{\_}1\sim\theta_{\_}2$ is shorthand for any comparison $\sim\mathop{\in}\{\leq,<,=,\neq,>,\geq\}$ where $\theta_{\_}i$ are real multivariate polynomials. The modalities ${[{\alpha}]}\phi$ and ${\langle{\alpha}\rangle}\phi$ say $\phi$ holds in all or some state(s) reached by executing hybrid program $\alpha$ respectively; they are used to express safety and liveness properties for our models.

Eq. 1 is a safety formula for $\alpha_{\_}{\textsf{1D}}$: If the robot has not collided initially ($d\geq 0$) then the verified model will never collide no matter how many further control cycles are executed:

[TABLE]

This toy example, which was previously used to demonstrate VeriPhy [4], misses out on many of the challenges essential to robotics: curved motion, acceleration, actuation disturbance, and goal-following all demand more sophisticated control conditions and invariants, which demand more sophisticated proof techniques. We take on these challenges in Sect. IV.

IV Ground Robot Model

This section introduces our 2D robot model in dL. This model is the heart of our verification effort: it lays out the definition of safety, assumptions on the controller, and assumptions on the plant. It will enable us in Sect. V to prove that these assumptions are strong enough to guarantee safety, then in Sect. VI to synthesize a monitor which functions as a runtime safety net, providing formal safety guarantees. The liveness proof of Sect. V complements safety and increases confidence in the model by showing our model is never so restrictive that it would force the robot to get stuck.

We use waypoint-following because it covers a wide variety of realistic scenarios, whereas collision avoidance is challenging to specify formally without making overly restrictive assumptions [7]. The implementation trusts waypoints from a planner. Feedback control is considered safe so long as it follows the waypoints within a fixed desired tolerance. The tolerance accounts for imperfect actuation and for discrepancies between the ideal dynamics and real dynamics of the implementation. The tolerance may also be increased to account for bounded sensor error, but the formal guarantees provided here are for perfect sensing.

Each waypoint is specified by coordinates $(\textsf{x},\textsf{y})$, a curvature k, and a speed limit $[\textsf{vl},\textsf{vh}]$ for the robot’s velocity v. By convention, positive x points forward, and positive y points left. The curvature k yields circular arcs (when ${\textsf{k}}\neq 0$) and lines (when ${\textsf{k}}=0$) as primitives. The addition of speed limits allows a plan to specify, for example, that the robot ought to slow down for a sharp curve or stop. The speed limits need only be met at the endpoint of the waypoints, which improves monitor compliance (in Sect. VI). Because realistic robots never follow a path perfectly, we bloat each arc to an annular section which is more easily followed. Our hybrid program $\alpha$ is again a time-triggered control-plant loop: $\alpha\equiv(\textsf{ctrl};\textsf{plant})^{*}$.

We use relative coordinates: the robot’s position is always the origin, from which perspective the waypoint “moves toward” the vehicle. This simplifies proofs (fewer variables) and implementation (real sensors and actuators are vehicle-centric). Figure 1 illustrates control scenarios for the system in relative coordinates. The robot is represented by where the triangle points in the robot’s forward direction. The control choice ${\textsf{k}}=0$ drives waypoints that are straight ahead of the robot straight towards the robot. For waypoints initially to the left of the robot, a control choice ${\textsf{k}}>0$ yields clockwise motion of the waypoint towards the robot. Conversely, for waypoints initially to the right, control choices with ${\textsf{k}}<0$ yield counter-clockwise motion.

The relative coordinate system and control choices for k are modeled by the ODE plant:

[TABLE]

Here, a is an input from the controller describing the acceleration with which the robot is to follow the arc of curvature k to waypoint $(\textsf{x},\textsf{y})$. In the equations for $\textsf{x}^{\prime},\textsf{y}^{\prime}$:

i) The v factor models $(\textsf{x},\textsf{y})$ moving at speed v, ii) The ${\textsf{k}},\textsf{x},\textsf{y}$ factors model circular motion with curvature k.

iii) The additional $-1$ term in the $\textsf{x}^{\prime}$ equation shifts the center of rotation to $\left(0,\frac{1}{{\textsf{k}}}\right)$.

The equations $\textsf{v}^{\prime}=\textsf{a}$ and $\textsf{t}^{\prime}=1$ make acceleration the derivative of velocity and t stand for current time. The domain constraint $\textsf{t}\leq\textsf{T}\land\textsf{v}\geq 0$ after $\&$ says that the duration of one control cycle shall never exceed the timestep parameter $\textsf{T}>0$ representing the maximum delay between control cycles and that the robot never drives in reverse.

Figure 1 depicts curves that are exact solutions of plant where the robot exactly meets the waypoint. Because realistic robots cannot follow these curves exactly, the waypoint is bloated by a fixed ball of radius $\varepsilon>0,$ giving the robot some freedom in curve-following. We refer to this bloated waypoint as the goal for the robot. Figure 2 illustrates a goal of size $\varepsilon=1$ around the origin and several trajectories which pass through the goal.

The controller’s task is to compute an acceleration a which slows down (or speeds up) soon enough that the speed limit $\textsf{v}\in[\textsf{vl},\textsf{vh}]$ is ensured by the time the robot reaches the goal. We allow the controller to exceed vh temporarily as long as there is time to achieve $\textsf{v}\leq\textsf{vh}$ before reaching the goal. This relaxation improves monitor compliance and lets the robot speed up more quickly, e.g., when it is far from the goal. The trade-off is that the proof becomes more challenging than it would be for a model that always enforces limits. The controller is written:

[TABLE]

where the nondeterministic assignment $(\textsf{x},\textsf{y})\mathrel{{:}{=}}\ast$ chooses the next 2D waypoint, the assignment $[\textsf{vl},\textsf{vh}]\mathrel{{:}{=}}\ast$ chooses the speed limit interval, and ${\textsf{k}}\mathrel{{:}{=}}\ast$ chooses any curvature. The subsequent feasibility test $?\textsf{Feas}$ checks whether or not the chosen waypoint, speed limit, and curvature are physically feasible in the current state under the plant dynamics (e.g., that there is enough remaining distance to get within the speed limit interval). We also simplify plans so that all waypoints satisfy $\textsf{x}>0$ by subdividing any violating paths automatically. This simplifies the feedback controller and proofs.

In $\textsf{Feas},$ formula Ann says we are within the annular section (Figure 3) ending at the waypoint $(\textsf{x},\textsf{y})$ with the specified curvature k and width $\varepsilon$. A larger choice of $\varepsilon$ yields more error tolerance in the sensed position and followed curvature at the cost of an enlarged goal region. Formula Ann also contains a simplifying assumption that the radius of the annulus is at least $\varepsilon$. Feas also says the speed limits are assumed distinct and large enough to not be crossed in one control cycle.

The admissibility test $?\textsf{Go}$ checks that the chosen a will take the robot to its goal with a safe speed limit, by predicting future motion of the robot. We illustrate this with the upper bound conditions. The bound will be satisfiable after one cycle if either the chosen acceleration a already maintains speed limit bounds ($\textsf{v}\leq\textsf{vh}\land\textsf{v}{+}\textsf{a}\textsf{T}\leq\textsf{vh}$) or when there is enough distance left to restore the limits before reaching the goal. For straight line motion (${\textsf{k}}=0$), the required distance can simply be found by integrating acceleration and speed:

[TABLE]

where $\textsf{a}\in[-\textsf{B},\textsf{A}]$. The extra factor of $(1+\lvert k\rvert\varepsilon)^{2}$ for curved motion accounts for the fact that an arc along the inner side of the annulus is shorter than one along the outside (Figure 3).

The abbreviation $\textsf{ctrl}_{\_}{\text{a}}$ names just the control code responsible for deciding how the waypoint is followed rather than which waypoint is followed. We show in Sect. VI that Feas and Go are easily satisfied by the implementation. We verify safety and liveness of the above model in Sect. V.

V Formal Safety and Liveness Guarantees

We now state the safety and liveness theorems in dL:

Theorem 1** (Safety).**

The following dL formula is valid:

[TABLE]

where validity means the formula holds in all states and, e.g., all admissible waypoints.

The first four assumptions ($\textsf{A}{>}0\land\dots\land\varepsilon{>}0$) are basic sign conditions on the symbolic constants used in the model. The final assumption, $J$, is the loop invariant. The full definition of $J$ is deferred to Sect. V-A, but captures the fact that the robot never strays far from its path. We write $\|(\textsf{x},\textsf{y})\|$ for the Euclidean norm $\sqrt{\textsf{x}^{2}+\textsf{y}^{2}}$ and consider the robot “close enough” to the waypoint when $\|(\textsf{x},\textsf{y})\|\leq\varepsilon$ for our chosen goal size $\varepsilon$. The theorem states that no matter which (admissible) control decisions are made, whenever the vehicle is in the goal region of size $\varepsilon$, it obeys the speed limit $\textsf{v}\in[\textsf{vl},\textsf{vh}]$. While this provides a formal notion of safety, it does not prove that the robot can actually reach the goal, which is a liveness property:

Theorem 2** (Liveness).**

The following dL formula is valid:

[TABLE]

Under the same assumptions as Theorem 1, this theorem says that no matter how long the robot has been running (${[{{(\textsf{ctrl};\textsf{plant})}^{*}}]}$) already, if some simplifying assumptions still hold ($\textsf{v}{>}0\land\textsf{x}{>}0$) the controller can be run (${\langle{{(\textsf{ctrl}_{\_}{\text{a}};\textsf{plant})}^{*}}\rangle}$) with admissible acceleration choices $(\textsf{ctrl}_{\_}{\text{a}})$ to reach the present goal $(\|(\textsf{x},\textsf{y})\|\leq\varepsilon)$ within the desired speed limits $(\textsf{v}\in[\textsf{vl},\textsf{vh}])$. The simplifying assumptions $\textsf{v}{>}0\land\textsf{x}{>}0$ say the robot is still moving forward and the waypoint is still in the upper half-plane, i.e., it has not driven past the waypoint.

V-A Proving Safety

We give the high-level insights here, such as invariants. We first prove the program stays in the region where $J$ is true, then that $J$ implies safety. To satisfy the safety condition, our program must maintain an invariant $J$ that:

i) the robot follows the plan closely and

ii) it drives at speeds that let it achieve the speed limits in the remaining distance to the goal.

Predicate $\mathsf{Lim}(v_{\_}1,v_{\_}2,a,\textsf{x},\textsf{y},{\textsf{k}})$ says acceleration $a$ can close velocity gap $v_{\_}1-v_{\_}2$ before waypoint $(\textsf{x},\textsf{y})$ reaches the origin:

[TABLE]

Here, $\delta_{\_}\mathsf{Lim}(v_{\_}1,v_{\_}2,a)$ bounds distance needed to change velocity from $v_{\_}1$ to $v_{\_}2$ with a scaling factor $(1+\lvert{\textsf{k}}\rvert\varepsilon)^{2}$ for the tolerance incurred from the width of the annular section compared to an arc. This is not too conservative in practice: it is tightest (near $1$) for small $\varepsilon$ or small $\lvert{\textsf{k}}\rvert$ and never exceeds $4$. This suffices to define $J$, which says the speed limits can be achieved with maximum braking (B) and acceleration (A):

[TABLE]

We proceed to prove Theorem 1 for waypoint-following safety. Per standard notation, the formula on the bottom (conclusion) is valid if all formulas on top (premisses) are valid:

[TABLE]

The first two premisses, which prove automatically in KeYmaera X, say the invariant $J$ holds initially and the postcondition follows from the invariant $J$, so staying inside $J$ is safe.

The main task is the third premiss: loop body $\alpha\equiv\textsf{ctrl};\textsf{plant}$ preserves the invariant $J$. The key conditions are Feas and Go; standard (automatic) dL proof steps reduce this to showing that $J$ holds again after running the plant for time $t\leq T$:

[TABLE]

It remains to show the premiss of auto: Feas and Go imply that Ann, $\mathsf{Lim}(\textsf{vh},\textsf{v},\textsf{B},\textsf{x},\textsf{y})$, and $\mathsf{Lim}(\textsf{vl},\textsf{v},\textsf{A},\textsf{x},\textsf{y})$ continue to hold throughout the plant, which can be proved in dL using differential induction [5]. KeYmaera X helps prove invariants, but identifying them takes human ingenuity. For example, $\mathsf{Lim}(\textsf{vh},\textsf{v},\textsf{B},\textsf{x},\textsf{y})$ is a natural choice, but because it is not inductive, we generalize it by hand in the full proof.

This completes the safety proof, showing that requirements Feas and Go guarantee that the robot obeys speed limits. We describe liveness next, which will reuse loop invariant $J$.

V-B Proving Liveness

We show Go also allows the robot to reach the goal within speed limits $[\textsf{vl},\textsf{vh}]$ by choosing correct acceleration a. The proof starts with the loop rule with invariant $J$ as in Theorem 1, after which it remains to show:

[TABLE]

Aside from the invariants, the key insight for liveness is a progress function which decreases as the waypoint approaches the origin [25]. There are multiple strategies to arrive at the goal within speed limit; for simplicity, we first enforce the speed limit $\textsf{v}\in[\textsf{vl},\textsf{vh}]$ with appropriate acceleration choices and then maintain it until reaching the waypoint. This strategy splits the proof into the following two questions:

[TABLE]

[TABLE]

To prove Eq. 2, we pick the acceleration for $\textsf{ctrl}_{\_}{\text{a}}$ in each of three situations:

i) if the robot is too slow ($\textsf{v}<\textsf{vl}$), it should speed up (pick $\textsf{a}=\textsf{A}$),

ii) if the speed is in the limits ($\textsf{v}\in[\textsf{vl},\textsf{vh}]$) it maintains speed (pick $\textsf{a}=0$), or

iii) if it is too fast ($\textsf{v}>\textsf{vh}$), it slows down (pick $\textsf{a}=-\textsf{B}$).

In all three cases, the invariant $\textsf{v}>0\land\textsf{Ann}$ is proved to be preserved throughout plant, so we soundly assume it in the proof of Eq. 3. The progress functions are case specific: e.g., in case i, the progress function $g\equiv\textsf{vl}-\textsf{v}$, for the gap to the speed limit, decreases as the robot speeds up. Conversely, the progress function for case iii is $g\equiv\textsf{v}-\textsf{vh}$.

Once the speed limit is achieved (case ii), the robot progresses toward the waypoint (Eq. 3) at a constant velocity ($\textsf{a}=0$). The proof uses the progress function $g=\textsf{x}^{2}+\textsf{y}^{2}-\varepsilon^{2}$, i.e., the (squared) Euclidean distance to the goal region. The intuition for this progress function is shown in Figure 4. The value of $g$ is positive outside the goal region, strictly decreases along the trajectory, and is negative in the goal region.

These are the crucial ingredients in the proof of liveness, which we have formally proved in KeYmaera X.

V-C Proof Effort and Automation

User interactions are usually required for significant dL theorems like Theorem 1 (279 interactions) and Theorem 2 (589 interactions). User insight was mainly needed to choose invariants and progress functions for loops and ODEs. Most interactions are simplifications to help the automation. Automation handled most steps: 53,883 for safety, 225,607 for liveness. The final KeYmaera X proof scripts run automatically in 23s and 73s on a 2.4GHz i7 with 16GB memory.

VI Implementation: Simulation

In this section, we fulfill the goal of extending verification to the level of simulation in AirSim. We use the VeriPhy tool to synthesize an automatically-verified monitor containing both controller and plant monitor conditions. The controller monitor condition corresponds to Feas and Go in Sect. IV: any control decision satisfying these conditions is allowed and is guaranteed safe by Theorem 1, else the verified fallback is invoked. VeriPhy guarantees that the monitor is safe down to its machine code implementation, regardless what decisions are made by the external controller, so long as the plant monitor conditions are satisfied, which is the case so long as the differential invariant of Sect. V-A (the premiss of auto) holds for the sensed values. When the plant monitor conditions fail, safe braking is employed, albeit without the strong guarantee available in the other cases except with extra assumptions [3].

High-Level Plans

Our plan data structure is a graph (Figure 5) where waypoints are connected by lines and arcs, as in the dL model. The evaluation uses fixed plans (up to ${\approx}$80 segments), but our data structure also supports, e.g., nondeterministic plans (Figure 5, nodes B and F) and cyclic graphs for repeating missions, for the sake of flexibility.

Feedback Control

The high-level plan gives an ideal path to follow; the job of the low-level controller is to follow it within some tolerance. We give two classical feedback controllers: the bang-bang controller switches between hard-left and hard-right steering, while the PD scales to the discrepancy between current position and orientation vs. their target values. We compare the low-level controllers in AirSim, using a human operating AirSim as a baseline.

AirSim Simulation

We implemented our own plan representation and controllers in AirSim, $\approx$1100 lines of C++. We built the test environments (Fig. 5,5,5) in Unreal Editor. Figure 5 shows the AirSim car driving autonomously.

Sensing and Actuation

AirSim does not explicitly simulate sensing and actuation error, but some implementation details of the kinematics are unknown, so actuation error must be accounted for in practice. The tolerance $\varepsilon$ does not include sensing error, but does account for deviation of the AirSim kinematics from ideal Dubins. Thanks to the proofs and sensors, errors do not accumulate: if actuation is imperfect, the deviation is detected by the sensors and feedback control counters the deviation as usual. If our monitor conditions are applied in systems where sensors accumulate drift over time, it would not obviate the need to account for those drifts.

Results

We assess monitor compliance and safety of each controller. We assess liveness indirectly by checking how quickly the goal is reached. We assess compliance and safety directly: a successful simulation should comply with the monitor conditions (especially the safety-critical plant monitor conditions) a large majority of the time and have no safety violations. Our three AirSim environments are shown in Figure 5. These environments cover medium turns at medium speed (Figure 5), tight turns at low speed (Figure 5), and wide curves at high speed (Figure 5). We simulated bang-bang and PD controllers of different speeds driving each environment (Table II), with amateur human pilots as a baseline.

The car completes every environment, except “Clover” where bang-bang control fails to track long curves. As promised, there were no safety violations. The controller monitor condition has few failures. The plant monitor condition fails more often, but rarely enough that the car completes the drive. The plant monitor failed more since our bloated ideal dynamics are simpler than the AirSim physics. In general, the failure rate increases the more physics differs from Dubins.

We ran the tests with $\varepsilon=1\textrm{m},$ which was small enough to stress-test the controllers. For our purposes, the exact value of $\varepsilon$ is less important than the fact that safety is guaranteed for all values of $\varepsilon$. The bang-bang controller exhibits tracking error at speed and so did not complete the Clover track. The slower PD controller (PD1, in bold) had the best (lowest) overall error rate. The human and the remaining controllers had high plant failure rate on the “Clover” level due to tracking error. PD control (particularly PD3) had speed and monitor failure rates competitive with the human baseline. The bang-bang controller’s rough steering increased its plant failure rate.

While complete model compliance is a challenge, well-tuned controllers came close in all environments, even though the model is simple. The crucial insight is that the bloated model allows realistic imperfections in actuation, and that the untrusted controller makes steering and acceleration choices that satisfy its monitor condition. Most of the time, formal guarantees apply because both monitor conditions are satisfied. The plant’s monitor condition detects the few cases where guarantees do not apply, engages the fallback action, and then returns to normal control without any actual safety violation. The monitor furthermore helps us or any other developer identify and reduce the remaining non-compliant cases.

VII Conclusions and Lessons

We cast a formally verified safety net that provides end-to-end verification guarantees for 2D Dubins waypoint-following. We developed a dL model, proved it safe and live in KeYmaera X, then synthesized a verified monitor with ModelPlex, and synthesized verified machine code with VeriPhy. The resulting safety net ensures safety even with unverified robot software so long as plant assumptions hold and collision-free plans are provided. We simulate the system in AirSim with several controllers; our aim was not to innovate in controller design, but to show that monitors generated from dL proofs can be applied in realistic scenarios, thanks largely to the use of verified tolerances in the model and proof. The evaluation showed that our simple tolerance-based model did not hinder applicability, because even realistic simulations look like Dubins at a distance. Our simple model greatly eased formal verification. Just as we improved on prior models [4], future work can verify more sophisticated models to improve compliance or reduce the tolerance $\varepsilon$.

The second major direction for future work is to apply VeriPhy on real robot hardware, and as a development aid for novel robots. Because the KeYmaera X proofs are significantly more complex than the sketches presented here (see Sect. V-C), VeriPhy’s reusability is essential to make it practical as a development tool. We are presently in the process of reusing our current monitors as-is on a hardware platform that follows Dubins paths without changing the proofs, and subsequently intend to pursue more challenging motion scenarios that violate our model’s assumption.