1. Verifying REACT Aleks Milisevic Will Noble Martin Rinard
Stelios Sidiroglou-Douskos
Damien Zufferey

2. Overview and Challenges
Programming robots + making sure it works [without a PhD in robotics/control theory/…]
Programming:
Interactions between robots
Interactions with the environment
Verification:
Discrete programs in a continuous world
Nothing against control theory, it’s just that not everybody has the right background (i.e. me).
What Aleks presented before was mostly about interactions between robots
I’ll comment some more on the question of discretization of the world
And speak about a lower level continuous view: setting speed to 0 in the program does not instantaneously stop an object with inertia

3. Simple model vs real world
Coordination language: planning and functionality
Discrete
API / IR
Continuous
Hybrid language: controller, sensor, and actuator

4. Coordination Programming: model-based, event-driven paradigm
Global view of entire system
High-level: “move to” rather than setting power on the motor
Discrete time step and instantaneous actions
Verification
State-space exploration: exhaustive search of possible program executions to find incorrect behaviors
Discrete of state-space is “easier” to explore

5. Discretizing the world
Semantics of (1,1):
anywhere within the box
abstraction of the real world
Problem:
spurious transitions
(arbitrarily close to the borders)
Solution:
rather than being exact
tolerate some error
focus on the likely paths 1 2 1
Discretization = abstraction
Spurious transitions: do not exists in the original system, but introduced by the abstraction
Quantifying the error: probabilities 2

6. Likely transitions 1 2 1 2 Steer the exploration toward likely
Quantifying the error: probabilities
Steer the exploration toward likely
paths and avoid spurious ones.
On the other hand, bugs are mostly
found in corner cases (unlikely). 2

7. Delay bounding
Let the verifier pick some unlikely transitions, i.e. introduce “delays”. Consider likely paths where a bounded number of improbable transitions can happen.
Strategy for bounding problems:
In the limit, equivalent to the original problem
Interesting things happens for low bounds
More practical / better complexity
Goal: remove the spurious bugs and keep the real bugs

8. Link to the actual world
Discrete controller + continuous dynamics = hybrid system
Finite automaton + ODEs
Complicated model, but simple properties:
“move to (x,y,z)” (for a given robot and controller)
Is it doable ? Accurately enough ?
if we want to say something like collision, we have to say connect the code to the environment through a model of the robot
usually those two parts are separated
eventually: code from continuous steps
More difficult: most properties are undecidable

9. Hybrid system: example
Spherical car moving along a line in frictionless vacuum.
cruise
accelerate
obstacle
stopped
brake

10. Hybrid system: trace
brake
stopped
accelerate
cruise

11. Simulation vs verification
Unfortunately, sensors and actuators have bias, noise, drift…
Looking at a few traces (simulation) is not enough.
To verify a system, we must ideally look at all the traces.
“Run” the system on intervals instead of points.

12. Hybrid system: flowpipes
brake
Flowpipe: trace + interval
Transition between modes introduce imprecision
stopped
accelerate
cruise

13. Using the language to simplify the verification
Programing language:
Discrete: sample-hold controller
Continuous: ODEs from robot description
Model checking:
Turn the model into code, rather than extract model from code
Sample-hold: easier to check discrete and continuous separately
Property: simple movement (functionality checked in layer above)
a bit of history:
previously: putting time in the language (giotto)
now: putting geometry/dynamics in the language (hardware/software split)
MC, read it as: work only on model, not actual code
SH:
avoid zeno behavior,
discrete run-to-completion semantics
Cannot check complex properties in an hybrid system, needs
either a bounded horizon
or systems that stabilizes quickly

14. Dynamic of robots Typical verification of hybrid systems:
Dynamic is given [by magic]
The robotic / mechanical engineering community seems to already have systems to specify the physical properties of robots:
Constructive solid geometry + Bond graphs
ROS URDF + GAZEBO extension
Bond graph / Modelica
Constructive solid geometry / Openscad
Geometry: properties like collision
Dynamics: evolution

15. Pointers to the appropriate references/tools are appreciated. Thx.
Dynamic of robots
controller
Synergy:
-the robot description => the dynamics
-robot + environment => adapt the size of the discretization
Pointers to the appropriate references/tools are appreciated. Thx.
Opportunities for collaborations.