A New Approach to Clock Jitter Simulation in Digital ...

2017 11th Asian Control Conference (ASCC) Gold Coast Convention Centre, Australia December 17-20, 2017

A new approach to clock jitter simulation in digital control system Long Quang Tran∗ , PJ Radcliffe† and Liuping Wang‡ School of Engineering, RMIT University Email: ∗ [email protected], † [email protected], ‡ [email protected] Abstract—Using current methods it is difficult to predict the effects of clock jitter on a real time control system. To be safe the designer will often choose an expensive high performance system where in fact a lower performance system with more jitter would be adequate. This paper proposes a new and novel technique to add realistic clock jitter to a MATLAB/Simulink based simulation of any real-time control system. This method is used to simulate a simple control system for speed control of a small DC motor and this is compared to the performance of a real system. Results show a close agreement between theory and the real system. It is further shown that considerable sampling jitter results in relatively small changes in performance for this system which suggests that a cheap controller with high jitter is quite adequate for the task. The pattern of jitter has been found to be important in affecting the response of the system. Most randomly chosen jitters have a small effect but particular patterns can have a much larger effect.

I. I NTRODUCTION Digital control systems are critical to many products including cost sensitive products. For instance, a modern motor vehicle is equipped with a cruise controller which can maintain a constant speed by collecting data from sensors and use algorithms to set the speed to some desired or legal value. Early in the design process it can be very difficult to select suitable hardware platform and an RTOS (Real Time Operating System), particularly when the product is cost sensitive. Of the many questions to answer this paper focuses on one, how much clock jitter can the controller exhibit before its functionality starts to degrade? This is a very important question as it significantly affects the cost of the controller. A common response is to choose a known good combination of hardware and RTOS but this is most likely more expensive than necessary and the less expensive alternatives are not considered. Given that time to market is critical and that failure is unacceptable this makes sense as a strategy. The analysis of simpler and less expensive control hardware can be made quicker and less costly by the use of simulation. Typically a z-domain controller is designed and the entire system simulated with parameter variations to see how the performance is affected. In most z-domain analysis the sampling clock is regular and without jitter. While parameters such as sampling speed can be altered, simulated, and evaluated the jitter cannot thus limiting the usefulness of simulation. This paper proposes a technique to add such jitter into the simulation of a control system using MATLAB and Simulink. The key innovation is a novel way to create a variable delay z −1 element which is essential to properly modeling a digital controller with clock jitter. Through this technique, the relation between jitter and system performance can be easily obtained. The method has been used on the control of a small DC motor and excellent agreement between the simulator and the 978-1-5090-1573-3/17/$31.00 ©2017 IEEE

real hardware has been found. It is now possible to quickly evaluate low cost and lower performance combinations of hardware and RTOS by simulation. This enables development to proceed using lower cost components without the usual risk of uncertainty as to the performance of the real system. This paper is organized as follows: section II on existing work discusses previous methods used to simulate the jitter in the sampling clock. Section III describes a new method which allows simulation of realistic clock jitter and the advantaged of the new method; then the detail of the new adding jitter technique is presented into the new work part. Section IV and V present a model of motor speed controller which is examined with new proposed technique using Simulink and MATLAB; an experiment with real motor is also compared to the simulation. Section VI discusses the result of experiment and simulation from previous parts. Section VII includes future work need to be developed and section VIII concludes the paper. II. E XISTING W ORK Several authors have developed useful classifications for jitter in control systems. Sampling clock jitter in digital control systems is introduced by inconsistent sampling intervals which in turn are caused by interference between processes [1], [2]. In other words, the presence of jitter cause the clock edge to come earlier or later than expected [3] Marti and et al.[2] classified 6 types of control system jitter based on sampling time, controller execution and actuation time. These six jitter cases can be summarized into three main cases. In the first case jitter is caused by non-constant sampling intervals, the second case describes delays between the sampling time and actuation time in the system. The third case combines non-constant sampling intervals and their delay to actuation time. Although this classification are useful to overcome jitter compensation method, the authors ignored random jitters such as an average with PDF[3] which can also cause non-constant sampling intervals. A number of authors have developed methods to simulate clock jitter in simulation systems. A simulator must be able to create a variable delay z −1 element as well as a nonvariable delay element, to model the change in clock periods on a sample to sample basis. This feature is not available in simulators such as Simulink where the unit delay z −1 has a fixed period [4]. Goddard [5] built a test model in MATLAB to make a clock edge oscillate around a nominal period, both in advance and delay of a stable clock. This test model function can alter the square clock generator module in Simulink with added jitter feature. This work only generates a clock with jitter

2563

and is not useful for creating a variable z −1 delay element which is required to model a control system with clock jitter. MathWorks [6] introduced a modeling method to account for computation delays. The model uses a zero-order hold function with a constant delay which matches case 5 of Martis jitter classification [2]. This is not an adequate model for a real system where there is clock jitter as well as computation delays. Smeds and Lu [7] built an approximately model for a non-ideal sampler and ZOH in motion control systems. In this proposed system, the jitter j(t) is considered as a disturbance input that affects the output of digital controller. This method does not apply jitter to the input to the digital controller which would occur in a real system. The jitter compensation method in [8],[2] and [9] is technically a re-calculation of control parameters depended on the current sampling period. In these references sampling jitter is introduced through variant sampling time. For instance, Niculae and et al. [8] implemented a digital PID control system in which the sampling time was changed every cycle based on a Gaussian random generation. Although sampling jitter is modified to cause 0 to 90% delay of sampling time, the result of step response is not different between re-calculating parameters system and default system with no jitter. Marti and et at.[10] demonstrates a simulation of PID inverted pendulum controller and the various sampling times are introduced by a virtual real-time kernel in MATLAB/Simulink. Yang and et al. [9] applies a delta operator system technique to compensate the sampling jitter in modeled networked control systems. The references proved that the clock sampling jitters can be added into the simulation however, the complexity mathematical calculation for a specific control application makes those methods impractical for general use. Cervin and et al.[1] introduced a MATLAB-based toolbox JITTERBUG that can test the sensitivity of a control system to delay and jitter. The authors also developed a simulation tool TRUETIME to capture and analyze information of delay and jitter. The source of delay and jitter values come from manually setting delay parameters for the network, ADC, scheduler and interrupt. It is notable that this paper, and papers which use JITTERBUG and TRUETIME, do not relate to any real hardware and so are of little use for practical design. There is no apparent link between the settable parameters and the performance of available real time controllers. The toolbox has very little flexibility in the setting of jitter, for example it cannot allow an arbitrary delay profile such as flat or Guassian nor can it replay a jitter pattern measured from a real device. JITTERBUG and TRUETIME are described as being useful for research on dynamic real-time controller systems[1]. A number of authors have used JITTERBUG and TRUETIME toolbox to investigate the effects of jitter. While such works are interesting they all suffer from the same limitations as the toolbox. Two such references are discussed here. Marti and et al. [10]’s application showed the performance of system is degraded dramatically in comparison to no clock jitter being present. In this experiment, the controller task is one of three scheduled tasks in systems using an RM or EDF scheduler. The result shows high overshoot in either RM or EDF scheduler when using unstable sampling intervals. The authors provided solutions using the offline re-computation parameter method to reduce significantly sampling jitter and computation delay.

Digital domain

Target

Digital Controller

S/H

DAC

Motor model

Motor speed

Speed sensor

Fig. 1. A simple motor controller model

Perera and et al.[11] demonstrated the degradation of system performance caused by input, output and sampling jitter. Those systems required a jitter compensation methods which were also proposed in these papers. However, the jitter in [10] and [11] are introduced by using the TrueTime platform [1] that has limitations discussed previously. Many authors have developed methods to simulate clock jitter in control systems but all those reviewed related poorly to real physical systems and it is notable that none of the authors tried to match their simulations to real hardware. There was no ability to simulate the clock jitter for a real digital control with an average delay and an arbitrary PDF. The ideal tool would have the ability to replay jitter observed on a real system. The key to modeling clock jitter is the ability to create a variable z −1 delay element which can be varied on a clock edge by clock edge basis. The literature does not offer any flexible method for generating such a delay. The TrueTime simulator comes closest to this goal but it lacks the ability for the user to define delay patterns. III. N EW APPROACH TO SIMULATING CLOCK JITTER All common simulators use a sampling clock with no jitter which makes simulator of real clock jitter impossible. This section proposes a technique to replace that ideal clock by a clock with added arbitrary jitter. Fig. 1 shows a simple DC motor controller that will be used to illustrate the novel method. The digital controller and sampling and hold (S/H) are where the clock jitter occurs and this will cause a change in system performance. The design process for making a digital controller is typically a conversion from an analog control function with a sample time version. This conversion results in a z-transfer function. For example, consider a digital controller with the C(z) function below: 0.02(z − 0.78) (1) z−1 This function can be converted to a state space model with an initial input u(k), the first output y(k) is related to the initial state [x(k), x2] and initial input by: x(k + 1) = x(k) + 0.0625u(k)

(2)

y(k) = 0.0704x(k) + 0.02u(k)

(3)

From Eq.1, a model of digital controller in Simulink can be created as shown Fig. 2. An alternative digital controller using state-space form is built based on Eq.2 and Eq.3 in Fig. 3. The final state space model relies on one or more z −1 delays for its functionality. In a real system with jitter for a given sample every z −1 block will have the same change in value due to this jitter. For example in a control system with a 10ms

2564

Analog dom ain +_

in

0.02(z-0.78)

Input

z-1

Digital Contoller C(z)

Output

out

plant P(s)

Sampler

Fig. 2. An example using of digital controller C(z) 0.02

y(k)

D C(z) input

u(k)

x(k+1)

0.0625

B

x(k)

-1 Z

C(z) output

0.0704

C

Delay

The hardware to be simulated is show in Fig.5. The controller is an Arduino like board called OUSB [13] which uses the more powerful ATMEGA32. The motor is a small DC motor kit that can be bought very cheaply on-line. The OUSB board has all the hardware to time the motor pulses and so measure speed, provide a digital controller function, and drive the motor with a PWM. The digital controller function is where jitter may be deliberately added to observe the effects of this jitter on system performance. Later sections will simulate this system so that real and simulated results may be compared and the effectiveness of the new simulation method can be determined.

A

DC MOTOR. Image source: http://www.futurlec.com/ Pictures/ET-MINI_DC_MOTOR.jpg

1

CONTROLLER OUTPUT ENABLE PIN

PROGRAMMING

Fig. 3. Digital contoller C(z) in State-space form OPTO INTERRUPTER

PWM OUTPUT

PC

period, if just one sample has a sudden extra delay of 1ms (10% jitter) then all z −1 blocks are affected, the length of the previous cycle was 11ms not 10ms, and the length of the next cycle will be 9ms not 10ms. Our technique effectively simulates the digital domain using analogue simulation and uses an analogue sample and hold plus a variable analog delay to mimic a variable z −1 delay. The sampling clock can now be set to any arbitrary waveform including any distribution available in the simulator or even data from an external file. Fig. 4 shows how this is achieved in Simulink. The variable time delay element can be changed dynamically as the simulation runs. The tiny delay Constant4 is required to stop an input rippling through a string of S&H blocks on a clock edge rather than stepping along at one S&H per clock cycle. Given this novel building block now it is possible to simulate any digital control system and apply clock jitter to investigate the consequential effects. IV. DC M OTOR S PEED C ONTROLLER H ARDWARE This section will use a classic digital controller design for a small DC motor to illustrate the new method of simulating clock jitter. There is an excellent tutorial provided by the University of Michigan, Carnegie-Mellon, and University of Detroit Mercy [12] which shows how to create a digital controller for a small DC motor. This method is applied to the motor we selected to produce a digital controller. Next the new approach is applied to add jitter to the sampling clock. The results from simulation are compared to a real system to gauge the effect of jitter and the efficacy of the new technique in predicting performance with jitter. y(k)

0.02

D

Sample and hold

0.0625

B

Ti

Variable delay

x(k+1)

A

0.0704

Sampling clock

x(k)

0.0001 Constant

1

Alternative z-1

Fig. 4. Diagram of Alternative delay block

C

COUNTER

DATA COLLECTION

SAMPLING

OPEN USB IO BOARD. Image source: https:// pjradcliffe.files.wordpress.com/2009/03/board_picture.png

Fig. 5. Hardware implementation block diagram

V. DC M OTOR S PEED C ONTROLLER S IMULATION The simulation in Matlab and Simulink was implemented one step at a time. Firstly, a PI controller was built in MATLAB script and Simulink. After that, the hardware limitation features were added in Simulink, for example PWM resolution. Finally, our new technique is applied to enable jitter insertion. The motor and controller parameters are shown in the Appendix session. In Fig. 6 a PI controller is designed to control speed of the DC motor which is characterized in a transfer function. While the transfer function input is voltage, the output is motor’s speed measured by rad/s. The motor speed is captured and feedback to the controller in the loop. Sampling clock

PID(z) Step Input

Voltage (V) Speed (rad/s)

InS/H

PI controller DC Motor Transfer Function

Sample and Hold

Fig. 6. Motor Speed PI controller in Simulink

One of the gaps between simulation and hardware experiment can be the omission of model elements to simulate physical hardware limitations into simulation. Our experience has been that neglecting this reality can produce a simulation that differs wildly from the real hardware. In Fig. 7, hardware limitation elements are added in the feedback path as well as between the controller and motor. The feedback elements quantize the input value to match the speed measuring technique that used a pulse counter. In addition, the 8 bit PWM output of hardware is simulated by adding condition blocks after output of controller to scale the integer 2565

VI. R ESULTS AND D ISCUSSION

Sampling clock

C (z) Step Input

Output 0-255 limitation

PWM quantization

Voltage Speed

PI Controller

Sample and Hold

DC Motor Transfer Function

Feedback quantization

Fig. 7. Motor speed controller model with added hardware limitation

value to be between 0 and 255. The PI controller element is not fully optimized as the aim is to show clearly how jitter may be simulated. Work to this point has simply implemented a control system simulation. The next and crucial step is to implement the variable z −1 delay blocks with jitter that can come from and equation or from an external file. Fig. 8 shows how the jitter is applied both to the sampling of the motor speed (sample and hold 1) and to the PI controller. The jitter is derived from an external spreadsheet file so it is possible to give an arbitrary jitter pattern. Fig. 9 shows how jitter is added to the PI controller block as the single z −1 delay is replaced with the jitter delay version as shown by the dotted box. In effect a z-domain delay z −1 is simulated in the analogue realm using a sample and hold driven by the jittered clock signal. The very small delay via Constant block and the variable delay is necessary to stop any signal propagating through a string of z −1 delays in the one clock cycle. This approach gives the ability to create a variable z −1 delay independent of Matlabs fixed z −1 delay. The jittered z −1 can be placed in a library and reused throughout the simulation anywhere that a jittered z −1 delay is required. Sampling clock with jitter generating from Speadsheet file

clock jitter

In Step Input

Out

Output 0-255 limitation

PWM quantization

PI controller with jitter

Voltage Speed

Sample and Hold

DC Motor Transfer Function

Feedback quantization

Fig. 8. New PI controller block replaced Simulink’s orginal PI controller block, Clock jitter block replaced system sampling block

Clock jitter input

Out

D Sample and Hold

B

In

0.0001 Constant

Ti Variable Time Delay

C

Jittered Z-1

A

Fig. 9. Inside the introduced PI Controller Block Diagram

To judge the behavior of the motor a step input was applied and the motor response recorded. The target speed was switched from 11 revs/second up to 60 revs/second and the motor speed captured. The sample rate was chosen to be quite low, only 10 ms per sample as we are interested in the ability of a very cheap microprocessor to act as a real-time controller. Embedded operating systems such as Linux can also operate around this speed and provide a very inexpensive option for real time control. The jitter in our tests has two key parameters, the first is the amplitude and the second is the pattern. The pattern is the timing relationship between the jitter on successive clock cycles. For example if the regular clock is 10ms then one pattern might be 9ms, 11ms, 9ms 11ms ... In terms of differences to the ideal 10ms period this would be -1ms, +1ms, -1ms, +1ms. Another pattern might be +1ms, +1ms, -1ms, 1ms, +1ms, +1ms, -1ms Random patterns are also possible. The amplitude is the size of the jitter in percent. For the first pattern example given one amplitude might be -2ms,+2ms and another amplitude might be -5ms, +5ms. These have the same pattern but different amplitudes. Many test cases with different jitter patterns and amplitudes are applied in both simulation and experiment. In this discussion two representative patterns will be used, Prand was derived from a random number generator whereas Pspec was a special hand craft version which resulted in poor performance. Each of these patterns was tested with five different levels of jitter; 0%, 10%, 20%, 30% and 40%. The waveforms were recorded for both simulation and the real motor system. As the calculation time is much smaller than the sampling time, we assumed that there is only jitter type 1 in [2] where the sampling interval is varying. Fig. 10 compares the simulation and real system step response with no clock jitter, and the same 40% random jitter using Pspec the overshoot with no jitter is around 16% both for simulation and the real system. The overshoot for 40% jitter is around 30% for simulation and the real system, around twice that for no jitter. There is excellent agreement between the simulation and experiment. The oscillation after the step change is higher for simulation than the real system which shows the simulation is not perfect but still provides useful predictions. Fig. 11 shows a more comprehensive set of tests with more jitter amplitudes for each of the two jitter patterns. Again, the agreement between simulation and experiment is very good. As the jitter amplitude increases so does the overshoot. The results from Prand with random jitter are interesting as high jitter had a relative small effect on overshoot, 0% jitter resulted in around 18% overshoot and 40% jitter resulted in 22% overshoot. The results from Pspec with a specially chosen pattern show a higher 18% overshoot at 0% jitter and 30% at 40% jitter. The difference between Prand and Pspec highlights an important design issue on how jitter patterns are chosen. If chosen at random then the pattern selected may have little effect and simulation will correctly predict only a small change in performance. In reality a pattern may occur which has a much bigger effect and result in performance much worse than the simulation. For the simple control system used in this paper the relative insensitivity of the overshoot to large amounts of jitter is

2566

EXPERIMENT - STEP RESPONSE COMPARISON

70

60

60

50

50

Speed (rev/s)

Speed (rev/s)

SIMULATION - STEP RESPONSE COMPARISON

70

40

30

20

40

30

20

10

10 NO JITTER JITTER 40% - PATTERN Pspec

0 0

0.05

0.1

0.15

0.2

0.25

NO JITTER JITTER 40% - PATTERN Pspec

0 0

0.3

0.05

0.1

Time (s)

0.15

0.2

0.25

0.3

Time (s)

SIMULATIONJ-JSTEPJRESPONSEJ-JJITTERJPrand

EXPERIMENTJ-JSTEPJRESPONSEJ-JJITTERJPrand

60

60

40

NOJJITTERJ

JITTERJ10a JITTERJ20aJ JITTERJ30aJ JITTERJ40aJ

20 0

SpeedJ(rev/s)

SpeedJ(rev/s)

Fig. 10. Comparison between 40% jitter and non-jitter sampling clock. Left figure simulation, Right figure Experiment

0

0.05

0.1

0.15

0.2

0.25

0

SpeedJ(rev/s)

SpeedJ(rev/s)

NOJJITTER

JITTERJ10a JITTERJ20a JITTERJ30a JITTERJ40a

0

0.05

0.1

0.15

0.2

0.25


0

0.05

0.1

0.15

0.2

0.25

0.3

Tim eJ(s) EXPERIMENTJ-JSTEPJRESPONSEJ-JJITTERJPspec

60

20

NOJJITTER

20 0

0.3

Tim eJ(s) SIMULATION-JSTEPJRESPONSEJ-JJITTERJPspec

40

40

60 40

Tim eJ(s)


20 0

0.3

NOJJITTER

0

0.05

0.1

0.15

0.2

Tim eJ(s)

Fig. 11. Comparison between simulation and experiment. Upper figures jitter pattern 1. Bottom figures: Jitter Pattern 2

2567

0.25

0.3

significant. It suggests that a cheaper control system with considerable jitter is quite adequate for this digital controller thus saving cost. This conclusion can be predicted quickly by simulation and help direct the choice of a hardware platform to start development. VII. F UTURE WORK This research points to several areas of future work. It was found that the clock jitter pattern can have a significant effect on performance but it is not clear how to predict or discover the worst-case patterns. It would be interesting to develop such a theory. The simple control system used for this paper showed a high degree of insensitivity to jitter but it was just a simple system. More complex systems and systems which are close to instability may well show a much larger response to jitter which would suggest that a higher quality controller with lower jitter is required. It would be of interest to use our methodology to investigate such systems. One of the aims of this paper is to help real time designers to choose an appropriate hardware platform and operating system early in the design cycle using simulation. The novel simulation method developed is a key enabler of this goal. It has the ability to take the clock jitter pattern from a file. What is missing is a library of jitter patterns from real hardware platforms which can be played into the simulation. In this manner, a designer might quickly gauge the performance of several hardware platforms and select the most appropriate one for development. It would be interesting work to find the quickest and most effective ways to capture jitter from real systems and then replay them into simulation. VIII. C ONCLUSION This paper has developed a novel method that enables a Matlab/Simulink simulation to add realistic clock jitter to a zdomain controller. The key novelty is simulating the z-domain using analogue elements thus allowing a variable z −1 delay element to be created that is independent of the Matlab zdomain clock. The method has been used on a simple DC motor controller and the results of the simulation and the real hardware match quite closely. One interesting discovery is that the pattern of clock jitter is important as well as the amplitude. In the DC motor controller example the clock jitter was moved from 0% to 40%. One pattern resulted in the overshoot rising from 18% to 22%, another pattern had overshoot rising from 18% to 30%. Clearly finding the worst case jitter pattern is important and this will be the subject of future work. The new method will be of great use to real time designers as it allows them to simulate a control system and determine the effect of clock jitter. This will give valuable information as to whether an inexpensive hardware and operating system combination with high jitter is acceptable, or whether a higher cost and higher quality combination is required. We plan to build a library of clock jitter from real hardware platforms under various conditions. This will enable a designer to play this clock jitter into their simulation and see the effects on system performance. Such an approach will make the selection of a hardware and operating system combination even more rapid and reliable.

TABLE I M OTOR PARAMETERS Parameter (J) moment of inertia of the rotor (b) motor viscous friction constant (Ke) electromotive force constant (Kt) motor torque constant (R) electric resistance (L) electric inductance

Value 9 × 10−8 kg.m2 1.026 33 × 10−7 N.m.s 3 × 10−3 V /rad/sec 3 × 10−3 N.m/Amp 1.324 × 101 Ω 3.62 × 10−3 H

The motor transfer function is built based on motor parameters in the Table I (with K = Ke = Kt): P (s) =

rad/sec K ] [ 2 (Js + b)(Ls + R) + K V

(4)

With selected Ki and Kp in Table II, The C(z) digital PI TABLE II PI C ONTROLLER Parameter Kp Ki T s sampling time

Value 0.08 0.9 10 ms

controller is: C(z) = Kp + Ki ∗

T s(z + 1) 0.0445(z − 0.7978) = (5) 2(z − 1) z−1 R EFERENCES

[1] A. Cervin, D. Henriksson, B. Lincoln, J. Eker, and K.-E. rzn, “How does control timing affect performance?” IEEE control systems magazine, vol. 23, no. 3, pp. 16–30, 2003. [2] P. Marti, J. M. Fuertes, G. Fohler, and K. Ramamritham, “Jitter compensation for real-time control systems,” in Proc. 2001 IEEE 22nd RealTime Systems Symposium, 2001, pp. 39–48. [3] T. H. Smilkstein, Jitter reduction on high-speed clock signals. University of California, Berkeley, 2007. [4] G. F. Franklin, J. D. Powell, and M. L. Workman, Digital control of dynamic systems. Addison-wesley Menlo Park, 1998, vol. 3. [5] P. Goddard, “Simulink s-functions - square wave with jitter.” [Online]. Available: http : / / www. goddardconsulting . ca / simulink-sfunction-square-wave-with-jitter.html [6] MathWorks, “Modeling computational delay and sampling effects.” [Online]. Available: http://au.mathworks.com/help/slcontrol/examples/ modeling-computational-delay-and-sampling-effects.html [7] K. Smeds and X. Lu, “Effect of sampling jitter and control jitter on positioning error in motion control systems,” Precision Engineering, vol. 36, no. 2, pp. 175–192, 2012. [8] D. Niculae, C. Plaisanu, and D. Bistriceanu, “Sampling jitter compensation for numeric pid controllers,” in Proc. 2008 IEEE International Conference on Automation, Quality and Testing, Robotics, vol. 2. IEEE, 2008, pp. 100–104. [9] H. Yang, Y. Xia, and P. Shi, “Stabilization of networked control systems with nonuniform random sampling periods,” International Journal of Robust and Nonlinear Control, vol. 21, no. 5, pp. 501–526, 2011. [10] P. Marti, R. Villa, J. M. Fuertes, and G. Fohler, “Stability of on-line compensated real-time scheduled control tasks,” in IFAC Conference on New Technologies for Computer Control, 2001. [11] C. Perera, T. Pearce, and M. Bolic, “A jitter compensating pid controller to mitigate the detrimental effects of software induced jitter in digital control systems,” Journal of Automation and Control Research, vol. 1, 2014. [12] B. Messner and D. Tilbury, “Control tutorials for matlab and simulink -dc motor speed: Digital controller design.” [Online]. Available: http://ctms.engin.umich.edu/CTMS/index.php?example=MotorSpeed& section=ControlDigital [13] P. Radcliffe, “Open-usb-io: A universal i/o solution-an atmel atmega32 micro project for driving a host of digital and analogue i/o,” Everyday Practical Electronics, vol. 40, no. 10, p. 40, 2011.

A PPENDIX This session provide parameters of the motor and PI controller which are used in section IV and V. 2568