mobile robot fault tolerant control. introducing artemic

Mobile Robot Fault Tolerant Control.Introducing ARTEMIC.

CRISTIAN AXENIEDunarea de Jos University

Department of Automation and Industrial InformaticsStiintei Street, Galati

[email protected],http://robotics.viviti.com

Abstract: Real-time applications should timely deliver synchronized data-sets, minimize latency in their responseand meet their performance specifications in the presence of disturbances and faults. The fault tolerant behaviorin mobile robots refers to the possibility to autonomously detect and identify faults as well as the capability tocontinue operating after a fault occurred. This paper introduces a real-time distributed control application withfault tolerance capabilities for differential wheeled mobile robots, named ARTEMIC. Specific design, developmentand implementation details will be provided in this paper.

Key–Words: Mobile Robotics, Fault Tolerant Control, Sliding Mode, EKF, Real Time Linux, Distributed ControlJanuary 13, 2010

1 Introduction

By accepting the challenge to ensure fault tolerantreal-time control of a self designed and built wheeleddifferential mobile robot the author has been able todevelop a hierarchical software application that min-imizes costs and supports extensibility. Analyticalsoftware redundancy is implemented rather than hard-ware redundancy for fault detection and identificationfor the minimal robot structure. The main applica-tion is designed on a distributed, client-server pattern,based on a TCP/IP wireless communication. The ap-plications base level is built over the interface withthe actuators (H-bridge MOSFET driver and 2 DCmotors) and sensors (encoders and bumpers) foundin the robots structure. The next level is the controland fault tolerance level, to the extent that the con-trol algorithm is implemented here and loops concur-rently with the monitoring and fault tolerance task toensure the robot’s autonomy and performance in tra-jectory tracking operation. The fault tolerant moduleis based on an set of Extended Kalman Filters used toestimate the current robot position and is using a resid-ual computation and a statistical analysis to determineif a fault occured in the system and to discriminatebetween the faults. The third level is a responsiblewith the communication task, to the extent that it im-plements a data server and a control server to ensurereliable data and command flows over a wireless net-work to the other nodes in the distributed system. The

client application was designed to meet some specificrequirements. The first type of client is responsible ofinteracting with the robot operation, basic start, stop,pause actions of the robot, but also with monitoringthe status of the robot by receiving specific packetswith sensor data. Due to the need of interactivity wheninjecting the faults a software fault injection frame-work was developed at this level. It’s purpose is to in-ject a certain fault at a certain moment in time choosedby the client user. ARTEMIC or Autonomous RealTime Embedded Mobile robot Intelligent Controllerwas developed as the diploma thesis project by the au-thor.

2 Server-side application description

Next an extended description of the server-side appli-cation running on the robot embedded computer isgiven. All architectural and functional aspects willbe presented, with focus on both software develop-ment elements and implemented control engineeringconcepts. The server-side application is a real-timeLinux C/C++ application. The real-time capabilitieswere obtained at the OS level by modifying the stan-dard Linux kernel with the RTAI (Real Time Appli-cation Interface) patch based on ADEOS (AdaptiveDomain Environment for Operating Systems)to theextent that the enhanced micro-kernel can ensure aproper preemptibility level and I/O latency minimiza-

RECENT ADVANCES in SIGNAL PROCESSING, ROBOTICS and AUTOMATION

ISSN: 1790-5117 213 ISBN: 978-960-474-157-1

tion. The hardware interface with the sensors andactuators is ensured by a data acquisition card (NI-PCI6024E) managed by a powerful kernel-space real-time driver and a rich API in user-space, both partof the COMEDI (Linux COntrol and MEasurementDevice Interface). To properly manage the executionof the two main tasks, namely the control task andthe monitoring task the application is organised onan abstract Grafcet (Graphe Fonctionnel de Controldes Etapes et Transitions) which supports the higherlevel parallelism in the execution of the two tasks.The control task is comprised of two inner speed con-trol PID loops (running at 50ms) for the 2 DC mo-tors and a main robot position control loop based ona sliding mode controller(running at 200ms). Con-currently, the monitoring and diagnosis task receivessensor data which is then processed by a set of 5 Ex-tended Kalman Filters every 50 ms. By examining thereal and predicted data the application can decide ifa fault occured and what kind of fault based only onsensor information using a simple thresholding mech-anism and a statistical test on the residuals. Next anarchitectural overview of the whole application is de-picted in figure 1.

Figure 1: Main application architecture.

2.1 Base level description

The base level is the main support for the control andmonitoring tasks to the extent that the sensors and ac-tuators are interfacing with the software by the real-time data I/O features given by the Linux+RTAI and

COMEDI tools. Next the presentation shall focus onthe base level of the server-side application runningon the embedded robot computer. The specific I/Ofunctions are presented in the application context. Theserver-side application is described in figure2.

Figure 2: Server-side application architecture.

To properly understand how the robot control ap-plication works, a typical operation context is de-scribed, emphasizing class communication during ex-ecution. Each sampling period the application readsthe data through the DAQ card from the encoders andcomputes, according to the read values, a control sig-nal for the 2 DC motors. The specific functions to ob-tain a value from a sensor or to set a value to an actua-tor are comprised in the Counter, Sensor and Actuatorclasses. The outer sliding mode loop computes thecontrol signal for the robot to achieve the next pointin the trajectory in a timely manner and then the com-puted control signal is transformed in speed set-pointsfor the inner PID loops. The monitoring and diagno-sis task that runs concurrently is fed with sensor data,in fact the odometry computations and each samplingperiod the 5 EKF are testing if a fault occured and ifoccured, what kind of fault is it. The fault tolerantcontrol module is then issuing specific warning mes-sages to the client application regarding the currentstatus of the robot operation. Next an in depth de-scription of the two tasks running on the embeddedrobot controller is given.

2.2 Control algorithm level description

As mentioned earlier the robot is operating in trajec-tory tracking mode so its main objective is to followa certain trajectory under time constraints. The con-trol algorithm goal is to minimize the position errors,namely the longitudinal error, the lateral error and theheading error. To ensure proper error convergence in


ISSN: 1790-5117 214 ISBN: 978-960-474-157-1

the presence of disturbances and modelling uncertain-ties a sliding mode controller was choosed. A slidingmode controller based on the kinematic model of therobot was used. By using a sliding mode controllera trade-off between tracking performance and para-metric uncertainty was made, to the extent that it pro-vides a good solution in maintaining the stability andconsistent performance in the face of modelling im-precision and disturbances. Next the complete robotcontrol system is presented in figure3.

Figure 3: Control system architecture.

The robot should track the reference parametrizedcurve with time constraints and so real-time controlsignal computation is critical. The main idea behindthe trajectory tracking operation mode considers a vir-tual robot that tracks the reference trajectory with noerror and ”pulls” the real robot after it to the ex-tent that the controller reacts to minimize the errors.Let the robot be defined by the next position vec-tor (state vector) [xr, yr, θr]T and we define the errorvector as [xe, ye, θe]T = [xd, yd, θd]T − [xr, yr, θr]T ,where [xd, yd, θd]T is the virtual robot state vector, theset-point vector to track. Next the robot’s kinematicmodel and tracking error computation is considered.

The main objective was to design a stable and ro-bust controller for robot position control that shouldoutput a control signal vector [vc, ωc] (linear and an-gular speeds) in the presence of disturbances. The er-ror derivative is given by

xe = −vd + vrcos(θe) + yeωdye = vrsin(θe)− xeωdθe = ωr − ωd

where the set-point values for the speed controlloops are vd and ωd. The set-point for the main robotposition control loop is generated by a trajectory plan-ner based on 5th degree equations for smoothing therobot’s operation and control effort. The trajectoryplanner outputs linear and angular speed and acceler-ation set-points at each sampling period. These val-ues are transformed using inverse kinematics equa-tions in vectorial form [xd, yd, θd]T . The next stepwas to design the switching surfaces for the slidingmode controller such that it can ensure proper errorconvergence. The first switching surface was choosedto ensure lateral error convergence and is given by thenext equation s1 = xe + k1xe. To ensure proper lon-gitudinal and heading error convergence the secondswitching surface combines the two objectives and isgiven by s2 = ye + k2ye + k0sgn(ye)θe, where thek1, k2, k3 parameters are specific weights associatedto each error component. Practically the control sig-nal could be computed using s = −Qs − Psgn(s)where Q,P are positive constant values that are deter-mining the error convergence speed. By deriving thesurfaces equations and replacing the error componentsone can easily obtain the control signal vector underthe form of

vc = −Q1s1−P1sgn(s1)−k1 (xe)−ωdye−ωdye+vr θesin(θe)+vd

cos(θe)

ωc = −Q2s2−P2sgn(s2)−k2 (ye)−vrsin(θe)+ ˙ωdxe+ωdxe

vrcos(θe)+k0sgn(ye)+

ωd

To ensure a good convergence speed of the robotstate vector to the switching surface (which in factgives the desired system dynamics) and also to el-liminate chattering (caused by fast control signalswitches) the P and Q terms should be cautiouslychoosed. To ensure the stability of the system we de-fined a Lyapunov candidate function given by V =12sT s and with V = s1s2+s2s1 = −sTQs−P1|s1|−

P2|s2| the main condition is that V V < 0 achieved ifQi >= 0 and Pi >= 0. As mentioned earlier the slid-ing mode controller outputs angular speed set-pointsfor the inner PID loops. The PID controllers for thetwo DC motors were implemented using first-order-hold discretization method. The PID loops are run-ning at 20Hz and the specific parameters were tunedto meet a fast response time (0.5s) and a small over-shoot (10%). Next some results from the closed loopfault-free operation of the robot are given to analyzethe robot behaviour on a specific trajectory.


ISSN: 1790-5117 215 ISBN: 978-960-474-157-1

Figure 4: Robot operation in trajectory tracking withsliding mode controller in fault free operation.

The real robot trajectory is represented by a con-tinuous line and the reference trajectory is given withcrosses. The movement direction is indicated by ar-rows. As one can see the position error is kept inacceptable limits by the robust sliding mode con-troller and the robot can achieve it’s objective in time.Once more one can observe that good performance isachieved in using the sliding mode controller. Anotherimportant aspect regards the analysis of the error com-ponents in the fault free operation, because it can beconsidered as a proper validation for the controller.Next the three error components are depicted.

Figure 5: Robot longitudinal error (xe).

Figure 6: Robot lateral error ye.

Figure 7: Robot heading error θe.

One can see that the error convergence is prop-erly ensured by the controller. The longitudinal errorin the fault free operation is under 3cm, the lateral er-ror is under 6cm and the heading error in under 8 rads.Experiments have shown that even for simpler trajec-tories (simple 2m line, 0.75m radius circle) the con-troller behaves well and depite the fact that the robotstructure had some hardware limitations (small en-coder resolution, 500PPR) the real-time control goalswere met even for slightly high sampling periods;allthe results are validated with the earlier error analy-sis. Following the next level of the application is pre-sented, namely the fault detection and identificationmodule and the support for fault tolerant control.

2.3 Monitoring and diagnosis level descrip-tion

Due to hardware limitations in injecting faults the ap-plication is also responsible to inject faults by soft-ware using a fault injection framework. By benefitingof a certain degree of robustness given by the slid-ing mode controller the application resides on a sim-ple mechanism for fault detection, identification andsupport for control reconfiguration based on the Ex-tended Kalman Filter (EKF). So, the application im-plements a set of 5 EKF that form the fault detec-tion and identification module. The current applica-tion considers a fault benchmark comprised of faultsmanifested by system’s parameter variation specifi-cally mechanical faults that alter the robot behaviour.Hence two fault classes were defined each containingtwo types of faults. The first class of faults introducesthe flat tyre fault for each of the robot wheels. At theimplementation level this fault exhibits by diminish-ing the wheel radius with a certain value. As a con-


ISSN: 1790-5117 216 ISBN: 978-960-474-157-1

sequence the whole kinematic model of the robot ismodified and visible modifications in the robot’s be-haviour will be present. The second class of faultsintroduces a periodic variation of the wheel radius (abump, caused hypotetically by an object attached tothe wheel). Hence, for a small time period the varia-tion will manifest itself and alter the robot operation.As mentioned earlier a fault injection framework wasimplemented and its main purpose is to alter the val-ues from the sensors in odometry specific computa-tions. Hence, when no fault is injected the robot willbehave normally (as presented when the control levelwas described) but when a fault was injected the robotposition determining system (in fact the control sys-tem feedback, odometry) will feed altered data to thecontroller as if a physical fault occured. Next a depic-tion of the fault detection and identification module isgiven.

Figure 8: Fault detection and identification module.

Each of the five EKF encapsules a kinematicmodel of the robot but with different parameters. Themain idea resides on the fact that for the same inputvector, z, with noise, each filter generates a predic-tion of the robot’s state vector. Each filter is asso-ciated with a certain fault type. EKF0 is the nomi-nal filter corresponding to the fault free robot opera-tion. EKF1 filter contains the same robot kinematicmodel but with modified parameters to emphasize theright tyre flat fault, so the right wheel radius has asmaller value. Hence, the prediction of EKF1 willbe the robot state vector if a right tyre flat occured.The EKF2 filter is similar to EKF1 excepting it en-capsules the left tyre flat fault specific model. In thesame way the other two filters associated with the sec-ond fault class, EKF3 and EKF4, are predicting the

robot’s state vector in the presence of a second faultclass fault. Besides the state estimate each EKF gen-erates a measurement vector estimate during the pre-diction stage, which is used in the correction stage ofthe filter. Basically the detection method is based on anominal residual computation and a simple threshold-ing test on the nominal residual which can output thata fault occured. It is the only one affected by the faultoccurence so it will step out from some preset valueintervals. When identifying the fault the applilcationjust finds the smallest residual from the 5 ones, be-cause when a fault occurs the main measurement vec-tor is altered and it nears the predicted measurementvector by the EKF encapsuling that fault behaviour.Next, specific implementation details of the EKFs arepresented. Starting from the generic structure duringthe implementation some simplifying hypothesis wereissued and we know that Q is the process noise covari-ance matrix, R is the measurement covariance matrix,σx = σy = σθ = 0.1 are the standard deviations forthe process noise, σmeas = 0.01 is the standard de-viation of the measurement noise. To correctly detectif a fault occured some statistical tests on the residualare required. The statistical parameters of the residual(mean and variance) will be compared on-line at eachsampling period with the values obtained for these pa-rameters in fault-free operation. In fault-free opera-tion the residual is a a white noise sequence with 0mean and ηk = Hk(x−k )P−k H

Tk (x−k ) + R variance.

Basically if a fault occurs in the system it will determ-nine a modification of the next residual based standardsequence,

ηsk = (ηk = Hk(x−k )P−k HTk (x−k )+R)−1/2(yk−

hk(x−k )) = η−1/2k rk

The goal is to determine the estimate of the realvalue of a sample given by

ˆηs = 1NΣηsj , where N is the number of samples.

So, in the hypothsesis H0 of no fault ˆηs has agaussian distribution with 0 mean and 1/N covariance.Over a certain acceptance threshold the H0 hypothe-sis is no longer true and so a new hypothesis H1 isnow true marking a fault occurence. Next some ex-perimental results are presented. First it is useful toanalyze the residuals generated by the nominal filterwhen a fault occurs, in fact these residuals are thosepredicted by the fault embedding filters, from the mo-ment the fault occurs. For example if a right tyre flatfault occurs at sample 100 in the execution the residualevolution from 100th sample is the predicted residualby the EKF1.


ISSN: 1790-5117 217 ISBN: 978-960-474-157-1

Figure 9: Residual analysis for first fault class.

From this residual analysis one can see that eachEKF is sensitive to a certain fault type and usingthese properties the detection and identification mod-ules were built. Assuming that a right tyre flat faultwas injected at moment t=10s and the new radius ofthe wheel is 3cm smaller than the initial value the be-haviour of the robot is altered as one can see in thenext figure.

Figure 10: Robot faulty operation vs. reference tra-jectory.

Next an extended position error analysis over the faultfree and faulty operation is given (red marks fault freeoperation and blue the faulty operation).

Figure 11: Longitudinal error comparison fault-free/faulty operation.

Figure 12: Lateral error comparison fault-free/faultyoperation.

Figure 13: Heading error comparison fault-free/faultyoperation.

As one can see there are major variations from thenominal behaviour after a fault occured in the system.It is important to mention that the thresholding mech-anism reacts if at least two components of the resid-ual vector are bigger than the preset values. So, thefault could be visible in all the residual componentsor not.As a typical operation context when a fault isdetected, it is then identified and the client applicationis informed what kind of fault occured. At the mo-ment only one fault can be detected and identified, nofault queue or priority system are implemented. Fol-lowing a brief description of the client application isgiven.

3 The client-side application descrip-tion

The two main components of the application arelinked through a wireless communication ensuring theclient application to be responsible with the external


ISSN: 1790-5117 218 ISBN: 978-960-474-157-1

events that determine the robot operation. It imple-ments a similar structure with the embedded applica-tion and supports the fault injection framework. Nexta synthetic image of the Java GUI client applicationarchitecture is given.

Figure 14: Client-side Java application architecture.

Besides the interactive task of injecting faults theclient application is responsible to choose the Grafcetstructure that encapsules the execution rules for thecontrol algorithm and and the specific supported ac-tions (start/pause/stop) for the robot operation, alsoit offers the possibility to choose between multipletrajectories and to visualize the robot’s current posi-tion. Using a full load of the embedded system latencymeasurements were taken. So, by using a 50ms sam-pling period for the inner control loop and the moni-toring and diagnosis tasks and a 200ms sampling pe-riod for the robot position controller good average mslevel latencies were obtained. Following a short suma-rizing overview over the paper is given emphasizingthe main advantages and some future work ideas.

4 Conclusions and future work

ARTEMIC was designed as a flexible application ded-icated to mobile robotics fault tolerant control. Itsarchitecture is open and supports extensibility at a”plug-an-play” level because at the lowest level itsupports and offers a simple mechanism to add newhardware to the robot and provides a generic andcompatible interface with the hardware. As futurework a port of the developed application from thecurrent Intel Celeron based embedded computer to aMPC8315ERDB PowerPC platform is started. Thenew platform uses an enhanced RTOS named Xeno-mai that is a super-set of RTAI and it provides bet-

ter performance and it is dedicated to embedded arch-tures. itec Another directon in the future work regardsthe possibility to combine multiple fault detection andidentification methods to gain the advantages of eachcomposing method and obtain a hibrid and efficientmechanism.This approach shall be combined with anfuzzy adaptive sliding mode controller to the extentthat it can self-adjust it’s parameters based on optimalcriteria to ensure faster error convergence. Next figureintroduces the ARTEMIC power robot.

Figure 15: The ARTEMIC powered mobile robot.

References:

[1] Patton R., Frank P., Clark R. Fault Diagnosis inDynamic Systems:Theory and Applications PrenticeHall, New York, 1989.

[2] Bruno Siciliano, Lorenzo Sciavicco, Luigi Villani,Giuseppe Oriolo Robotics, Modelling, Planning andControl Springer, 2009

[3] Razvan Solea, Urbano Nunes Trajectory Planningand Sliding Mode Control for WMR Trajectory Track-ing and Path Following Rescpecting Human ComfortTravel CONTROLO Conference Portugal, 2006.

[4] Mayback P.S.,Cox I.J.,Wilfong G.T.(eds) The KalmanFilter:An Introduction to Concepts in AutonomousRobot Vehicles Springer-Verlag, 1990

[5] Burns A., Wellings A. Real-Time Systems and Pro-gramming Languages AddWesley, California, 1996.

[6] Utkin V.I. Sliding Modes in Optimization and ControlProblems Springer-Verlag, New York, 1992.


ISSN: 1790-5117 219 ISBN: 978-960-474-157-1

mobile robot fault tolerant control. introducing artemic

Documents