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

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

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

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

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

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

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

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

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

Hybrid system: trace brake stopped accelerate cruise

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.

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

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

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

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.