Model Checking of Robotic Control Systems

1

Model Checking of Robotic Control Model Checking of Robotic Control SystemsSystems

Presenting:Sebastian Scherer

Authors:Sebastian Scherer, Flavio Lerda,

and Edmund M. Clarke

2

OutlineOutline

● Motivation

– Why verification

– Scope

– Control software● Method

● Case Study

● Conclusions

3

Why verify robot software?Why verify robot software?

● Failure is expensive:

– Interplanetary exploration

– Crash / Rollover

● Autonomy increases responsibility:

– Human interaction

– Large forces and momenta

4

The scope of our approachThe scope of our approach

Start by verifying this part.

Typical mobile robot architecture

Environment

ActuatorsSensors

Preprocessing Controller

Accumulation Planning

GoalSoftware

Hardware

Specified

5

Control systems are implemented in Control systems are implemented in softwaresoftware

● Main loop is only a small fraction of the control software:

– Initialization

– Exception handling

– Conversion● Fatal bugs can be in any line

of the code.

Typical mobile robot architecture

Environment

ActuatorsSensors

Preprocessing Controller

Accumulation Planning

Goal

Software

Hardware

Specified

6

OutlineOutline

● Motivation

● Method

– Capabilities & Limitations

– Method

– Model Checking

● Case Study

● Conclusions

import gov.nasa.jpf.jvm.Verify;import com.ajile.jem.PeriodicThread;import com.ajile.jem.PianoRoll;import com.ajile.drivers.gptc.*;import intermediate.*;import drivers.*;import controller.*;import model.*;

public class Mobot{

static final int PR_DURATION_MSEC = 80; static final int PR_BEAT_MSEC = 1; static PianoRoll Piano_Roll = new PianoRoll (PR_DURATION_MSEC, PR_BEAT_MSEC); public static void main(String[] args) { DecsionPoints.runSys=true; //Initialize threads PWM2 pwm = PWM2.getInstance(); Gate gate = Gate.getInstance(); SpeedOMeter encoder = SpeedOMeter.getInstance(); LightArray lightsensor = LightArray.getInstance(); TLC2543 tlc = TLC2543.getInstance();* if(Environment.isMC) { lightsensor.initDefault();

SpeedControl speedcontrol = SpeedControl.getInstance(); SteeringControl steeringcontrol = SteeringControl.getInstance(); Environment env = Environment.getInstance();

+

Code of controller +environment(plant)

kukD+kxkC=ky

kukB+kxkA=+kx

dd

dd1

7

CapabilitiesCapabilities of our method of our method● Utilizes environment (plant) of the control system.

● Simulates behaviour:

– Determines stability.

– Models influence of noise.

– Checks performance specifications.

– Computes ranges of trajectories.

● Checks programming errors:

– Null pointer exceptions.

– Dead lock, concurrency bugs.

– Errors affecting the behavior.

● Code checked is identical to executed code.

8

LimitationsLimitations of our method of our method● Discrete method:

– Makes assertions only about a particular initial condition.– Continuous states are approximated up to a fixed point

precision.– Precision often determines the length of a simulation trace

and the size of the state space to explore.– Noise is approximated by a discrete set of values.

● Detailed model:– Requires model relating inputs and outputs.– Additional memory and computation time.

● Assumptions:– Time elapses only while tasks sleep.– Unbounded variables like time and distance must be

abstracted manually.

9

Model check software with a Model check software with a physical environmentphysical environment


public class Mobot{



+

Code of controller +environment(plant)

kukD+kxkC=ky

kukB+kxkA=+kx

dd

dd1


public class Mobot{



Source codeof controller

Abstract controller

Source code including the environment

Verify actual source code

10

MethodMethod


public class Mobot{



Actual Robot

Sensors

Actuators

Software executedon robot Environment model

● Execute the source code.

● After all tasks sleep execute the environment.

● Equivalent states are not revisited.

kukD+kxkC=ky

kukB+kxkA=+kx

dd

dd1

11

MethodMethod


public class Mobot{



Actual RobotSoftware executedon robot Environment model

● Software executes until all tasks yield.

kukD+kxkC=ky

kukB+kxkA=+kx

dd

dd1

12

MethodMethod


public class Mobot{





● Commands are set. Sensors are read. Time elapses

kukD+kxkC=ky

kukB+kxkA=+kx

dd

dd1

13

MethodMethod


public class Mobot{





● Commands are set. Sensors are read. Time elapses

● Software executes with new sensor values.

kukD+kxkC=ky

kukB+kxkA=+kx

dd

dd1

14

MethodMethod


public class Mobot{





● Commands are set. Sensors are read. Time elapses.

● Software executes with new sensor values.

● Commands are set. Sensors are read. Time elapses with new commands.

kukD+kxkC=ky

kukB+kxkA=+kx

dd

dd1

15

Model checkingModel checking

● Model consists of states and transitions.

● Java byte code specifies a model.

● Verify a model against a specification given as logic properties.

● The algorithm visits all states of the model to verify that none of the specified properties are violated.

● If the same state is reached twice backtrack.


public class Mobot{



States

Transitions

16

Java PathFinderJava PathFinder

● All states are explored to find a violation of the properties.

● Executing the byte code generates successors.

● If no new successors are generated the search backtracks.

● Environment byte code is executed on host JVM. No intermediate states are generated from it.

● Environment stores only necessary state variables.

Robot source code

Host JVM running Java PathFinder

Java Virtual Machine of Model Checker

Environment

17

OutlineOutline

● Motivation

● Method

● Case Study

– Architecture

– Verification

– Model

– Results

● Conclusions

18

OverviewOverview

• Robot has to follow a line and maintain a constant speed.

• Native Java microcontroller executes the code.

• Check source code without change.

19

ArchitectureArchitecture

● Actuators

– Steering

– Motors

● Sensors

– Light sensors

– Encoder

20

SoftwareSoftware● 3 tasks running with a

fixed frequency of 33Hz.

● Task 1: Reads sensor values.

● Task 2: Controls the steering.

● Task 3: Controls the velocity.

● A fixed rate scheduler determines the execution order and duration.

Task 1 Task 2

Task 3

21

VerificationVerification

● Need model of the environment.

● Need definition of states.

● Verify robot starting from initial condition offset from center of line and on a straight line.

22

Environment modelEnvironment model● Two models necessary

● Model relate commands to sensor information

● Sensed position over line depends on

– Steering command

– Velocity command

● Sensed encoder velocity depends on the velocity command.

Sensed positionmodel

Sensed velocitymodel

Input:Velocity command

Output:Encoder velocity

Inputs:Velocity commandSteering command

Output:Encoder velocity

23

Determining the modelDetermining the model

• One way to obtain a model of the environment is system identification.

• Performed experiments and obtained a second-order model for velocity and a fourth-order model for steering

• Quality of sensor gave a better fit for the velocity

0027.0)(

)(

8.8

7.0

9.5

4.1

10)(

87.004.002.003.0

13.098.010.0096.0

07.011.098.011.0

22.011.014.096.0

)1(

1

5

txy

tutxtx

24

StatesStates● Continuous state:

– 6 state variables– 2 inputs

● States are discretized up to a fixed precision to terminate on stability and disambiguate quasi-equal states.

● Monotonic variables such as time or distance are (manually) abstracted.

● DESCRIBE PICTURE


public class Mobot{

static final int PR_DURATION_MSEC = 80; static final int PR_BEAT_MSEC = 1; static PianoRoll Piano_Roll = new PianoRoll (PR_DURATION_MSEC, PR_BEAT_MSEC); public static void main(String[] args) { DecsionPoints.runSys=true; //Initialize threads PWM2 pwm = PWM2.getInstance(); Gate gate =

+State space model

Discrete State Continuous State

kukD+kxkC=ky

kukB+kxkA=+kx

dd

dd1

25

Non-DeterminismNon-Determinism

● Possible to explore non-determinism in the software and environment.

● Model checking explores a wider spread of trajectories.

● Non-determinism is discrete. Differential equations are deterministic.

Blue region is the spread of trajectories covered by the model checker.

Red trajectory showsan actual trace of therobot.

26

ResultsResults● Added different kinds

of non-determinism to model.

– Encoder reading off by -10, 0, +10 ticks

– Failure of one sensor in the array of light sensors

– Commanded steering and velocity pulsewidth is not accurate.

Ground

Wheel Slip

27

ResultsResults

● We verified a set of properties of the control software.

● No programming errors (e.g. Null pointer exceptions) were found.

29

ConclusionConclusion

● Model checker covers a sufficient range of trajectories to simulate all inputs to program.

● Seeded type conversion bug was found.

● Verifies software for robot controllers directly.

● Discretization, abstraction and extraction of continuous states enable efficient verification.

● Exhaustive exploration of non-determinism such as random sensor failure.

● Aids the control system designer by direct verification of all reachable states of the model.

30

Future workFuture work

● Prove correctness of model checking algorithm

● Extend notion of discretization of state space to be an over-approximation.

● Provide integrated support for modeling the environment

● Integrate with higher level software interfaces

● Check complex systems

● Extend to languages other than Java

31

Questions? Comments?Questions? Comments?

Contact Information:Sebastian Scherer

[email protected]://www.cs.cmu.edu/~basti/

mailto:[email protected]

http://www.cs.cmu.edu/~basti/

Date post:	08-Jan-2016
Category:	Documents
Upload:	peers
View:	44 times
Download:	3 times

Model Checking of Robotic Control Systems

Documents