Remote Fault Diagnosis of Robots Using a Robotic Black Box Ahmad Drak1 and Youssef Youssef1 and Paul G. Plöger1 and Anastassia Kuestenmacher1 1 Bonn-Rhein-Sieg University of Applied Sciences, Department of Computer Science e-mail: {ahmad.drak,youssef.youssef}@smail.inf.h-brs.de e-mail: {paul.ploeger,anastassia.kuestenmacher}@h-brs.de

Abstract Autonomous mobile robots comprise of several hardware and software components. These components interact with each other continuously in order to achieve autonomity. Due to the complexity of such a task, a monumental responsibility is bestowed upon the developer to make sure that the robot is always operable. Hence, some means of detecting faults should be readily available. In this work, the aforementioned fault-detection system is a robotic black box (RBB) attached to the robot which acquires all the relevant measurements of the system that are needed to achieve a fault-free robot. Due to limited computational and memory resources on-board the RBB, a distributed diagnosis is proposed. That is, the fault diagnosis task (detection and isolation) is shared among an on-board component (the black box) and an off-board component (an external computer). The distribution of the diagnosis task allows for a non-intrusive method of detecting and diagnosing faults, in addition to the ability of remotely diagnosing a robot and potentially issuing a repair command. In addition to decomposing the diagnosis task and allowing remote diagnosability of the robot, another key feature of this work is the addition of expert human knowledge to aid in the fault detection process.

1

Introduction

Modern day autonomous mobile robots are in need of higher system performance to perform their tasks. Associated with this need is the growing complexity of the robot’s system. Regardless for the countless hours spent developing and prototyping robotic systems, a fault is always prone to happen [Steinbauer, 2013] [Isermann, 2005]. For those reasons, and many more, the need for a fault handling mechanism arises. This fault handling mechanism is referred to as fault diagnosis. Several notable work has been done in the field of robotics regarding fault diagnosis, some of which is a comprehensive survey on different model-based fault detection, isolation and controller reconfiguration methods [Hwang et al., 2010], a comparison of several robust fault diagnosis schemes that cover internal and external faults [Kustenmacher and Ploeger, 2012] and model-based reasoning techniques which deals with hardware and software supervision

[Hofbaur et al., 2007]. Most of the work revolves around methods that utilize the concept of redundancy (hardware or software) where the idea is to compare signals of the same system variables, and based on the error, decide if a fault has occurred [Brandstotter et al., 2007]. In addition, online model-based reasoning techniques for robots software demonstrate the ability to diagnose faults without prior knowledge [Alexander and Steinbauer, 2008]. Analytical redundancy, rather than hardware redundancy, is usually preferred due to less cost involved [Verma et al., 2004]. However, it is more challenging since its robustness in the presence of noise and unknown disturbances is hard to maintain [Hwang et al., 2010]. Other techniques include quantitative model-based methods, such as observers and kalman filters, and qualitative model-based methods, such as causal models and abstraction hierarchy [Venkatasubramanian et al., 2003]. On the other hand, other fault diagnosis (FD) communities (DX) have emerged where the use of classical methods has been minimized. Rather, AI techniques are utilized. These methods include expert systems coded into a knowledge base, consistency-based diagnosis and abstract modelling [Zaman et al., 2013] [Nan et al., 2008]. Most of these methods are component oriented and require only models of correct behaviour. Once an inconsistency has been detected between an observation and the model, a reasoning engine determines the cause of this conflict, and in return produces a diagnosis consisting of a set of possible faulty components [Koitz and Wotawa, 2015]. The idea of remote diagnosis for robots was first introduced by Fritsch et al. in [Fritsch et al., 2006], with the main focus centered around using discrete-event systems and optimizing the communication method. Several other attempts at internet-based diagnosis were divulged earlier. The main purpose of such internet-based remote diagnosis systems (IRDS) was mainly for remote machine maintenance or simply a proof of concept [Wang et al., 2006] [Hongsheng et al., 2000]. It is noteworthy to disclose that IRDS does not practically decompose the diagnosis task, it rather creates web-based capabilities for the system in order to notify the engineers of faults, in addition to minimal diagnosis done on a remote machine. In this sense, the authors of IRDS field argue that it is indeed remote diagnosis. For robot users who utilize the robot for certain services, the presence of faults is undeniably a waste of money and power. Similarly for robot development companies, faults will only cause more being spent on fixing the problem and resuming the robots service. Such a scenario, for exam-

ple, could occur in service robots in hospitals. The interruption of the robots service (aiding patients and/or nurses) would cause certain hospital operations to seize thus leading to increased wasted cost and time in resuming operation. This would also imply that the robot development company would have to suffer the consequence of sending a technician to diagnose the problem and fix it, thus spending more money (tickets, expenses etc.) The aim of this project is to allow for remote diagnosis of robots. The idea is to set a non-intrusive device, referred to as the on-board component (robotic black box), which handles the task of fault detection, and to set-up an off-board component (a computer) which addresses the issue of fault isolation and identification. The decomposition of the diagnostic task as such will allow for reserving the robots resources for its allocated tasks, remotely isolating faults and suggesting repairs, resume robot operation with no further expense and time in case of simple faults and a comprehensive overview of the robots state at all times.

2

Remote Diagnosis

The fault diagnosis task is a rather complex burden when it comes to computation and memory resources. Modern communication technologies allow for fast and reliable data transmission. This fact will be exploited in order to decompose the diagnosis task and produce remote diagnosis, thus allowing the system with limited resources to not handle the burden of diagnosis [Fritsch et al., 2006]. Moreover, this scheme ensures that the robot resumes its operation as soon as possible after the occurrence of a fault. An example of this would be a domestic robot that operates in a hospital. The robot would typically be responsible in aiding the nurses and delivering hospital supplies (medicine, linen etc.), in addition to aiding patients in need. If a fault is to occur, the hospital’s operations will be impeded pending the help of a specialized engineer. However, remote diagnosis allows for the following: • non-intrusive addition of an on-board component (robotic black box) which handles fault detection • diagnosing the robot remotely and determining the cause of the fault immediately • possibly repairing the fault (e.g. controller restart) or suggesting a repair to the local technician

components, where the off-board component would then request specific information needed. • The communication means will cause various time delays and (possibly) loss of data packets. This limits the real-time factor of the remote diagnosis. In addition, it can be regarded as a potential cause of fault, therefore, the amended fault model must incorporate these effects. To overcome this limitation, the communication network can be modeled by a timed automata with discrete inputs and outputs [Schlage and Lunze, 2010a]. The general architecture of the remote diagnosis is depicted in Fig. 1. The on-board component’s sole objective is to perform fault detection. In that sense, it will only have to answer the question "has a fault occurred?". Generally, a correct model of the system is needed in the on-board component. On the other hand, the off-board component will be responsible for isolating and identifying the fault. For this, faulty models of the system are needed if a traditional FDI approach is used, or as an alternative, a diagnostic engine can be used.

Figure 1: Remote diagnosis architecture.

3

Approach

3.1

The On-board Component: The Robotic Black Box

The ultimate goal of the robotic black box (RBB) is to effectively detect faults in the robot, send relevant information to the off-board component and ultimately allow the robot to resume its tasks with minimal human intervention. However, this functionality alone does not fully constitute a reliable and effective RBB. Hence, the following functionalities embody the preliminary design of the RBB:

• reduce the amount of idle time of the robot

• detection of faults upon occurrence

• ultimately reducing the cost for the developer’s company by not sending an engineer to diagnose the problem.

• send relevant information needed for fault isolation to the off-board component

For remote diagnosis to function, it obviously needs both the on-board and the off-board components, in addition to the communication means between them. However, some limitations are imposed on these components [Schlage and Lunze, 2010b]: • The On-board component lacks the memory and computational resources and has to, therefore, deal with these limitations by deploying non-complex algorithms. • The off-board component will receive limited and highly needed data only, as the data network should not be flooded. This limitation could be overcome by allowing for a two-way communication between the

• highly modular design which allows for interfacing with any target robot with minimal set-up process • non-intrusive connection to the target robot as to not interfere with the robot’s system • addition of human expert diagnosability information to aid in fault detection • storing all robot information on an external hard drive for offline fault analysis • automatic modelling of the robot with minimal human intervention • ease of expansion to include redundant hardware to be triggered by the off-board component and redundant sensors for additional measurements.

There are several methods to detect faults in a system such as; structural analysis, observer based fault detection, model based fault detection and logistic approach. The selection of the fault detection method to use is dependant on the resources available, the simplicity/complexity of the system, the linearity or non-linearity of the system as well as other factors that can be taken into consideration. Structural analysis can be used for non linear systems, where the information about the system components that can not be measured can be extracted.The parity equations allow the generation of residuals. The structure of the system is described using a set of constraints and variables, which allows for an incidence matrix to be constructed. Using this incidence matrix, the parity equations can be deducted and the residuals can be generated. This method was implemented successfully in [Fourlas et al., 2015], where the goal was to detect faults in a 4-wheel skid steering mobile robot as early as possible and achieve fault tolerance. Observer-based fault detection requires an accurate mathematical model of the system under investigation. However, in real world applications, approximated models can only be found. An approach by Wunnenberg [Wünnenberg, 1990] allows robust residual evaluation even in the presence of model uncertainties. This is done by designing a linear observer, which treats the systems non-linearities as known inputs. This method has been applied and tested on an industrial robot in [Sneider and Frank, 1996], where the experimental results prove the high sensitivity of this method to faults. In [Yong et al., 2006], a combined logistic and model based approach for fault detection is applied to the suction foot control of a climbing robot. By modelling the kinematics and dynamics of the robot, some of the faults can be detected easily. Logic relations of the system state could be modelled using a ’Fault Analysis Tree’, where events and causes are linked. By analysing the events, one can detect faults in a system. The results of such work showed that the faults could be timely detected using this approach. The methods that have been previously mentioned have been well studied and tested, however, as accurate as models are, there are still faults that can go undetected because of the differences between the real system and it’s model. Usually, when faults occur in a system that can not be detected by the fault detection method, or can not be amended by the normal user of the system, an expert on the system is required to resolve the problem. Fault detection can be further enhanced by adding expert knowledge to the fault diagnosis system. The idea behind expert systems is to emulate the decision making ability of an expert. The ability to detect faults timely and suggest mending actions would benefit the system greatly and reduce costs effectively. A common problem in expert systems is usually the knowledge acquisition, this problem is still to this day being addressed. In [Wang et al., 2011], artificial neural networks are used to tackle this problem. Artificial neural networks have the ability to mimic the decision making process of an expert and has some advantages such as, strong ability to learn from samples, obtain knowledge, store it in the form of weight and threshold, it also allows parallel processing. This approach has been tested on a fire control system and the experimental results show that the output of the neural network are consistent with the learned samples and the expected results. Artificial neural networks (ANN) are also

used in [Ranganathan et al., 2001] for failure detection and control in an autonomous underwater vehicle. The ANN used here integrates the ability of a fuzzy rule based expert system, where it is used for detecting failures by observing various changing parameters of the vehicle. The experiment results showed that the ANN detects faults 94% of the time.

3.2

The Off-board Component

The main purpose of the off-board component is to perform fault isolation, upon a detection of a fault by the on-board component. Physically, the off-board component is a PC with (almost) unlimited memory and processing resources, in addition to the necessary hardware to receive data from the on-board component (Ethernet, WiFi...). After receiving a signal from the on-board component that a fault has occurred, the off-board component is responsible for determining the root cause of the fault. The method adapted in this work is based on consistency-based diagnosis (CBD) [Koitz and Wotawa, 2015] [Poole and Mackworth, 2010]. CBD produces a set of possible faults based on the correct behaviour and current observations of the system. When conflicts arise between the former and the latter, the CBD is capable of proving what’s wrong with the system, and hence isolating the fault(s). In general, CBD needs the correct behavioral model of every component in the system, in addition to the correct structural model of the system as a whole. The observed behaviour is then checked with the predicted behaviour, if a discrepancy is found, the conflict is identified and a possible set of fault candidates is generated. For CBD to operate correctly, a set of assumptions were introduced [De Kleer and Kurien, 2004]: • The physical system is a set of interconnected components. • Every component has a known desired function. • The design of every component does achieve its function. • All malfunction(s) are caused by faulty component(s). Generating fault candidates is done by identifying a set of minimal conflicts. This is needed so as to prevent a combinatorial explosion in the set. Generating this minimal conflict set is typically achieved through problem solvers such as Assumption-based Truth Maintenance System (ATMS) or Satisfiability (SAT) solvers. A python-based diagnostic engine is used in this work [Quaritsch and Pill, 2014]. This engine is a CBD one that follows the outline of the famous work of Reiter [Reiter, 1987]. Once the outcome of the model and the observations contradict, the diagnostic engine resolves that contradiction and locates the component, or set of components, that is the root cause. A SAT solver is used in this engine to produce the minimal conflict set. The SAT solvers is favoured as it is capable of solving hard structured problems with over a million variables and several million constraints [Gomes et al., 2008]. The overall architecture of the on-board and the off-board components is depicted in Fig. 2 The model used in the diagnostic engine is an abstract one that utilizes propositions and Horn clauses to describe the correct behaviour of the system. The model is saved in a YAML1 file with three major sections, an example of which 1

"YAML is a human friendly data serialization standard for all programming languages." http://www.yaml.org

Figure 4: Physical depiction of the RBB non-intrusively connected to a KUKA youBot. Figure 2: The complete architecture of the remote diagnosis scheme.

4

Evaluation

4.1 can be seen in Fig. 3. The first section defines the propositions that represent the predicates, where AB stands for abnormal and ¬AB is not abnormal. The second section is a list of all the set of propositions of the system. The third section is a set of clauses that define the model. In this example, the model represents a simplified version of a robot with a laser scanner, a gripper and a camera (realsense).

A preliminary implementation of the RBB was nonintrusively connected to a KUKA youBot2 in order to proceed with experimental testing, as seen in Fig. 4. The power to the black box was taken from one of the robots external power jacks and an existing Ethernet port was used for I/O. Since the external power jack of the youBot is at 24v, a step down DC-DC converter was used to step down the voltage to 5v, as it is the operational voltage of the RBB. Internally, a set of observers were deployed to monitor the different aspects of the robot. It is noteworthy to mention that correct modelling of the system is of paramount importance, as it is one of the leading factors behind a successful fault detection. An external PC serving as the off-board component was also set-up to receive information from the RBB, where the diagnostic engine will be able to locate the root cause of a fault.

4.2

Figure 3: Example of an abstract model written in a YAML file. As seen in the Fig. 2, the off-board component receives the observed behaviour of the robot once a fault occurs. The diagnostic engine takes as input these observations in addition to data from the model to determine the root cause of the fault. An additional stage could be added to the offboard component, which is the repair engine. The repair engine takes observations, the diagnosis and a repair model as input. These inputs are transformed into a planning problem which the engine attempts to solve. The repair model is a set of rules or actions which the repair engine would need in order to solve the problem, e.g. shutdown(n). When a solution to that repair planning problem is found, it is provided to the user at the off-board component, in turn the user could initiate a remote repair action, if the repair is a non-complex one e.g. USB reset.

Set-up

Results

The tests were conducted by injecting a fault in the Intel realsense 3D camera3 ROS4 node. The camera’s main objective is to detect objects on a platform. The fault injected resembles a lost connection between the robot and the camera, i.e the camera either malfunctioned or the cable was severed. As can be seen from Fig. 5, the RBB was successfully able to detect a fault in the realsense camera node. Any non-zero value for the fault detection indicator signifies a detected fault. After a detection of a fault, the relevant information needed is sent to the off-board component. The diagnostic engine in turn takes the observed behaviour as input, along with the model of the robot. The diagnostic engine was then capable of identifying the set of minimal conflicts and generates fault candidates. The successful isolation of the off-board component is depicted in the fault isolation indicator plot in Fig. 5. 2

http://www.youbot-store.com/ http://www.intel.com/content/www/us/en/architecture-andtechnology/realsense-overview.html 4 http://www.ros.org 3

vast range of different robot fields (at work, at home etc.). One of the benefits of such a fault diagnosis decomposition is the minimum usage of the robots own PC resources. Moreover, it can be made possible that all data on-board the robot be saved to an external hard drive attached to the black box. This allows for deeper diagnosis and investigation after the fact. The trade-off between using valuable robot resources and the cheap cost of building such a black box makes this idea even more endearing. The process of isolating a fault requires a substantial amount of CPU and memory resources, hence shifting this process to an off-board component with relatively unlimited resources is highly praised. A proof of concept was demonstrated in this work where the RBB was capable of detecting a fault and the off-board component successfully isolated it. However, more future work is needed for a complete functional system. Such work include the effective addition of human expert knowledge, a reliable automatic modelling of the robot with minimal human intervention and dependable communication means between both components. Figure 5: Test results of the fault injected in the camera node. Any non-zero value indicates successful fault detection and isolation. Table 1: Resource usage comparison between two observer implementations. CPU resource (% CPU) Memory resource (% MEM) Mean BW (KB\s) Mean Frequency (Hz)

1st Implementation

2nd Implementation

95.8

1.6

20.3

2.4

1.445

0.212

39.91

0.99

A resource usage comparison between two observer implementations can be seen in Table 1. The major difference between both implementations is that the first declares each observer as a separate ROS node while the second creates one node for all the observers deployed [Zaman et al., 2013]. As can be seen, the first utilizes more than 95% of the CPU resource and almost 20% of the total memory. On the other hand, the second uses significantly fewer resources at almost sixty fold less CPU usage and approximately eight fold less memory resource. This is attributed to the superior and more enhanced implementation, which in turn allows for using less overall resources on the RBB.

5

Conclusion and Future Work

The idea behind using a robotic black box is to, firstly, introduce a non-intrusive method of fault detection on robots, and secondly, to allow for remote debugging of a robot in case of occurrence of a fault. This work discusses this idea of distributed diagnosis, where the fault detection occurs on the robotic black box on an on-board component and fault isolation takes place on an external PC. Means of communication between both components is highly essential since transmission errors or delays could potentially lead to misdiagnosing the system. The applications of such a distributed architecture are theoretically unlimited and applicable to a

Acknowledgments We would like to extend our gratitude and a very special thanks to Dr. Gerald Steinbauer and his team at TUGraz, especially Stefan Loigge and Clemens Mühlbacher.

References [Alexander and Steinbauer, 2008] Kleiner Alexander and Gerald Steinbauer. Towards Automated Online Diagnosis of Robot Navigation Software. Lecture Notes in Computer Science, 5325:159 – 170, 2008. [Brandstotter et al., 2007] Mathias Brandstotter, Michael W. Hofbaur, Gerald Steinbauer, and Franz Wotawa. Model-based fault diagnosis and reconfiguration of robot drives. 2007 IEEE/RSJ International Conference on Intelligent Robots and Systems, pages 1203–1209, 2007. [De Kleer and Kurien, 2004] Johan De Kleer and James Kurien. Fundamentals of model-based diagnosis. Proc. 5th IFAC Symposium on Fault Detection, Supervision, and Safety of Technical Processes (Safeprocess)., pages 25–36, 2004. [Fourlas et al., 2015] George K Fourlas, George C Karras, and Kostas J Kyriakopoulos. Fault tolerant control for a 4-wheel skid steering mobile robot. Proceedings of the 26th International Workshop on Principles of Diagnosis, pages 177–184, 2015. [Fritsch et al., 2006] Carsten Fritsch, Jan Lunze, Matthias Schwaiger, and Volker Krebs. Remote Diagnosis of Discrete-Event Systems with On-Board and Off-Board Components. Fault Detection, Supervision and Safety of Technical Processes, 6(1):1467–1472, 2006. [Gomes et al., 2008] Carla P. Gomes, Henry Kautz, Ashish Sabharwal, and Bart Selman. Satisfiability Solvers. Handbook of Knowledge Representation, 3:89–134, 2008. [Hofbaur et al., 2007] Michael Hofbaur, Gerald Steinbauer, and Franz Wotowa. Model-Based Reasoning For

Fault-Tolerant Robot Hardware And Software. Proceedings of 16th Int. Workshop on Robotics in Alpe-AdriaDanube Region, 2007. [Hongsheng et al., 2000] Li Hongsheng, Shi Tielin, Yang Shuzi, Li Zhijian, Tao Yunfeng, and Chen Wenwu. Internet-based remote diagnosis: Concept, system architecture and prototype. Proceedings of the 3rd World Congress on Intelligent Control and Automation, 1:719– 723, 2000. [Hwang et al., 2010] Inseok Hwang, Sungwan Kim, Youdan Kim, and Chze Eng Seah. A survey of fault detection, isolation, and reconfiguration methods. IEEE Transactions on Control Systems Technology, 18(3):636–653, 2010. [Isermann, 2005] Rolf Isermann. Model-based faultdetection and diagnosis status and applications. Annual Reviews in Control, 29(1):71–85, 2005. [Koitz and Wotawa, 2015] Roxane Koitz and Franz Wotawa. From Theory to Practice : Model-Based Diagnosis in Industrial Applications. Annual Conference of the Prognostics and Health Management Society, 6, 2015. [Kustenmacher and Ploeger, 2012] Anastassia Kustenmacher and Paul G. Ploeger. Model-Based Diagnosis of Faults in Robotics. 23rd InternationalWorkshop on Principles of Diagnosis, pages 1–8, 2012. [Nan et al., 2008] Cen Nan, Faisal Khan, and M. Tariq Iqbal. Real-time fault diagnosis using knowledge-based expert system. Process Safety and Environmental Protection, 86:55–71, 2008. [Poole and Mackworth, 2010] David L. Poole and Alan K. Mackworth. Artificial Intelligence: foundations of computational agents. Cambridge University Press, 2010. [Quaritsch and Pill, 2014] Thomas Quaritsch and Ingo Pill. PyMBD: A Library of MBD Algorithms and a Lightweight Evaluation Platform. Proceedings of DX’14, 2014. [Ranganathan et al., 2001] N. Ranganathan, M. I. Patel, and R. Sathyamurthy. An intelligent system for failure detection and control in an autonomous underwater vehicle. IEEE Transactions on Systems, Man, and Cybernetics - Part A: Systems and Humans, 31(6):762–767, Nov 2001. [Reiter, 1987] Raymond Reiter. A theory of diagnosis from first principles. Artificial Intelligence, 32(1):57–95, 1987. [Schlage and Lunze, 2010a] Thorsten Schlage and Jan Lunze. Modelling of Networked Systems for Remote Diagnosis. Proceedings of the Conference on Control and Fault-Tolerant Systems, pages 795–800, 2010. [Schlage and Lunze, 2010b] Thorsten Schlage and Jan Lunze. Remote Diagnosis of Timed I/O-Automata. Proceedings of the 21st International Workshop on the Principles of Diagnosis, pages 1–8, 2010. [Sneider and Frank, 1996] H. Sneider and P. M. Frank. Observer-based supervision and fault detection in robots using nonlinear and fuzzy logic residual evaluation. IEEE Transactions on Control Systems Technology, 4(3):274–282, May 1996.

[Steinbauer, 2013] Gerald Steinbauer. A survey about faults of robots used in RoboCup. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 7500 LNAI:344–355, 2013. [Venkatasubramanian et al., 2003] Venkat Venkatasubramanian, Raghunathan Yin, Rengaswamy Kewen, and Surya N Kavuri. A review of process fault detection and diagnosis: Part I: Quantitative model-based methods. Computers & chemical engineering, 27(3):293–311, 2003. [Verma et al., 2004] Vandi Verma, Geoff Gordon, Reid Simmons, and Sebastian Thrun. Real-time fault diagnosis. IEEE Robotics and Automation Magazine, 11(June):56–66, 2004. [Wang et al., 2006] Wanbin Wang, Peter W. Tse, and Jay Lee. Remote machine maintenance system through Internet and mobile communication. The International Journal of Advanced Manufacturing Technology, 31(78):783–789, 2006. [Wang et al., 2011] Y. Wang, M. Chang, H. Chen, Y. Ren, and Q. Li. Research on fault diagnosis expert system fusing the neural network knowledge. In Intelligent HumanMachine Systems and Cybernetics (IHMSC), 2011 International Conference on, volume 1, pages 196–200, Aug 2011. [Wünnenberg, 1990] Jürgen Wünnenberg. Observer-based fault detection in dynamic systems. VDI Verlag, 1990. [Yong et al., 2006] J. Yong, W. Hongguang, F. Lijin, and Z. Mingyang. A combined logistic and model based approach for fault detection and identification in a climbing robot. In 2006 IEEE International Conference on Robotics and Biomimetics, pages 1512–1516, Dec 2006. [Zaman et al., 2013] Safdar Zaman, Gerald Steinbauer, Johannes Maurer, Peter Lepej, and Suzana Uran. An Integrated Model-Based Diagnosis and Repair Architecture for ROS-Based Robot Systems. IEEE International Conference on Robotics and Automation (ICRA), pages 482– 489, 2013.