Verification and Validation of Robotic Assistants

Introduction Techniques and Approach The Domestic Scenario The Manufacturing Scenario Conclusions
Veriﬁcation and Validation of Robotic Assistants
Clare Dixon
Department of Computer Science
University of Liverpool
1 University of Liverpool (UoL)
2 University of Hertfordshire (UoH)
3 Bristol Robotics Lab (BRL)
www.robosafe.org
Farshid Amirabdollahian2
Kerstin Dautenhahn2 Anthony Pipe3
Kerstin Eder3 Maha Salem2
Michael Fisher1 Joe Saunders2
Dejanira Araiza Illan3 Matt Webster1
Kheng Lee Koay2 David Western3
Clare Dixon Veriﬁcation and Validation Robotic Assistants 1 / 23

Robotic Assistants
Robotic assistants are being developed to
help, or work closely with humans in
industrial, domestic and health care
environments (e.g. RI-MAN, Pearl,
Wakamaru, . . . )
The robots will need to be able to act
autonomously and make decisions to
choose between a range of activities.
In addition they will need to operate close
to, or in collaboration with humans.
How do we make sure they are trustworthy,
safe, reliable and do what they are
supposed to?
Wakamaru image by Nesnad (Own work) [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0) or GFDL
(http://www.gnu.org/copyleft/fdl.html)], via Wikimedia Commons

What is Trustworthiness and Safety?
Safety involves showing that the robot does nothing that
(unnecessarily) endangers the person.
There are ISO safety requirements and guidelines for
industrial robots (ISO 10218, 2011), personal care robots
(ISO 13482, 2014), and for collaborative robots (ISO
15066, 2016).
Trustworthiness involves social issues beyond pure safety.
It is not just a question of whether the robots are safe but
whether they are perceived to be safe, useful and reliable.
There are also legal (and ethical) issues such as what
happens when
the robot spills a hot drink on someone;
the robot doesn’t remind the person to take their medicine;
the robot doesn’t go to the kitchen when told?

Robots in the Workplace and at Home
Currently many robots used in industry or domestic use operate
in limited physical space or have limited functionality. This helps
assure their safety.
Robots’ industrial environments are limited so they can
only move in a ﬁxed area and have limited interactions with
humans e.g. welding or paint spraying robots.
Small or limited capability domestic robots, e.g., vacuum
cleaning robots, robot lawn mowers, pool cleaning robots
etc

Trustworthy Robotic Assistants Project
The EPSRC funded Trustworthy Robotic Assistants Project
develops three different approaches to veriﬁcation and
validation of robotic assistants.
Each approach is aimed at increasing trust in robotic assistants.
Formal Veriﬁcation (Liverpool)
Simulation-based Testing (Bristol Robotics Laboratory)
End-user Validation (Hertfordshire)

Robotic Assistants
We consider two use cases, domestic
and manufacturing.
A personal robot assistant (the Care-
O-bot R
,) located in a domestic house
in the University of Hertfordshire.
A co-operative manufacturing task
with BERT a robot at Bristol Robotics
Lab.
8 Journal Title XX(X)
• System model inaccuracies. All the verification
techniques use models of the real-world. The models
might have been constructed erroneously, or may be
inconsistent with the real world, or relative to one
another.
• Requirement model inaccuracies. In our approach,
the real-world requirements of the system are con-
verted into textual requirements, assertions and prop-
erties for verification. These requirements models
may not have been correctly formulated.
• Tool inaccuracies. It is possible that numerical
approximations affect the verification results. In
addition, third party tools can contain bugs that are
unknown to us.
We could now proceed to perform “Experiments.” As
before, we may find a problem with the textual require-
ments or the physical system during experimentation. At
Figure 2. BERT 2 engaged in the handover task.
robot. BERT 2 then picks up a nearby object, and holdsClare Dixon Verification and Validation Robotic Assistants 6 / 23

Formal Verification
A mathematical analysis of all behaviours using logics, and
tools such as theorem provers or model checkers.
We focus on temporal verification using automatic tools
and techniques that do not require user interaction.
Model checking is a fully automatic, algorithmic technique
for verifying the temporal properties of systems.
Input to the model checker is a model of the system and a
property to be checked on that model.
Output is that the property is satisfied or a counter
example is given.
Model Checker
Property holds
or
counter example
Property eg
"always p"

Robot Architectures and Veriﬁcation
We assume an architecture where there is a separation
between the high level decision making layer and the low level
control layer.
etc
Control System
Sense and act
High level choices
Rational Agent
Low level control
Decision making
Avoidance
Reactive
Goal selection
Plan selection
Prediction
etc
We aim to represent and verify the decision making layer and
we don’t deal with low level control such as movement etc.

Simulation Based Testing
This is an exhaustive testing methodology widely used in
the design of micro-electronic and avionics systems.
These appeal to Monte-Carlo techniques and dynamic test
reﬁnement in order to cover a wide range or practical
situations.
Tools are used to automate the testing and analyse the
coverage of the tests.
over Scenario

End User Validation
This approach involves experiments and user evaluations
in practical robotic scenarios.
Scenarios relating to robot human interaction are
developed to test some hypothesis and experiments with
users carried out.
This helps establish whether the human participants
indeed view the robotic assistants as safe and trustworthy.

Overall Approach

A Domestic Robot Assistant
Here we apply model checking to the
high level behaviours controlling the
(commercially available) Care-O-bot R
,
manufactured by Fraunhofer IPA.
It is based on the concept of a “robot
butler” which has been developed as a
mobile robotic assistant to support
people in domestic environments.
It has a manipulator arm, an articulated
torso, stereo sensors serving as “eyes”,
LED lights, a graphical user interface,
and a moveable tray.
The robot’s sensors monitor its current location, the state
of the arm, torso, eyes and tray.
Its software is based on the Robot Operating System.

Care-O-bot and Robot House
This is deployed in a domestic-type house (the robot
house) at the University of Hertfordshire.
The robot house is equipped with sensors which provide
information on the state of the house and its occupants,
such as whether the fridge door is open and whether
someone is seated on the sofa.
Low-level robot actions such as movement, speech, light
display, etc., are controlled by groups of high-level rules
that together define particular behaviours. 3
Fig. 2. A plan view of the ground floor of the University of Hertfordshire Robot House. Numbered boxes show the locations of sensors.
models, and their formal verification, are described in
Section IV.
• Figs. 2 and 3 have been added to provide additional
information on the Robot House and the user activity
within it.
move_tray_and_wait(lowered_position)
set_light(white)
wait()
set(tray_is_raised,false)
set(tray_is_lowered,true)Clare Dixon Verification and Validation Robotic Assistants 13 / 23

Care-O-bot Decision Making: Behaviours
The Care-O-bot’s high-level decision making is determined
by a set of behaviours of the form precondition → action
(each a sequence of rules).
Examples of high-level rules can take the form “lower tray”,
“move to sofa area of the living room”, “say ‘The fridge
door is open’ ”, set a ﬂag, check a sensor etc.
Only one behaviour executes at once.
Each behaviour has a priority (integer between 0 and 90).
Higher priority behaviours are executed in preference to
lower priority behaviours.
Each behaviour is ﬂagged as interruptible or not.
Once it has started executing, a behaviour will execute to
completion, if it is not interruptible.
Users can add new behaviours.

The S1-alertFridgeDoor Behaviour
Behaviours (a set of high level rules) take the form:
Precondition-Rules -> Action-Rules
27 Fridge Freezer Is *ON* AND has been ON for more than 30 secs
31 ::514:: GOAL-fridgeUserAlerted is false
32 Turn light on ::0::Care-o-Bot 3.2 to yellow
34 move ::0::Care-o-Bot 3.2 to ::2:: Living Room and wait for
completion
35 Turn light on ::0::Care-o-Bot 3.2 to white and wait for
completion
36 ::0::Care-o-Bot 3.2 says ‘The fridge door is open!’ and
wait for completion
37 SET ::506::GOAL-gotoCharger TO false
38 SET ::507::GOAL-gotoTable TO false
39 SET ::508::GOAL-gotoSofa TO false
40 ::0::Care-o-Bot 3.2 GUI, S1-Set-GoToKitchen, S1-Set-WaitHere
41 SET ::514::GOAL-fridgeUserAlerted TO true
Its priority is 60 and it is not interruptible.

Models and Properties
We need to abstract away from some of the timing details
included in the database to obtain a model that is discrete,
ﬁnite and not too large.
We developed a (by hand) model in the input language for
the model checker NuSMV and later developed a tool
(CRutoN) to automatically translate from behaviours to
NuSMV input.
We also need a set of properties of the system to check
over the model.
Ideally these would come from a speciﬁcation or standards
documents about what is expected of the robot with
respect to functionality, safety etc.
Here we focus on issues relating to the scheduling of
behaviours, priorities and interruptions (which at least
provide a sanity check).

Sample Properties and Model Checking Results
1 ((fridge_freezer_on ∧ ¬goal_fridge_user_alerted) ⇒
♦(location = livingroom ∧ ♦say = fridge_door_open))
2 ((fridge_freezer_on ∧ ¬goal_fridge_user_alerted ∧
schedule = schedule_alert_fridge_door) ⇒
♦(location = livingroom ∧ ♦say = fridge_door_open))
Property Output Time (sec)
1 FALSE 11.1
2 TRUE 12.3
The model had 130,593 reachable states.
We did ﬁnd a small bug in the behaviours (a ﬂag was
wrongly set) but this was by inspection of the behaviours.
It would be better to try properties relating to the
requirements of the robot.

Discussion
CRutoN allowed us to translate from different databases of
behaviours into input for a model checker, setting
parameters to control particular aspects of the translation.
CRutoN uses an intermediate representation so that input
to different model checkers can potentially be generated.
Understanding the semantics of the robot execution cycle
took a lot of close work and interaction with UoH.
The state explosion problem means we have to ﬁnd a
balance between the level of detail/abstraction and
veriﬁcation times (timing details were not well represented).
We could deal better with uncertainty or timing constraints
by applying a different model checker.
The model of a person in the robot house was not
represented but this could be incorporated showing their
location for example.

Experiments with Trust and Reliability
In the robot house UoH experimented using two scenarios
where the robot appeared faulty or not.
In both scenarios the person was asked to carry out a task with
the robot.
Results suggested that although errors in a robot’s behavior are
likely to affect participant’s perception of its reliability and
trustworthiness, this doesn’t seem to inﬂuence their decisions
to comply with instructions (or not).
Their willingness to comply with the
robot’s instructions seem to depend
on the nature if the task, in particular,
whether its effects are irrevocable.

The Manufacturing Scenario: Verification
The focus was on a table leg handover task. The gaze, hand
location and hand pressure of the human should be correct
before the handover takes place.
Journal Title XX(X)
All the verification
-world. The models
oneously, or may be
, or relative to one
s. In our approach,
he system are con-
assertions and prop-
quirements models
mulated.
ble that numerical
fication results. In
ontain bugs that are
“Experiments.” As
the textual require-
experimentation. At
formal verification
e compared against
cover that one of the
ed testing or formal
ents. In this case we
assets, as explained
e between the dif-
cover the cause of
isons are indicated
Formal Verification”
ulation-based Test-
Figure 2. BERT 2 engaged in the handover task.
robot. BERT 2 then picks up a nearby object, and holds
it out to the human. The robot announces that it is ready
to handover. The human responds verbally to indicate that
they are ready to receive. (For practical reasons, human-to-
robot verbal signals were relayed to the robot by a human
operator pressing a key.) Then, the human is expected to
pull gently on the object while looking at it. BERT 2 then
calculates three binary sensor conditions:
• Gaze: The human’s head position and orientation
relative to the object are tracked using the Vicon R
motion-tracking system for an approximate measure
of whether he/she is looking at the object.
11
RobotController_3S
Modelling was carried out using Probabilistic Timed Automata
and verification via the PRISM probabilistic model checker.

Manufacturing Scenario: Simulation and Experiments
Simulation based testing and real robot experiments (BRL)
12
code to be used in simulation and in the actual robot,
providing consistency between simulations, experiments,
and deployed use. A screenshot of the ROS/Gazebo
simulation can be seen in Figure 5.
For the simulator, additional ROS nodes were con-
structed in Python, to simulate BERT 2’s sensor sys-
tems and embedded actuation controllers. The pre-existing
URDF file describing BERT 2 was extended as described
previously for use in Gazebo. The simulated human
behaviour was controlled by a ROS node written in Python,
driving a simplified physical model of the head and hand.
Figure 5. Screenshot of the simulated handover task. The
human head and hand are represented in orange. The object
to be handed over is shown in blue.
A testbench was incorporated into the simulator. The
testbench comprised a test generator, a driver, a checker
and a coverage collector. Achieving the exploration of
meaningful and interesting sequences of behaviours from
the robot and its environment in an HRI task is a
challenging task. For this reason, we stimulate the robot’s
code in the simulation indirectly through stimulating its
environment (e.g., the person’s behaviour) instead, and we
use a combination of model-based and pseudorandom test
generation. Also, to alleviate the complexity of generating
and timing different types of system inputs, the test
generator is based on a two-tiered approach (Araiza-Illan
et al. 2016) where an abstract test is generated first and
then concretized by instantiating low-level parameters. The
high-level actions of the human in the simulator include
sending signals to the robot, or setting abstract parameters
for gaze, location and pressure. Low-level parameters
include the robot’s initial pose and the poses and force
vectors applied by the human during the interaction. For
example, we computed an abstract test of high-level actions
for the human, by exploring the model in UPPAAL⇤⇤
, so
that the
robot an
pressure
gaze, pr
released
the hum
The
simulato
monitor
describe
Finally,
triggerin
The s
5.2.1
assertio
in Pyth
If the
machine
to deter
postcon
For e
both ini
if (sens
wait
asse
Note th
be diff
same t
misinter
The
collecte
verified
The nu
triggere
coverag
5.3 E
5.3.1
imental
custom
in Figur
of a sy
unbiase
environ
to repro
safety c
quently,
be inac
such as
⇤⇤http:
††https
Prepared using sagej.cls
We carried out a small user valida-
tion study with 10 participants each
carrying out 10 handover tasks.

The Manufacturing Scenario: Discussion
A number of properties checked inspired by the ISO
requirements, e.g. “At least 95% (60%) of handover
attempts should be completed successfully”.
Disagreement between outcomes from some of the
techniques meant further investigation and refinement of
the models was needed:
simulation based testing revealed that the robot sometimes
dropped the table leg accidentally (gripper failure) which
was not modelled in the formal verification;
real experiments revealed false negatives for the pressure
sensor and location sensor (they were wrongly reported as
too low/incorrect hand position) not represented elsewhere.
Some of the techniques were not suitable for verifying
some of the requirements, for example for aspects such as
speed or closeness formal verification may not be the best
technique to use.

Concluding Remarks
We gave an overview to the research carried out on the project
Trustworthy Robotic Assistants and discussed approaches to
trust and safety for robotic assistants.
We advocate the use of a suite of veriﬁcation and validation
techniques at different levels of abstraction and coverability to
help gain assurance of the robot’s safety, reliability and
functional correctness.
We considered the combination of formal veriﬁcation (model
checking), simulation-based testing, and user validation in
experiments with real robots in a domestic and collaborative
manufacturing scenario.
Papers available at www.robosafe.org

Verification and Validation of Robotic Assistants

More Related Content

What's hot (18)

Viewers also liked (18)

Similar to Verification and Validation of Robotic Assistants (20)

More from AdaCore (18)

Recently uploaded (20)

Verification and Validation of Robotic Assistants