Page - 13 - in Proceedings of the OAGM&ARW Joint Workshop - Vision, Automation and Robotics

does not reason over different diagnosis but only over the set of components which may be faulty. The components which may be the faulty need either to be observed more closely or need to be repaired. Additionally, one cannot assume that this component works properly with the information given so far. Thus, this set is sufficient to decide which action to execute. The rule engine consists of a set of rulesRwhere each rule r is a tuple comprising the following elements. • A set posObs defining observations which should have been made • A set negObs defining observations which should not have been made • A set posPosAb which is a set of components which should have been diagnosed as possibly faulty • A set negPosAb which is a set of components which should not have been diagnosed as possibly faulty • α an action to execute. Due to the use of the sets, one can simply perform the reasoning by intersecting the sets to determine if the rule should be triggered. As some observations, may be missing one may face the problem that neitherobsresource∈Obs nor ¬obsresource ∈Obs holds, thus one cannot take a decision if the observation of the resource is true or false. If one would strictly perform the reasoning a rule may not triggered because obsresource 6∈Obs holds although ¬obsresource 6∈ Obs holds. This is of special interest as not every observer may state regularly which observations are true but only state which observations are false. To deal with this problem we trigger a rule if no contradicting information is observed. This is achieved by the following simple procedure. Trigger the rule if neither of the following holds. • posObs ∩Obs 6= ∅, where posObs = {¬po|po ∈ posObs} • negObs∩Obs 6=∅ • posPosAb ∩ PosAb 6= ∅, where posPosAb = {¬posAb|posAb∈posPosAb} • negPosAb∩PosAb 6=∅ As only set operations are performed one can perform an efficient reasoning which allows a fast reaction. Espe- cially as one can assume that the sets posObs, negObs, posPosAb andnegPosAb are small. Thus, one can perform this checks inO(|posObs|∗log(Obs)+|negObs|∗log(Obs)+ |posPosAb|∗log(PosAb)+|negPosAb|∗log(PosAb))which allows a fast reaction even in case of many observations or many possible faulty components. As rules, should only be used to allow the robot to react to faults, instead of continuously checking the rules, they are only checked if the set of observations or possible faulty components changes. This allows to save resources but also prohibits to trigger a rule multiple times without any change in the system. After deciding that a rule should be triggered one needs to execute the action αwhich is defined for this rule. The actions range from printing a message to the console or to a log file over changing parameters to triggering the execution of an external script. Thus, one can trigger nearly arbitrary behavior to react to a fault. VI. USE CASE Before we discuss related research, we will show a simple use case of the system. The use case is the simplified odometry calculation of a robot which delivery good in a warehouse, see [10] for a detailed description of the robot. The odometry is calculated using the wheel encoders and an IMU is used to improve this odometry. The IMU is fused with the calculation by using the rotation of the IMU instead of the calculated rotation. Thus, if the IMU is fault free the odometry is improved. To show the impact of the proposed system three faults is simulated. The IMU can either be stuck to zero after some time, it can overestimate the rotation by 20% or issue that there is no rotation after rotating a certain amount of time. To evaluate the impact of the system the robot was commanded to move between six waypoints in the environ- ment, for three minutes. During the movement, the wheel encoder the IMU measurements and the real position of the robot were determined. The real position of the robot was determined with the help of an OptiTrack system. After the movement of the robot was recorded the odometry is calcu- lated using the wheel encoders and the IMU. Additionally, one observer is used which checks if the calculated rotation of the wheel encoder and the IMU correlate. This allows detecting a fault of the IMU. Using this fault detection, the diagnosis can calculate that the IMU is faulty. In such a case the rule engine changes a parameter to ensure that the IMU is no longer used for the odometry calculation. The evaluation compares the error between the ground truth and the calculated odometry which always uses the IMU and the calculated odometry which only use the IMU if it is not diagnosed to be faulty. In case the IMU was stuck to zero after several seconds the mean error was reduced by 28.1% and the root mean squared error (RMS) was reduced by 39.9%. In case the IMU was overestimating the rotation by 20% the mean error was reduced by 25.6% and the root mean squared error (RMS) was reduced by 35.6%. In case the IMU was reporting zero rotation after one second of rotation the mean error was reduced by 39.3% and the root mean squared error (RMS) was reduced by 50.9%. Thus, the use of the diagnosis system could react quickly enough to improve the odometry calculation drastically. The evaluation was performed on an intel i5-2430M with 8 GB of RAM and took less than 2 % of the CPU. VII. RELATED RESEARCH We begin our discussion of related research with the method proposed in [11]. The method adds to each software module so-called software sensors. These sensors supervise the execution of a software component which is treated as a black box. Thus, the software component can be devel- oped and tested independently from the sensors. During the execution, the software sensor checks for faults and report these faults on a diagnosis port. To ease the reuse of the 13