Simulation of Fault Detection for Robot ApplicationsChase Baker, Taeghyun Kang, Michael Shin Ph.D.

Interaction with robot applications are becoming increasingly common in our daily lives. With this increase in human-robot interaction, the robot applications should be reliable for human and robot safety. Robotics has made huge strides over the last decade, but the need for fault detection and handling has never been greater in component-based robot applications. Reliable robot components should be able to detect faults in robot applications in a prompt manner in order to avoid potentially dangerous problems. Additionally, the robot application may need to provide a method of determining the best action for future operation based on the detected fault. This research is to develop a simulator for detecting faults in the unmanned ground vehicle (UGV) application that is composed of multiple robot components. The constituting components for the UGV contain fault detection functions such as sensor data range check or data period failure check. The simulator checks if each component can detect faults encountered while a UGV drives on a road.

To effectively observe our vehicle’s components at work, we implemented our vehicle in a simulation environment. We used Microsoft Robotics Developer Studio in conjunction with Google Sketchup and Artificial Robotics to create both a virtual environment for our vehicle as well as the vehicle itself. Our goal for the simulation was to create a small vehicle that would be able to detect curbs around itself and continue in a straight path when possible, while making appropriate turns when a straight path is not available.

For our vehicle, we implemented a small unmanned robot that consisted of several sensor and actuator components including laser range finder sensor that would perform 180 degree sweeps at an interval of our choosing. The laser range finder would allow the vehicle to detect nearby obstacles in front of itself, making it an optimal sensor to use for detecting curbs, for instance. Artificial Robotics provides a means to insert these robotics components into a Google Sketchup model, while also allowing a user to edit their properties for when they are implemented with a simulation in Microsoft Robotics Developer Studio.

For our environment, we created a small grid-based roadway that had curbs surrounding the roads. This would allow the vehicle to detect the curbs and use them to determine if it can continue on a forward path. At the corners of the grid, the vehicle will then have to determine an appropriate time and power setting to begin turning to avoid hitting the curbs.

By implementing our fault detection system in a simulated vehicle, we observe our approach in a controlled environment. We have proven that our components can be created in a simulated environment and that our fault detection can be applied as our approach suggests. Our goal is to now extend this project by implementing a fault blackboard and repository to store fault information found throughout the system. We also plan on adding a larger variety of components such as pedestrian detection, car detection, GPS localization, and more to validate our approach. We can further extend the project by featuring self-recovery mechanisms that further increase the efficiency and safety of robotics applications.

[1] Michael E. Shin, Self-healing components in robust software architecture for concurrent and distributed systems, Science of Computer Programming, Volume 57, Issue 1, July 2005, pp 27-44

[2] Rolf Isermann, Model-based fault-detection and diagnosis, Annual Reviews in Control, Volume 29, Issue 1, 2005, pp 71-85

I would like to extend my thanks to Texas Tech University, the National Science Foundation, Dr. Susan Urban, Dr. Michael Shin, Dr. Mohan Sridharan, Taeghyun Kang, along with all other individuals and organizations both directly and indirectly involved with bringing this program together. This experience has been more than I could ever ask for, and I have been honored to be a part of it as well as being surrounded by these great individuals and my fellow student researchers alike.

* This material is based upon work supported by the National Science Foundation under Grant No. CNS-1005212. Any opinions, findings, and conclusions or recommendations

expressed in this material are those of the author(s) and do not necessarily reflect the reflect the views of the National Science

Foundation.

Once the initial simulation environment was built, we could then focus on the components themselves. For the standard vehicle simulation, we required the use of multiple components: A laser range finder, wheels, and chassis for the virtual vehicle, a curb detection component whose responsibility is to detect curbs and obstacles around the vehicle, a differential drive component to handle driving commands sent to the wheels of the vehicle, and a controller component to consolidate data from the other components and make actions based on the incoming information.

The curb detection component was built from scratch to serve our purposes. We created a new Distributed Software Service (DSS) with references to our laser range finder component to read incoming data from the LRF and then make observations based on that data, such as if we had curbs on both sides or a clear path ahead of the vehicle. The curb detection component is set to read data from the LRF sensor every two milliseconds and then store state information regarding any nearby findings. Similarly, the differential drive component allows us to communicate directly with the vehicle’s wheels for controlling speed and direction.

Each component in the UGV application is monitored to check if it encounters any faults or failures. The typical fault or failure types are defined in Fault Detection Library (Fig. 1), which includes out of data range failure, periodic data failure, and real-time processing time failure. These detection functions are called by each component to detect faults or failures. This research implements the components of the UGV application with detection functions. In particular, periodic data failure function is implemented to check if each component processes data periodically. For example, the Curb Detection component (Fig. 1) should receive and process data from the LRF component periodically. If the Curb Detection component does not receive the periodic data regularly from the LRF component, the Curb Detection component can detect the failure using the periodic data failure function defined in the Fault Detection Library. This failure detection is helpful to avoid that the UGV drives out of road.

FAULT DETECTION

MOTIVATION AND BACKGROUND

CREATING THE SIMULATOR

CONCLUSIONS

ACKNOWLEDGMENTS

RELATED WORK

For our approach, we use an unmanned ground vehicle application to develop and test our fault detecting and handling components. Our approach involves several stages:

RESEARCH APPROACH

Texas Tech University 2012 NSF Research Experience for Undergraduates Site Project

Figure 2: Screenshot of a Simulation featuring a Robot using a Laser Range Finder for Curb Detection

Figure 1: The Fault Detection Process

LRF Curb Detection

Fault Detection Library

Controller

Differential DriveWheels