Only released in EOL distros:
- Author: Safdar Zaman, Gerald Steinbauer
- License: GPLv3
- Source: git git://robotics.ist.tugraz.at/tug_ist_model_based_diagnosis.git (branch: None)
Every Robot system that claims to be fully autonomous, has to have the capability of monitoring its own system, detecting the faults if any, and repairing them automatically. Model-based diagnosis system implements fault diagnosis and repair system for both hardware and software components for ROS-based robot systems. It comprises five major modules: (1) a set of observers, (2) a model server , (3) a diagnosis engine, (4) a repair engine and (5) a hardware diagnosis board. Following figure describes the connections between all modules:
Observers collect observations from hardware and software components. Model Server provides system model describing the correct behavior of the robot system. Both observations and model are used by the diagnosis engine that calculates the root cause of the failure if any. Diagnosis engine provides diagnosis that describes working and not working components of the system. Diagnosis repair engine uses diagnosis along with observations to extract action plan from the action planner. Diagnosis repair engine then uses action plan to invoke action servers to start/stop a particular software node or power-up/shutdown a particular hardware device with the help of hardware diagnosis board.
Observers are general software entities implemented as ROS nodes that monitor particular aspects of the system. There are different kinds of observers supervising different aspects or properties. The result of the observation is published on the /observations topic as a first order logic (FOL) sentence. The sentence is a representation of the observed property and its status. Observations are published as a set of strings. Each string represents a single FOL sentence like ok(topic_name), running(node_name),.etc. There are different kinds of observers: Diagnostic Observer (DObs) , General Observer (GObs), Node Observer (NObs), Multiple Observer (MObs), Qualitative Observers (QObs), Binary Qualitative Observers (BiQObs), Hardware Observer (HObs), Property Observer (PObs).
Diagnosis Model Server
The diagnosis model server is an action server which provides the diagnosis model. The diagnosis model is stored as a YAML file (similar to XML) and contains five sections: (1) a string that denotes the proposition that represents the AB predicate, (2) the same for Not AB, (3) a string for a prefix denoting a negative literal, (4) a set of all propositions, (5) a set of clauses that defines the diagnosis model. This model described the correct behavior of the robot system. For more detail please refer to diagnosis model.
The diagnosis engine takes observations in the form of First Order Logic (FOL) sentences and an abstract diagnosis model (system description) to generate a diagnosis, a set of components that are faulty and a set of components that are still working properly. The diagnosis engine follows the principles of model-based diagnosis. The approach uses an abstract model that defines correct behavior and some current observations of the system. A fault is detected if the outcome of the model and the observation lead to a contradiction. Using a hitting set algorithm the approach calculates diagnoses that resolve the contradiction. The engine locates that component or set of components that is the root cause for the contradiction.
Diagnosis Repair Engine
Diagnosis repair engine is a planner based repair engine. It uses widely recognized Planning Domain Definition Language (PDDL). In order to describe and enable repair actions, we model the repair as a planning domain. The repair engine takes current observations and diagnoses as input. If the repair engine receives a diagnosis message, it converts the diagnosis into to a planning problem and solves it. Please note that in the current implementation in the case of multiple diagnosis always a repair plan for the first diagnosis is obtained.
Diagnosis board is a hardware that is responsible to take care of sensors connected through its channels. The central part of the hardware diagnosis board is a micro-controller embedding a TCP/IP stack. It is responsible for the current easurements, the power monitoring and the power configuration of the individual channels. The board is connected with the outside over Ethernet and embeds a server with a proprietary protocol. The protocol allows the client to pull information like measurements and states of channels or to initiate broadcasts on a regular basis. Moreover, it provides commands to change the power configuration of individual channels. Finally, the board can be configured in a way that at power up a defined set of channels is automatically on. The diagnosis board package provides controller node to control the diagnosis hardware board.
Diagnosis messages are all necessary message types used by diagnosis system. It includes message types for observations, diagnosis, repair and model server. Diagnosis messages are discussed in diagnosis_msgs
Diagnosis Launch Files
Diagnosis launch provides files to launch different modules of the diagnosis system. For example observers.launch launches observers defined, similarly there are other launch files like diagnosis_model.launch, diagnosis_engine.launch, diagnosis_repair.launch,.etc.
Report a Bug