Autonomous Skill-centric Testing using Deep Learning

TL;DR

This paper introduces a model-free, skill-centric testing approach for robotics that uses deep learning to autonomously detect software bugs through real-world skill execution and sensor data analysis, avoiding traditional model-based methods.

Contribution

It presents a novel deep learning-based, model-free testing framework that autonomously identifies software bugs in robots by analyzing sensor data during skill execution.

Findings

High accuracy bug detection demonstrated in simulation and real robot experiments.

Effective identification of software bugs without task-specific models or tests.

Sensor data analysis links misbehavior to specific software functions.

Abstract

Software testing is an important tool to ensure software quality. This is a hard task in robotics due to dynamic environments and the expensive development and time-consuming execution of test cases. Most testing approaches use model-based and / or simulation-based testing to overcome these problems. We propose model-free skill-centric testing in which a robot autonomously executes skills in the real world and compares it to previous experiences. The skills are selected by maximising the expected information gain on the distribution of erroneous software functions. We use deep learning to model the sensor data observed during previous successful skill executions and to detect irregularities. Sensor data is connected to function call profiles such that certain misbehaviour can be related to specific functions. We evaluate our approach in simulation and in experiments with a KUKA LWR 4+ robot by purposefully introducing bugs to the software. We demonstrate that these bugs can be detected with high accuracy and without the need for the implementation of specific tests or task-specific models.

Equations

$$b:S\mapsto S$$

$$\beta \left(b\left(\mathbf{s}\right)\right)=\text{true}$$

$${\Delta }_a=\{\left({\mathbf{M}}_a(\mathbf{s}),{\mathbf{F}}_a(\mathbf{s})\right)\}$$

$$\mathbf{M}_{a}(\mathbf{s})=\blockarray{cccc}\block{(ccc)c}\mathbf{m}_{1}(0)&\dots\mathbf{m}_{1}(T)\text{sensor }1\\ \mathbf{m}_{2}(0)\dots\mathbf{m}_{2}(T)\text{sensor }2\\ \vdots\ddots\vdots\downarrow\\ \mathbf{m}_{M}(0)\dots\mathbf{m}_{M}(T)\text{sensor }M\\ t=1&\xrightarrow{\Delta t}t=T\\$$

$$\mathbf{F}_{a}(\mathbf{s})=\blockarray{cccc}\block{(ccc)c}fc_{1}(0)&\dots fc_{1}(T)\text{function }1\\ fc_{2}(0)\dots fc_{2}(T)\text{function }2\\ \vdots\ddots\vdots\downarrow\\ fc_{F}(0)\dots fc_{F}(T)\text{function }F\\ t=1&\xrightarrow{\Delta t}t=T\\$$

$$p_a\left(succ|\mathbf{M},t\right)$$

$$p_a^f\left(fc|\mathbf{M},t,succ=\text{true}\right)$$

$$p_{\text{blame}}\left(f=f_i|o_{1:T},a_{1:T}\right)$$

$$p_a\left(\mathbf{F}|\mathbf{M},t,succ=\text{true}\right)\approx \mathcal{N}\left({\mu }_{\mathbf{F}}(t),\Sigma (t)\right)$$

$$\begin{gathered} p_a^f\left(fc|\mathbf{M},t,succ=\text{true}\right)= \\ {\int }_{t^{\prime }\ne t}{\int }_{f^{\prime }\ne f}{p}_a\left(\mathbf{F}|\mathbf{M},t,succ=\text{true}\right)d{f}^{\prime }d{t}^{\prime } \end{gathered}$$

$$\begin{gathered} p_{\text{blame}}\left(f=f_i|o_{1:T},o,a_{1:T},a\right)\propto \\ {p}_a\left(o|f=f_i,o_{1:T},a_{1:T}{\Delta }_a\right)p_{\text{blame}}\left(f=f_i|o_{1:T},a_{1:T}\right)\approx \\ {p}_a\left(o|f=f_i,{\Delta }_a\right)p_{\text{blame}}\left(f=f_i|o_{1:T},a_{1:T}\right). \end{gathered}$$

$$\begin{gathered} {\mathbf{E}}_{t_{\text{fail}}}^{\Delta }\left[f_i\right]:={\mathbf{E}}_{t_{\text{fail}}}^{\Delta }\left[{\mathrm{e}}^{-\alpha \delta t}f{c}_i\right]= \\ {\int }_{\mathbb{N}}{\int }_{\mathbf{M}}{\int }_0^{t_{\text{fail}}}{\mathrm{e}}^{-\alpha \delta t}fc{p}_a^{f_i}\left(fc|\mathbf{M},t,succ=\text{true}\right)\mathrm{d}t\mathrm{d}\mathbf{M}\mathrm{d}fc \end{gathered}$$

$${\mu }_{t_{\text{fail}}}^{\text{exec}}[f_i]=\frac{1}{T}\sum _{t=0}^{t_{\text{fail}}}{\mathrm{e}}^{-\alpha \delta t}f{c}_i^{\text{exec}}(t).$$

$$p_a\left(o|f=f_i,{\Delta }_a\right)=\{\begin{array}{ll}{p}_{\text{dev}}& \text{if }a\text{ was successful}\\ \frac{\left(1+p_{\text{dev}}\right)}{2}& \text{else,}\end{array}$$

$$p_{\text{dev}}=\mathcal{N}\left(x\in \left[{\mu }_{t_{\text{fail}}}^{\text{exec}}[f_i],{\mathbf{E}}_{t_{\text{fail}}}^{\Delta }\left[f_i\right]\right]|{\mathbf{E}}_{t_{\text{fail}}}^{\Delta }\left[f_i\right],va{r}_{t_{\text{fail}}}^{\Delta }\left[f_i\right]\right).$$

$$I\left[a\right]=H\left[p_{\text{blame}}\left(f=f_i|o_{1:T},a_{1:T}\right)\right]-H\left[p_{\text{blame}}\left(f=f_i|o_{1:T},o,a_{1:T},a\right)\right]$$

$$\begin{gathered} a_{\text{next}}=\underset{a}{\mathrm{argmax}}\mathbf{E}\left[I\left(a\right)\right]=\underset{a}{\mathrm{argmax}} \\ H\left[p_{\text{blame}}\left(f=f_i|o_{1:T},a_{1:T}\right)\right]-\mathbf{E}\left[H\left[p_{\text{blame}}\left(f=f_i|o_{1:T},o,a_{1:T},a\right)\right]\right]. \end{gathered}$$

Full text

I Introduction

In recent years robot programming increasingly matured and trained skills became more complex. Programming paradigms shifted from pure hard-coding of skills to (semi-) autonomous skill acquisition techniques. Human supervisors are asked for advice only when needed, e.g. in programming by demonstration and/or reinforcement learning [1, 2, 3]. These new paradigms typically produce a large corpus of mostly unused data. Further, skills involve synchronisation of a high number of components (e.g. computer vision, navigation, path planners, force/torque sensors, artificial skins) and are implemented by large teams of experts in their respective fields. Software components change rapidly which makes it very hard for one single programmer to debug certain components in case of failure. This problem becomes even more severe if the developer is not an expert in the field to which a certain component belongs. Currently, software testing is done in simulation with a high initial cost of implementing test cases. This has some obvious advantages such as the high repeatability and higher safety. However, this testing paradigm also has some serious disadvantages such as the limited conformity with the world or the demand for precise models of the physical environment.

We propose a novel testing scheme that does not require the test engineer to be an expert. Skills are executed autonomously and all collected data, i.e. sensor data and function call profiles, is compared to previous experiences. From this stack of experiences two models can be trained: a measurement observation model (MOM) and a functional profiling fingerprint (FPF). The MOM models sensor measurements observed during successful skill executions. It is trained with deep learning and, as opposed to other testing approaches in robotics, does not impose a strong prior on the nature of tasks or functions to be tested. Therefore our approach is model-free in a sense that no component-specific models are predefined. The FPF provides a typical fingerprint of function calls for a certain skill. The idea is to identify the point in time, in which a skill execution failed, by using the MOM and to relate this to anomalies in the FPF. The skills are selected in order to maximise the expected information gain about which functions might cause problems. The suggestions about possible erroneous functions can be forwarded to the respective developers.

We do not distinguish between skills and tests, which eliminates the need for developing specific test cases. Currently, experts spend time to design test cases with well-defined pre- and post conditions. They typically also do not have a system overview which causes the test cases to be too loose or too strict. In our paradigm, the test cases are just as strict as they need to be as they are grounded on the skills.

The concept is illustrated by a task in which an object is to be pushed along a given path. Many components such as robot control software, an object tracker (image acquisition, segmentation, localisation), a path planner and pushing-specific functions are involved. If the robot loses contact to the object it will be detected by comparing the end-effector force measurements to previous experiences. Our approach will first suggest all running functions from segmentation to pushing-specific functions. If the scene segmentation contains a bug, all functions not related to segmentation can be eliminated as a cause by running skills that use a different segmentation algorithm or no object tracking at all.

II Related Work

Bihlmaier et al. propose robot unit testing RUT [4], closely relating to the idea of classical unit tests. They rely on simulators that are sufficiently accurate and argue that this indeed is the case for most tasks. Laval et al. use pre-defined tests for robot hardware in an industrial setting, in which robots are manufactured in high numbers [5]. In such a scenario, testing can only be performed in an autonomous manner. They provide a multi-layered testing approach with guidelines on how to test hardware with hand-crafted test cases and how to share them between quality assurance and maintenance staff. A similar idea is proposed by Lim et al. by using a hierarchical testing framework composed of unit testing, integration testing and system testing [6]. As opposed to this work, these approaches are guidelines for the developers rather than testing frameworks for autonomous robots. Regression testing is applied to robotics by Biggs [7]. He argues that even testing of low-level control stacks should be performed in simulation in order to prevent dangerous situations. Previous communication of network-based control middle-ware is stored and fed back for testing again. Even though this approach is similar in nature to our framework, it is restricted to and designed for low-level components. Zaman and Steinbauer et al. describe a diagnosis framework and augment it with the additional ability of autonomous self-repair [8, 9]. The framework is embedded into the ROS diagnostics stack in which single components can publish observations and diagnostic messages. It requires pre-defined abstract diagnosis models, whereas our method learns the model from experience. Petters et al. provide a set of tools to ensure the proper working of the control software used by teams of autonomous mobile robots [10]. This involves a high level of manual test design.

Simulation-based testing [11, 12] is one of the most widespread testing techniques. Son et al. propose a simulation-based framework and guidelines for unit, state, and interface testing, which involves the generation of test cases and the execution in a simulator [11]. Park and Kang propose the SITAF architecture [12] for testing software components in which tests are specified as abstractly as possible. Tests are generated automatically and are run on a simulator. Related work is also done in the area of fault detection [13, 14, 15, 16, 17, 18, 19, 20, 21]. Many of these systems follow an observer-based approach in which separate observers monitor components. Reasoning over the observed data in combination with a pre-defined model allows failures to be identified in dynamic systems. An extensive discussion of fault detection systems is outside the scope of this work, as these methods are mainly concerned with model-based approaches applied to specific scenarios or components.

Work that also relies on automatic data storage from previous successful experiences was proposed by Niemueller et al. [22]. Data is queried automatically during the execution of skills and stored to a database. It is directly taken from listening to ROS topics and stored to the NoSQL database MongoDB. They demonstrate the applicability of automatic data storage to fault analysis by hand-crafting a Data-Information-Knowledge-Wisdom hierarchy [23], which represents different levels of abstraction. Developers can then manually work through the hierarchy and identify potential errors by comparing current sensor data on several levels to previous experiences. This demonstrates that such an approach makes sense in principle, however, in our method the identification of problems is done completely autonomously.

III Skill-centric Autonomous Testing

A skill is a pair of a state-changing behaviour and a predicate that determines success. A behaviour is a function

[TABLE]

that maps an environment state $\mathbf{s}\in S$ to another state $\mathbf{s^{\prime}}\in S$. A skill $a=(b,\beta)$ consists of a behaviour $b\in B$ and a predicate

[TABLE]

with $\mathbf{s}\in D$. The predicate $\beta$ provides a notion of success for the behaviour $b$. The set $D\subseteq S$ is called the domain of applicability of the skill $a$. We assume the robot holds a set of well-trained skills $A$, i.e. the set $D_{a}$ is large with $|D_{a}|\gg 1$.

For each skill $a\in A$, the robot holds a database $\Delta_{a}$ of pairs

[TABLE]

These pairs are positive experiences of successful skill executions, i.e. $\beta(\mathbf{s})=\text{true}$. The matrix $\mathbf{M}_{a}(\mathbf{s})$ contains the sensor data (e.g. $\mathbf{m}_{1}=$ force/torque sensors, $\mathbf{m}_{2}=$ position data, $\mathbf{m}_{3}=$ images, …) measured during execution of $a$ by

[TABLE]

with $dim(\mathbf{M}_{a}(\mathbf{s}))=\left(\sum_{i}{dim(\mathbf{m}_{i})},T\right)$ and the execution time $T$. Analogously, the profiling matrix $\mathbf{F}_{a}(\mathbf{s})$ is given by

[TABLE]

where $fc_{i}(t)$ denotes the number of active executions of function $i$ at time $[t,\,t+1]$. Two distributions can be estimated from $\Delta_{a}$: the measurement observation model (MOM)

[TABLE]

and the functional profiling fingerprint (FPF)

[TABLE]

The MOM reflects the probability of a successful execution of skill $a$ given the sensor data $\mathbf{M}$ at time $t$. The FPF denotes the probability of how many instances of a function $f$ were active in the time period $[t,\,t+1]$. The conditioning on $\mathbf{M}$ is required in order to include closed-loop controllers that can chose certain actions dependent on the current measurement.

The goal is to execute skills from the robot’s skill repertoire in order to find a blaming distribution

[TABLE]

given a sequence of executed skills $a_{1:T}$ and corresponding observations $o_{1:T}$. Each observation $o=\left(\mathbf{M},\,\mathbf{F}\right)$ contains sensor data and a functional profile. The skills are selected by maximising the expected information gain given the current belief $p_{\text{blame}}$ (section III-D). After each execution of a skill, the belief is updated by Bayesian inference (section III-C). The complete algorithm is summarised in Algorithm 1.

III-A Training the Observation Model

For the MOM we follow the idea of learning an encoder/decoder neural network and using the reconstruction error to determine whether a given sequence is part of the training distribution or not. Similarly, the reconstruction error was used for anomaly detection [24, 25].

Our neural network is implemented as follows: Each vector of the time series is encoded by the same fully connected neural network with fewer output neurons than there are dimensions in the input vector. This inevitably means that information is lost. This compression step is followed by a layer of Gated Recurrent Units (GRUs) [26], with a number of output neurons equal to the dimensions of the input vector. Fig. 1 shows a schematic sketch of the network used.

The network is trained by providing a given time series as input, and the same time series as expected output. As a loss function we use the average of the cosine similarities between the vectors of the actual output of the network and the expected output (the original time series). This way, the network is forced to compress the time series and reconstruct a time series as close to the original as possible. The cosine similarity is later also used as a metric for the reconstruction error. The network is trained end to end using ADAM as an optimization scheme [27]. Since GRUs have recurrent connections, they can use information from previously-seen vectors in the reconstruction of following vectors. Therefore, the decoding is done as a whole for the complete time series, although the encoding is done for each vector separately.

After such a network is trained on multiple time series of successful skill executions, we can assume that it has specialised to encode and decode sequences of this kind with a low reconstruction error. The hypothesis is that sequences deviating from successful examples will have a higher reconstruction error. Unfortunately, depending on the different phases of execution, the reconstruction error will also vary for the successful examples. In practice this means that there are times at which a high reconstruction error is more suspicious. To incorporate this information in our model, we calculate the mean and standard deviation of the reconstruction errors of all successful examples for each time step. This gives us a normal distribution per time step, which we use to determine the likelihood that a given reconstruction error is of a familiar time series. For a given reconstruction error, we use the probability density at this point as an indication of the likelihood that this error is produced by a successful sequence. Since we get a reconstruction error at each time step, we are able to detect at which point in time the sequence begins to deviate from successful examples. Therefore, we can infer at which point an error has occurred. To filter out inevitable noise, we smooth the resulting likelihood sequence using moving average.

Figure 5 shows the reconstruction error likelihood of different sequences. It can be seen that the likelihood of failing sequences (red) generally falls to a value close to 0 over time. The drop-off point is where an error in execution of the task has likely occurred. The successful sequences used during training are shown in green. Additional successful examples, not seen during training, are shown in blue.

III-B Training the Functional Profiling Fingerprint

We assume that fingerprints, i.e. the time-series of function calls, are Gaussian distributed separately at each time step for a specific skill. For each cell $fc_{i}(t)$ of the matrix $\mathbf{F}$ in equation (5), we estimate the mean and variance over all sample executions of a skill $a\in A$ independently. This is equivalent to approximating the fingerprint distribution by a multivariate Gaussian distribution

[TABLE]

with a diagonal co-variance matrix $\Sigma(t)$. Therefore, the mean and variance are computed for each time step independently, but are averaged over all observed executions. This allows us to model the fingerprint of each function $f$ separately, i.e. the probability

[TABLE]

of function $f$ being called at time $t$. While the independence assumption is not true in general, we assume a certain degree of smoothness for a specific skill where the function call time-series is similar for all supported environment states (e.g. also for closed-loop controllers). This allows us to further approximate by averaging over all observaions $\mathbf{M}$. We stress that, in contrast, the MOM demands a more powerful modelling technique such as deep learning in order to model sensor data can vary strongly.

III-C Bayesian Inference for Bug Detection

When a skill $a\in A$ is executed, an observation $o=\left(\mathbf{M}_{a}^{\text{exec}},\,\mathbf{F}_{a}^{\text{exec}}\right)$ is measured. We seek to update the probability distribution $p_{\text{blame}}\left(f=f_{i}\,|\,o_{1:T},o,\,a_{1:T},a\right)$ accordingly. Using Bayes’ theorem and assuming that the likelihood function does not depend on the previous actions $a_{1:T}$ and observations $o_{1:T}$, i.e. $p_{a}\left(o\,|\,f=f_{i},\,o_{1:T},\,a_{1:T},\,\Delta_{a}\right)\approx p_{a}\left(o\,|\,f=f_{i},\,\Delta_{a}\right)$, we can write

[TABLE]

The likelihood function $p_{a}\left(o\,|\,f=f_{i},\,\Delta_{a}\right)$ denotes the probability of seeing a certain observation $o$ given that the function $f=f_{i}$ is buggy. For the sake of readability we omit the condition on the database $\Delta_{a}$ for the distribution $p_{\text{blame}}$. The likelihood function typically is unknown but can be approximated given the following assumptions:

(i) A failure in function $f_{i}$ executed at time $t_{\text{exec}}$ influences $p_{a}\left(succ\,|\,\mathbf{M},\,t=t_{\text{exec}}+\delta t\right)$ with a probability proportional to $\mathrm{e}^{-\alpha\delta t}=\mathrm{e}^{-\alpha\left(t_{\text{fail}}-t_{\text{exec}}\right()}$, where $t_{\text{fail}}$ is the estimated failure time and $\alpha$ is a free parameter.

(ii) As all probabilities $p_{a}^{f_{i}}\left(fc\,|\,\mathbf{M},\,t,\,succ=\text{true}\right)$ for all $f_{i}$ are assumed to be independent, the failure of $f_{i}$ only causes changes in the $i$th row of $\mathbf{F}_{a}^{\text{exec}}$.

(iii) A failure of $f_{i}$ can, but does not have to, cause a change in the $i$th row of the fingerprint $\mathbf{F}_{a}^{\text{exec}}$, e.g. the execution length of $f_{i}$ changes (which would affect $\mathbf{F}_{a}^{\text{exec}}$) or just the behaviour of $f_{i}$ changes (which does not mean that the distribution of function calls is affected).

A skill is executed and the MOM is used to estimate the earliest time step $t_{\text{fail}}$ with $p_{a}\left(succ\,|\,\mathbf{M},\,t_{\text{fail}}\right)\leq p_{\text{thresh}}$. We use the fingerprints $\mathbf{F}_{a}^{\Delta}$ in the database $\Delta$ of skill $a$ to compute the expected values of exponentially weighted function counts $\mathrm{e}^{-\alpha\delta t}fc_{i}^{\Delta}(t)$ for each function $f_{i}$ with

[TABLE]

and corresponding variances $var_{t_{\text{fail}}}^{\Delta}\left[f_{i}\right]\coloneqq var_{t_{\text{fail}}}^{\Delta}\left[\mathrm{e}^{-\alpha\delta t}fc_{i}\right]$. The open parameter $\alpha$ determines the size of the time window on the fingerprint. We further compute the weighted mean of the executed fingerprint $\mathbf{F}_{a}^{\text{exec}}$ with

[TABLE]

These values are used to compare the observed fingerprint of the executed skill $a$ to the corresponding FPF in the database $\Delta_{a}$. The assumptions defined above culminate in

[TABLE]

[TABLE]

The probability $p_{dev}$ measures how much a measurement $\mu_{t_{\text{fail}}}^{\text{exec}}$ deviates from a regular execution of the skill $a$ within the time window $t\in\left[0,\,t_{\text{fail}}\right]$. Case 1 of equation 14 treats the case of a successful execution. The probability of observing a successful observation $o$ given the function $f_{i}$ has a bug should be low. However, a function might still have a bug but just did not affect the skill enough to make it fail. Therefore, $p_{a}\left(o\,|\,f=f_{i},\,\Delta_{a}\right)$ should increase if the finger print strongly differs from other successful experiences. The second case of equation 14 applies if the skill was not executed successfully. Each executed function should at least be suspicious, i.e. $p_{a}\left(o\,|\,f=f_{i},\,\Delta_{a}\right)\geq 1/2$. The probability increases proportionally to the deviation from previous successful experiences.

III-D Skill Selection by Information Gain Maximisation

The previous section described how to update the belief $p_{\text{blame}}\left(f=f_{i}\,|\,o_{1:T},o,\,a_{1:T},a\right)$ given a skill $a$ was selected. This skill should be selected such that the entropy of the probability distribution $p_{\text{blame}}$ decreases. A common way to solve this problem is to maximise the expected information gain. The information gain is defined by

[TABLE]

Before executing the skill $a\in A$, the information gain cannot be computed directly, as the corresponding observation $o$ is not known yet. However, the current belief $p_{\text{blame}}\left(f=f_{i}\,|\,o_{1:T},\,a_{1:T}\right)$ can be used to estimate the expected information gain $\mathbf{E}\left[I\left[a\right]\right]$. We estimate $\mathbf{E}\left[I\left[a\right]\right]$ by uniformly sampling pairs $\left(succ,\,t_{\text{fail}}\right)$ for each sample in the database $\Delta_{a}$ with random success $succ\in\{\text{true},\,\text{false}\}$ and random failure time with probability $p(t_{\text{fail}})=1/T$. At each step a Bayesian belief update is performed, and the expected entropy $\mathbf{E}\left[H\left[p_{\text{blame}}\left(f=f_{i}\,|\,o_{1:T},o,\,a_{1:T},a\right)\right]\right]$ is estimated. The current entropy $H\left[p_{\text{blame}}\left(f=f_{i}\,|\,o_{1:T},\,a_{1:T}\right)\right]$ can be computed in closed form and the robot optimises

[TABLE]

IV Experiments

We evaluate our method in simulation and in real-world tasks. In simulation we analyse the behaviour of the Bayesian inference and the information gain optimisation independently of the MOM. Our approach is tested with a real robot by implementing a set of purposefully sabotaged skills.

IV-A Simulated Experiments

The Bayesian reasoning is decoupled from the MOM by generating artificial fingerprints of the type $\mathbf{F}_{a}\left(f_{1},\,f_{2},\,\dots\,f_{F}\right)=\left(\mathbf{fc}_{1},\,\mathbf{fc}_{2},\,\dots,,\,\mathbf{fc}_{F}\right)^{T}$. If $f_{i}=\text{false}$, the vector $\mathbf{fc}_{i}$ is chosen with $\mathbf{fc}_{i}=\vec{0}$. Otherwise it is given by $\mathbf{fc}_{i}=\left(fc_{i}(0)\propto\mathcal{N}(\mu_{i},\sigma_{i}),\,\dots,fc_{i}(T)\propto\mathcal{N}(\mu_{i},\sigma_{i})\right)^{T}$. If the matrices $\mathbf{F}_{a}\left(f_{1},\,f_{2},\,\dots\,f_{F}\right)$ are generated this way, the particular choice of the MOM is irrelevant. Artificial skills using the first 6 out of 241 available functions were generated. In order to simplify the notation, only used functions are denoted, e.g. $\mathbf{F}_{a}\left(\text{true},\,\text{true},\,\text{false},\,\dots,\,\text{false}\right)\equiv\mathbf{F}_{a}\left(1,\,2\right)$. In Figs. 2 – 4 typical evolutions of information gains and blaming probabilities by using skills with different fingerprints are shown. In all scenarios a bug in function $f_{2}$ causes an error if a skill uses $f_{2}$. Our system was able to detect the error in all scenarios with $p_{\text{blame}}(f=f_{2})\approx 1$. Fig. 2 shows a typical scenario, in which one skill is executed until another skill has a higher information gain. The skill is switched after 19 executions in order to discriminate between two failure candidates $f_{1}$ and $f_{2}$. Note that all functions except $f_{1}$ and $f_{2}$ have almost 0 probability as after executing the skill $a_{1}$ has identified that a bug must be in functions $f_{1}$ or $f_{2}$ which places the algorithm in a local optimum. If further bugs are contained in the software, the system has to be re-iterated when the bug in $f_{2}$ is fixed. The high number of functions with very low probability causes the probabilities in Fig. 2b to look like they are not normalised, however, this is just a visual artifact. Fig. 3 shows a similar scenario with a slightly different selection of used functions per skill. Even though the information gains develop differently, the bug belief develops the same way as in Fig. 2b because no different actions are taken. Fig. 4 shows a degenerate case in which two skills contribute equally much to identify the function $f_{2}$ and are executed alternately while the confidence in $f_{2}$ increases continuously. Even though the correct function is identified, the skill switching might require extra effort for preparation of different environments.

IV-B Real-world experiments

We show the applicability of deep learning to failure detection in two simple tasks: simple grasping and object handover. Further, our system is tested with a set of simple skills by purposefully introducing bugs to the software. The robot setting used can be found in Fig. 6. It consists of two KUKA LWR 4+ robotic arms with one Schunk SDH gripper attached to each arm. The KUKA arms provide a control interface called fast research interface (FRI), which enables control and sensor data retrieval (joint positions, joint forces, Cartesian forces and torques). For object detection two Kinects are mounted - one on the chest and one above the robot. Objects are localised by segmenting them from the table surface and fitting a box to the remaining point cloud image by using PCL. Three different skills are implemented:

• •

Simple grasp: Objects are placed in front of the robot. A PCL based localiser recognises the objects and a Cartesian planner is used to move the end-effector. The fingers are closed and the object is lifted.

• •

Pressing a button: A red emergency button is placed in a fixed robot-relative position. A joint plan is executed and the button is pressed with the wrist and without using the fingers.

• •

Handover: The robot reaches forward by using a joint plan and waits until an object is placed in the hand. This event is detected by observing the end-effector forces. When an object is handed over, the fingers are closed.

IV-B1 Evaluation of the MOM

A set of erroneous executions was generated by either adding bugs to the code or by manually interfering with the environment, e.g. by kicking the object out of the robots hand.

Our implementation of the MOM uses a fully connected neural network with 32 output neurons and a RELU nonlinearity. The size of this bottleneck depends on the dimensionality of the input vectors. In our case, it was determined empirically. The GRU layer uses an internal $tanh$-nonlinearity and a logistic sigmoid nonlinearity for the output. The network is trained for 500 epochs which, on an nVidia GTX 1080 GPU for 70 sequences of 2000 time steps each, takes about five minutes.

Fig. 5a shows the MOM performance on the dataset for simple grasping. For most negative samples the likelihood of being a successful sample drops close to zero, while this is not the case for successful samples. Two different failure types are visible: the first failure type arises very early, at $t<500$, and corresponds to failed path planning which causes the arm not to move at all. When the arm moves, a failure cannot be detected as there is no contact with the object yet. Failures are detected when contact is made with the object from time $t>1000$. In the handover task (Fig 5b), the failure is detected when the arm does not move at all during the reaching motion or when the object should be placed in the hand, but is not. It should be noted that as soon as an error is detected, the further development of the reconstruction error is not relevant anymore.

IV-B2 Running the complete system

Sensor data and fingerprints were measured for at least 70 executions per skill. In total, more than 80 functions (including robot control) were used by the skills. Different types of bugs were purposefully introduced to the software. To reduce the computational effort for the estimation of the information gain, the decaying expected value in equation 12 was computed only for a window of 2 seconds before $t_{\text{fail}}$.

In the first scenario, the Cartesian planner was destroyed by introducing a constant shift. This type of error could happen if the robot model is not correct. The robot started to test the grasping skill which failed due to missing the object. It identified a set of potentially faulty functions and the 4 functions with the highest belief were {getRobotId, planJointTrajectory, storeJointInfoToDatabase, updateFilter}. None of these functions are related to the Cartesian shift bug. However, the confidence of the robot was low and planCartesianTrajectory was included with a similar probability. The grasping skill was used to confirm the belief until the button pressing skill provided a higher expected information gain. The button pressing skill was executed successfully because only a joint plan was used. This allowed the robot to exclude most wrong guesses and to suggest the list {cartesianPtp, planCartesianTrajectory, computeIk, closeHand} with high probability. The localiseObject is not suspicious as it was executed outside the time window, but is in the list as well if the window is enlarged. The handover skill enabled the robot to eliminate closeHand. All identified functions, i.e. {cartesianPtp, planCartesianTrajectory, computeIk}, are involved in Cartesian planning (and not in joint planning).

In the second scenario commands for moving the hand were not forwarded to the hardware. This affected the grasping skill and the handover skill, whereas the button pressing skill succeeded. All functions used in the button pressing skill were removed from the list of candidates (e.g. for joint planning, arm control functions) and the functions for Cartesian planning and hand control remained: {closeHand, cartesianPtp, planCartesianTrajectory, computeIk}. In the next step the handover skill was executed. Because the Cartesian planning functions were not used in the failing handover skill, the corresponding functions were eliminated.

In another scenario, the localisation system was destroyed by returning a constant position. In this case, the error is hard to detect: In the grasping scenario, the robot misses the object long after the localiser was run. If the time window is long enough, the system still identifies the localiser among other plausible candidates and returns the set {localiseObject, cartesianPtp, planCartesianTrajectory, computeIk} with high probabilities. Given the three provided skills, the robot has no possibility to discriminate between errors in the respective functions. In our setting, the localiser and Cartesian planning are always used together and an error in the localiser does not appear earlier in the sensor data. A video demonstration of the approach switching from one skill to another can be found online111https://iis.uibk.ac.at/public/shangl/iros2017/hangl-iros2017.mp4.

V Conclusion and Future Work

We introduced a skill-centric software testing approach that uses data collected over the life-time of a robot, which eliminates the need for defining separate test cases. We use two different types of data: sensor data of successful skill executions and corresponding profiling data. We train a so-called measurement observation model (MOM) (deep learning) and a functional profiling fingerprint (FPF) (Multivariate Gaussian model). Skills are executed as test cases and sensor data is compared to previous experiences. We use Bayesian belief updates to estimate a probability distribution of which functions contain bugs. The skills are selected in order to maximize the expected information gain. The approach is evaluated in simulation and in real robot experiments by purposefully introducing bugs to existing software.

This work discusses the problem of bug detection and autonomous testing. Future work will be concerned with developing autonomous strategies for bug fixing (e.g. by automatically performing selective git roll-backs or autonomously replacing hardware). Further, due to the lack of data, the likelihood function of the Bayesian belief update (equation 14) had to be hand-crafted following reasonable assumptions. In a more general framework the likelihood function can be trained automatically by providing ground truth data whenever the programmer has fixed a certain bug.

ACKNOWLEDGMENT

This work has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement no. 731761, IMAGINE.